From owner-aaa-bof@merit.edu Tue May 1 01:23:31 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08812 for ; Tue, 1 May 2001 01:23:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EA9E15DE0F; Mon, 30 Apr 2001 15:44:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DBC385DDFF; Mon, 30 Apr 2001 15:44:39 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 4409D5DDD5 for ; Mon, 30 Apr 2001 15:44:38 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06358 for ; Mon, 30 Apr 2001 12:44:36 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id MAA08616 for ; Mon, 30 Apr 2001 12:44:34 -0700 (PDT) Message-Id: <200104301944.MAA08616@heliopolis.eng.sun.com> Date: Mon, 30 Apr 2001 12:44:35 -0700 (PDT) From: Jonathan Wood Reply-To: Jonathan Wood Subject: [AAA-WG]: Diameter/SCTP and watchdogs To: aaa-wg@merit.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: z0Nww5e6HJBmOrBwjQwSXQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk Section 7 of the base protocol draft describes watchdogs to detect peer failure. SCTP already has this functionality built in, so when using SCTP, diameter doesn't need to do it too. To this end I suggest that we add some text stating section 7 is needed only when transporting diamter over TCP. Jonathan From owner-aaa-bof@merit.edu Tue May 1 06:08:39 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22566 for ; Tue, 1 May 2001 06:08:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6F81A5E0C2; Tue, 1 May 2001 03:28:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 157EF5DFB5; Tue, 1 May 2001 03:06:12 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 1584E5DEA1 for ; Tue, 1 May 2001 02:41:56 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id XAA97184; Mon, 30 Apr 2001 23:34:27 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Mon, 30 Apr 2001 23:34:27 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Session Movement In-Reply-To: <20010430095343.D3397@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk You may also want to move Acct-Multi-Session-Id. On Mon, 30 Apr 2001, Pat Calhoun wrote: > All, > > A week or so ago, the following text was proposed, and I am now just getting > around to making spec changes, and some questions arose: > > > 11.7 Session Movement > > > > When a user moves between different access devices it may be desirable > > to keep the Session Id unchanged. It is therefore possible for a > > server to send the original Session Id back to the requester in the > > Original-Session-Id AVP. If the AAA server already has a > > sessionidentifier > > how about the following??? > > "11.7 Session Movement > > There are applications that over the course of a session a user MAY > receive service from different access servers. While the service is > relocated, it MAY be desirable for the AAA infrastructure to view this > as a persistent session, as opposed to a new session each time a user is > relocated. In order to support these applications, when an AAA server > identifies that a request is the continuation of an existing session, > it MUST include the original session identifier in the Original-Session-Id > AVP in the corresponding response message to the access device." > > WARNING!!!!!! > > This is really unchartered territory, and we really need to think this one > through. Let's assume, for the moment, that a user's device crashes, and > the mobile re-connects to a new FA. In this case, the AAAF, or AAAH, *could* > believe this is the continuation of an old session. > > If one is billed by time, this is a problem. > > So, I think that additional text is required on when this should be done. > > > [...] > > > 11.8 Session Termination > > > > The Diameter Base Protocol provides a set of messages that MUST be > > used by any peer to explicitly request that a previously > > authenticated and/or authorized session be terminated. Since the > > Session-Id is typically tied to a particular service (i.e. Mobile IP, > > NASREQ, etc), the session termination messages are used to request > > that the service tied to the Session Id be terminated. > > Did you add 11.8 in your e-mail to help me locate where the text should be > added? It appears to be exactly the same as what's in the draft. > > PatC > From owner-aaa-bof@merit.edu Tue May 1 09:37:57 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26750 for ; Tue, 1 May 2001 09:37:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B4AD55DDC6; Tue, 1 May 2001 09:37:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A0AB85DDB8; Tue, 1 May 2001 09:37:40 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 3A87F5DDB7 for ; Tue, 1 May 2001 09:37:39 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA02755; Tue, 1 May 2001 06:37:36 -0700 (PDT) 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 GAA02854; Tue, 1 May 2001 06:37:34 -0700 (PDT) Received: from sunray-mpke (sunray-mpke.Eng.Sun.COM [129.146.6.32]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA02549; Tue, 1 May 2001 06:37:33 -0700 (PDT) Date: Tue, 1 May 2001 06:37:34 -0700 (PDT) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [AAA-WG]: Diamter/SCTP: preventing head-of-the-line blocking To: Yiwen Jiang Cc: "'Jonathan Wood'" , "'aaa-wg@merit.edu'" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > Well, what are the options for a Diameter transport? > > o TCP: doesn't meet all the transport requirements > > o roll-yer-own: this would probably delay diameter by at least a year > > o or SCTP: meets all the transport requirments, and is farther along > > than diameter in the standards process. > But from the I-D, it talks about the fact that TCP is insufficient for > timely detection of failed or unresponsive peers, and hence, SCTP. But as > you pointed out in your original mail, isn't this what the watchdog timer is > used for? Or am I misinterpreting??? TCP implementations that support the Congestion Manager would "probably" work, but what SCTP does provide is a way to retrieve information from the transport for specific sessions, such as RTO. This information is used by the application to detect whether a failover should occur. The failover section is in dire need of a re-write. I believe that once the new draft is available, support for watchdogs will become more obvious. If not, then additional clarifying text will be added. PatC From owner-aaa-bof@merit.edu Tue May 1 11:06:45 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00260 for ; Tue, 1 May 2001 11:06:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 151035E06D; Tue, 1 May 2001 11:00:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 63E925DEA5; Tue, 1 May 2001 10:59:33 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 66D6D5DE55 for ; Tue, 1 May 2001 10:58:05 -0400 (EDT) Received: (qmail 21929 invoked by uid 500); 1 May 2001 14:48:01 -0000 Date: Tue, 1 May 2001 07:48:01 -0700 From: Pat Calhoun To: Jonathan Wood Cc: aaa-wg@merit.edu, Brian.Cain@motorola.com Subject: Re: [AAA-WG]: Diameter/SCTP and watchdogs Message-ID: <20010501074801.G19382@charizard.diameter.org> Mail-Followup-To: Jonathan Wood , aaa-wg@merit.edu, Brian.Cain@motorola.com References: <200104302030.NAA10086@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104302030.NAA10086@heliopolis.eng.sun.com>; from Jonathan.Wood@Sun.COM on Mon, Apr 30, 2001 at 01:30:29PM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, Apr 30, 2001 at 01:30:29PM -0700, Jonathan Wood wrote: > This is one possibility. But there is more than just redundancy > on the network at stake here. Incorporated with the watchdog > functionality is the whole bundle of RTT measurement and RTO > calculation, which can be pretty subtle (how many papers have > been written on this subject? :) and is, I believe, something > best left to the transport layer. It would be nice to not > have to do this at all in Diameter (another argument for moving > to SCTP exculsively). But the reality is that the application must have access to some measurement information in order to make a more intelligent failover decision. The watchdog messages are intended to be used for that purpose, since it is the only message that doesn't get proxies, and can therefore provide the actual application RTT (meaning both transport and application processing) measurements. Also, can one "configure" how SCTP keepalives will be sent? > > Now that I think about it, could we rely on TCP keepalives > for analagous functionality in TCP and get rid of this > altogether? See above, and with TCP, there is no way for the application to specify the frequency of the keepalives, which is necessary for quick failover. PatC From owner-aaa-bof@merit.edu Tue May 1 12:57:08 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03891 for ; Tue, 1 May 2001 12:57:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AFB655DEDE; Tue, 1 May 2001 12:55:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3F6035E094; Tue, 1 May 2001 12:54:49 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 4050F5E2C0 for ; Tue, 1 May 2001 12:53:29 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id MAA17720 for ; Tue, 1 May 2001 12:53:37 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma017717; Tue, 1 May 01 12:53:29 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id MAA05049 for ; Tue, 1 May 2001 12:53:19 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma004935; Tue, 1 May 01 12:52:41 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <2XDRFZMD>; Tue, 1 May 2001 12:52:25 -0400 Message-ID: From: Yiwen Jiang To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: FW: questions and comments regarding the Diameter API draft Date: Tue, 1 May 2001 12:52:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk -----Original Message----- From: Yiwen Jiang Sent: Tuesday, May 01, 2001 10:29 AM To: 'James Kempf'; 'aaa-wg@merit.com' Subject: questions and comments regarding the Diameter API draft Hi James, I have some questions regarding the ID. If you could clarify them, it would be great. My apologies for it being a long mail... Thank you very much! Yiwen - General questions + Language: Why is there a Java API for server? Is C API for server not good enough? 'cause people can use JNI to put a wrapper around the C API. Or is the intent to standardize the server interface despite the fact that C API provides the same functionality? + Callback: Is callback associated with *all* existing commands or is it only have one-to-one mapping with all extension commands? E.g., does it make sense to have a callback for DRI messages which is only used during the peer connection establishment? - Section specific questions: 3 questions for callbacks: + Sec. 3.1.13, Pg. 11. last three paragraphs, description on AAA_APP_INSTALL_FIRST and LAST. "If subsequent callbacks are installed with this code, the callback is moved down/up the list". THis is inconsistent with the description of the callback processing order in section 3.5.4 (pg 39), which says that "If the API client adds another, any existing pre- and post-processors are removed". + Sec. 3.4.2.1, Pg. 20. From the signature of the function, does this mean that there can be > 1 callbacks for the same command, but for different extensions? (an example would be any accounting commands that can be for MIP or NASREQ, etc)? + Sec. 3.5.4, Pg. 40. Last paragraph. Does this imply that the LAST callback is for error handling of message processing (since if ANY completes successful, the LAST callback is not called)? 6 questions for messages: + Sec. 3.2.4, Pg 16. first line, identifier. Is this hop-by-hop ID or End-to-End ID? Shouldn't there be another ID in the message? + Sec. 3.2.4, Pg 16. 4th line, appHandle. Is this handle for user session only? What about peer connection handle? Why would these two handles be handled different? + Sec. 3.4.5.1, Pg. 28. First paragraph. What is the "Initialization-Vector AVP"? I can't find it in the base protocol. (base ID, pg. 24). + Sec. 3.4.5.2, Pg. 28. Shouldn't the signature be: AAAReturnCode AAAFreeMessage(AAAMessage **message) Note: ** instead of *? I would assume that after the successful return, value of message would be NULL.? + Sec. 3.4.5.3, Pg. 29. When would I use the AAARespondToMessage()? Can't I just do: AAANewMessage(); AAASetServer(); AAASendMessage(); ? + Sec. 3.4.6.2, Pg. 36. Why is the AAASendMessage() responsible for assigning the msg ID to the message, wouldn't this be the responsibility of AAANewMessage() function call? Also, what is the server id mentioned in this paragraph? 2 questions on AVPs: + Sec. 3.4.5.9, Pg. 32. Shouldn't this function be associated with AAA_AVP_LIST pointers rather than AAA_AVP pointers? The logic behind having an Extended_AAA_AVP structure specified on Pg 39 is to hide the fact that AVP actually is a node of a doubly linked list. In which case, AAAJoinAVPList() should not be dealing with AAA_AVPs. + Sec. 3.4.5.11, Pg. 33. Shouldn't the avp passed into the function be **? I.e. AAAReturnCode AAAFreeAVP(AAA_AVP **avp) ? Successful return of this function would have avp to be NULL. one question on session: + Sec. 3.4.3.1. THis is to start a user session, and *not* a peer connection, correct? Cheers, Yiwen --- Yiwen Jiang Mobile IP Networking Email: Yiwen.Jiang@tic.siemens.ca Phone: (613)271-7710 Telecom Innovation Centre 505 March Road Kanata, Ontario, Canada K2K 2M5 From owner-aaa-bof@merit.edu Tue May 1 12:58:42 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03918 for ; Tue, 1 May 2001 12:58:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4BCA45DF6F; Tue, 1 May 2001 12:55:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C9E7B5E0E3; Tue, 1 May 2001 12:54:50 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 625B65E2C1 for ; Tue, 1 May 2001 12:53:29 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id MAA17722 for ; Tue, 1 May 2001 12:53:37 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma017718; Tue, 1 May 01 12:53:29 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id MAA05051 for ; Tue, 1 May 2001 12:53:19 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma004937; Tue, 1 May 01 12:52:53 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <2XDRFZM1>; Tue, 1 May 2001 12:52:37 -0400 Message-ID: From: Yiwen Jiang To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: FW: questions and comments regarding the Diameter API draft Date: Tue, 1 May 2001 12:52:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Tuesday, May 01, 2001 12:23 PM To: aaa-wg@merit.com; Yiwen.Jiang@innovation.siemens.ca Subject: Re: questions and comments regarding the Diameter API draft Since I'm doing the Java API, I'll confine my comments to that. > >- General questions > + Language: Why is there a Java API for server? Is C API for server >not good enough? 'cause people can use JNI to put a wrapper around the C >API. Or is the intent to standardize the server interface despite the fact >that C API provides the same functionality? The C API is not cross platform. The Java API is. So requring a JNI wrapper would tie a Java implementation to a particular platform. Allowing a full all Java implementation improves portability. In addition, there is nothing stopping an implementor from implementing the Java server API with a JNI wrapper. The callback functions need to be in Java and not C, which is somewhat cumbersome to program through possible. jak From owner-aaa-bof@merit.edu Tue May 1 13:26:52 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04784 for ; Tue, 1 May 2001 13:26:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D3D065DE55; Tue, 1 May 2001 13:24:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BEAEF5E069; Tue, 1 May 2001 13:24:45 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 5129E5DE55 for ; Tue, 1 May 2001 13:24:41 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19569; Tue, 1 May 2001 10:24:39 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA01779; Tue, 1 May 2001 10:24:38 -0700 (PDT) Message-Id: <200105011724.KAA01779@heliopolis.eng.sun.com> Date: Tue, 1 May 2001 10:24:38 -0700 (PDT) From: Jonathan Wood Reply-To: Jonathan Wood Subject: Re: [AAA-WG]: Diameter/SCTP and watchdogs To: Jonathan.Wood@Sun.COM, pcalhoun@diameter.org Cc: aaa-wg@merit.edu, Brian.Cain@motorola.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: HPJv42HotXalOI9bGzGsbg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk Just in case people are getting confused about terminology: In Diameter they are called watchdogs In SCTP they are called heartbeats in TCP they are called keepalives > >On Mon, Apr 30, 2001 at 01:30:29PM -0700, Jonathan Wood wrote: >> This is one possibility. But there is more than just redundancy >> on the network at stake here. Incorporated with the watchdog >> functionality is the whole bundle of RTT measurement and RTO >> calculation, which can be pretty subtle (how many papers have >> been written on this subject? :) and is, I believe, something >> best left to the transport layer. It would be nice to not >> have to do this at all in Diameter (another argument for moving >> to SCTP exculsively). > >But the reality is that the application must have access to some >measurement information in order to make a more intelligent >failover decision. Remember that this is the whole point of RTO calculation by the transport layer: when can we reasonably decide that a peer is down? SCTP is flexible enough that the application layer should be able to tune some parameters, and leave the rest up to SCTP. >The watchdog messages are intended to be used >for that purpose, since it is the only message that doesn't get >proxies, and can therefore provide the actual application RTT (meaning >both transport and application processing) measurements. Perhaps I am way off base here, but I would be surprised if, in practice, the the cost of application processing for watchdogs actually became significant for RTT measurements. Furthermore (and now I may be heading too much into implementation-detail land), for resource efficiency reasons you often don't want an otherwise idle application periodically waking up. Ultimately transports like SCTP will be in the kernel, so they won't cause app wakeups for heartbeats. > >Also, can one "configure" how SCTP keepalives will be sent? Yes. >> >> Now that I think about it, could we rely on TCP keepalives >> for analagous functionality in TCP and get rid of this >> altogether? > >See above, and with TCP, there is no way for the application to >specify the frequency of the keepalives, which is necessary for >quick failover. > Actually some platforms do allow you to configure keepalive frequency. However, it is non-standard, so there would be code-portability issues. So for TCP I see a case for leaving in watchdogs, but for SCTP I still think it makes sense to turn them off and make use of SCTP heartbeats. From owner-aaa-bof@merit.edu Tue May 1 14:17:49 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06458 for ; Tue, 1 May 2001 14:17:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C0B905DFE6; Tue, 1 May 2001 14:15:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A26D75DFEF; Tue, 1 May 2001 14:15:39 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 2A2D75DFF9 for ; Tue, 1 May 2001 14:15:36 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id OAA18444; Tue, 1 May 2001 14:15:50 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma018440; Tue, 1 May 01 14:15:45 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id OAA13127; Tue, 1 May 2001 14:15:29 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma013071; Tue, 1 May 01 14:14:19 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <2XDRFZ3D>; Tue, 1 May 2001 14:14:04 -0400 Message-ID: From: Yiwen Jiang To: "'Pat Calhoun'" Cc: "'Jonathan Wood'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Diamter/SCTP: preventing head-of-the-line blocking Date: Tue, 1 May 2001 14:14:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, > TCP implementations that support the Congestion Manager would > "probably" work, > but what SCTP does provide is a way to retrieve information > from the transport > for specific sessions, such as RTO. This information is used by the > application to detect whether a failover should occur. > > The failover section is in dire need of a re-write. I believe > that once the > new draft is available, support for watchdogs will become > more obvious. I guess it is just not very clear to me why TCP is mentioned in the draft then. If TCP truely does not satisfy the requirements for Diameter, then shouldn't the draft focus on SCTP only, and not worry about the watchdog at all? If TCP is discussed in the ID because of the unavaiablility of SCTP implementations, should there not be a separate section discussing features required because of TCP, so that later on, when a stable SCTP implementation is available, it would be easier to remove these additional features? Or am I completely off the base here? From owner-aaa-bof@merit.edu Tue May 1 14:40:38 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07120 for ; Tue, 1 May 2001 14:40:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 32BEA5DD9E; Tue, 1 May 2001 09:10:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2210F5DDD6; Tue, 1 May 2001 09:10:50 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 3BF7F5DD9E for ; Tue, 1 May 2001 09:10:48 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id JAA15592; Tue, 1 May 2001 09:10:56 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma015590; Tue, 1 May 01 09:10:49 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id JAA10954; Tue, 1 May 2001 09:10:39 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma010710; Tue, 1 May 01 09:09:34 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <2XDRFZ1D>; Tue, 1 May 2001 09:09:19 -0400 Message-ID: From: Yiwen Jiang To: "'Jonathan Wood'" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Diamter/SCTP: preventing head-of-the-line blocking Date: Tue, 1 May 2001 09:09:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Jonathan, > >There is really no stable SCTP implementation out there > avaiable for us to > >do development on (kernel or user land implementation). In > addition, it is > > That depends on your definition of stable. For development purposes, > I would say that the following publicly available implementations > are stable enough: > > http://www.sctp.de/ > Userland, runs under Linux, FreeBSD and Mac OS X and > supports IPv4 > and IPv6. I spent some time looking at this user land implementation. It does not cover many error conditions. I was told by Michael Tuexen that him and Andreas were only interested in the protocol itself, rather than error handlings of the software. For example, up until their latest release, (sctplib-1.0.0-pre9) if both peer are trying to initiate a connection at the same time, one peer will be successful, the other will return fail. Of course, this bug will probably be fixed in the next release, but this tells me something about the implementation. In the mean time, I'm not a believer of using a user land implementation for level 3 protocol.. > http://people.cs.uchicago.edu/~piggy/sctp_chicago_il_us/ > Userland / Kernel hybrid, runs on FreeBSD > http://playground.sun.com/sctp/ > Solaris kernel These are on my investigation list.... I think Piggy's version also runs on Linux (kernel) as well. > >my impression that the RFC is still not that stable (e.g. > the recently > >discovered Adler32 checksum weakness), why is SCTP a mandate for the > >Diameter base protocol? Sure it provides us many desirable > features, but if > >there is no publicly available implementation out there, how > can we support > >this? Or is the current mandate only to look at using future > possibilities > >at a theorotical level? > > Well, what are the options for a Diameter transport? > o TCP: doesn't meet all the transport requirements > o roll-yer-own: this would probably delay diameter by at least a year > o or SCTP: meets all the transport requirments, and is farther along > than diameter in the standards process. But from the I-D, it talks about the fact that TCP is insufficient for timely detection of failed or unresponsive peers, and hence, SCTP. But as you pointed out in your original mail, isn't this what the watchdog timer is used for? Or am I misinterpreting??? Yiwen > Jonathan > > > > >Cheers, > >Yiwen > >--- > >Yiwen Jiang > >Mobile IP Networking > >Email: Yiwen.Jiang@tic.siemens.ca > >Phone: (613)271-7710 > > > >Telecom Innovation Centre > >505 March Road > >Kanata, Ontario, Canada > >K2K 2M5 > > > > > >> -----Original Message----- > >> From: Jonathan Wood [mailto:Jonathan.Wood@Sun.COM] > >> Sent: Monday, April 30, 2001 4:15 PM > >> To: aaa-wg@merit.edu > >> Subject: [AAA-WG]: Diamter/SCTP: preventing > head-of-the-line blocking > >> > >> > >> > >> While SCTP has built in support for preventing head- > >> of-the-line blocking, there is currently no provision > >> in the diameter spec to utilize this functionality. > >> This means that Diameter/SCTP at present has the > >> same head-of-the-line blocking problems as Diamter/ > >> vanilla TCP. > >> > >> We can easily use SCTP streams to fix this. I propose > >> the following: > >> > >> Each diameter node should stripe its messages across > >> the range of SCTP streams that it and its peer have > >> agreed upon. (A lost message in one stream will not > >> cause any other streams to block.) A trivial and > >> effective implementation of this simply increments > >> a counter for the stream ID to send on. When the > >> counter reaches the maximum number of streams for > >> the association, it resets to 0. > >> > >> Diameter peers must be able to accept messages on > >> any stream. Note that streams are used *solely* to > >> prevent head-of-the-line blocking. All identifying > >> information is carried within the diamter payload. > >> > >> SCTP peers can allocate up to 65535 streams for an > >> association. The cost for idle streams may or may not > >> be zero, and the cost for non-idle streams is always > >> greater than 0. So administrators may wish to limit > >> the number of possible streams on their diameter nodes > >> according to the resources (i.e. memory, CPU power, etc.) > >> of a particular node. > >> > >> Stream IDs do not need to be preserved by proxies. For > >> example, consider the following case, where B serves > >> as a proxy between A and C: > >> > >> A --------------------- B -------------------- C > >> 1000 streams 2000 streams > >> > >> msg 1: str id 0 msg 1: str id 0 > >> msg 2: str id 1 msg 2: str id 1 > >> ... ... > >> msg 1000: str id 999 msg 1000: str id 999 > >> msg 1001: str id 0 msg 1001: str id 1000 > >> > >> The striping acts sort of like a hash table. It is > >> possible, yet unlikely, that two messages will end > >> up in the same stream, and even less likely that > >> there will be message loss resulting in blocking when > >> this happens. If it does turn out to be a problem, local > >> administrators can increase the number of streams on > >> their nodes to improve performance. > >> > >> Questions / comments? > >> > >> Jonathan > >> > >> > >> > >> > > > From owner-aaa-bof@merit.edu Tue May 1 20:24:12 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12868 for ; Tue, 1 May 2001 20:24:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A40845E149; Tue, 1 May 2001 20:20:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 440885E094; Tue, 1 May 2001 20:16:11 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id EC7195E00C for ; Tue, 1 May 2001 20:14:38 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id UAA10980; Tue, 1 May 2001 20:07:04 -0400 (EDT) Message-Id: <4.1.20010501195012.017b29b0@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 01 May 2001 19:54:38 -0400 To: aaa-wg@merit.edu, Patrice Calhoun From: Paul Funk Subject: [AAA-WG]: Grouped AVPs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Though it is perhaps ambiguous in the base draft, the intent of the grouped type is to allow only a fixed set of AVPs in a specified order within any particular grouped AVP. I think this severely limits the usefulness of grouped AVPs and is contrary to the spirit of extensibility which characterizes Diameter. And what a waste of bits it is to use a self-describing format to encapsulate what amounts to a fixed structure. Diameter as currently defined is a hierarchical, self-describing data modeling language with extensibility at the top level, and calcification into fixed structures thereafter. If ASN.1, XML or LDAP had such limitations, they would never have achieved success. One need look no further than the original RADIUS grouping mechanism to see why fixed structures is a bad idea. In RADIUS, tunnel attributes are tagged to allow related attributes to be grouped. In Diameter, this is accomplished by including all values for a particular tunnel within the grouped Tunnel AVP. But in RADIUS, it is possible to omit particular tunnel attributes, or define new ones as required. In Diameter, it is not. Another example is the Redirect-Host AVP, comprising one AVP for address and another for port. But the draft vacillates, saying that if only address is required, it may be sent ungrouped. The draft also states that the redirect may also include certificates for the home server. But if different certificates are required for different servers, how would you associate the certificate with the address/port it applies to? Better would to require redirect destinations to be specified only one way -- within the grouped Redirect-Host AVP, allow it to contain an address and optionally a port, and let it be extensible to contain a certificate reference or any other information that may be required in the future. I suggest that we allow a grouped AVP to be defined as restrictively or as liberally as we allow Diameter messages to be defined. Thus, the ABNF for a grouped AVP could contain sequence rules or not, could contain optional attributes or not, could contain the wildcard [AVP] or not, etc. In general, the liberal approach should be used, unless there is a really good reason to fix the contents of a group. An additional benefit of this approach is that it makes it possible to define an AVP as a homogeneous list of AVPs, simply by defining its ABNF as *[Some-AVP]. Should the group agree, here's some suggested language: Every Grouped AVP defined MUST include a corresponding ABNF specification, which is used to define the AVPs that MUST, MAY and MUST NOT be present. The format to be used follows the format for Command Code ABNF specifications (3.2), with the following additional definition: group-def = AVP-name "::=" [*fixed] [*required] [*optional] [*fixed] It is possible to include an AVP with a Grouped type within a Grouped type, that is, to nest them. AVPs within an AVP of type Grouped have the same padding requirements as non-Grouped AVPs, as defined in section 4.0. Example: group-def ::= example-avp {Origin-FQDN} {Host-IP-Address} *[AVP] Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Tue May 1 20:25:55 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12901 for ; Tue, 1 May 2001 20:25:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8CD3B5DF2E; Tue, 1 May 2001 20:22:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2356E5DF42; Tue, 1 May 2001 20:21:57 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 5CA5A5E09F for ; Tue, 1 May 2001 20:18:47 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id UAA10988; Tue, 1 May 2001 20:11:12 -0400 (EDT) Message-Id: <4.1.20010501195709.017b4e90@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 01 May 2001 19:58:47 -0400 To: aaa-wg@merit.edu, Patrice Calhoun From: Paul Funk Subject: [AAA-WG]: Session Termination Issues Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk I have several issues/questions relating to session termination. Clarity of the draft -------------------- I think that the draft (11.8) can give the impression that session termination has to do only with explicit termination at the request of the server (STI), and the STR/STA is merely a means of acknowledgement. My understanding of the actual intent is that whenever a session terminates, the client is supposed to issue an STR to notify the server. The server is not meant to rely on accounting for such notifications. Thus, session termination serves two purposes -- to allow the client to notify the server of session state and to allow the server to explicitly terminate a session. If so, this should be made explicit. Use of STR as indirect means of acknowledging STI ------------------------------------------------- I think that the mechanism of issuing an STI to explicitly terminate a session and relying on STR/STA to acknowledge is problematic. First, it is unnatural. Unlike a two-way transaction, there is no guarantee of a response. The server simply hopes to receive an STR. The STR is a SHOULD, not a MUST, so it may not be forthcoming. And what if the session is not active -- does the client lie and issue an STR anyway? If the server does not see an STR, should it retry the STI? Second, what if the server that issues the STI is not the authenticating server? For example, you might want to maintain a server whose whole job is to kick people off the network. This forces the client to send an STR to the authenticating server, who is holding resources, as well as to the terminator server. This is outside the normal flow of processing. Instead of an Indication, why not use Request/Answer to kill a session? There's no law that says requests can only flow downstream. That way, the terminator server gets the result of its request in a natural way, and the client simply issues the STR to the authenticating server as it would do anyway. Sessions that don't start ------------------------- A Diameter client may issue a request, get an accept and then decide not to start the session, for whatever reason. The Diameter server will not know that the session was not started unless the client tells it. I think the draft should be explicit about this case, and specify that a client must issue a Session-Terminate-Request for sessions that are never started, as well as sessions that terminate normally. In fact, it might be prudent to add a Termination-Cause AVP that indicates the reason for termination, e.g., user logoff, administrative, non-start, etc. Sessions that time out ---------------------- The draft provides that a server must automatically release resources for a session that times out due to Session-Timeout or Authorization-Lifetime. But is the client also required to issue a Session-Terminate-Request in this case? Doing so may not be necessary, strictly speaking, but it might be advisable to require it in any case. Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Tue May 1 20:33:30 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13029 for ; Tue, 1 May 2001 20:33:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7A3E95E1C9; Tue, 1 May 2001 20:29:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 660EB5E0C1; Tue, 1 May 2001 20:29:21 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 9B9FB5E1C9 for ; Tue, 1 May 2001 20:29:17 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id UAA11017; Tue, 1 May 2001 20:21:42 -0400 (EDT) Message-Id: <4.1.20010501200718.017bda20@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 01 May 2001 20:09:17 -0400 To: aaa-wg@merit.edu, Patrice Calhoun From: Paul Funk Subject: [AAA-WG]: Indications and three-legged transactions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Indications are different from other types of messages in that they can be issued in any of three legs of a transaction: by the originator, by the responder, or by the originator after receiving a response it doesn't understand. This poses a problem for interpreting the Identifier. In some cases, the Identifier in an Indication was manufactured by the sender, in some cases by the receiver. In the case of two-legged transactions, the ownership of the Identifier can at least be distinguished, since different Indication messages are issued by originators and responders. But in the case of a three-legged transaction, it can be ambiguous. An MRI can be issued by the responder if it doesn't understand an request AVP, or by the originator if it doesn't understand an answer AVP. But in both cases the Identifier is the one created by the originator. Thus, when you receive an MRI, you can't tell if it's your Identifier or the other guy's. For example, suppose A sends B a request with A's Identifier = 10 and gets an MRI in response, Meanwhile, B sends A a separate request with B's Identifier = 10, gets an answer containing an unknown AVP, and sends an MRI back to A. Now A has received two MRIs, each with Identifier = 10 and can't tell them apart. Another problem with three-legged transactions is that you have to make real sure you won't respond to an MRI with another MRI, otherwise you'll get two servers with a lot to say to each other. I'm not sure why we need three-legged transactions at all. When a server finds out its answer was rejected, what is it expected to do? Is it supposed to learn which AVPs the client doesn't like and make them non-mandatory? Is it supposed to locate the session that it thought had started and release it? Better would be to have the client just issue an STR indicating that the session is terminated (or was not started). At some point a human being will have to notice and perform some reconfiguration. If it is felt that debugging information at the server side is necessary, we should define a separate Indication (e.g., Reply-Reject-Indication) that the client issues with a completely new Identifier (that is, unrelated to the original request) that simply allows the server to log the fact that this client doesn't understand a particular AVP and is not starting sessions because of it. Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Tue May 1 20:39:37 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13092 for ; Tue, 1 May 2001 20:39:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 29C5E5DF89; Tue, 1 May 2001 20:33:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6BF1E5E14A; Tue, 1 May 2001 20:33:01 -0400 (EDT) Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 8C3945E150 for ; Tue, 1 May 2001 20:32:54 -0400 (EDT) Received: (qmail 29806 invoked by uid 500); 2 May 2001 00:37:19 -0000 Date: Tue, 1 May 2001 19:37:19 -0500 From: David Frascone To: Paul Funk Cc: aaa-wg@merit.edu, Patrice Calhoun Subject: Re: [AAA-WG]: Grouped AVPs Message-ID: <20010501193718.A29008@newman.frascone.com> Mail-Followup-To: Paul Funk , aaa-wg@merit.edu, Patrice Calhoun References: <4.1.20010501195012.017b29b0@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010501195012.017b29b0@cairo.funk.com>; from paul@funk.com on Tue, May 01, 2001 at 07:54:38PM -0400 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk I can not agree with you more. I love the idea of grouped AVPs, but I am very much against the strict ordering and format of them. A grouped avp shoud be as extensible as the Diameter message itself. -Dave On Tue, May 01, 2001 at 07:54:38PM -0400, Paul Funk wrote: > Though it is perhaps ambiguous in the base draft, the > intent of the grouped type is to allow only a fixed set > of AVPs in a specified order within any particular > grouped AVP. > > I think this severely limits the usefulness of grouped > AVPs and is contrary to the spirit of extensibility > which characterizes Diameter. And what a waste of bits > it is to use a self-describing format to encapsulate > what amounts to a fixed structure. > > Diameter as currently defined is a hierarchical, > self-describing data modeling language with extensibility > at the top level, and calcification into fixed structures > thereafter. If ASN.1, XML or LDAP had such limitations, > they would never have achieved success. > > One need look no further than the original RADIUS > grouping mechanism to see why fixed structures is a bad > idea. > > In RADIUS, tunnel attributes are tagged to allow related > attributes to be grouped. In Diameter, this is > accomplished by including all values for a particular > tunnel within the grouped Tunnel AVP. But in RADIUS, > it is possible to omit particular tunnel attributes, or > define new ones as required. In Diameter, it is not. > > Another example is the Redirect-Host AVP, comprising > one AVP for address and another for port. But the > draft vacillates, saying that if only address is > required, it may be sent ungrouped. The draft also > states that the redirect may also include certificates > for the home server. But if different certificates are > required for different servers, how would you > associate the certificate with the address/port it > applies to? Better would to require redirect > destinations to be specified only one way -- within > the grouped Redirect-Host AVP, allow it to contain > an address and optionally a port, and let it be > extensible to contain a certificate reference or any > other information that may be required in the future. > > I suggest that we allow a grouped AVP to be defined > as restrictively or as liberally as we allow Diameter > messages to be defined. Thus, the ABNF for a grouped > AVP could contain sequence rules or not, could contain > optional attributes or not, could contain the wildcard > [AVP] or not, etc. In general, the liberal approach > should be used, unless there is a really good reason to > fix the contents of a group. > > An additional benefit of this approach is that it makes > it possible to define an AVP as a homogeneous list of > AVPs, simply by defining its ABNF as *[Some-AVP]. > > Should the group agree, here's some suggested language: > > Every Grouped AVP defined MUST include a corresponding ABNF > specification, which is used to define the AVPs that MUST, MAY and > MUST NOT be present. > > The format to be used follows the format for Command Code ABNF > specifications (3.2), with the following additional definition: > > group-def = AVP-name "::=" [*fixed] [*required] [*optional] [*fixed] > > It is possible to include an AVP with a Grouped type within a > Grouped type, that is, to nest them. AVPs within an AVP of type > Grouped have the same padding requirements as non-Grouped AVPs, as > defined in section 4.0. > > Example: > > group-def ::= example-avp > {Origin-FQDN} > {Host-IP-Address} > *[AVP] > > Paul Funk > Funk Software, Inc. > 617 497-6339 > paul@funk.com > > From owner-aaa-bof@merit.edu Wed May 2 00:10:32 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17490 for ; Wed, 2 May 2001 00:10:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CDB815DEA3; Wed, 2 May 2001 00:01:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D0AE05DF61; Wed, 2 May 2001 00:01:18 -0400 (EDT) Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id F0D6C5E0CE for ; Wed, 2 May 2001 00:01:03 -0400 (EDT) Received: (qmail 8392 invoked by uid 500); 2 May 2001 04:05:35 -0000 Date: Tue, 1 May 2001 23:05:34 -0500 From: David Frascone To: aaa-wg@merit.edu, diameter@diameter.org Subject: [AAA-WG]: Re: questions and comments regarding the Diameter API draft Message-ID: <20010501230534.C29008@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu, diameter@diameter.org 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 Below are responses from the three original authors. There are some un- answered questions for the WG. > > I have some questions regarding the ID. If you could clarify them, it would > be great. My apologies for it being a long mail... > > Thank you very much! > > Yiwen > > - General questions > + Language: Why is there a Java API for server? Is C API for server > not good enough? 'cause people can use JNI to put a wrapper around the C > API. Or is the intent to standardize the server interface despite the fact > that C API provides the same functionality? > + Callback: Is callback associated with *all* existing commands or > is it only have one-to-one mapping with all extension commands? E.g., does > it make sense to have a callback for DRI messages which is only used during > the peer connection establishment? The Sun aaa server handles DRIs itself. But, there is no reason why another server's applications can't register for all messages, including DRIs. > - Section specific questions: > 3 questions for callbacks: > + Sec. 3.1.13, Pg. 11. last three paragraphs, description on > AAA_APP_INSTALL_FIRST and LAST. "If subsequent callbacks are installed with > this code, the callback is moved down/up the list". THis is inconsistent > with the description of the callback processing order in section 3.5.4 (pg > 39), which says that "If the API client adds another, any existing pre- and > post-processors are removed". The document needs to be updated. If another application requests first or last and the slot is already in use, then an error should be returned. > > + Sec. 3.4.2.1, Pg. 20. From the signature of the function, does > this mean that there can be > 1 callbacks for the same command, but for > different extensions? (an example would be any accounting commands that can > be for MIP or NASREQ, etc)? yes that is correct. > + Sec. 3.5.4, Pg. 40. Last paragraph. Does this imply that the LAST > callback is for error handling of message processing (since if ANY completes > successful, the LAST callback is not called)? This is correct. If a callback returns a successful return code, it implies to the library that the message was locally consumed, and therefore it isn't processed by any other callbacks. So returning a success is only done in few instances. > 6 questions for messages: > + Sec. 3.2.4, Pg 16. first line, identifier. Is this hop-by-hop ID > or End-to-End ID? Shouldn't there be another ID in the message? Yes, there needs to be another identifier added. The API is slightly behind the AAA specification. > + Sec. 3.2.4, Pg 16. 4th line, appHandle. Is this handle for user > session only? What about peer connection handle? Why would these two handles > be handled different? The API is slightly behind the AAA specification, in reguards to sessions. > + Sec. 3.4.5.1, Pg. 28. First paragraph. What is the > "Initialization-Vector AVP"? I can't find it in the base protocol. (base ID, > pg. 24). The API is slightly behind the AAA specification. The document will be updated. > + Sec. 3.4.5.2, Pg. 28. Shouldn't the signature be: > AAAReturnCode AAAFreeMessage(AAAMessage **message) > Note: ** instead of *? I would assume that after the successful return, > value of message would be NULL.? This question has fostered much debate between the authors. For now, our implementation takes an AAAMessage *, and it is the application's duty to make sure that he null's his own pointer (just like calling free()). But, if you feel otherwise, this would be a good question for the aaa-wg list. > + Sec. 3.4.5.3, Pg. 29. When would I use the AAARespondToMessage()? > Can't I just do: > AAANewMessage(); > AAASetServer(); > AAASendMessage(); Yes, but AAARespondToMessage will set the flags right (indicating a response), and will include any Proxy-State type information that the application shouldn't have to mess with. > + Sec. 3.4.6.2, Pg. 36. Why is the AAASendMessage() responsible for > assigning the msg ID to the message, wouldn't this be the responsibility of > AAANewMessage() function call? Also, what is the server id mentioned in this > paragraph? Actually that is not a bad idea. > > 2 questions on AVPs: > + Sec. 3.4.5.9, Pg. 32. Shouldn't this function be associated with > AAA_AVP_LIST pointers rather than AAA_AVP pointers? The logic behind having > an Extended_AAA_AVP structure specified on Pg 39 is to hide the fact that > AVP actually is a node of a doubly linked list. In which case, > AAAJoinAVPList() should not be dealing with AAA_AVPs. It would be perfectly acceptable to have the function deal with AVPLists (and I thought it did). > > > + Sec. 3.4.5.11, Pg. 33. Shouldn't the avp passed into the function > be **? I.e. > AAAReturnCode AAAFreeAVP(AAA_AVP **avp) See my comments above. Currently, our api DOES pass a **, which is very ugly compared to AAAFreeMessage (and departs from the API). Definately one of the styles needs to be chosen. Again, this is a WG opinion question > ? Successful return of this function would have avp to be NULL. > > one question on session: > + Sec. 3.4.3.1. THis is to start a user session, and *not* a peer > connection, correct? > Correct. There is no way to kick start a peer connection via the API. This is transparent to the application. From owner-aaa-bof@merit.edu Wed May 2 00:31:53 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17734 for ; Wed, 2 May 2001 00:31:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1201E5E197; Tue, 1 May 2001 20:24:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8DCA05E19E; Tue, 1 May 2001 20:24:28 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 249895E019 for ; Tue, 1 May 2001 20:23:35 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id UAA10995; Tue, 1 May 2001 20:16:00 -0400 (EDT) Message-Id: <4.1.20010501200021.01798580@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 01 May 2001 20:03:35 -0400 To: aaa-wg@merit.edu, Patrice Calhoun From: Paul Funk Subject: [AAA-WG]: Vendor-Specific Values Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk I'd like to trot out a suggestion that was first made within the RADIUS group. A "Vendor-Specific Value" is an AVP whose attribute is a standard one but whose value has semantics defined by a particular vendor. Such extensibility is useful for Unsigned32 types that are really enumerations, such as Service-Type and Accounting-Record-Type. For example, a vendor may offer services other than "Login", "Framed", etc., and may wish to extend the Service-Type AVP with the values it requires. Or, a vendor may wish to define an Accounting-Record-Type other than start, stop, etc. Vendors and service providers routinely have such requirements, have always satisfied these requirements by defining what they pleased, and have not always bothered to go to IANA for permission. One might argue that the workaround is to define the enumerations within a separate VSA. But this is problematic for a couple reasons. First, it is useful for a Diameter server to recognize that a particular value is a Service-Type naturally, without having to figure out that Acme-Service-Type carries service type information. Second, and more problematic, is that AVPs such as Service-Type and Accounting-Record-Type are defined as required AVPs within the Diameter command, and any vendor that replaced these AVPs with their own would be instantly non-compliant. By adopting VSVs there is an added benefit that relates specifically to Diameter: Currently, the only way for a vendor to define a new extension is to apply to the IANA. But by allowing VSVs, any vendor would be able to define its own values for Extension-Id. I think this ability is critical to motivate widespread use of Diameter for new applications. Command codes and attributes are already extensible by vendors, but enumerated values and extensions are not. VSVs effectively make Diameter completely vendor- extensible, at the cost of a single bit in the AVP Flags. Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Wed May 2 09:07:12 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09221 for ; Wed, 2 May 2001 09:07:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 289EA5DF1D; Tue, 1 May 2001 18:13:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7A4DE5E23F; Tue, 1 May 2001 17:58:16 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 6CA405E226 for ; Tue, 1 May 2001 17:38:57 -0400 (EDT) Received: (qmail 7119 invoked by uid 500); 1 May 2001 21:28:52 -0000 Date: Tue, 1 May 2001 14:28:52 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Cc: aboba@internaut.com, davemitton@nortelnetworks.com, smb@att.com Subject: [AAA-WG]: End-to-End Security Extension Message-ID: <20010501142852.D4672@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu, aboba@internaut.com, davemitton@nortelnetworks.com, smb@att.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, The Diameter End-to-End Security Extension, previously called strong security, has been sent to the secretariat for publication as a WG document. A preview of the document can be found at http://www.diameter.org/draft-ietf-aaa-diameter-e2e-sec-00.txt Comments would be most appreciated. PatC From owner-aaa-bof@merit.edu Wed May 2 10:52:56 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13557 for ; Wed, 2 May 2001 10:52:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CD6535DEEC; Wed, 2 May 2001 10:45:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BC3455DEEB; Wed, 2 May 2001 10:45:55 -0400 (EDT) Received: from hindon.hss.co.in (unknown [202.54.26.202]) by segue.merit.edu (Postfix) with ESMTP id EA9CD5DEE2 for ; Wed, 2 May 2001 10:45:50 -0400 (EDT) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f42El5I11926 for ; Wed, 2 May 2001 20:17:06 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A40.004FC6BD ; Wed, 2 May 2001 20:01:22 +0530 X-Lotus-FromDomain: HSS From: sargupta@hss.hns.com To: aaa-wg@merit.edu Message-ID: <65256A40.004FC62F.00@sandesh.hss.hns.com> Date: Wed, 2 May 2001 20:08:48 +0530 Subject: [AAA-WG]: Radius Accounting Client Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Can anybody tell, where I can find a Radius Accounting Client Software?? Regards Sarika From owner-aaa-bof@merit.edu Wed May 2 10:56:36 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13699 for ; Wed, 2 May 2001 10:56:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 675D35DEE5; Wed, 2 May 2001 10:54:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 50BF65DE67; Wed, 2 May 2001 10:54:11 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id BC17E5DDF6 for ; Wed, 2 May 2001 10:54:09 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16359; Wed, 2 May 2001 07:54:06 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id HAA27727; Wed, 2 May 2001 07:54:05 -0700 (PDT) Message-Id: <200105021454.HAA27727@heliopolis.eng.sun.com> Date: Wed, 2 May 2001 07:54:05 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft To: dave@frascone.com, aaa-wg@merit.edu, diameter@diameter.org, Yiwen.Jiang@tic.siemens.ca MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: jrONYEhba7573C6FA6it5A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk Yiwen, >I read some thread in the mailing list earlier that the configuration file >was taken out of the I-D on purpose to allow flexible user defined >configuration. The end result, from my interpretation to the thread, was >that the configuration file was going to be put back in again, but only one >file is. Could you verify this for me please? > In the current draft, there is no requirement for configuration files for the C library. This is because different operating system platforms may have different requirements. However, in the case of Java, it is very likely that people will write portable modules that can be used on a variety of different platforms. Since command and AVP parsing is driven by the command configuration file, a standardized configuration file is required for cross-platform compatibility. jak From owner-aaa-bof@merit.edu Wed May 2 11:11:50 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14285 for ; Wed, 2 May 2001 11:11:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BDB015DE01; Wed, 2 May 2001 11:10:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A95515DDDF; Wed, 2 May 2001 11:10:30 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id DFEEA5DD8E for ; Wed, 2 May 2001 11:10:28 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id LAA01487; Wed, 2 May 2001 11:09:57 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma001482; Wed, 2 May 01 11:09:35 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id LAA06145; Wed, 2 May 2001 11:09:35 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma005992; Wed, 2 May 01 11:08:58 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <2XDRF5FT>; Wed, 2 May 2001 11:08:42 -0400 Message-ID: From: Yiwen Jiang To: "'James Kempf'" , dave@frascone.com, aaa-wg@merit.edu, diameter@diameter.org Subject: RE: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Date: Wed, 2 May 2001 11:08:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi James, > In the current draft, there is no requirement for configuration files > for the C library. This is because different operating system > platforms > may have different requirements. I can see for the general aaa.conf file, the different OS may have different way of describing the file path, but I would argue that the dictionary file should exist regardless of the OS. It is up to the implementor to ensure the AVP types are actually supported. This is because there are already well-defined AVPs and its types and for some, possible values. Or am I missing something here? From owner-aaa-bof@merit.edu Wed May 2 12:00:16 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15548 for ; Wed, 2 May 2001 12:00:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CADFB5DE96; Wed, 2 May 2001 10:35:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 771835DF15; Wed, 2 May 2001 10:34:26 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id D28755E1DD for ; Wed, 2 May 2001 10:28:16 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id KAA00902; Wed, 2 May 2001 10:27:44 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma000897; Wed, 2 May 01 10:27:25 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id KAA29875; Wed, 2 May 2001 10:27:24 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma029559; Wed, 2 May 01 10:26:25 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <2XDRF5DM>; Wed, 2 May 2001 10:26:09 -0400 Message-ID: From: Yiwen Jiang To: "'David Frascone'" , aaa-wg@merit.edu, diameter@diameter.org Subject: RE: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Date: Wed, 2 May 2001 10:26:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Thanks for the comments, Dave. I forgot to list some questions/comments about the configuration files in my last mail. SO here it is, followed by my comments to your reply. Yiwen I read some thread in the mailing list earlier that the configuration file was taken out of the I-D on purpose to allow flexible user defined configuration. The end result, from my interpretation to the thread, was that the configuration file was going to be put back in again, but only one file is. Could you verify this for me please? Another comment I have regarding Sec. 2.2.3 was the use of "value" in the configuration file. I went through the dictionary file that was provided by the Sun's aaa server, and it seems that the "value" for AVPs in the dictionary file is actually the AVP code. This is quite confusing with the actual value of the AVP, which should be assigned by the server application/extension when messages are created, rather than from the configuration file. Is there any chance we can change the word "value" to "code" in the AVP definitions? (Sec. 2.2.3.1).. I'm assuming the value definition in Sec. 2.2.3.2 is the valid values for various AVPs described in the AVP definitions earlier in the dictionary? > > + Callback: Is callback associated with *all* existing > commands or > > is it only have one-to-one mapping with all extension > commands? E.g., does > > it make sense to have a callback for DRI messages which is > only used during > > the peer connection establishment? > > The Sun aaa server handles DRIs itself. But, there is no reason why > another server's applications can't register for all messages, > including DRIs. If a server's application does register callback for message such as DRI, one would assume that the callback for DRI is invoked *after* the action in the state machine is processed, right? If so, could we add that in the I-D? > > + Sec. 3.1.13, Pg. 11. last three paragraphs, description on > > AAA_APP_INSTALL_FIRST and LAST. "If subsequent callbacks > are installed with > > this code, the callback is moved down/up the list". THis is > inconsistent > > with the description of the callback processing order in > section 3.5.4 (pg > > 39), which says that "If the API client adds another, any > existing pre- and > > post-processors are removed". > > The document needs to be updated. If another application > requests first or last > and the slot is already in use, then an error should be returned. hmm... So you are saying neither of the sections listed above is correct? > > + Sec. 3.4.5.3, Pg. 29. When would I use the > AAARespondToMessage()? > > Can't I just do: > > AAANewMessage(); > > AAASetServer(); > > AAASendMessage(); > > Yes, but AAARespondToMessage will set the flags right (indicating a > response), and will include any Proxy-State type information that > the application shouldn't have to mess with. But the signature of AAARespondToMessage, it only contains one reference to the message to respond to... To set these information correctly, wouldn't you need to have another AAAMessage somewhere in the signature for the respond message? > > + Sec. 3.4.5.9, Pg. 32. Shouldn't this function be > associated with > > AAA_AVP_LIST pointers rather than AAA_AVP pointers? The > logic behind having > > an Extended_AAA_AVP structure specified on Pg 39 is to hide > the fact that > > AVP actually is a node of a doubly linked list. In which case, > > AAAJoinAVPList() should not be dealing with AAA_AVPs. > > It would be perfectly acceptable to have the function deal > with AVPLists (and > I thought it did). So are we agreeing that the signature of AAAJoinAVPList be: AAAReturnCode AAAJoinAVPLists(AAA_AVP_LIST *dest, AAA_AVP_LIST *source); > > + Sec. 3.4.3.1. THis is to start a user session, and > *not* a peer > > connection, correct? > Correct. There is no way to kick start a peer connection via > the API. This is > transparent to the application. but if one calls AAAOpen(), at the return of the function call, a peer connection is created. And there can be only one peer connection between two servers, right? From owner-aaa-bof@merit.edu Wed May 2 12:18:28 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16105 for ; Wed, 2 May 2001 12:18:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D00EB5DE93; Wed, 2 May 2001 11:21:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BEFAF5DE8E; Wed, 2 May 2001 11:21:45 -0400 (EDT) Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 3F8455DE85 for ; Wed, 2 May 2001 11:21:44 -0400 (EDT) Received: (qmail 21982 invoked by uid 500); 2 May 2001 15:26:24 -0000 Date: Wed, 2 May 2001 10:26:23 -0500 From: David Frascone To: Yiwen Jiang Cc: "'David Frascone'" , aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Message-ID: <20010502102623.E17632@newman.frascone.com> Mail-Followup-To: Yiwen Jiang , 'David Frascone' , 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 Yiwen.Jiang@tic.siemens.ca on Wed, May 02, 2001 at 10:26:02AM -0400 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, May 02, 2001 at 10:26:02AM -0400, Yiwen Jiang wrote: > > > > The Sun aaa server handles DRIs itself. But, there is no reason why > > another server's applications can't register for all messages, > > including DRIs. > If a server's application does register callback for message such as DRI, > one would assume that the callback for DRI is invoked *after* the action in > the state machine is processed, right? If so, could we add that in the I-D? I don't think so. We might want to mention that a server *might* handle DRI's itself, but that is kind of implementation specific. Remember, we're not designing a server here, just an API to do AAA work. If "Bob's AAA Server" decides to allow applications to register for DRI's, that is Bob's perrogative. > > > + Sec. 3.4.5.3, Pg. 29. When would I use the > > AAARespondToMessage()? > > > Can't I just do: > > > AAANewMessage(); > > > AAASetServer(); > > > AAASendMessage(); > > > > Yes, but AAARespondToMessage will set the flags right (indicating a > > response), and will include any Proxy-State type information that > > the application shouldn't have to mess with. > But the signature of AAARespondToMessage, it only contains one reference to > the message to respond to... To set these information correctly, wouldn't > you need to have another AAAMessage somewhere in the signature for the > respond message? That is assumed to be handled internally. -- In other words, when you do an AAARespondToMessage(), it massages the current message from incoming to outgoing, and allows you to modify fields. From owner-aaa-bof@merit.edu Wed May 2 13:02:49 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17353 for ; Wed, 2 May 2001 13:02:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D7E135DDD5; Mon, 30 Apr 2001 16:59:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B3A775DE0D; Mon, 30 Apr 2001 16:59:14 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 2FC1D5DDD5 for ; Mon, 30 Apr 2001 16:59:13 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA04777; Mon, 30 Apr 2001 13:59:05 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA10981; Mon, 30 Apr 2001 13:58:53 -0700 (PDT) Message-Id: <200104302058.NAA10981@heliopolis.eng.sun.com> Date: Mon, 30 Apr 2001 13:58:53 -0700 (PDT) From: Jonathan Wood Reply-To: Jonathan Wood Subject: RE: [AAA-WG]: Diamter/SCTP: preventing head-of-the-line blocking To: aaa-wg@merit.edu, Yiwen.Jiang@tic.siemens.ca Cc: pcalhoun@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: R959mMgqu2fzAwF2cvx2eA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk > >Hi there, > >I have a question that has been bugging me from the very beginning regarding >SCTP... > >There is really no stable SCTP implementation out there avaiable for us to >do development on (kernel or user land implementation). In addition, it is That depends on your definition of stable. For development purposes, I would say that the following publicly available implementations are stable enough: http://www.sctp.de/ Userland, runs under Linux, FreeBSD and Mac OS X and supports IPv4 and IPv6. http://people.cs.uchicago.edu/~piggy/sctp_chicago_il_us/ Userland / Kernel hybrid, runs on FreeBSD http://playground.sun.com/sctp/ Solaris kernel >my impression that the RFC is still not that stable (e.g. the recently >discovered Adler32 checksum weakness), why is SCTP a mandate for the >Diameter base protocol? Sure it provides us many desirable features, but if >there is no publicly available implementation out there, how can we support >this? Or is the current mandate only to look at using future possibilities >at a theorotical level? Well, what are the options for a Diameter transport? o TCP: doesn't meet all the transport requirements o roll-yer-own: this would probably delay diameter by at least a year o or SCTP: meets all the transport requirments, and is farther along than diameter in the standards process. Jonathan > >Cheers, >Yiwen >--- >Yiwen Jiang >Mobile IP Networking >Email: Yiwen.Jiang@tic.siemens.ca >Phone: (613)271-7710 > >Telecom Innovation Centre >505 March Road >Kanata, Ontario, Canada >K2K 2M5 > > >> -----Original Message----- >> From: Jonathan Wood [mailto:Jonathan.Wood@Sun.COM] >> Sent: Monday, April 30, 2001 4:15 PM >> To: aaa-wg@merit.edu >> Subject: [AAA-WG]: Diamter/SCTP: preventing head-of-the-line blocking >> >> >> >> While SCTP has built in support for preventing head- >> of-the-line blocking, there is currently no provision >> in the diameter spec to utilize this functionality. >> This means that Diameter/SCTP at present has the >> same head-of-the-line blocking problems as Diamter/ >> vanilla TCP. >> >> We can easily use SCTP streams to fix this. I propose >> the following: >> >> Each diameter node should stripe its messages across >> the range of SCTP streams that it and its peer have >> agreed upon. (A lost message in one stream will not >> cause any other streams to block.) A trivial and >> effective implementation of this simply increments >> a counter for the stream ID to send on. When the >> counter reaches the maximum number of streams for >> the association, it resets to 0. >> >> Diameter peers must be able to accept messages on >> any stream. Note that streams are used *solely* to >> prevent head-of-the-line blocking. All identifying >> information is carried within the diamter payload. >> >> SCTP peers can allocate up to 65535 streams for an >> association. The cost for idle streams may or may not >> be zero, and the cost for non-idle streams is always >> greater than 0. So administrators may wish to limit >> the number of possible streams on their diameter nodes >> according to the resources (i.e. memory, CPU power, etc.) >> of a particular node. >> >> Stream IDs do not need to be preserved by proxies. For >> example, consider the following case, where B serves >> as a proxy between A and C: >> >> A --------------------- B -------------------- C >> 1000 streams 2000 streams >> >> msg 1: str id 0 msg 1: str id 0 >> msg 2: str id 1 msg 2: str id 1 >> ... ... >> msg 1000: str id 999 msg 1000: str id 999 >> msg 1001: str id 0 msg 1001: str id 1000 >> >> The striping acts sort of like a hash table. It is >> possible, yet unlikely, that two messages will end >> up in the same stream, and even less likely that >> there will be message loss resulting in blocking when >> this happens. If it does turn out to be a problem, local >> administrators can increase the number of streams on >> their nodes to improve performance. >> >> Questions / comments? >> >> Jonathan >> >> >> >> > From owner-aaa-bof@merit.edu Wed May 2 16:01:25 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21715 for ; Wed, 2 May 2001 16:01:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3E51C5DF3E; Wed, 2 May 2001 15:59:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 990575DECB; Wed, 2 May 2001 15:59:34 -0400 (EDT) Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 1AFEB5DE03 for ; Wed, 2 May 2001 15:59:30 -0400 (EDT) Received: (qmail 16528 invoked by uid 500); 2 May 2001 20:04:13 -0000 Date: Wed, 2 May 2001 15:04:13 -0500 From: David Frascone To: Yiwen Jiang Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [diameter] RE: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Message-ID: <20010502150413.G10084@newman.frascone.com> Mail-Followup-To: Yiwen Jiang , 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 Yiwen.Jiang@tic.siemens.ca on Wed, May 02, 2001 at 03:27:17PM -0400 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, May 02, 2001 at 03:27:17PM -0400, Yiwen Jiang wrote: > > That is assumed to be handled internally. -- In other words, > > when you do > > an AAARespondToMessage(), it massages the current message > > from incoming > > to outgoing, and allows you to modify fields. > Okay, but how does one modify the fields, since upon return of this > function, the message is already sent? For example, what happens if the > server decides to add more AVPs onto the response message? The > AAAResponseMessage() does not provide a mean for the server to add or delete > AVPs from itself before sending the modified message. I thought the response > message is created by AAANewMessage, with the request message as the last > parameter? If the AAAResponseToMessage() is to be kept this way, can we > have some detailed description of what it does in the ID then? > Ahhh, now I see your confusion. AAARespondToMessage does NOT send the message, but sets all the flags to mart it as a response, and sets the internal destination/etc so that it will be routed back to the sender. So, you would call AAARespondToMessage(), manipulate the AVPs, then do an AAASendMessage() to send the message. Clearer? From owner-aaa-bof@merit.edu Wed May 2 16:11:47 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22071 for ; Wed, 2 May 2001 16:11:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6AAC35DF45; Wed, 2 May 2001 15:29:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C35415DE7E; Wed, 2 May 2001 15:29:44 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 8FAB15DEA1 for ; Wed, 2 May 2001 15:29:33 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id PAA03712; Wed, 2 May 2001 15:29:01 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xmaa03708; Wed, 2 May 01 15:28:51 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id PAA01664; Wed, 2 May 2001 15:28:50 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma001469; Wed, 2 May 01 15:27:36 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <2XDRF5M2>; Wed, 2 May 2001 15:27:19 -0400 Message-ID: From: Yiwen Jiang To: "'David Frascone'" Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: RE: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Date: Wed, 2 May 2001 15:27:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Dave, > I don't think so. We might want to mention that a server > *might* handle > DRI's itself, but that is kind of implementation specific. > Remember, we're > not designing a server here, just an API to do AAA work. If "Bob's > AAA Server" decides to allow applications to register for DRI's, that > is Bob's perrogative. Agreed. > > > > + Sec. 3.4.5.3, Pg. 29. When would I use the > > > AAARespondToMessage()? > > > > Can't I just do: > > > > AAANewMessage(); > > > > AAASetServer(); > > > > AAASendMessage(); > > > > > > Yes, but AAARespondToMessage will set the flags right (indicating a > > > response), and will include any Proxy-State type information that > > > the application shouldn't have to mess with. > > But the signature of AAARespondToMessage, it only contains > one reference to > > the message to respond to... To set these information > correctly, wouldn't > > you need to have another AAAMessage somewhere in the > signature for the > > respond message? > > That is assumed to be handled internally. -- In other words, > when you do > an AAARespondToMessage(), it massages the current message > from incoming > to outgoing, and allows you to modify fields. Okay, but how does one modify the fields, since upon return of this function, the message is already sent? For example, what happens if the server decides to add more AVPs onto the response message? The AAAResponseMessage() does not provide a mean for the server to add or delete AVPs from itself before sending the modified message. I thought the response message is created by AAANewMessage, with the request message as the last parameter? If the AAAResponseToMessage() is to be kept this way, can we have some detailed description of what it does in the ID then? From owner-aaa-bof@merit.edu Wed May 2 16:35:27 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22701 for ; Wed, 2 May 2001 16:35:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 370385DF8B; Wed, 2 May 2001 16:33:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C35475DEDA; Wed, 2 May 2001 16:33:43 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 917E25DE05 for ; Wed, 2 May 2001 16:33:28 -0400 (EDT) Received: (qmail 15317 invoked by uid 500); 2 May 2001 20:23:19 -0000 Date: Wed, 2 May 2001 13:23:19 -0700 From: Pat Calhoun To: Yiwen Jiang Cc: "'David Frascone'" , aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [diameter] RE: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Message-ID: <20010502132319.C4672@charizard.diameter.org> Mail-Followup-To: Yiwen Jiang , 'David Frascone' , 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 Yiwen.Jiang@tic.siemens.ca on Wed, May 02, 2001 at 04:02:48PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, May 02, 2001 at 04:02:48PM -0400, Yiwen Jiang wrote: > > > > That is assumed to be handled internally. -- In other words, > > > > when you do > > > > an AAARespondToMessage(), it massages the current message > > > > from incoming > > > > to outgoing, and allows you to modify fields. > > > Okay, but how does one modify the fields, since upon return of this > > > function, the message is already sent? For example, what > > happens if the > > > server decides to add more AVPs onto the response message? The > > > AAAResponseMessage() does not provide a mean for the server > > to add or delete > > > AVPs from itself before sending the modified message. I > > thought the response > > > message is created by AAANewMessage, with the request > > message as the last > > > parameter? If the AAAResponseToMessage() is to be kept > > this way, can we > > > have some detailed description of what it does in the ID then? > > > > > > > Ahhh, now I see your confusion. AAARespondToMessage does NOT send the > > message, but sets all the flags to mart it as a response, and > > sets the > > internal destination/etc so that it will be routed back to the sender. > > > > So, you would call AAARespondToMessage(), manipulate the > > AVPs, then do an > > AAASendMessage() to send the message. > > > > Clearer? > Definitely.. :) > > Now, my question is, wouldn't this be the same functionality as > AAANewMessage with the request message (last parameter in its signature) > provided at the time of call? Sure but they have different functinality. AAANewMessage will allocate a new AAAMessage, while AAARespondToMessage will prep a received AAAMessage to be used as a response message. If AAAMessage is to be used instead, you would have to allocate a new AAAMessage, copy all of the AVPs over, and delete the request AAAMessage. Hope this helps, PatC From owner-aaa-bof@merit.edu Wed May 2 16:42:44 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22883 for ; Wed, 2 May 2001 16:42:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AE4765E12D; Wed, 2 May 2001 16:40:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D899B5E1EA; Wed, 2 May 2001 16:40:49 -0400 (EDT) Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 5D2F95E1CC for ; Wed, 2 May 2001 16:40:42 -0400 (EDT) Received: (qmail 25020 invoked by uid 500); 2 May 2001 20:45:26 -0000 Date: Wed, 2 May 2001 15:45:25 -0500 From: David Frascone To: Yiwen Jiang Cc: diameter@diameter.org, aaa-wg@merit.edu Subject: Re: [diameter] RE: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Message-ID: <20010502154525.I10084@newman.frascone.com> Mail-Followup-To: Yiwen Jiang , diameter@diameter.org, aaa-wg@merit.edu References: <20010502132319.C4672@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010502132319.C4672@charizard.diameter.org>; from pcalhoun@diameter.org on Wed, May 02, 2001 at 01:23:19PM -0700 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, May 02, 2001 at 01:23:19PM -0700, Pat Calhoun wrote: > On Wed, May 02, 2001 at 04:02:48PM -0400, Yiwen Jiang wrote: > > > > > That is assumed to be handled internally. -- In other words, > > > > > when you do > > > > > an AAARespondToMessage(), it massages the current message > > > > > from incoming > > > > > to outgoing, and allows you to modify fields. > > > > Okay, but how does one modify the fields, since upon return of this > > > > function, the message is already sent? For example, what > > > happens if the > > > > server decides to add more AVPs onto the response message? The > > > > AAAResponseMessage() does not provide a mean for the server > > > to add or delete > > > > AVPs from itself before sending the modified message. I > > > thought the response > > > > message is created by AAANewMessage, with the request > > > message as the last > > > > parameter? If the AAAResponseToMessage() is to be kept > > > this way, can we > > > > have some detailed description of what it does in the ID then? > > > > > > > > > > Ahhh, now I see your confusion. AAARespondToMessage does NOT send the > > > message, but sets all the flags to mart it as a response, and > > > sets the > > > internal destination/etc so that it will be routed back to the sender. > > > > > > So, you would call AAARespondToMessage(), manipulate the > > > AVPs, then do an > > > AAASendMessage() to send the message. > > > > > > Clearer? > > Definitely.. :) > > > > Now, my question is, wouldn't this be the same functionality as > > AAANewMessage with the request message (last parameter in its signature) > > provided at the time of call? > > Sure but they have different functinality. AAANewMessage will allocate a > new AAAMessage, while AAARespondToMessage will prep a received AAAMessage > to be used as a response message. > > If AAAMessage is to be used instead, you would have to allocate a new > AAAMessage, copy all of the AVPs over, and delete the request AAAMessage. > And set all the flags, which is not currently possible with the API, since AAARespondToMessage is there. From owner-aaa-bof@merit.edu Wed May 2 16:47:37 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23008 for ; Wed, 2 May 2001 16:47:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 55BB05E069; Wed, 2 May 2001 16:43:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CDB925DDED; Wed, 2 May 2001 16:43:41 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 4A2015E0B9 for ; Wed, 2 May 2001 16:43:23 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id QAA04755; Wed, 2 May 2001 16:42:51 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma004753; Wed, 2 May 01 16:42:36 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id QAA11994; Wed, 2 May 2001 16:42:35 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma011711; Wed, 2 May 01 16:41:37 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <2XDRF5PJ>; Wed, 2 May 2001 16:41:20 -0400 Message-ID: From: Yiwen Jiang To: "'Pat Calhoun'" Cc: "'David Frascone'" , aaa-wg@merit.edu, diameter@diameter.org Subject: RE: [diameter] RE: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Date: Wed, 2 May 2001 16:41:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, > > Now, my question is, wouldn't this be the same functionality as > > AAANewMessage with the request message (last parameter in > its signature) > > provided at the time of call? > > Sure but they have different functinality. AAANewMessage will > allocate a > new AAAMessage, while AAARespondToMessage will prep a > received AAAMessage > to be used as a response message. > > If AAAMessage is to be used instead, you would have to allocate a new > AAAMessage, copy all of the AVPs over, and delete the request > AAAMessage. > > Hope this helps, Yes it does help. Thank you very much.. Could we have this sort of explaination added in the ID though? Because my initial understanding from reading the draft for AAARespondToMessage is completely different from the above clarification. Thanks again, everyone.. :) From owner-aaa-bof@merit.edu Wed May 2 16:51:13 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23093 for ; Wed, 2 May 2001 16:51:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 68EA85E084; Wed, 2 May 2001 16:08:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D41E55E13D; Wed, 2 May 2001 16:08:57 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 1E6285E084 for ; Wed, 2 May 2001 16:08:56 -0400 (EDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f42K8gg17936 for ; Wed, 2 May 2001 15:09:02 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 2 May 2001 15:08:35 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Wed, 2 May 2001 15:08:35 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213954@daeis07nok> From: Basavaraj.Patil@nokia.com To: aaa-wg@merit.edu Cc: pcalhoun@diameter.org Subject: [AAA-WG]: Mobile IP Extension Date: Wed, 2 May 2001 15:08:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, Would you agree that the current Mobile IP extension document (draft-ietf-aaa-diameter-mobileip-02.txt) specifically deals with Mobile IPv4 only? If so would you mind changing the title to : "Diameter Mobile IPv4 Extensions"? And maybe add an applicability statement (to MIPv4 only) someplace in the document. Regards, -Basavaraj From owner-aaa-bof@merit.edu Wed May 2 16:51:59 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23130 for ; Wed, 2 May 2001 16:51:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 964955E04D; Wed, 2 May 2001 16:49:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 734E65DEBC; Wed, 2 May 2001 16:49:32 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 1F3315E078 for ; Wed, 2 May 2001 16:49:27 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id QAA04848; Wed, 2 May 2001 16:49:26 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma004846; Wed, 2 May 01 16:49:08 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id QAA12994; Wed, 2 May 2001 16:49:08 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma012919; Wed, 2 May 01 16:48:27 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <2XDRF5PZ>; Wed, 2 May 2001 16:48:10 -0400 Message-ID: From: Yiwen Jiang To: "'David Frascone'" Cc: diameter@diameter.org, aaa-wg@merit.edu Subject: RE: [diameter] RE: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Date: Wed, 2 May 2001 16:48:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > > Sure but they have different functinality. AAANewMessage > will allocate a > > new AAAMessage, while AAARespondToMessage will prep a > received AAAMessage > > to be used as a response message. > > > > If AAAMessage is to be used instead, you would have to > allocate a new > > AAAMessage, copy all of the AVPs over, and delete the > request AAAMessage. > > > > And set all the flags, which is not currently possible with > the API, since > AAARespondToMessage is there. > If this is the case, why is the request message required at all for AAANewMessage()? shouldn't everyone be using AAARespondToMessage() when sending a reply to a response, and using AAANewMessage() when creating a brand new message? From owner-aaa-bof@merit.edu Wed May 2 17:15:09 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23768 for ; Wed, 2 May 2001 17:15:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AF6AA5DDE2; Wed, 2 May 2001 17:14:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 350C35DE0C; Wed, 2 May 2001 17:14:06 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 7C7B55DDDF for ; Wed, 2 May 2001 17:13:57 -0400 (EDT) Received: (qmail 17322 invoked by uid 500); 2 May 2001 21:03:49 -0000 Date: Wed, 2 May 2001 14:03:48 -0700 From: Pat Calhoun To: Paul Funk Cc: aaa-wg@merit.edu, Patrice Calhoun Subject: Re: [AAA-WG]: Vendor-Specific Values Message-ID: <20010502140348.I4672@charizard.diameter.org> Mail-Followup-To: Paul Funk , aaa-wg@merit.edu, Patrice Calhoun References: <4.1.20010501200021.01798580@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010501200021.01798580@cairo.funk.com>; from paul@funk.com on Tue, May 01, 2001 at 08:03:35PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Tue, May 01, 2001 at 08:03:35PM -0400, Paul Funk wrote: > I'd like to trot out a suggestion that was first made within > the RADIUS group. > > A "Vendor-Specific Value" is an AVP whose attribute is a > standard one but whose value has semantics defined by a > particular vendor. Such extensibility is useful for > Unsigned32 types that are really enumerations, such as > Service-Type and Accounting-Record-Type. > > For example, a vendor may offer services other than "Login", > "Framed", etc., and may wish to extend the Service-Type > AVP with the values it requires. Or, a vendor may wish to > define an Accounting-Record-Type other than start, stop, > etc. sure. > > Vendors and service providers routinely have such > requirements, have always satisfied these requirements by > defining what they pleased, and have not always bothered > to go to IANA for permission. well, that is problematic. If vendors want to encode a new value in an existing RADIUS attribute, and pick an unused value without registering with IANA, then conflicts will occur. > > One might argue that the workaround is to define the > enumerations within a separate VSA. But this is problematic > for a couple reasons. > > First, it is useful for a Diameter server to recognize that > a particular value is a Service-Type naturally, without > having to figure out that Acme-Service-Type carries service > type information. correct. > > Second, and more problematic, is that AVPs such as > Service-Type and Accounting-Record-Type are defined as > required AVPs within the Diameter command, and any vendor > that replaced these AVPs with their own would be instantly > non-compliant. right. > > By adopting VSVs there is an added benefit that relates > specifically to Diameter: > > Currently, the only way for a vendor to define a new extension > is to apply to the IANA. But by allowing VSVs, any vendor would > be able to define its own values for Extension-Id. I think this > ability is critical to motivate widespread use of Diameter for new > applications. An interesting, if not dangerous, proposal. > > Command codes and attributes are already extensible by > vendors, but enumerated values and extensions are not. > VSVs effectively make Diameter completely vendor- > extensible, at the cost of a single bit in the AVP Flags. I hear you, but question whether this is really necessary. I can appreciate the desire to have a truly flexible protocol, but this can lead to many other undesirable side effects. The -03 base now includes lots of new text that is the result of conversations I've had with IESG members and the chairs. Specifically, the following section has been created: 2.3.1 Defining new AVP Values Defining a new AVP value is the best approach when a new application needs to make use of an existing Diameter extension, but requires that an existing AVP communicate different service-specific information (e.g. NAS-Port-Type set to avian carriers). When an existing AVP can be used to communicate the new information, this approach is preferred over creating new AVPs. In order to allocate a new AVP value, a request MUST be sent to IANA, with a detailed explanation of the value. Furthermore, if the command code on which the AVP value is to be used would require a different set of mandatory AVPs be present, the list of AVPs must accompany the request. Now I am in the process of checking how complex it is to request a new value since I sent an e-mail to iana@iana.org to request a new value for a RADIUS attribute. If all goes well, the pain to register a new value is near zero. So I'd like to punt this one to the chairs and see what they think. PatC From owner-aaa-bof@merit.edu Wed May 2 17:52:42 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24556 for ; Wed, 2 May 2001 17:52:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2ED7B5DDF0; Wed, 2 May 2001 17:50:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D4A315E0A0; Wed, 2 May 2001 17:50:12 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 816AB5E079 for ; Wed, 2 May 2001 17:49:56 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA00098; Wed, 2 May 2001 14:49:52 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA10904; Wed, 2 May 2001 14:49:51 -0700 (PDT) Message-Id: <200105022149.OAA10904@heliopolis.eng.sun.com> Date: Wed, 2 May 2001 14:49:51 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft To: James.Kempf@sun.com, dave@frascone.com, aaa-wg@merit.edu, diameter@diameter.org, Yiwen.Jiang@tic.siemens.ca MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: rWMEt3Pm2ASH/X3ir/ZccA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk OK, it sounds like you are in favor of having a dictionary file regardless of the language. Any other comments from WG members? jak >From: Yiwen Jiang >To: "'James Kempf'" , dave@frascone.com, aaa-wg@merit.edu, diameter@diameter.org >Subject: RE: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft >Date: Wed, 2 May 2001 11:08:37 -0400 > >Hi James, > >> In the current draft, there is no requirement for configuration files >> for the C library. This is because different operating system >> platforms >> may have different requirements. >I can see for the general aaa.conf file, the different OS may have different >way of describing the file path, but I would argue that the dictionary file >should exist regardless of the OS. It is up to the implementor to ensure >the AVP types are actually supported. This is because there are already >well-defined AVPs and its types and for some, possible values. > >Or am I missing something here? From owner-aaa-bof@merit.edu Wed May 2 18:21:55 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25266 for ; Wed, 2 May 2001 18:21:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B39455E190; Wed, 2 May 2001 18:20:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D7D095E204; Wed, 2 May 2001 18:19:58 -0400 (EDT) Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id D23005DEB1 for ; Wed, 2 May 2001 18:19:51 -0400 (EDT) Received: (qmail 13646 invoked by uid 500); 2 May 2001 22:24:37 -0000 Date: Wed, 2 May 2001 17:24:36 -0500 From: David Frascone To: James Kempf Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Message-ID: <20010502172436.J10084@newman.frascone.com> Mail-Followup-To: James Kempf , aaa-wg@merit.edu, diameter@diameter.org References: <200105022149.OAA10904@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105022149.OAA10904@heliopolis.eng.sun.com>; from James.Kempf@sun.com on Wed, May 02, 2001 at 02:49:51PM -0700 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk I'd like to have a standardized dictionary. Preferably in XML. But, I think the other configuration files should be left out of the API. On Wed, May 02, 2001 at 02:49:51PM -0700, James Kempf wrote: > OK, it sounds like you are in favor of having a dictionary file regardless > of the language. > > Any other comments from WG members? > > jak > > >From: Yiwen Jiang > >To: "'James Kempf'" , dave@frascone.com, aaa-wg@merit.edu, > diameter@diameter.org > >Subject: RE: [AAA-WG]: Re: questions and comments regarding the Diameter A PI > draft > >Date: Wed, 2 May 2001 11:08:37 -0400 > > > >Hi James, > > > >> In the current draft, there is no requirement for configuration files > >> for the C library. This is because different operating system > >> platforms > >> may have different requirements. > >I can see for the general aaa.conf file, the different OS may have different > >way of describing the file path, but I would argue that the dictionary file > >should exist regardless of the OS. It is up to the implementor to ensure > >the AVP types are actually supported. This is because there are already > >well-defined AVPs and its types and for some, possible values. > > > >Or am I missing something here? > > From owner-aaa-bof@merit.edu Wed May 2 18:25:01 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25321 for ; Wed, 2 May 2001 18:24:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A7ABE5DE8E; Wed, 2 May 2001 16:05:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 22D905E084; Wed, 2 May 2001 16:05:35 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 7B89B5E1AB for ; Wed, 2 May 2001 16:05:10 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id QAA04207; Wed, 2 May 2001 16:04:39 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma004205; Wed, 2 May 01 16:04:26 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id QAA06183; Wed, 2 May 2001 16:04:26 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma006050; Wed, 2 May 01 16:03:07 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <2XDRF5NZ>; Wed, 2 May 2001 16:02:50 -0400 Message-ID: From: Yiwen Jiang To: "'David Frascone'" Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: RE: [diameter] RE: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Date: Wed, 2 May 2001 16:02:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > > > That is assumed to be handled internally. -- In other words, > > > when you do > > > an AAARespondToMessage(), it massages the current message > > > from incoming > > > to outgoing, and allows you to modify fields. > > Okay, but how does one modify the fields, since upon return of this > > function, the message is already sent? For example, what > happens if the > > server decides to add more AVPs onto the response message? The > > AAAResponseMessage() does not provide a mean for the server > to add or delete > > AVPs from itself before sending the modified message. I > thought the response > > message is created by AAANewMessage, with the request > message as the last > > parameter? If the AAAResponseToMessage() is to be kept > this way, can we > > have some detailed description of what it does in the ID then? > > > > Ahhh, now I see your confusion. AAARespondToMessage does NOT send the > message, but sets all the flags to mart it as a response, and > sets the > internal destination/etc so that it will be routed back to the sender. > > So, you would call AAARespondToMessage(), manipulate the > AVPs, then do an > AAASendMessage() to send the message. > > Clearer? Definitely.. :) Now, my question is, wouldn't this be the same functionality as AAANewMessage with the request message (last parameter in its signature) provided at the time of call? Thanks! From owner-aaa-bof@merit.edu Wed May 2 18:26:10 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25349 for ; Wed, 2 May 2001 18:26:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D803C5DE0A; Wed, 2 May 2001 18:24:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B18FA5DFBA; Wed, 2 May 2001 18:24:18 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 4770B5DEB1 for ; Wed, 2 May 2001 18:24:16 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id SAA12843; Wed, 2 May 2001 18:16:35 -0400 (EDT) Message-Id: <4.1.20010502132420.017be100@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 02 May 2001 18:04:12 -0400 To: Erik Guttman From: Paul Funk Subject: Re: [AAA-WG]: Grouped AVPs Cc: aaa-wg@merit.edu, Patrice Calhoun In-Reply-To: References: <4.1.20010501195012.017b29b0@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Erik, At 03:19 AM 5/2/01 -0700, Erik Guttman wrote: >On Tue, 1 May 2001, Paul Funk wrote: > >> Though it is perhaps ambiguous in the base draft, the >> intent of the grouped type is to allow only a fixed set >> of AVPs in a specified order within any particular >> grouped AVP. > >It is not too ambiguous I hope. The ambiguity arises from requiring ABNF specification for grouped AVPs, implying the expressive power of that language, yet a grouped AVP must be a well-defined sequence. If it's just a list of attributes, why use ABNF? >> I think this severely limits the usefulness of grouped >> AVPs and is contrary to the spirit of extensibility >> which characterizes Diameter. And what a waste of bits >> it is to use a self-describing format to encapsulate >> what amounts to a fixed structure. > >The purpose of the Grouped-AVP was to allow certain AVPs >to be provided in combination with each other - always >the same exactly the same AVPs. This allowed complex >data to be delivered. The only other options would have >been to have a complex data type (which would have made >for an indeterminate set of parsers - and a messy base >protocol requiring specialized parsers) or an open ended >grouping (which defies a regular grammar and automatic >parsing). The complex data type approach was tried in >draft-calhoun-diameter-0..14 and the group-avp bucket >was tried in draft-calhoun-diameter-15..17. We already have a regular grammar for the Diameter message, so having one for grouped AVPs doesn't add to the order of complexity. Just set your automatic parser to "stun" when you want to use it on an AVP rather than on an entire message. > >The requirements for diameter protocol clean up vis-a-vis >data representation issues was discussed in >draft-ietf-aaa-issues-04.txt - with solutions proposed >in draft-ietf-aaa-solutions-01.txt. The WG last call on >the issues document ended Feb 28. Please read section 9 >of that document - which now represents working group >consensus. Now I have to cry foul. What you're saying is that any discussion of this issue is out-of-bounds. But the solutions document is a set of recommendations for how the group ought to proceed, according to then current thinking, not a bounding box. > >> Diameter as currently defined is a hierarchical, >> self-describing data modeling language with extensibility >> at the top level, and calcification into fixed structures >> thereafter. If ASN.1, XML or LDAP had such limitations, >> they would never have achieved success. > >What we have in DIAMETER is *one* feature which allows for >structuring data - the Grouped-AVP. These allow for regular >groupings. If more groupings are needed - say a Bag-AVP, >these too can be defined. Please feel free to define one. "Grouped" is not an AVP -- it's a data type. I certainly don't feel free to define a new type. We need to make sure that the primitive data types that are defined in the base draft are adequate for expressing the data exchanges that will be required, rather than just dodge the issue by saying that you can define an AVP however you like. AVPs that represent collections should not follow ad hoc rules defined for that AVP alone. > >> One need look no further than the original RADIUS >> grouping mechanism to see why fixed structures is a bad >> idea. >> >> In RADIUS, tunnel attributes are tagged to allow related >> attributes to be grouped. In Diameter, this is >> accomplished by including all values for a particular >> tunnel within the grouped Tunnel AVP. But in RADIUS, >> it is possible to omit particular tunnel attributes, or >> define new ones as required. In Diameter, it is not. > >So - either do not define tunnel attributes as being >delivered by a Group-AVP or define a new Group-AVP when >it becomes clear that the old one is no longer correct. >In either case, backward compatibility is a problem which >doesn't go away by removing rules from the protocol. Your suggestion of "either don't use it or define lots of them" really argues for a single extensible AVP. In fact, the ability to provide backward compatibility is greatly enhanced by being able to extend the same grouped AVP. For example, additional AVPs could be added to the group and marked non-mandatory, allowing older servers to remain compatible. > >> Another example is the Redirect-Host AVP, comprising >> one AVP for address and another for port. But the >> draft vacillates, saying that if only address is >> required, it may be sent ungrouped. The draft also >> states that the redirect may also include certificates >> for the home server. But if different certificates are >> required for different servers, how would you >> associate the certificate with the address/port it >> applies to? Better would to require redirect >> destinations to be specified only one way -- within >> the grouped Redirect-Host AVP, allow it to contain >> an address and optionally a port, and let it be >> extensible to contain a certificate reference or any >> other information that may be required in the future. > >Where it is not necessary, we should not specify that >the Grouped-AVP be used. In some cases it is necessary. > >> I suggest that we allow a grouped AVP to be defined >> as restrictively or as liberally as we allow Diameter >> messages to be defined. Thus, the ABNF for a grouped >> AVP could contain sequence rules or not, could contain >> optional attributes or not, could contain the wildcard >> [AVP] or not, etc. In general, the liberal approach >> should be used, unless there is a really good reason to >> fix the contents of a group. > >This would lose the advantages of simplicity, regularity, >and specifiability, as discussed in the issues draft. These are minor advantages that really dumb-down the protocol -- a bad tradeoff against flexibility and durability. > >> An additional benefit of this approach is that it makes >> it possible to define an AVP as a homogeneous list of >> AVPs, simply by defining its ABNF as *[Some-AVP]. > >We have not had any specific examples of where lists >would be needed. No examples exist in current RADIUS >specs. If we could find such uses, we should specify >a mechanism to do this. The Grouped-AVP does not support >creation of lists, I fully agree. Well, see section 9 of draft-ietf-aaa-solutions-01.txt. It recommends that "List" be one of the data types. That represents working group consensus, right? Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Wed May 2 18:47:35 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25632 for ; Wed, 2 May 2001 18:47:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 996F45E173; Wed, 2 May 2001 18:18:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D82415E071; Wed, 2 May 2001 18:18:28 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by segue.merit.edu (Postfix) with ESMTP id 822275E092 for ; Wed, 2 May 2001 18:18:20 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id PAA03222 for ; Wed, 2 May 2001 15:18:20 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA18697 for ; Wed, 2 May 2001 15:18:19 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 17:18:20 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECEB7@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'James Kempf'" , dave@frascone.com, aaa-wg@merit.edu, diameter@diameter.org, Yiwen.Jiang@tic.siemens.ca Subject: RE: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Date: Wed, 2 May 2001 17:18:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk > OK, it sounds like you are in favor of having a dictionary > file regardless > of the language. > > Any other comments from WG members? I concur. A standardized dictionary file syntax could only aid an implementor. Is there any reason why the C API couldn't use an XML dictionary file, like the Java portion? I would imagine there is probably no lack of publically available C XML parsers. -Brian From owner-aaa-bof@merit.edu Wed May 2 19:12:49 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26004 for ; Wed, 2 May 2001 19:12:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3B7895DEE1; Wed, 2 May 2001 16:33:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9EC775E04C; Wed, 2 May 2001 16:32:48 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 05B565E17D for ; Wed, 2 May 2001 16:28:28 -0400 (EDT) Received: (qmail 15245 invoked by uid 500); 2 May 2001 20:18:19 -0000 Date: Wed, 2 May 2001 13:18:19 -0700 From: Pat Calhoun To: Basavaraj.Patil@nokia.com Cc: aaa-wg@merit.edu, pcalhoun@diameter.org Subject: Re: [AAA-WG]: Mobile IP Extension Message-ID: <20010502131819.B4672@charizard.diameter.org> Mail-Followup-To: Basavaraj.Patil@nokia.com, aaa-wg@merit.edu, pcalhoun@diameter.org References: <7B5C0390ACE7D211BC9C0008C7EABA2B03213954@daeis07nok> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B03213954@daeis07nok>; from Basavaraj.Patil@nokia.com on Wed, May 02, 2001 at 03:08:34PM -0500 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, May 02, 2001 at 03:08:34PM -0500, Basavaraj.Patil@nokia.com wrote: > > Pat, > > Would you agree that the current Mobile IP extension document > (draft-ietf-aaa-diameter-mobileip-02.txt) > specifically deals with Mobile IPv4 only? I believe so > If so would you mind changing the title to : "Diameter Mobile IPv4 > Extensions"? Not at all. > > And maybe add an applicability statement (to MIPv4 only) someplace in the > document. Sure. PatC From owner-aaa-bof@merit.edu Wed May 2 19:27:32 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26218 for ; Wed, 2 May 2001 19:27:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 352625E1FF; Wed, 2 May 2001 17:34:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8ACA25E0FF; Wed, 2 May 2001 17:33:48 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 07FB85E0B7 for ; Wed, 2 May 2001 17:32:52 -0400 (EDT) Received: (qmail 17805 invoked by uid 500); 2 May 2001 21:22:43 -0000 Date: Wed, 2 May 2001 14:22:43 -0700 From: Pat Calhoun To: Paul Funk Cc: aaa-wg@merit.edu, Patrice Calhoun Subject: Re: [AAA-WG]: Indications and three-legged transactions Message-ID: <20010502142243.J4672@charizard.diameter.org> Mail-Followup-To: Paul Funk , aaa-wg@merit.edu, Patrice Calhoun References: <4.1.20010501200718.017bda20@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010501200718.017bda20@cairo.funk.com>; from paul@funk.com on Tue, May 01, 2001 at 08:09:17PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Paul, You bring up an interesting problem, and one does certainly does need to be resolved. You are correct in your problem statement below that an MRI sent in response to a bad reply will contain an identifier that may not be recognized by the receiver. Your proposal is to do away with the MRI, and just allow a response to include the proper Result-Code when an error occurs. An if an error occurs in a Reply, that an STR should be sent to inform the server that the session is being cleared (presumably with some indication of why the STR was sent). I believe that this is a reasonable approach. However, the original intent behind the MRI was to allow a proxy in the chain to return an error. The proxy could, of course, return an error using the a request's natural response, but my thinking was that proxies may not support all extensions, and therefore would not know what the correct command code should be set to. However, in my conversations with IESG and the chairs in the past few days, we came to the conclusion that the following text was necessary in the base protocol: "Diameter servers MUST support the Base protocol, which includes Accounting, and both the NASREQ and Mobile IP extensions. Diameter Clients MUST support the Base protocol, including Accounting, and MAY support any other extension that would be required to provide service." So, if all servers (including proxies) MUST support all extensions, then the problem I had originally created the MRI for (proxies not supporting an extension) is no longer a problem. Well, this is true until another extension is standardized. So, I believe that your proposal is workable, and requests the rest of the WG's comments. Thanks, PatC On Tue, May 01, 2001 at 08:09:17PM -0400, Paul Funk wrote: > Indications are different from other types of messages in > that they can be issued in any of three legs of a > transaction: by the originator, by the responder, or by > the originator after receiving a response it doesn't > understand. > > This poses a problem for interpreting the Identifier. In > some cases, the Identifier in an Indication was > manufactured by the sender, in some cases by the receiver. > > In the case of two-legged transactions, the ownership > of the Identifier can at least be distinguished, since > different Indication messages are issued by originators > and responders. > > But in the case of a three-legged transaction, it can be > ambiguous. > > An MRI can be issued by the responder if it doesn't > understand an request AVP, or by the originator if it > doesn't understand an answer AVP. But in both cases the > Identifier is the one created by the originator. > > Thus, when you receive an MRI, you can't tell if it's > your Identifier or the other guy's. > > For example, suppose A sends B a request with A's > Identifier = 10 and gets an MRI in response, Meanwhile, > B sends A a separate request with B's Identifier = 10, > gets an answer containing an unknown AVP, and sends an > MRI back to A. Now A has received two MRIs, each with > Identifier = 10 and can't tell them apart. > > Another problem with three-legged transactions is > that you have to make real sure you won't respond to > an MRI with another MRI, otherwise you'll get two > servers with a lot to say to each other. > > I'm not sure why we need three-legged transactions at > all. When a server finds out its answer was rejected, > what is it expected to do? Is it supposed to learn > which AVPs the client doesn't like and make them > non-mandatory? Is it supposed to locate the session > that it thought had started and release it? > > Better would be to have the client just issue an STR > indicating that the session is terminated (or was > not started). At some point a human being will have > to notice and perform some reconfiguration. > > If it is felt that debugging information at the server > side is necessary, we should define a separate > Indication (e.g., Reply-Reject-Indication) that the > client issues with a completely new Identifier (that > is, unrelated to the original request) that simply > allows the server to log the fact that this client > doesn't understand a particular AVP and is not > starting sessions because of it. > > Paul > > Paul Funk > Funk Software, Inc. > 617 497-6339 > paul@funk.com > > From owner-aaa-bof@merit.edu Wed May 2 19:28:03 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26255 for ; Wed, 2 May 2001 19:28:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EB9885DE8A; Wed, 2 May 2001 18:55:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CCBC45DD8C; Wed, 2 May 2001 18:55:56 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id EE94B5DE8A for ; Wed, 2 May 2001 18:55:52 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA29202; Wed, 2 May 2001 15:55:49 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA13322; Wed, 2 May 2001 15:55:49 -0700 (PDT) Message-Id: <200105022255.PAA13322@heliopolis.eng.sun.com> Date: Wed, 2 May 2001 15:55:49 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft To: James.Kempf@sun.com, dave@frascone.com, aaa-wg@merit.edu, diameter@diameter.org, Yiwen.Jiang@tic.siemens.ca, Brian.Cain@motorola.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2Ks6rl5YwUelCtSfESHUag== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk >> OK, it sounds like you are in favor of having a dictionary >> file regardless >> of the language. >> >> Any other comments from WG members? > >I concur. A standardized dictionary file syntax could only aid an >implementor. Is there any reason why the C API couldn't use an XML >dictionary file, like the Java portion? I would imagine there is probably >no lack of publically available C XML parsers. > Well, as a purely practical matter, XML seems to be the logical choice for implementability reasons, doesn't it? I haven't investigated XML C parser availability in several years, but the last time I looked there were a couple. jak From owner-aaa-bof@merit.edu Wed May 2 19:42:44 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26501 for ; Wed, 2 May 2001 19:42:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 23ADC5E03E; Wed, 2 May 2001 19:41:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D0B755E18C; Wed, 2 May 2001 19:41:49 -0400 (EDT) Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 353385E03E for ; Wed, 2 May 2001 19:41:40 -0400 (EDT) Received: (qmail 30587 invoked by uid 500); 2 May 2001 23:46:26 -0000 Date: Wed, 2 May 2001 18:46:25 -0500 From: David Frascone To: James Kempf Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Message-ID: <20010502184625.A29494@newman.frascone.com> Mail-Followup-To: James Kempf , aaa-wg@merit.edu, diameter@diameter.org References: <200105022255.PAA13322@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105022255.PAA13322@heliopolis.eng.sun.com>; from James.Kempf@sun.com on Wed, May 02, 2001 at 03:55:49PM -0700 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk Libxml is pretty common, and can be gotten here: http://xmlsoft.org On Wed, May 02, 2001 at 03:55:49PM -0700, James Kempf wrote: > > >> OK, it sounds like you are in favor of having a dictionary > >> file regardless > >> of the language. > >> > >> Any other comments from WG members? > > > >I concur. A standardized dictionary file syntax could only aid an > >implementor. Is there any reason why the C API couldn't use an XML > >dictionary file, like the Java portion? I would imagine there is probably > >no lack of publically available C XML parsers. > > > > Well, as a purely practical matter, XML seems to be the logical choice for > implementability reasons, doesn't it? I haven't investigated XML > C parser availability in several years, but the last time I looked > there were a couple. > > jak > From owner-aaa-bof@merit.edu Wed May 2 21:15:13 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27863 for ; Wed, 2 May 2001 21:15:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DC5495E078; Wed, 2 May 2001 17:00:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3C0135DDD0; Wed, 2 May 2001 16:59:40 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 581615E02B for ; Wed, 2 May 2001 16:59:28 -0400 (EDT) Received: (qmail 17077 invoked by uid 500); 2 May 2001 20:49:19 -0000 Date: Wed, 2 May 2001 13:49:19 -0700 From: Pat Calhoun To: Paul Funk Cc: aaa-wg@merit.edu, Patrice Calhoun Subject: Re: [AAA-WG]: Session Termination Issues Message-ID: <20010502134919.H4672@charizard.diameter.org> Mail-Followup-To: Paul Funk , aaa-wg@merit.edu, Patrice Calhoun References: <4.1.20010501195709.017b4e90@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010501195709.017b4e90@cairo.funk.com>; from paul@funk.com on Tue, May 01, 2001 at 07:58:47PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Tue, May 01, 2001 at 07:58:47PM -0400, Paul Funk wrote: > I have several issues/questions relating to session > termination. > > Clarity of the draft > -------------------- > I think that the draft (11.8) can give the impression > that session termination has to do only with explicit > termination at the request of the server (STI), and > the STR/STA is merely a means of acknowledgement. hmmmm... that is bad. > > My understanding of the actual intent is that whenever > a session terminates, the client is supposed to issue > an STR to notify the server. The server is not meant > to rely on accounting for such notifications. Thus, > session termination serves two purposes -- to allow > the client to notify the server of session state and > to allow the server to explicitly terminate a session. > If so, this should be made explicit. yes, I will look over 11.8 again, and clean up the text. > > Use of STR as indirect means of acknowledging STI > ------------------------------------------------- > I think that the mechanism of issuing an STI to > explicitly terminate a session and relying on STR/STA > to acknowledge is problematic. > > First, it is unnatural. Unlike a two-way transaction, > there is no guarantee of a response. The server simply > hopes to receive an STR. The STR is a SHOULD, not a > MUST, so it may not be forthcoming. The text should state that an STR in response to an STI is a MUST. > And what if the > session is not active -- does the client lie and issue > an STR anyway? If the server does not see an STR, > should it retry the STI? It should return an MRI with the Result-Code set to the unknown session id error message. > > Second, what if the server that issues the STI is not > the authenticating server? For example, you might > want to maintain a server whose whole job is to kick > people off the network. I can see the possibilities of a start-up :) > This forces the client to > send an STR to the authenticating server, who is > holding resources, as well as to the terminator > server. This is outside the normal flow of processing. Not at all. If another server was to issue the STI, it would receive the STR. It could process the STR, and proxy it to the authenticating server. > > Instead of an Indication, why not use Request/Answer > to kill a session? There's no law that says requests > can only flow downstream. That way, the terminator > server gets the result of its request in a natural > way, and the client simply issues the STR to the > authenticating server as it would do anyway. So only an STR and STA, and the STR can be initiated by *any* peer? That still doesn't solve your "special purpose Diameter server" problem, but I don't have a particular problem with this approach. It would reduce the number of messages, and presumably, complexity. Others? > > Sessions that don't start > ------------------------- > A Diameter client may issue a request, get an accept > and then decide not to start the session, for whatever > reason. > > The Diameter server will not know that the session was > not started unless the client tells it. I think the > draft should be explicit about this case, and specify > that a client must issue a Session-Terminate-Request > for sessions that are never started, as well as sessions > that terminate normally. correct. > > In fact, it might be prudent to add a Termination-Cause > AVP that indicates the reason for termination, e.g., > user logoff, administrative, non-start, etc. ok, but this is really extension specific, and some termination causes don't apply to certain extensions. > > Sessions that time out > ---------------------- > The draft provides that a server must automatically > release resources for a session that times out due to > Session-Timeout or Authorization-Lifetime. But is the > client also required to issue a Session-Terminate-Request > in this case? yes, but this is to protect against a client that has rebooted, and will never issue an STR. > > Doing so may not be necessary, strictly speaking, but > it might be advisable to require it in any case. Thanks, PatC From owner-aaa-bof@merit.edu Wed May 2 22:46:34 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00700 for ; Wed, 2 May 2001 22:46:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 25CF75DDCF; Wed, 2 May 2001 21:25:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 131AD5DDC8; Wed, 2 May 2001 21:25:12 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 48B5A5DDAC for ; Wed, 2 May 2001 21:25:10 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA29931 for ; Wed, 2 May 2001 18:25:08 -0700 (PDT) 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 SAA00464 for ; Wed, 2 May 2001 18:25:07 -0700 (PDT) Received: from sun.com (dsl199-239.Eng.Sun.COM [129.146.199.239]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id SAA25678 for ; Wed, 2 May 2001 18:25:06 -0700 (PDT) Message-ID: <3AF0A5CC.7522DE49@sun.com> Date: Wed, 02 May 2001 17:26:52 -0700 From: jonathan wood X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diamter/SCTP: preventing head-of-the-line blocking Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The WG consensus so far seems to be that we need to include TCP at least for a transition to SCTP. But I would like to echo Yiwen's question: how should we spec out Diameter over TCP and SCTP? Should we have different sections (or drafts??) for Diameter over XXX mappings? Or perhaps a simpler approach would be, as Yiwen suggests, to write the protocol spec to SCTP, and then have a section stating what extra stuff is needed for Diameter over TCP... This would, of course, entail more draft editing (sorry Pat). What does the WG and the chairs think? Jonathan Yiwen Jiang wrote: > > Hi Pat, > > > TCP implementations that support the Congestion Manager would > > "probably" work, > > but what SCTP does provide is a way to retrieve information > > from the transport > > for specific sessions, such as RTO. This information is used by the > > application to detect whether a failover should occur. > > > > The failover section is in dire need of a re-write. I believe > > that once the > > new draft is available, support for watchdogs will become > > more obvious. > I guess it is just not very clear to me why TCP is mentioned in the draft > then. If TCP truely does not satisfy the requirements for Diameter, then > shouldn't the draft focus on SCTP only, and not worry about the watchdog at > all? > > If TCP is discussed in the ID because of the unavaiablility of SCTP > implementations, should there not be a separate section discussing features > required because of TCP, so that later on, when a stable SCTP implementation > is available, it would be easier to remove these additional features? > > Or am I completely off the base here? From owner-aaa-bof@merit.edu Thu May 3 05:40:52 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA17834 for ; Thu, 3 May 2001 05:40:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0403F5DDB4; Thu, 3 May 2001 05:38:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D99E15DDBF; Thu, 3 May 2001 05:38:53 -0400 (EDT) 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 D276C5DDB4 for ; Thu, 3 May 2001 05:38:51 -0400 (EDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f439coO01256 for ; Thu, 3 May 2001 11:38:50 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu May 03 11:38:50 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 11:38:50 +0200 Message-ID: <577066326047D41180AC00508B955DDA01D7FFBF@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Patrice Calhoun'" , "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Msg Header Identifiers?? Date: Thu, 3 May 2001 11:38:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, See enclosed comments. Martin > > Should duplicates be also discarded? I would assume that > > a duplicate message detected based on the Hop-By-Hop Identifier > > should be discarded, while a duplicate message detected based > > on the End-to-End Identifier is not so obvious to me. > > For Request, Query or Indication messages, I don't think so. > Perhaps there is > a problem in the proxy chain that caused a message to take > two paths. For > responses or answer, yes it can be discarded. > > > > > The introduction of the End-to-End Identifier was to detect > > when a Diameter client was re-sending a pending request, since > > it was impatient. Now that we have the DSI-Event "STILL_WORKING", > > and the Max-Wait-Time AVP, do we still need the End-to-End > > Identifier? > > A home server may want to minimize processing unnecessary > packets, and the E2E > ID would allow it to queue recently sent responses. Of course, the > Record-Route AVPs and Proxy-State (now Proxy-Info) should > have to change. Ok, I see that we might want to keep the e2e identifier. However, it remains unclear to me how a duplicate message should be handled by a server that detects it. If it only discards the Request/Query/Indication messages, then I guess that the dowstream proxy will retry sending it again and again, which is not right. Should it be informed that it is a duplicate message that is already being processed? I guess that we are having the same problem with duplicate answer/response messages. > > Anyway, the thing is that if a duplicate detected based on the > > End-to-End Identifier is received in the Home server while > it is still > > processing the previous request, should the Home server send an > > MRI with a new Result-Code to "Duplicate Message-Still Working"? > see above on home servers being able to queue recent responses. > > > That would make sure that the Diameter nodes on the way to the Home > > server do not retry to re-send once more the duplicate message > > as well. The "Duplicate Message-Still Working" would be an > End-to-End > > error of type Permanent. > I am not sure that we can guarantee that a dup message will > never occur, and > we need to handle such cases when failures in the network occur. > > PatC > From owner-aaa-bof@merit.edu Thu May 3 09:07:38 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21927 for ; Thu, 3 May 2001 09:07:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 173E95DE0C; Thu, 3 May 2001 07:51:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 06D9C5DE06; Thu, 3 May 2001 07:51:26 -0400 (EDT) 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 1DF915DDF6 for ; Thu, 3 May 2001 07:51:24 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f43BpMO18935 for ; Thu, 3 May 2001 13:51:22 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.27.159]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f43BpHJ00026 for ; Thu, 3 May 2001 14:51:17 +0300 (EET DST) Message-ID: <3AF14635.A7D6A7E6@lmf.ericsson.se> Date: Thu, 03 May 2001 14:51:17 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: transport MUSTs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi. I fear this may have been discussed in-depth already, but we were reading the specs and came up with the following: Servers are required to support both SCTP and TCP transports. Clients are required to support TCP. Our question is, why do we require the latter part? If servers are required to support both transports, wouldn't it be sufficient to require clients to support either TCP or SCTP? Also, section 1.1 says that Diameter should be transported over SCTP. How should this be interpreted with respect to the first information piece above. Or does this statement mean that when multiple transports are available, SCTP should be used? Jari From owner-aaa-bof@merit.edu Thu May 3 09:14:43 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22148 for ; Thu, 3 May 2001 09:14:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E7E665DD96; Thu, 3 May 2001 09:14:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D33425DDBF; Thu, 3 May 2001 09:14:22 -0400 (EDT) Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 5E42D5DD96 for ; Thu, 3 May 2001 09:14:21 -0400 (EDT) Received: (qmail 6355 invoked by uid 500); 3 May 2001 13:19:17 -0000 Date: Thu, 3 May 2001 08:19:16 -0500 From: David Frascone To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: transport MUSTs Message-ID: <20010503081916.F10879@newman.frascone.com> Mail-Followup-To: Jari Arkko , aaa-wg@merit.edu References: <3AF14635.A7D6A7E6@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AF14635.A7D6A7E6@lmf.ericsson.se>; from Jari.Arkko@lmf.ericsson.se on Thu, May 03, 2001 at 02:51:17PM +0300 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, May 03, 2001 at 02:51:17PM +0300, Jari Arkko wrote: > > Hi. > > I fear this may have been discussed in-depth already, > but we were reading the specs and came up with the > following: > > Servers are required to support both SCTP and TCP > transports. Clients are required to support TCP. > > Our question is, why do we require the latter > part? If servers are required to support both > transports, wouldn't it be sufficient to require > clients to support either TCP or SCTP? I believe the intent of that sentance was not to force clients to implement TCP, but to allow them to communicate even if they don't have SCTP support. So, I think the intent of that sentance was: clients MUST support either TCP or SCTP. The wording of the ID should be changed. > Also, section 1.1 says that Diameter should be > transported over SCTP. How should this be > interpreted with respect to the first information > piece above. Or does this statement mean that > when multiple transports are available, SCTP > should be used? I believe that was the intent. SCTP is the preferred Diameter transport. -Dave From owner-aaa-bof@merit.edu Thu May 3 10:11:10 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24869 for ; Thu, 3 May 2001 10:11:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F00035DF06; Thu, 3 May 2001 10:08:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E002C5DE7D; Thu, 3 May 2001 10:08:36 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 26F365DDDB for ; Thu, 3 May 2001 10:08:35 -0400 (EDT) Received: (qmail 2659 invoked by uid 500); 3 May 2001 13:58:23 -0000 Date: Thu, 3 May 2001 06:58:23 -0700 From: Pat Calhoun To: Jeff Meyer Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Vendor-Specific Values Message-ID: <20010503065823.C26582@charizard.diameter.org> Mail-Followup-To: Jeff Meyer , Pat Calhoun , aaa-wg@merit.edu References: <4.1.20010501200021.01798580@cairo.funk.com> <20010502140348.I4672@charizard.diameter.org> <3AF0CEAD.D3510BFC@hp.com> <20010502201614.A26582@charizard.diameter.org> <3AF0D526.6C4C9B39@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AF0D526.6C4C9B39@hp.com>; from jeff_meyer2@hp.com on Wed, May 02, 2001 at 08:48:54PM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, May 02, 2001 at 08:48:54PM -0700, Jeff Meyer wrote: > Pat, > > You sure are fast on e-mail! > > Could you point me to any thread in the mail archive where > you went over this? > > I haven't been following the group that long. And > if this is already discussed I'm really intested in > the deciding factors. I will let you have fun the with archives, but this would have been early last year. I will however, point to a requirement in RFC 2989: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | Mandatory Compact | | M | | | Encoding | | 7 | | | b | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [b] The AAA protocol's Accounting data format MUST NOT be bloated, imposing a large overhead for one or more accounting data elements. This requirement was introduced by some folks that have had prior experience with accounting using SNMP, and the problems that occured (they can chime in at this point, if they like). > > I'm asking, because IPDR.org is looking at means to effectively > create unique attribute identifiers for bulk self-describing delivery > of accounting information and Diameter's flat structure > seems problematic in an environment where lots of new > attributes will be defined. Note that IPDR is strictly > interested in the accounting aspect and not authorization/authen. ok, and we've discussed this in the past. If IPDR requires an XML like approach, a Diameter AVP could easily be defined to contain an XML accounting record. This should be quite simple. > > The simplicity of just using integer identifiers seems > appealing, but if the space of attributes grows like > the space of attributes for SNMP, not having a hierarchical > structure seems like a problem. Perhaps this type of > growth isn't expected. Correct, since the AAA WG has set a limit on Diameter's applicability. Of course, if other folks (or WGs) want to use the protocol for other reason, then we cannot stop them. > > Do you end up parcelling out ranges of ids to a given > service, so that version 2, 3, 4... of that service > don't end up with new identifiers which are scattered all > over the map? Again, Diameter would allow an XML, or any other encoding mechanism, to be carried within an AVP. Would this work? PatC From owner-aaa-bof@merit.edu Thu May 3 10:22:48 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25281 for ; Thu, 3 May 2001 10:22:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C4C455DE5D; Thu, 3 May 2001 10:19:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A4B0D5DE67; Thu, 3 May 2001 10:19:07 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 3751E5DE5D for ; Thu, 3 May 2001 10:19:06 -0400 (EDT) Received: (qmail 3193 invoked by uid 500); 3 May 2001 14:08:55 -0000 Date: Thu, 3 May 2001 07:08:55 -0700 From: Pat Calhoun To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: transport MUSTs Message-ID: <20010503070855.E26582@charizard.diameter.org> Mail-Followup-To: Jari Arkko , aaa-wg@merit.edu References: <3AF14635.A7D6A7E6@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AF14635.A7D6A7E6@lmf.ericsson.se>; from Jari.Arkko@lmf.ericsson.se on Thu, May 03, 2001 at 02:51:17PM +0300 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, May 03, 2001 at 02:51:17PM +0300, Jari Arkko wrote: > > Hi. > > I fear this may have been discussed in-depth already, > but we were reading the specs and came up with the > following: > > Servers are required to support both SCTP and TCP > transports. Clients are required to support TCP. correct, however, the actual text for clients is: "Diameter clients MUST support TCP, but are warned that future versions of this specification may mandate SCTP support." > > Our question is, why do we require the latter > part? If servers are required to support both > transports, wouldn't it be sufficient to require > clients to support either TCP or SCTP? The general feeling was that requiring SCTP on embedded systems was difficult at the moment, but this could change in the future. So clients should use TCP (but can, of course, use SCTP if they support it), and servers communicate with each other using SCTP. > > Also, section 1.1 says that Diameter should be > transported over SCTP. How should this be > interpreted with respect to the first information > piece above. Or does this statement mean that > when multiple transports are available, SCTP > should be used? Thanks for that. The last paragraph in section 1.1 needs to be deleted. Thanks, PatC From owner-aaa-bof@merit.edu Thu May 3 10:28:42 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25576 for ; Thu, 3 May 2001 10:28:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A5A2F5DDBE; Thu, 3 May 2001 10:28:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 91EFD5DDBF; Thu, 3 May 2001 10:28:26 -0400 (EDT) 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 78BE55DDBE for ; Thu, 3 May 2001 10:28:24 -0400 (EDT) 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 f43ESMN02163; Thu, 3 May 2001 16:28:22 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.27.159]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f43ESMJ08494; Thu, 3 May 2001 17:28:22 +0300 (EET DST) Message-ID: <3AF16B06.12B89B10@lmf.ericsson.se> Date: Thu, 03 May 2001 17:28:22 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: transport MUSTs References: <3AF14635.A7D6A7E6@lmf.ericsson.se> <20010503070855.E26582@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > The general feeling was that requiring SCTP on embedded systems was > difficult at the moment, but this could change in the future. Sure.. but see below > So clients should use TCP (but can, of course, use SCTP if they support it), > and servers communicate with each other using SCTP. Yeah... but this wasn't exactly the issue. The issue from our client implementation people is: they have SCTP and they don't want to do TCP at all. Given the requirements that we already placed on the servers (SCTP *and* TCP), I was proposing that it would make sense to relax the client requirements so that you could do either SCTP or TCP. This would be good for the client folks who have SCTP, would make no difference to servers, and would make no difference to client folks who have just TCP. Jari From owner-aaa-bof@merit.edu Thu May 3 10:42:41 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26007 for ; Thu, 3 May 2001 10:42:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B8D425DDE1; Thu, 3 May 2001 10:42:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A787C5DDDF; Thu, 3 May 2001 10:42:08 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id ACD6F5DDC3 for ; Thu, 3 May 2001 10:42:06 -0400 (EDT) Received: (qmail 3589 invoked by uid 500); 3 May 2001 14:31:55 -0000 Date: Thu, 3 May 2001 07:31:55 -0700 From: Pat Calhoun To: Jari Arkko Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: transport MUSTs Message-ID: <20010503073155.J26582@charizard.diameter.org> Mail-Followup-To: Jari Arkko , Pat Calhoun , aaa-wg@merit.edu References: <3AF14635.A7D6A7E6@lmf.ericsson.se> <20010503070855.E26582@charizard.diameter.org> <3AF16B06.12B89B10@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AF16B06.12B89B10@lmf.ericsson.se>; from Jari.Arkko@lmf.ericsson.se on Thu, May 03, 2001 at 05:28:22PM +0300 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, May 03, 2001 at 05:28:22PM +0300, Jari Arkko wrote: > Yeah... but this wasn't exactly the issue. The issue > from our client implementation people is: they have SCTP > and they don't want to do TCP at all. Given the > requirements that we already placed on the servers > (SCTP *and* TCP), I was proposing that it would > make sense to relax the client requirements so > that you could do either SCTP or TCP. This would > be good for the client folks who have SCTP, would > make no difference to servers, and would make no > difference to client folks who have just TCP. ok, I see your point. So the language can be changed slightly such that it encourages the use of SCTP on clients, when they have the stack. PatC From owner-aaa-bof@merit.edu Thu May 3 11:53:26 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27998 for ; Thu, 3 May 2001 11:53:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6ED545DE3F; Thu, 3 May 2001 11:48:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5D2185DE3E; Thu, 3 May 2001 11:48:32 -0400 (EDT) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 967D05DE3C for ; Thu, 3 May 2001 11:48:30 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id LAA27441; Thu, 3 May 2001 11:42:30 -0400 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id LAA23708; Thu, 3 May 2001 11:49:13 -0400 (EDT) From: "Mark Jones" To: "David Frascone" , "James Kempf" Cc: , Subject: RE: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Date: Thu, 3 May 2001 11:51:10 -0400 MIME-Version: 1.0 Message-ID: <013601c0d3e8$dfa46420$2096a8c0@mjones.bridgewatersys.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_012B_01C0D3C7.5771EAD0"; micalg=SHA-1 Importance: Normal In-Reply-To: <20010502172436.J10084@newman.frascone.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_012B_01C0D3C7.5771EAD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > I'd like to have a standardized dictionary. Preferably in XML. But, I > think the other configuration files should be left out of the API. > I agree. Standardizing on a dictionary format would be very useful for device vendors and server implementors alike. I have vague recollections of a Diameter draft which contained a DTD for dictionaries (an early version of the API draft maybe?) but since I can't find it, here's one to use as a starting point. I did not include Protected and Mandatory attributes in the dictionary entries since I assume their value would depend on the context in which the AVP was being used. Is that correct? Regards, Mark ------=_NextPart_000_012B_01C0D3C7.5771EAD0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw ggH9oAMCAQICAwS4ODANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDUwMTE4MTgwOFoXDTAyMDUwMTE4MTgwOFowTzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdbWpvbmVzQGJyaWRnZXdhdGVyc3lzdGVt cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMemr5diJO/8+r2Hj3Opr9LbaVAXFgo2 Fhu0tfSSdvlMy52Y67GMoJbv0I282FWO9z4bsnuSIU7y3arEmyA78mwjTSdt2GK5QJHT6jKOqF6M 81Q5j2fU3dQwCPiCQZlOqUJEA3PySRjUQNOgnRUhoSuzGd7IMJ3Y6oeMtE8a02nTAgMBAAGjOjA4 MCgGA1UdEQQhMB+BHW1qb25lc0BicmlkZ2V3YXRlcnN5c3RlbXMuY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEANyubKv2ajV9VxVe4xUDaqZbQ2DEXgGKSFWwsdC06zUucuCmeHHqT vLcoUnI8/dCbSnSwRrELpemSoqTv/99uW+jS6cN5320w1ZEBsC2RSVrSJd8LqxKALmMexgbywYvF /hMe120ctocvwnfbeZmzBIKSF7BDs8YPGzSWgsa5gKUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2 17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP 6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9 edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O +PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R hGvk+NHOd6KBMYICmzCCApcCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDBLg4MAkGBSsOAwIaBQCgggFWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDUwMzE1NTEwOFowIwYJKoZIhvcNAQkEMRYEFEcOSEg2apctYNEI3+lIg1LRBhVD MEkGCSqGSIb3DQEJDzE8MDowCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMAIDBLg4MA0GCSqGSIb3DQEBAQUABIGAI+omjhHPxjS/6FQrtgLjWrb7 2A+gzJ8H+Iu9I/bG3ipRS4FBkEdBgG0MWlBYAMxrFWAlcFy3NNKRM/vuv8sHBAuujIhqp2SlkWKp lptHkjzBKxyISHoxxKh0EX6wokMYEh+HWvUfZdZbQbjV3cS2D9SHZj3ZyLhGLVG5bAYcOkwAAAAA AAA= ------=_NextPart_000_012B_01C0D3C7.5771EAD0-- From owner-aaa-bof@merit.edu Thu May 3 11:56:09 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28106 for ; Thu, 3 May 2001 11:56:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9D0385DEAD; Thu, 3 May 2001 11:52:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 85E415DE64; Thu, 3 May 2001 11:52:54 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D233C5DE26 for ; Thu, 3 May 2001 11:52:52 -0400 (EDT) Received: (qmail 5601 invoked by uid 500); 3 May 2001 15:42:41 -0000 Date: Thu, 3 May 2001 08:42:41 -0700 From: Pat Calhoun To: Jari Arkko , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: transport MUSTs Message-ID: <20010503084241.L26582@charizard.diameter.org> Mail-Followup-To: Jari Arkko , Pat Calhoun , aaa-wg@merit.edu References: <3AF14635.A7D6A7E6@lmf.ericsson.se> <20010503070855.E26582@charizard.diameter.org> <3AF16B06.12B89B10@lmf.ericsson.se> <20010503073155.J26582@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010503073155.J26582@charizard.diameter.org>; from pcalhoun@diameter.org on Thu, May 03, 2001 at 07:31:55AM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, May 03, 2001 at 07:31:55AM -0700, Pat Calhoun wrote: > On Thu, May 03, 2001 at 05:28:22PM +0300, Jari Arkko wrote: > > Yeah... but this wasn't exactly the issue. The issue > > from our client implementation people is: they have SCTP > > and they don't want to do TCP at all. Given the > > requirements that we already placed on the servers > > (SCTP *and* TCP), I was proposing that it would > > make sense to relax the client requirements so > > that you could do either SCTP or TCP. This would > > be good for the client folks who have SCTP, would > > make no difference to servers, and would make no > > difference to client folks who have just TCP. > > ok, I see your point. So the language can be changed slightly such > that it encourages the use of SCTP on clients, when they have the > stack. How does the following sound? " The base Diameter protocol is run on port TBD of both TCP [27] and SCTP [26] transport protocols (for interoperability test purposes port 1812 will be used until April 2001). Diameter clients SHOULD support SCTP, but MUST support TCP if SCTP is not available. future versions of this specification may mandate that clients support SCTP. Diameter servers MUST support both TCP and SCTP." From owner-aaa-bof@merit.edu Thu May 3 12:05:40 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28482 for ; Thu, 3 May 2001 12:05:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 438915DDA8; Thu, 3 May 2001 12:04:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2E3045DDDF; Thu, 3 May 2001 12:04:44 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 62DB15DDA8 for ; Thu, 3 May 2001 12:04:42 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id MAA18366; Thu, 3 May 2001 12:04:41 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma018363; Thu, 3 May 01 12:04:19 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id MAA22424; Thu, 3 May 2001 12:04:19 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma022310; Thu, 3 May 01 12:03:52 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <2XDRF6AW>; Thu, 3 May 2001 12:03:35 -0400 Message-ID: From: Yiwen Jiang To: "'Pat Calhoun'" , Jari Arkko , aaa-wg@merit.edu Subject: RE: [AAA-WG]: transport MUSTs Date: Thu, 3 May 2001 12:03:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > " The base Diameter protocol is run on port TBD of both TCP [27] and > SCTP [26] transport protocols (for interoperability test purposes > port 1812 will be used until April 2001). Diameter clients SHOULD Except now we are in May 2001. can we maybe extend the deadline? :) > support SCTP, but MUST support TCP if SCTP is not available. future > versions of this specification may mandate that clients > support SCTP. > Diameter servers MUST support both TCP and SCTP." From owner-aaa-bof@merit.edu Thu May 3 12:15:42 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28830 for ; Thu, 3 May 2001 12:15:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 471C35DDDB; Thu, 3 May 2001 12:14:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 369995DDD4; Thu, 3 May 2001 12:14:59 -0400 (EDT) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id 22FC15DDC8 for ; Thu, 3 May 2001 12:14:57 -0400 (EDT) Received: from jariws1 ([212.54.17.27]) by fep01-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010503161456.TKYY20492.fep01-app.kolumbus.fi@jariws1>; Thu, 3 May 2001 19:14:56 +0300 Message-ID: <003401c0d3f6$2fc921e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pat Calhoun" , "Jari Arkko" , References: <3AF14635.A7D6A7E6@lmf.ericsson.se> <20010503070855.E26582@charizard.diameter.org> <3AF16B06.12B89B10@lmf.ericsson.se> <20010503073155.J26582@charizard.diameter.org> <20010503084241.L26582@charizard.diameter.org> Subject: Re: [AAA-WG]: transport MUSTs Date: Thu, 3 May 2001 20:26:28 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > How does the following sound? > > " The base Diameter protocol is run on port TBD of both TCP [27] and > SCTP [26] transport protocols (for interoperability test purposes > port 1812 will be used until April 2001). Diameter clients SHOULD > support SCTP, but MUST support TCP if SCTP is not available. future > versions of this specification may mandate that clients support SCTP. > Diameter servers MUST support both TCP and SCTP." Very good! Jari From owner-aaa-bof@merit.edu Thu May 3 12:40:06 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29590 for ; Thu, 3 May 2001 12:40:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D3F5E5DDC8; Thu, 3 May 2001 12:39:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C366D5DDB1; Thu, 3 May 2001 12:39:47 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 18A045DD94 for ; Thu, 3 May 2001 12:39:46 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id MAA18745; Thu, 3 May 2001 12:39:44 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma018739; Thu, 3 May 01 12:39:27 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id MAA26773; Thu, 3 May 2001 12:39:27 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma026554; Thu, 3 May 01 12:38:33 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <2XDRF6CA>; Thu, 3 May 2001 12:38:15 -0400 Message-ID: From: Yiwen Jiang To: "'James Kempf'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question on MRI Date: Thu, 3 May 2001 12:38:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk What about another error condition where none of the extensions that the peer advertised via DRI message is supported by the receiving server? > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Thursday, May 03, 2001 12:22 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Question on MRI > > > Hi folks, > > We've been discussing when to return an MRI and what the return > code should be in order to determine when the API should signal > an error locally. > > It seems like there are clear MRI error returns when an AVP or a > command is unrecognized. But there doesn't seem to any error code > or error AVP for the following conditions: > > 1) Version number is unrecognized. > 2) Vendor code is unrecognized. > > Any ideas about what the appropriate return action > to to the other peer should be? > > jak > > From owner-aaa-bof@merit.edu Thu May 3 13:07:41 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00409 for ; Thu, 3 May 2001 13:07:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 84D765DE6F; Thu, 3 May 2001 13:02:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 70F8C5DE56; Thu, 3 May 2001 13:02:25 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id B0F195DE68 for ; Thu, 3 May 2001 13:02:23 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04768; Thu, 3 May 2001 10:02:19 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA28587; Thu, 3 May 2001 10:02:11 -0700 (PDT) Message-Id: <200105031702.KAA28587@heliopolis.eng.sun.com> Date: Thu, 3 May 2001 10:02:11 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft To: Erik.Guttman@sun.com, mjones@bridgewatersystems.com Cc: dave@frascone.com, James.Kempf@sun.com, aaa-wg@merit.edu, diameter@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: HLERNERSTs00qSgB4dHkUA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk > >Did you have a spec in mind for your DTD? Base/API? > If the working group agrees, we could put it into the API draft as the basis for the command/AVP dictionary format, like we had the previous one. jak From owner-aaa-bof@merit.edu Thu May 3 13:22:46 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00881 for ; Thu, 3 May 2001 13:22:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F06CE5DE79; Thu, 3 May 2001 12:34:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DDE435DE6E; Thu, 3 May 2001 12:34:32 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 84C8B5DDE5 for ; Thu, 3 May 2001 12:34:31 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA18915; Thu, 3 May 2001 09:34:27 -0700 (PDT) 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.1p1) with SMTP id SAA03064; Thu, 3 May 2001 18:34:19 +0200 (MET DST) Date: Thu, 3 May 2001 18:45:49 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft To: Mark Jones Cc: David Frascone , James Kempf , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <013601c0d3e8$dfa46420$2096a8c0@mjones.bridgewatersys.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-LA_F2155733230R-1A-988908350=:313NCE.IlHAFeR" Sender: owner-aaa-bof@merit.edu Precedence: bulk ---LA_F2155733230R-1A-988908350=:313NCE.IlHAFeR Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > > I'd like to have a standardized dictionary. Preferably in XML. But, I > > think the other configuration files should be left out of the API. > > > > I agree. Standardizing on a dictionary format would be very useful for > device vendors and server implementors alike. I have vague recollections > of a Diameter draft which contained a DTD for dictionaries (an early > version of the API draft maybe?) but since I can't find it, here's one to > use as a starting point. See Appendix A of draft-ietf-aaa-solutions-01.txt (version 1 of my XML) I attach a new version. It should've been posted as www.diameter.org/diameter.xml Hopefully that will happen soon. Work went into it (making sure its reasonably complete, correct, etc) and there's lots more to do. Unless its awefully broken, please start work from that base. > > > > > > > > ExtensionId ID #REQUIRED > ExtensionName CDATA #IMPLIED > > > > > AVPCode CDATA #REQUIRED > AVPName CDATA #REQUIRED > AVPDataType (OctetString | Address | Integer32 | Integer64 | Unsigned32 | > Unsigned64 | Float32 | Float64 | Float128) #REQUIRED > VendorSpecific (Y | N) "N" > VendorId CDATA #IMPLIED > > > > > AVPCode CDATA #REQUIRED > AVPName CDATA #REQUIRED > VendorSpecific (Y | N) "N" > VendorId CDATA #IMPLIED > > > > I did not include Protected and Mandatory attributes in the dictionary > entries since I assume their value would depend on the context in which > the AVP was being used. Is that correct? I think it is important to add the flags - to aid in automatic interpretation of what the AVPs *should* contain and how they should be stored, reresented on the wire, etc. It is not the goal of the XML to describe the wire syntax - but we do want to capture all of the data which is associated with the particular AVP type. Erik ---LA_F2155733230R-1A-988908350=:313NCE.IlHAFeR Content-Type: APPLICATION/OCTET-STREAM; name="diammeter.xml.zip"; charset=iso-8859-1 Content-Description: default Content-Transfer-Encoding: BASE64 UEsDBBQAAAAIAFCVoyr5iqaQ/CAAAH/eAAAMAAAAZGlhbWV0ZXIueG1s1D1b d5tI0s+TX9HreYgzG2Rbju1kTi6HSHKiHesykuydy9mTg6Fts0Gg5WJHe/bH f1XdDTQIEAhEvslDokhQ96qu6kv1M0LI2w/flhZ5pK5nOva7g5PO8QHxfM02 NMux6buDNfUOyIf3z/DRv/UnvcXv0wExTG1JfeqSP5/hD+w3RSHjyWLwMyGL B9Mj/UWfGNTTXfOWesR/oMSjPnHuiHoz9cjTg6k/kKW2JreUEEV5L4PxgtXK cX1qkNs10chKc31TDyzNJf2hOhosBjNiLlcWXVLb13wgu8NfRjAynLlp61R6 xyP0m09tz7y16EtiOz6hwPc6foLEcCQwSVzkybSskESiwWfkjTEVsmsQ0wa6 U2A0Yjh6gHCI7th3jrs07XviO/A+F1eHZP5Jc5UhXYYdIDJSVoG7cjyKovaQ dPNujYjS5ISiMC3TX+PDObL1XpKV6/iO7lhZwtFszVr/F6wHPhnAjWN5HdkC HCAPJW3QO9OmjMAsMI6twE/Kk+kCAy71ImkLgwGYl4w/gGsy4fGfU2BcegdG yWRKiW6iCXkrqpt3ps6ZiaR0q3k0ZmyDKSOUD7yTo5cSqlJ2+5MmJ/I2Q/PB ikwdWdHAcJlQTSaIPHIaokaG8zyk53nKwZMyZfYQukYGOaYfelEFCafADK4G o8F4EUvokBOhPa5+Ai9bLoGIn2JV/p28SLGCTz/HyICUBq6F9sZiFVhN+DnB VieXBvbY4Y/TXl9dqIhnD5YQcbJN9S1YQsh3TNMhfrZBExjpYvGDMjYFL56M ZM9eEwKPIHYKGZEIYG/LspdRATG5KuZixDi8gTfTzoCvPatYiK2igver4pCm Q6IvDSZr+Bd9/wN+0B2DbuhXPJip3xDcFi4i7AJnnn4FLQyVJkLSKhw88vHl oML3i1AxbgVTIWD23aFGXkEguoe4FoAV3dssD/Bf5KPir8Wo+CP7MCpwwcoG tS+jQjkCPenBQ/N9+E/gUxzgc8JAlhyRtUP8m9kI/Mvt0l+vKHnUrID+tGGb 4uHnzCgxccExKsQapUEb6HOwF9qmoOc58QFcimNAmjfw5aAqtE3GrHAC9lmB /Gd5FL620kxXZGEGy4KyVbyNsjKWElLMqCCH8A9+RCoyaBYUh2kaf2kL9hxk RaLhWkgVJFtw5qAp0kJD/sqsmpnw9x/nUYBIShTKWRbKiEMzEtl5GXJuUMwe 0cHhbunPZKL71J+D19v3L8m1CJmn3ZfbwBAytH16T118Nnzv/NXL8Gv8eGk5 mo+/sw/4TQYY9ttJ9/VL8sl1ghX4BfBzZXp+ofllUMMHA40XXSlYL3kCrLl0 Cxibej4vHYULyrrXvNBasSqmlvPU2QQT2ijTTWig5H/kXlD0P2IBQWnnEL8+ F8GBOSP9T0Cxdg7Ldf9BY1Wr55s+hOgM+kUQZaghTbYoFCmP1FoDmV0UxdJx aSwJKMytwACSNooCm1BNf4hIDj1TteEnnJbgRAlsT6b/wFGmwMRMmVjyWSAv PpsQAvHC3OAeqIxdK62UtCBKRsUspYQcHSJQhQ0a4Ye/p1WCapL0YUNC4bgG dbGclSZRwkQWYWVQj4IBgic2tyZWOXOxc4EmJSiQboIBtfsayA3piL2U2MHy Fgqu5/bzl2I2Rxb1JhgQvr0pfqSBqSBXslmyRFLJIYiCiW9PifgI58B8B8ps DMZSelJB+U3GYMwWoxiMUyTuIwg6SjVBJbeQeg77oWiB6k6KHHWxuBrOec7E kk8eIX6cDX69Hs4G/bQdLrW1AubvrldgGT+zCTT432rNQtKKukvTh5D1oUgC MkoJHDn0XcgN7jTLoy9iAvajyQmrBiA/YIrEaQk0+O0a3Zcml6FlKXeWdi8k iyp7PnpO8CsoIzyNe9IHUPV/AhNc/8PmwHPHptZCr35JAi+qsRgYADuZLoaT sXrVyeQqqR2ZKnIY00DCf0NSXjwLgf04HE2vhoM+ORDPHJB07kVtw3E3OL3J 4LRA9uWYFZA62WBkZiWqsjgtYnDDLSGmuRqm1RJ/LEIBdRa959kvS3ziRzf5 Y5OWOG8rEgCePCOcDf/KEVPSu2NUSVeL+GFfpLlZQTbma7cWjzQgYpzTBZIM nEClPA9g+R9KHr0oR1tSbicNICQCTzz2WzhVnAcGNOPDY4HpPYD8bqn/RKmd AYd5tbPSYLTOAuMgNV6dkiaULeM9xl5FtOZK0QwDArdXSbYlRWuT4ZQI+FmM 5jITk1WJG99clrYRKWvY4IZlJYBT90GtCFQYvsId2wkwdQRfQghsGt/2s4Ry u/Z5UgGCGC+mDBKkGksYAv+cXfZI9/j0+F/lhcII2SIOeOtfXChvw+nnUEZv cS44BE3u/NXPR0fwd8ek/l3Hce+PwH6oa0P+Yrjane8dsX8UXbMenMBWQnDK yUXH/+YLmEcc6LOI7Tp/3sdgSD+cPP+IFcw0nL+P5u23O4gAFqYV7w5ODuTB /t0BSvIgEshbMWvynlxDFqOMMX99exR+GT3FbCfytRBIwv7fHuFDITMIIsog JGq6FyXJmYMXQKagLED9TuDnEfVetuhMEtIUnJ6mKOBGJKBKg9G7g3gwOkgN ye8OwvE3i3bQ27e1MvfRBfPojkY18laUI9JX8OWSYk6vCGEgKKXnUqQAQMo/ bntrwkNx3ktvj9Loyyly8bGfKccsVaaoz7auOPhtNy8OHSd/JE4W0UjNUhGT rcXGYZnl4SK6hpPRnKQYhPh+hfrDlXefdmKpJDHmmVdluUT6ybHvakLYKgbN hdLExRVLxh+LsZWZ7J5d7N2JPsNQowyniip01oTd5PPzumRYGoQz0crQqByS 4AGmGdn94Iv35ASeww/J75kiyFidQ0nGH0gom30TbIXdLYANMnJARnOqBy5u PdgZyWkBkhn1IHXQKVbx2j3bzVAdEUfzqgDNyLk1LQoWszsXZwXgVV2HfMDn JlUMP9/K3pQNDWz6FFWi9B6o/lW5oXpB7Kw2mCxczfZw24Yy7JceS36h6yqP D3s3Sh+zt5rDTlqEFaJris2GsocKBEQiax+1JP6qo0qu8Z4fl8U+4E9QQ5lq a8vRjL+O3W6Q/r2tOJeg5vR6UpaWsYPT702i7pZ25rCGzE0DsEyMEoCqrtU9 P61YlgyNRgXxqp10qunybpOR8yw5VuVD+i2DkxsOZv+8XOyfl0vTXT5pLlVm 9NFkG7caGy6656/LehdkaIHlKz1chmgkVAuAA9cFGQmw5QJw4s1IXW1EX3me Nt//szirXgVkFa849RpveEH4jF4vtzjLTWPJcUEeG6L4Mr/u9Qbz+e7ZcmHV EqG5VIdX17NBDTTdMmimk8nsCy5dDeaLGrhOy+Aajm/Uq2H/i3q9+FwD16sy uK7Hv4wn/xx/mYOqhpPxF5bL7IrxrBTGeYy2Bq7zMrh6k9FIHfcB3fx6Op3M FoM67F2UQbkYjgaT6zo28roMGvVmmsNVaTxvyuCZDfrD2aC3AKPsD3sqLjDu ztrJcTmU6tXoy3iyAKOc3dTR2MlJOReIxPhlMVPH88vJbFQDaal4gr49GC+E SIHnf4CQa/F6WhbtZDb8ozGspYJMFNDAaOHTdY1ofVIqxoyGEM3GnxBhDVSl QsxgNoOR4aPa//LL4PcayC6qIfs8GQ2+qP3+rNYQe/K6PNbFZPLl4/W8Do9v ymMbDadgntOr3+sP8N3jKjbaG82/sJ0yu+M7qahKdaYY2vbJ0Yr55rbkMkp+ a1c4+QmnvGbthDtzHgKoYYhLNSO5O2DIlxNiEHcmtQxcNU5uBuErKKlNAXx9 m628HMcQLGrf+w/Vlx/O35Qs1/sUNy2w82bKWB3utV68OC670mp/tZ0nG8oH dmRhxzIin46ywrnUTIsaCg/Cjc1lXJRdSplRw3Sp7is4NZGrmUaWdy4udqFJ meKx0uYU87r0DGq4b3m/QqkwP7BfTe1/A4VwtYJNFPHOwLfiKFHMnjj1hOHk 0dRxsubWcXxliMew+rPhC2AnfER+JxVx1Zg4tmHUxf06uBMLQPBdOzi5jTuq KB6cxa07Wvy2y3CSB80j/w5wQ5uuBy41pNiZxvhWHGuCEe/sgv/O/htqIGJz K9u4pDwCvWr3yPu/0RIY76PSvDMIwObKdR5Ng3F9T23qmjpZUs1m4wLgX1mU rbD5ONWv6fyY8O06hiN2NuEzbIokOqC05OSJ7fFsq76GW/jht2UH0T/7IYuF 8NQYjEx4zhmhgQGvAC0tKdk3tSQb7XLBDbxinGKinS/KmxU8GzGAp/Rt6Rg9 fIcLu+IYtqbruJRuMDMGicDXOGcMg6SwN/mAv8dpw64AviAP93Ni4gCvCoGH fQPY1rOnB7YjUFi3Aaau+14IWYCDV9GGAXMCrrRxHcIE6Niy1sRwbIrHLYAs xzL1NbxrUJ3Pkx7SDiQllgNPosrYCrMHoB8pAAYy6LcVtVk+Qn39RTllXrxq XJkzIV5Q6KyCr6RUuqE7KV7gb5+dJapTVVUhbVBDAD+A8nXmBkDwkeOyLx3X /C87vMC1y5R5S5nXxVouJ66zxsWl2t4THh2fL9RK0lLT0kKJxF4w5xYJQtN0 zL0g7bln9o/C4v0wuDTQNJn5VJbFeQlZ1Ni5Lm9dfxsdh4w2grLvxBgVMi02 jkQ7VnALTfhU/J7hJLYPldggKT2ds1fS1jwIK8rxWbxlEsXBUEX/rTXov5fB xONqmuXijZPSYYBEYlSw7FNrMS5RA+Buy6nmeU+Om5XnkTLbv+QkKsHCaRss 9D6r0/2x8KoNFsBeireYkd02J+ZyddYWVzmlCymxOJVLfObabsayWdP8YPTG tHuBmtiJp4y5oGjSS0wGSXNAV869aWdM92zOMBXA7W7CvXSBbKMu4NNNwD0Q 7C2MbM1Q/qoAQTMsnG1imAT+LYwhtUGfb4JWDRjJTbRRPAZbF8HFJgLwN6w0 lyu/LvDXGdRLeRyZ2Na6Lo43BeqtyEl+qLj4TqGC26cS1f31okV+iJhO5YWL fPHnB4OyEPIDQPoXYS8rKKIXmvWVzOjSAZtRed0QieRQnanTF00FiUwi5C/x zyfWwu4Oq/+VC3kl7j6fw7hp0SvT/no0CizfxE9RZ6cE1GZiTba0fltbEDJ1 L0HacPrb0fwqcyNxSdQkHY6g1pCxdqB0mq9t/cF1bCfwajrb6zaSCuFZrWZL b9plbEz9peZ9bYGxk+PvGx9nTuBnLy7tEB6PScaQiDM3u4W3k0KHnYMciCvI X8GYRX2vbojoFmLExiHUZv1V6uH9IUKYkcIxvnAmUqCTQP9QIRScnLTiMqaF Zf6woOqruD6Zz1Ar1bhwi9Hiuuma6aSVUlzQ34PMzRUzWU3XScdbnXwn34u8 /QcJ8M0/yKI3PYIR+IFqBnXZ0kDMWNN1GYz3e0CU5eS+pitXf8wroymwr1bm SVhdiUNkzgJg005/9p2GR86nmG9oanTcMIMFtWwqV1hb64eMCmRmpWr9XYoQ 8DLSs6jm7qUUwTmokeaxXrBSfl2x9siflbhSF1X4z5h1+K17pkzVfhUo59lQ FqfTyXxHKb4ukmK6lopV9msA8iSHXsBCCWtOtWZzf2xlFZcuWMqBf8BzbKr7 YjPOiwSieuHnvL3wA5znT2vWGqNbKaBmdGWtFbEG3UIMbaV4CmeOlDFvQbZ3 trrHrbLVRorbbTPFhTEci78WDLDbZuYLKVxrfLUSLYaGRQt6n9SKd6et+RBo Zu6LXS0teNJpK9UvMgZktctZKzGCLYcauNpwZ7YRzE9bLF4gWayX2Bew0cqq bszGOHu/cNPKaTG1Q67Yntci1ezGxUWLoxBbe/E166vCVjOaNrM25/ljVsbU f3Lc5rlpc3I/5uYPx6ZN29h5O+MpbrfpPeCoat/Txh3lPHPsbGHOJdyt0sT2 jvw5F9Vb23rNKZd5RRBZU43z/rg8nOIlAwaL83XTOQlPUeWtGWQBfbUN6ElZ oPlTLDem6weaVXOKZTpUL3edXtk8uSdPUpHP/auemFEB77Jtau0yPZWxc+O3 TvesCttvskBcVAJxkmH5nzqn5FL7tqPwToqX4+rO/nf3Cv10r9BfNQc9BJnh PwP/ge2+rWQGGR70rT+/qgQjY6NTj53o29GQCmc5yT9hgLBwV4FCJshxbe28 KYtuOBgMyOvjLkS7urOh561UaWywvDKXZvMbPFuZsolT/uJNqk0VMpvnb/fC 1iLAsWNrGZOwx6xOOuyHZOMzDlnkR3l9dHLfG1HDDJY7vz5lFzlS3vqr8ts9 y6S2rwxsY+WYrPFjZRD88EYtENIu9R34Nx+xTytTbHEvuVwYqofOiJ0v+WzR 91ECbiXdkQGhg5IQjjbtejNj17J61zJs8d00eKWrpuvBMrA0fiEPHuFJuFpH fn+A99WsHB+nsCDn9Dk4vOLVvA9cfk2p6RGXintN2UU0MoAkbHb5lsxDmuaC UNrK1FYyMuxnY3z2ADpFV1R8R2EfBCEYluN9ptPpov4+0y17s7Q1pAqLJwdv pH3SXAMpOLzqXtbGe1oSbxbjV90GGC/OLlVPxw1jwl+kxrrSNt/FqD4Vxbtn o+IuSwo3IISa2M+LsKejznAq75VHT//M9/SIE8LCV5bsokf1c+VF8J0rzOFU YZtnsJentvIwlLEDrPD9sL6GijcP8A0AI9M2l6CmPEpGw7HCqeGTA/UoelNR axIxci/qsHfspvoa1FxGxytZdZ/EGXW+tJiS2qfZoLb2tpTXH7U1Hm60IkcT Kxi1t7xuKbwjQ4kdu2Zl1MoSSWbC22yF1MqiSG7uvOdK6byVxZLctH7f3LWy 4rBZceyZrdetLHrnFEP7566VKZWcMm3fvLUy3ZJVQTYaE9+0svyVV8ruWUdv 2vSujSp7z8y9Om5FdeX5IDsz8r1WL9utuqWupIMvk/FVVrPHBsvrsBtpM7hO S+KSmayZdr467n4nuxiw3hh5t1+QHZbqW+mXUtgnjfVLiQClG/sQqbWPqsaN j1Q1s/ERkZr5YNGJfXzg0egaQyj72D3Lco8qLVHfs9dSjY14aYZn9TRxnTSe swaAboctX2/2D5J6+Jxv9jNCNaS6+GxnPWxipKpqec7Vol5kYf+uWK7sTdGD q4OtOZMSeNK8UGrYAksjXsCOgd8FFnszAvxkWlbYu5O3mUrA4TOxK356AxI/ 9jKKlzdN4tvpePco0drNKCPo82YEHe2G4T3T1N6wtLx7ww15Y+u0uHsSayDl hX2j2Ium5wUgIKJHm3B4DGCXniZ0pREDqnYlWJU2vYsyEmH9m5Kdn1ruKZV1 l9d3aDAFslaW90tfOT5vu8VUoQQ2+k3ltJg6ayfx+jWg8CT4Bv3WdNJ/dtxK YhxKW1k4X2nRodZEUlFuWTW6yqfaiph8kU75t+TbVSusvknXHpV/S76jsNKL kbQ/avcFL5ZY3/vuq/EpVnZJwEjOGmV4pSaNpoOpfK0mRnx+q2bUZDuwDBnC bXSxOGvgiDclC7aJt6I6br43GIYn03/ARAalLQPg9yIDrS/ZWEy/adg5tdJK ZfuhMZ1aJkJj0UAf+mmkUhbWyOF89mvZ4R4ejYZ70bA0Y8i3cWkIR297DUrh Q77viXa8UhYqbk4NVgZeEMsQ8PVknd25iqfiHZcnaI5L5SvD2PAgdJ/Dlsjp OHZxj7cnN6pkGYmDjaCeNNv3OGU6xdZW/gN/LxU1o3wtMi7R7vLQe1EiN7m4 aCBb2+CWHYdEJc7KK3GWlxtrTMNROiyelnNkqdV9lngobhzAhsOPVGpUS7jc E8k0eTS1hP64WjlS7Ta0AlGcrFOPRcoHck1wWjPUbZImL8qz+Q4ImS6PjK7n CzRhl/oB5E1GwvGLVfn6r5Fmpu+ljaNIWxmmxyhQ2BDlfIdOpkICPYZ/a0PT nDTz9HhLx3l5xOyN5nl3S9YaLbNuozbRDQEhcW6xFTeh4S2XuNvHYds4ZCCi +p0fjYajAXk8jZxaRDQ+H9Ahf84ue1BLnZ7+iyGWQaD7UwyXQAZNLDjHuBl0 RppHffRh6f3INFEB5Ufa7+9K/Fpkts5epU6r5EQ5PrRkqM2VcnLStvtkcp3b DDjPfdo5bD7CM9n0Ppoxa/wIXLeVUi1mY8WaVDbNRCsLgaOxouIMXgCJd5Vi M1VYJcsqAXQ+HRZWY4mXotYdyT1NUMyvAp/FaeWKXZ4jHiwNWAYIAuNAdn59 cnfn0aItuaJW/H9cKSa0s9tiTt7AhzDFtQZSJo/bWu8dyGselliA8Afwa19z 7ym2bZHA4MSwyPlxPvnzC+I9YD1JNN+n2KcVxkYYX00sRVj+L78rq4r1nAr4 jld+YwYPkazocdgsZ/Jt8GXRNBfSjjA2YeVZpcxsXZvb3KVxHfMrrDCvv12j flmaQ/OlRw6TMiRk5bjsKXgzPRTAiPWC1wdC6+FNG5onQzCRy+iOj8i4DkOr i3TObR3t8gWDk0qy8MYOvPaA4k0e7BQOW3RImBFLEb1ghbVLCFcGI0ZedkYd cilmm52/isnIAXEvZiKsQ0uIlN+FEnpxllDDyJAIB2aHdl4SFhT+SgKOhoxm BexwsOyEQK4DovG+FEqQAZTRR5YSZBjZ+qiijtNuK7skIQhASXupKr/QNak1 o57MDKYUPlZKcniwgAJfmYfU1JhzLjCOBMtYgEazQahYfjfh8v/Ku7Leto0g /N5fQeSpBUTXlgLDBYoCjGVBAiLbsNwAfSpW1NoWQpECD8n+9905llweoiiF oh00L0EU7jUzu7NzfLMruYAQp5cDhDwFQGR8HQf6Sc2K1PjSlSPLQvVJyTE8 W7RE2/JWDW/B8KMwWKEIzZI5zP9TD544UiZRskJESv5gL9hWqUklhLC/yzf7 HE2rI/f/oJuCOUT9cesCd4zEdSZyarlq0Wrp7yly448ncv1OMqhHJvVPcca9 1yFXR9lu6sM4p9nMH5my3VTfGv8fZbaTnHyi7AlvPAdQ9ucOqxsat73ru2MN +vZ8GVvBWqh7OsULeiXHCMW9kogfP1zI19wV3vPwW19CnhsE4ul9RDIAQumC j0NpxSfQhRRJpeBSXvllTZQOBPBgDFbsQgKVP7gdW96zbWc95K4w6ipAvgjF DTeU4H8S6RzS0F2Oz1EUuEui7lzGW3xnUXuioBH4oqKjLxadIK7VIaJOaAJT hFDestW9cNiCuylt54Cy/xALHnSCl6ELNxZZ7PCpm0E3tTAhq9V2nhFC0+Ha OvFrKBndLIMkAkV/69RIaWsVMrspkWmuC5jWCccaPOBGuQStb7/JvT1S2iQJ pf1NuuCPa9tVWJ2PsFjAC9aQcQfTpI8g2yg2m7MrcBSEUo1r4U6y1BT5d2Vj j6xg61c6cSPI/hT5xwgXwUpRE6zxUre1etA6FkFknm50GJC86JDDjz/uWA8p yo3pePB+N+5EG542BNA5fjAkspy0hIZxFLa29voaZ8xe2zyEN2LpFaqqHTXy xWU922/ZZDeyDH4MzNXfN96o1fEu65lJt5QWx7voXzWVnolva85mtXIPR611 lgazE+PVOCPXUZdg4xzJoF7T5lCv6UMOeONjQFspCj/uYcIjYGoiIzsXW7qI /u1RyifHwaqAYoUYmwEWK+CbMPfaCFlSGmf+eFdGTsTpuJl1+ISP1XI2Z2Ws CcwiVJeJG3MuKS67CRro3GoFH5W7ympQ2rQ5KG1aBqVlim5cAVDDpjukI83O NbdEPRkuWiCDsVEpus6yOm4OS1Sf1tBBx90RMEaa25o8pRzPfoa2FFoUEd1a gIIC0nxR2nw6PHpZU4JDIuwMLxRwvWgiPv326abFZ9wc0zh2doqPQRTw5cSR BReB3LOvRqS7lOxdzdMzy6T7CwwhcAhB1wxIm+Cf2fTRifEkrtgURLZH5wd/ BBwgfGS63ytMRJJ8KBe3nz2Ddtnj6OURCnLsTJpzaFIj2KMMdao2e7LmQxTB BuuYjs4MVors3r6wS8dg8FYQcUyhh082ywjDVCz2Z+mMmNq5DBfdZ8F2hYlX 2euUpLsf2fCH9VOkwzuuq9QN6sTuM+FFOrh9ftV1Hm/Vyncn8u7I4/189V7P 7WbTV4cUJLa/Q6lG80f4c/Pt5vbx34eb67uHYfH/HD9H8Q3sX5p4issn3zum lRVbY6KaAPyTHS/V/pfY/kVd4wLXTcB7aP26ksKn0LaIy+0lQKvCGPc11Dfk dCnqCAqCRstV4sXCl0ES/XZW7ACd1CHNN8P7IMDdDAV4ciNQ81ROgEDtPYsP RfgN0VbcL0+JP8tN4ZSGc3Gqs0fnoRkXZ0DRnjWBjb9c0bpmcbBmxmKh1WIP RU5r1mrEP579ipVREoLxWmzOyW7A+Tk4+bESw1nlxHgWxR5y0raMlxhd8K3s LNJoKFxPsXXG++x7UwRwNSgqJAolOSC9xyOznUBcx0Hb5PrgEK5PbpU6mEwb 8j3lcarcYWGY4VmxeyvJi9KSkpML8SpulhpXE9rYa7SRX5WdVAD3wJ8T0PXz Ybvp7r4Voip61ZBmD1GNT0v7oQFRj6ZiTf2cborLOcPJiBXkkVHLuiV0krxh aHo+aenvDT59coS6r1tRJ3EwY0VD6SnxVO2m4tX+ImL3pf01dRL+2rUm9Q/x 1v6aOgl7le+Y+95iPXY5l+9/i54h8r6VR6IqHni6uXW+fL056DnoijeehpPZ 3m66cP5W2067vL/Nnb+mvGnH73Vzx+91pTOtUIYh5wPOuX5Nd698dV8E1GGq vn5gO66hAUUcmngE9rgc+ZdDCZU6X6+bO1+vHfMWLNzvfrD15OIZL8IVTOCp 5LQ/dlSahiZ/Lp0Ho5NZsYLUX27qZrS7qSSCDGVaiSHOj2JWKNOTggpl8FkK MsfyJoq5/BADd0NetFJX5JBTUyA3IFb5B/poGDgkhrGHPitklhuKXU/s3OJu SIi4bhm2J9Q/tsiHD3Q22tT5J8Vgae/hOgnXgY4RKENBdRhLl3LInoG+MTw4 kSzIlGgihP2TCOF94Hm6UNp9czG837NdZ6UwjC5e4RIjdP2UCCx69AOAMZ/t WKqV88hZ8SYfI3UWxNabjGlco03Ititm8wGy0ZP6vXtdJgNz3LcS6mdEBcMp 31xpJWKd/xwY1+hGDsTBSTgFWi6JmFez5kXtZpMGR2uJU3RiZqVulAhr+J+h QnivRVQxcM77xTgBnhLI2TiznGJBHTa2xTwgkCK3jQUUX4Hf1IDasTAb3/39 dagr7fnVRDHruvTogC8cQXRNwI0vcUytk8EJgc0r5gjoRxc80jRjnrRH6aYw ocLplJEEE1NbnzPfRk7nx/7zd+3k/euX/wBQSwECEwMUAAAACABQlaMq+Yqm kPwgAAB/3gAADAAAAAAAAAABAAAApIEAAAAAZGlhbWV0ZXIueG1sUEsFBgAA AAABAAEAOgAAACYhAAAAAA== ---LA_F2155733230R-1A-988908350=:313NCE.IlHAFeR-- From owner-aaa-bof@merit.edu Thu May 3 13:39:06 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01453 for ; Thu, 3 May 2001 13:39:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6CDA25DE27; Thu, 3 May 2001 13:32:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5C00D5DE26; Thu, 3 May 2001 13:32:12 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id D34FE5DE20 for ; Thu, 3 May 2001 13:32:10 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21559; Thu, 3 May 2001 10:32:05 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA29523; Thu, 3 May 2001 10:31:56 -0700 (PDT) Message-Id: <200105031731.KAA29523@heliopolis.eng.sun.com> Date: Thu, 3 May 2001 10:31:56 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft To: aaa-wg@merit.edu, diameter@diameter.org, dave@frascone.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KHRRjOuixXvSICXOT14mjQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk So do we have any volunteers who want to push this separate draft forward? jak >Delivered-To: aaa-wg-outgoing@merit.edu >Date: Thu, 3 May 2001 12:27:35 -0500 >From: David Frascone >To: aaa-wg@merit.edu, diameter@diameter.org >Subject: Re: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft >Mail-Followup-To: aaa-wg@merit.edu, diameter@diameter.org >Content-Disposition: inline >User-Agent: Mutt/1.2.5i >X-encrypt-payload: no > >I agree. > >On Thu, May 03, 2001 at 10:01:10AM -0700, Pat Calhoun wrote: >> On Thu, May 03, 2001 at 10:02:11AM -0700, James Kempf wrote: >> > >> > > >> > >Did you have a spec in mind for your DTD? Base/API? >> > > >> > >> > If the working group agrees, we could put it into the API draft as >> > the basis for the command/AVP dictionary format, like we had the >> > previous one. >> >> I would prefer that the dictionary be its own separate informational RFC. It >> is independent of the API. >> >> PatC >> > From owner-aaa-bof@merit.edu Thu May 3 14:11:59 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02325 for ; Thu, 3 May 2001 14:11:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EF70A5DDDF; Thu, 3 May 2001 12:07:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D9B6A5DDB1; Thu, 3 May 2001 12:07:11 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 63BA65DDEA for ; Thu, 3 May 2001 12:07:07 -0400 (EDT) Received: (qmail 5887 invoked by uid 500); 3 May 2001 15:56:56 -0000 Date: Thu, 3 May 2001 08:56:55 -0700 From: Pat Calhoun To: Yiwen Jiang Cc: "'Pat Calhoun'" , Jari Arkko , aaa-wg@merit.edu Subject: Re: [AAA-WG]: transport MUSTs Message-ID: <20010503085655.O26582@charizard.diameter.org> Mail-Followup-To: Yiwen Jiang , 'Pat Calhoun' , Jari Arkko , aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Yiwen.Jiang@tic.siemens.ca on Thu, May 03, 2001 at 12:03:30PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, May 03, 2001 at 12:03:30PM -0400, Yiwen Jiang wrote: > > " The base Diameter protocol is run on port TBD of both TCP [27] and > > SCTP [26] transport protocols (for interoperability test purposes > > port 1812 will be used until April 2001). Diameter clients SHOULD > Except now we are in May 2001. can we maybe extend the deadline? :) sure, I will change it to state that 1812 is to be used until a port has been granted by IANA. PatC From owner-aaa-bof@merit.edu Thu May 3 14:12:01 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02336 for ; Thu, 3 May 2001 14:12:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6F7805DEFD; Thu, 3 May 2001 14:04:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5D38C5DEFC; Thu, 3 May 2001 14:04:34 -0400 (EDT) Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id D081F5DEFA for ; Thu, 3 May 2001 14:04:32 -0400 (EDT) Received: (qmail 3182 invoked by uid 500); 3 May 2001 18:09:32 -0000 Date: Thu, 3 May 2001 13:09:32 -0500 From: David Frascone To: James Kempf Cc: aaa-wg@merit.edu, diameter@diameter.org, dave@frascone.com Subject: Re: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Message-ID: <20010503130932.I16328@newman.frascone.com> Mail-Followup-To: James Kempf , aaa-wg@merit.edu, diameter@diameter.org, dave@frascone.com References: <200105031731.KAA29523@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105031731.KAA29523@heliopolis.eng.sun.com>; from James.Kempf@Sun.COM on Thu, May 03, 2001 at 10:31:56AM -0700 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk Sure, I can do it. On Thu, May 03, 2001 at 10:31:56AM -0700, James Kempf wrote: > So do we have any volunteers who want to push this separate draft forward? > > jak > > >Delivered-To: aaa-wg-outgoing@merit.edu > >Date: Thu, 3 May 2001 12:27:35 -0500 > >From: David Frascone > >To: aaa-wg@merit.edu, diameter@diameter.org > >Subject: Re: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the > Diameter A PI draft > >Mail-Followup-To: aaa-wg@merit.edu, diameter@diameter.org > >Content-Disposition: inline > >User-Agent: Mutt/1.2.5i > >X-encrypt-payload: no > > > >I agree. > > > >On Thu, May 03, 2001 at 10:01:10AM -0700, Pat Calhoun wrote: > >> On Thu, May 03, 2001 at 10:02:11AM -0700, James Kempf wrote: > >> > > >> > > > >> > >Did you have a spec in mind for your DTD? Base/API? > >> > > > >> > > >> > If the working group agrees, we could put it into the API draft as > >> > the basis for the command/AVP dictionary format, like we had the > >> > previous one. > >> > >> I would prefer that the dictionary be its own separate informational RFC. It > >> is independent of the API. > >> > >> PatC > >> > > > From owner-aaa-bof@merit.edu Thu May 3 14:15:00 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02418 for ; Thu, 3 May 2001 14:15:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EA3815DDE8; Thu, 3 May 2001 14:14:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D89A05DDE7; Thu, 3 May 2001 14:14:43 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by segue.merit.edu (Postfix) with SMTP id 29DFB5DD94 for ; Thu, 3 May 2001 14:14:42 -0400 (EDT) Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id OAA00396; Thu, 3 May 2001 14:14:38 -0400 Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Thu, 3 May 2001 14:14:28 -0400 Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KHAN7MZJ; Thu, 3 May 2001 14:14:28 -0400 Received: from mitton.nortelnetworks.com (47.16.86.121 [47.16.86.121]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KBYWFXLG; Thu, 3 May 2001 14:14:28 -0400 Message-Id: <4.3.2.7.2.20010503141423.03686830@ZBL6C016.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C016.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 May 2001 14:16:20 -0400 To: Basavaraj.Patil@nokia.com From: "David Mitton" Subject: Re: [AAA-WG]: Mobile IP Extension Cc: aaa-wg@merit.edu, pcalhoun@diameter.org In-Reply-To: <20010502131819.B4672@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Sender: owner-aaa-bof@merit.edu Precedence: bulk Is there a plan vis-a-vis MIP v6 support?? Dave. At 5/2/01 04:18 PM -0400, Pat Calhoun wrote: >On Wed, May 02, 2001 at 03:08:34PM -0500, Basavaraj.Patil@nokia.com wrote: > > > > Pat, > > > > Would you agree that the current Mobile IP extension document > > (draft-ietf-aaa-diameter-mobileip-02.txt) > > specifically deals with Mobile IPv4 only? > >I believe so > > > If so would you mind changing the title to : "Diameter Mobile IPv4 > > Extensions"? > >Not at all. > > > > > And maybe add an applicability statement (to MIPv4 only) someplace in the > > document. > >Sure. > >PatC ------------------------------------------------------------ David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Wireless Solutions, IP Mobility Billerica, MA 01821 dmitton@nortelnetworks.com From owner-aaa-bof@merit.edu Thu May 3 14:29:14 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02737 for ; Thu, 3 May 2001 14:29:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 24ABD5DF10; Thu, 3 May 2001 14:26:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 082D35DF0F; Thu, 3 May 2001 14:26:18 -0400 (EDT) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 339055DF10 for ; Thu, 3 May 2001 14:26:16 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id OAA29047; Thu, 3 May 2001 14:20:20 -0400 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id OAA27813; Thu, 3 May 2001 14:27:04 -0400 (EDT) From: "Mark Jones" To: "James Kempf" , , , Subject: RE: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Date: Thu, 3 May 2001 14:29:00 -0400 MIME-Version: 1.0 Message-ID: <018301c0d3fe$ec643d00$2096a8c0@mjones.bridgewatersys.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0178_01C0D3DD.642EB670"; micalg=SHA-1 Importance: Normal In-Reply-To: <200105031731.KAA29523@heliopolis.eng.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0178_01C0D3DD.642EB670 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit If the goal is to define a DTD for Diameter dictionaries purely for the purpose of attribute encoding/decoding (and NOT for validating the message format) then I'm up for it. Regards, Mark > -----Original Message----- > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > Of James Kempf > Sent: May 3, 2001 1:32 PM > To: aaa-wg@merit.edu; diameter@diameter.org; dave@frascone.com > Subject: Re: [diameter] Re: [AAA-WG]: Re: questions and comments > regarding the Diameter A PI draft > > > So do we have any volunteers who want to push this separate draft forward? > > jak > > >Delivered-To: aaa-wg-outgoing@merit.edu > >Date: Thu, 3 May 2001 12:27:35 -0500 > >From: David Frascone > >To: aaa-wg@merit.edu, diameter@diameter.org > >Subject: Re: [diameter] Re: [AAA-WG]: Re: questions and comments > regarding the > Diameter A PI draft > >Mail-Followup-To: aaa-wg@merit.edu, diameter@diameter.org > >Content-Disposition: inline > >User-Agent: Mutt/1.2.5i > >X-encrypt-payload: no > > > >I agree. > > > >On Thu, May 03, 2001 at 10:01:10AM -0700, Pat Calhoun wrote: > >> On Thu, May 03, 2001 at 10:02:11AM -0700, James Kempf wrote: > >> > > >> > > > >> > >Did you have a spec in mind for your DTD? Base/API? > >> > > > >> > > >> > If the working group agrees, we could put it into the API draft as > >> > the basis for the command/AVP dictionary format, like we had the > >> > previous one. > >> > >> I would prefer that the dictionary be its own separate > informational RFC. It > >> is independent of the API. > >> > >> PatC > >> > > > > > ------=_NextPart_000_0178_01C0D3DD.642EB670 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw ggH9oAMCAQICAwS4ODANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDUwMTE4MTgwOFoXDTAyMDUwMTE4MTgwOFowTzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdbWpvbmVzQGJyaWRnZXdhdGVyc3lzdGVt cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMemr5diJO/8+r2Hj3Opr9LbaVAXFgo2 Fhu0tfSSdvlMy52Y67GMoJbv0I282FWO9z4bsnuSIU7y3arEmyA78mwjTSdt2GK5QJHT6jKOqF6M 81Q5j2fU3dQwCPiCQZlOqUJEA3PySRjUQNOgnRUhoSuzGd7IMJ3Y6oeMtE8a02nTAgMBAAGjOjA4 MCgGA1UdEQQhMB+BHW1qb25lc0BicmlkZ2V3YXRlcnN5c3RlbXMuY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEANyubKv2ajV9VxVe4xUDaqZbQ2DEXgGKSFWwsdC06zUucuCmeHHqT vLcoUnI8/dCbSnSwRrELpemSoqTv/99uW+jS6cN5320w1ZEBsC2RSVrSJd8LqxKALmMexgbywYvF /hMe120ctocvwnfbeZmzBIKSF7BDs8YPGzSWgsa5gKUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2 17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP 6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9 edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O +PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R hGvk+NHOd6KBMYICmzCCApcCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDBLg4MAkGBSsOAwIaBQCgggFWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDUwMzE4Mjg1OFowIwYJKoZIhvcNAQkEMRYEFLs3jaZGY2RUh4DEM0ocP11R1J1Q MEkGCSqGSIb3DQEJDzE8MDowCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMAIDBLg4MA0GCSqGSIb3DQEBAQUABIGACqNky3FpnLA+ATuUvAkbe+/g aouEMGhuM2z8tKMdoinTnGY352JUM8vpdXsgLm8IcHHFH06IyZxaKZC0mG9JKdI1FNaqhfyg6g1d 58dOLs4hGLcK/wVy6KUg6nd0pkMPaMjMgZEusOXpmZOKvWACEJkL6JJpPkt6xltNSuWfuSMAAAAA AAA= ------=_NextPart_000_0178_01C0D3DD.642EB670-- From owner-aaa-bof@merit.edu Thu May 3 14:56:44 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03629 for ; Thu, 3 May 2001 14:56:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C806A5DDC4; Thu, 3 May 2001 11:30:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7CEF05DDA8; Thu, 3 May 2001 11:30:10 -0400 (EDT) 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 B1D745DDC4 for ; Thu, 3 May 2001 11:30:06 -0400 (EDT) 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 f43FU5N12431; Thu, 3 May 2001 17:30:05 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.27.159]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f43FU4J10991; Thu, 3 May 2001 18:30:05 +0300 (EET DST) Message-ID: <3AF1797C.18A2F57B@lmf.ericsson.se> Date: Thu, 03 May 2001 18:30:04 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Patrice Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: A resolution to the Accounting problem References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Getting back to the separate accounting issue after a while. Pat wrote the following: >So, could we not simply create a new AVP >that is exchanged in the DRI, called >the Accounting-Extension-Id? It would >use the same address space as the existing >Extension-Id AVP, but this would be ONLY >for accounting purposes. This way a server >could advertise that it wishes to receive >both auth and acct messages for MIP ONLY, >or perhaps only NASREQ and MIP acct messages, >etc. > >This seems very flexible, and an even better >solution to the old approach (read split acct >from base) that would not allow a peer to >advertise that it only wanted accounting >messages for a particular application. First, I support schemes to allow separate accounting flows, based on seeing a number of important applications that demand it. We really need to do this! Then, to your proposal Pat. I think it's good and a like the dynamic no-configuration-in-the- normal-case -approach in it. I would like to add, though, that we also need to state clearly in 11.0 and 13.1 that separate accounting flows are allowed. In fact, that's perhaps the first thing we must do, and then the Accounting-Extension-Id AVP would be nice addition to it. Here's some proposed text for the 13.1 case: 13.1 Server Directed Model The server directed model means that the device generating the accounting data gets information from either the authorization server (if contacted) or the accounting server regarding the way accounting data shall be forwarded. This information includes accounting record timeliness requirements. What to do about the 11.0? Should we state at the beginning that everything regarding the user sessions relates only to situations deploying authorization/authentication, but not when only accounting is used? Jari From owner-aaa-bof@merit.edu Thu May 3 15:35:14 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05216 for ; Thu, 3 May 2001 15:35:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E92405DF24; Thu, 3 May 2001 13:03:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D5D925DF21; Thu, 3 May 2001 13:03:33 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 6B69D5DF18 for ; Thu, 3 May 2001 13:03:32 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05507; Thu, 3 May 2001 10:03:28 -0700 (PDT) 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.1p1) with SMTP id TAA03701; Thu, 3 May 2001 19:03:26 +0200 (MET DST) Date: Thu, 3 May 2001 19:14:56 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft To: Mark Jones Cc: Erik Guttman , David Frascone , James Kempf , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <015101c0d3f2$b3ee0200$2096a8c0@mjones.bridgewatersys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Mark, > Did you have a spec in mind for your DTD? Base/API? The initial cut at the DTD is included in the XML. Please let me know how it can be improved. If you think we should separate these into two files, have at it. I really appreciate your help moving this forward. Erik From owner-aaa-bof@merit.edu Thu May 3 15:37:00 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05463 for ; Thu, 3 May 2001 15:37:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AE2E55DE7E; Thu, 3 May 2001 13:11:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9C5785DE06; Thu, 3 May 2001 13:11:46 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B2DE25DDDD for ; Thu, 3 May 2001 13:11:44 -0400 (EDT) Received: (qmail 9944 invoked by uid 500); 3 May 2001 17:01:10 -0000 Date: Thu, 3 May 2001 10:01:10 -0700 From: Pat Calhoun To: James Kempf Cc: Erik.Guttman@sun.com, mjones@bridgewatersystems.com, dave@frascone.com, aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Message-ID: <20010503100109.Q26582@charizard.diameter.org> Mail-Followup-To: James Kempf , Erik.Guttman@sun.com, mjones@bridgewatersystems.com, dave@frascone.com, aaa-wg@merit.edu, diameter@diameter.org References: <200105031702.KAA28587@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105031702.KAA28587@heliopolis.eng.sun.com>; from James.Kempf@sun.com on Thu, May 03, 2001 at 10:02:11AM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, May 03, 2001 at 10:02:11AM -0700, James Kempf wrote: > > > > >Did you have a spec in mind for your DTD? Base/API? > > > > If the working group agrees, we could put it into the API draft as > the basis for the command/AVP dictionary format, like we had the > previous one. I would prefer that the dictionary be its own separate informational RFC. It is independent of the API. PatC From owner-aaa-bof@merit.edu Thu May 3 15:55:47 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06568 for ; Thu, 3 May 2001 15:55:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CF1535DF14; Thu, 3 May 2001 15:53:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BE5495DF13; Thu, 3 May 2001 15:53:33 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by segue.merit.edu (Postfix) with ESMTP id 34CF95DE29 for ; Thu, 3 May 2001 15:53:32 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id MAA22885 for ; Thu, 3 May 2001 12:53:31 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id MAA19778 for ; Thu, 3 May 2001 12:53:30 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 14:53:30 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECEBB@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'Mark Jones'" , James Kempf , aaa-wg@merit.edu, diameter@diameter.org, dave@frascone.com Subject: RE: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Date: Thu, 3 May 2001 14:53:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Mark, After taking a quick look at Erik's DTD, it seems to not include any information about position/number/inclusion/exclusion of AVPs within commands. This would probably line up with your desire not to have the message's format validated by the DTD. What I don't understand is why it's desirable for this information to be absent. Is there another file format that is recommended for describing message formats? I don't see why XML wouldn't be able to describe it. Does the information not architecturally belong in a dictionary? -Brian > -----Original Message----- > From: Mark Jones [mailto:mjones@bridgewatersystems.com] > > If the goal is to define a DTD for Diameter dictionaries > purely for the > purpose of attribute encoding/decoding (and NOT for > validating the message > format) then I'm up for it. > > Regards, > Mark > > > -----Original Message----- > > From: owner-aaa-bof@merit.edu > [mailto:owner-aaa-bof@merit.edu]On Behalf > > > > > > So do we have any volunteers who want to push this separate draft > forward? > > > > jak > > From owner-aaa-bof@merit.edu Thu May 3 15:57:48 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06685 for ; Thu, 3 May 2001 15:57:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 906CF5DDAF; Thu, 3 May 2001 15:57:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7A0DE5DDE7; Thu, 3 May 2001 15:57:20 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id DB6675DDAF for ; Thu, 3 May 2001 15:57:18 -0400 (EDT) Received: (qmail 13116 invoked by uid 500); 3 May 2001 19:47:07 -0000 Date: Thu, 3 May 2001 12:47:07 -0700 From: Pat Calhoun To: Cain Brian-BCAIN1 Cc: "'Mark Jones'" , James Kempf , aaa-wg@merit.edu, diameter@diameter.org, dave@frascone.com Subject: Re: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Message-ID: <20010503124707.T26582@charizard.diameter.org> Mail-Followup-To: Cain Brian-BCAIN1 , 'Mark Jones' , James Kempf , aaa-wg@merit.edu, diameter@diameter.org, dave@frascone.com References: <35DBB8B7AC89D4118E98009027B1009B0ECEBB@IL27EXM10.cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0ECEBB@IL27EXM10.cig.mot.com>; from Brian.Cain@motorola.com on Thu, May 03, 2001 at 02:53:29PM -0500 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, May 03, 2001 at 02:53:29PM -0500, Cain Brian-BCAIN1 wrote: > Mark, > > After taking a quick look at Erik's DTD, it seems to not include any > information about position/number/inclusion/exclusion of AVPs within > commands. This would probably line up with your desire not to have the > message's format validated by the DTD. What I don't understand is why it's > desirable for this information to be absent. Is there another file format > that is recommended for describing message formats? I don't see why XML > wouldn't be able to describe it. Does the information not architecturally > belong in a dictionary? Well, not dictionary in the historical sense. If a Diameter dictionary is more than just a list of AVPs, then perhaps it should. My inclination is to leave that information out of the dictionary. PatC From owner-aaa-bof@merit.edu Thu May 3 16:24:31 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08138 for ; Thu, 3 May 2001 16:24:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 73AC05DF9F; Thu, 3 May 2001 16:21:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6236E5DF9E; Thu, 3 May 2001 16:21:34 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id C5F685DF9C for ; Thu, 3 May 2001 16:21:32 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12853; Thu, 3 May 2001 13:21:28 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA05514; Thu, 3 May 2001 13:21:27 -0700 (PDT) Message-Id: <200105032021.NAA05514@heliopolis.eng.sun.com> Date: Thu, 3 May 2001 13:21:27 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft To: James.Kempf@sun.com, aaa-wg@merit.edu, diameter@diameter.org, dave@frascone.com, mjones@bridgewatersystems.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: PmNz2YFswwOjicfRONNqVQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk That's the intent. jak >From: "Mark Jones" >To: "James Kempf" , , , >Subject: RE: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft >Date: Thu, 3 May 2001 14:29:00 -0400 >X-Priority: 3 (Normal) >X-MSMail-Priority: Normal >Importance: Normal >X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 > >If the goal is to define a DTD for Diameter dictionaries purely for the >purpose of attribute encoding/decoding (and NOT for validating the message >format) then I'm up for it. > >Regards, > Mark > >> -----Original Message----- >> From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf >> Of James Kempf >> Sent: May 3, 2001 1:32 PM >> To: aaa-wg@merit.edu; diameter@diameter.org; dave@frascone.com >> Subject: Re: [diameter] Re: [AAA-WG]: Re: questions and comments >> regarding the Diameter A PI draft >> >> >> So do we have any volunteers who want to push this separate draft >forward? >> >> jak >> >> >Delivered-To: aaa-wg-outgoing@merit.edu >> >Date: Thu, 3 May 2001 12:27:35 -0500 >> >From: David Frascone >> >To: aaa-wg@merit.edu, diameter@diameter.org >> >Subject: Re: [diameter] Re: [AAA-WG]: Re: questions and comments >> regarding the >> Diameter A PI draft >> >Mail-Followup-To: aaa-wg@merit.edu, diameter@diameter.org >> >Content-Disposition: inline >> >User-Agent: Mutt/1.2.5i >> >X-encrypt-payload: no >> > >> >I agree. >> > >> >On Thu, May 03, 2001 at 10:01:10AM -0700, Pat Calhoun wrote: >> >> On Thu, May 03, 2001 at 10:02:11AM -0700, James Kempf wrote: >> >> > >> >> > > >> >> > >Did you have a spec in mind for your DTD? Base/API? >> >> > > >> >> > >> >> > If the working group agrees, we could put it into the API draft as >> >> > the basis for the command/AVP dictionary format, like we had the >> >> > previous one. >> >> >> >> I would prefer that the dictionary be its own separate >> informational RFC. It >> >> is independent of the API. >> >> >> >> PatC >> >> >> > >> >> >> From owner-aaa-bof@merit.edu Thu May 3 16:26:49 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08218 for ; Thu, 3 May 2001 16:26:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A579D5DE05; Thu, 3 May 2001 16:24:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 942DD5DDEA; Thu, 3 May 2001 16:24:00 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by segue.merit.edu (Postfix) with ESMTP id B57355DF40 for ; Thu, 3 May 2001 16:23:54 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA15224 for ; Thu, 3 May 2001 13:23:54 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id NAA19453 for ; Thu, 3 May 2001 13:23:53 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 15:23:53 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECEBD@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'Pat Calhoun'" Cc: "'Mark Jones'" , James Kempf , aaa-wg@merit.edu, diameter@diameter.org, dave@frascone.com Subject: RE: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Date: Thu, 3 May 2001 15:23:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > On Thu, May 03, 2001 at 02:53:29PM -0500, Cain Brian-BCAIN1 wrote: ... > > wouldn't be able to describe it. Does the information not > architecturally > > belong in a dictionary? > > Well, not dictionary in the historical sense. If a Diameter > dictionary is more > than just a list of AVPs, then perhaps it should. > > My inclination is to leave that information out of the dictionary. I skimmed through the API, and I couldn't find mention of a non-dictionary file (or other parameter) that specifies message formats. Is this because message format validation isn't intended to occur within the library, or is this the first time that the issue of where message format should be defined is being addressed, and everyone was assuming (like me) that the dictionary would define message format? Or did I overlook something in the API? -Brian From owner-aaa-bof@merit.edu Thu May 3 16:27:56 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08415 for ; Thu, 3 May 2001 16:27:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B54EA5DFA8; Thu, 3 May 2001 16:24:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8DE285DE02; Thu, 3 May 2001 16:24:50 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id EDBC95DDEF for ; Thu, 3 May 2001 16:24:48 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14197; Thu, 3 May 2001 13:24:44 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA05613; Thu, 3 May 2001 13:24:42 -0700 (PDT) Message-Id: <200105032024.NAA05613@heliopolis.eng.sun.com> Date: Thu, 3 May 2001 13:24:42 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft To: mjones@bridgewatersystems.com, James.Kempf@sun.com, aaa-wg@merit.edu, diameter@diameter.org, dave@frascone.com, Brian.Cain@motorola.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Csa28lWGe3Ru4z8bS3BXiQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk > >After taking a quick look at Erik's DTD, it seems to not include any >information about position/number/inclusion/exclusion of AVPs within >commands. This would probably line up with your desire not to have the >message's format validated by the DTD. What I don't understand is why it's >desirable for this information to be absent. Is there another file format >that is recommended for describing message formats? I don't see why XML >wouldn't be able to describe it. Does the information not architecturally >belong in a dictionary? > > As a practical matter, I'd like to see commands and AVPs defined in the same file. I believe the working group has decided to recommend standardizing AVPs and commands together in extensions, and not allow separate standardization (someone please correct me if I'm wrong), so it seems to make sense. I'd rather avoid having a separate file with commands and AVPs. I know that's not how Radius did it, but Radius really didn't have extensions. jak From owner-aaa-bof@merit.edu Thu May 3 16:29:53 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08683 for ; Thu, 3 May 2001 16:29:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7E76A5DDE9; Thu, 3 May 2001 16:29:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6A3525DDE7; Thu, 3 May 2001 16:29:24 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by segue.merit.edu (Postfix) with ESMTP id E43295DDB1 for ; Thu, 3 May 2001 16:29:22 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA18315 for ; Thu, 3 May 2001 13:29:22 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA09809 for ; Thu, 3 May 2001 13:29:21 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2653.19) id <2RXQW9WB>; Thu, 3 May 2001 15:29:21 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECEBE@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'James Kempf'" , mjones@bridgewatersystems.com, aaa-wg@merit.edu, diameter@diameter.org, dave@frascone.com, Cain Brian-BCAIN1 Subject: RE: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Date: Thu, 3 May 2001 15:29:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk > -----Original Message----- > From: James Kempf [mailto:James.Kempf@sun.com] > > > >After taking a quick look at Erik's DTD, it seems to not include any > >information about position/number/inclusion/exclusion of AVPs within > >commands. This would probably line up with your desire not ... > > > > As a practical matter, I'd like to see commands and AVPs > defined in the > same file. I believe the working group has decided to recommend > standardizing AVPs and commands together in extensions, and not My read of the DTD seemed to indicate that AVPs are defined in the same document as the commands, but whether (and where, and how often) they should be included in commands was absent. And in keeping with the sense of a "dictionary", I guess that's a good thing. But at least everything is defined in one place, like you suggest. > jak > From owner-aaa-bof@merit.edu Thu May 3 16:42:37 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09304 for ; Thu, 3 May 2001 16:42:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A20195DF0E; Thu, 3 May 2001 13:22:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 904F15DDEF; Thu, 3 May 2001 13:22:39 -0400 (EDT) Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 81DC65DDEE for ; Thu, 3 May 2001 13:22:37 -0400 (EDT) Received: (qmail 26529 invoked by uid 500); 3 May 2001 17:27:36 -0000 Date: Thu, 3 May 2001 12:27:35 -0500 From: David Frascone To: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Message-ID: <20010503122735.C16328@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu, diameter@diameter.org References: <200105031702.KAA28587@heliopolis.eng.sun.com> <20010503100109.Q26582@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010503100109.Q26582@charizard.diameter.org>; from pcalhoun@diameter.org on Thu, May 03, 2001 at 10:01:10AM -0700 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk I agree. On Thu, May 03, 2001 at 10:01:10AM -0700, Pat Calhoun wrote: > On Thu, May 03, 2001 at 10:02:11AM -0700, James Kempf wrote: > > > > > > > >Did you have a spec in mind for your DTD? Base/API? > > > > > > > If the working group agrees, we could put it into the API draft as > > the basis for the command/AVP dictionary format, like we had the > > previous one. > > I would prefer that the dictionary be its own separate informational RFC. It > is independent of the API. > > PatC > From owner-aaa-bof@merit.edu Thu May 3 16:43:53 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09372 for ; Thu, 3 May 2001 16:43:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 32CD75DF2F; Thu, 3 May 2001 12:22:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 218835DF2C; Thu, 3 May 2001 12:22:15 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 69AF25DF2B for ; Thu, 3 May 2001 12:22:13 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01645 for ; Thu, 3 May 2001 09:22:12 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA27247 for ; Thu, 3 May 2001 09:22:11 -0700 (PDT) Message-Id: <200105031622.JAA27247@heliopolis.eng.sun.com> Date: Thu, 3 May 2001 09:22:11 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: [AAA-WG]: Question on MRI To: aaa-wg@merit.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: kE5ABY69d4kvMi6Nl2efxw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi folks, We've been discussing when to return an MRI and what the return code should be in order to determine when the API should signal an error locally. It seems like there are clear MRI error returns when an AVP or a command is unrecognized. But there doesn't seem to any error code or error AVP for the following conditions: 1) Version number is unrecognized. 2) Vendor code is unrecognized. Any ideas about what the appropriate return action to to the other peer should be? jak From owner-aaa-bof@merit.edu Thu May 3 16:43:55 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09386 for ; Thu, 3 May 2001 16:43:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AADBB5DDEF; Thu, 3 May 2001 16:34:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 97E085DDEE; Thu, 3 May 2001 16:34:53 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by segue.merit.edu (Postfix) with ESMTP id 1E0795DDEC for ; Thu, 3 May 2001 16:34:52 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA21716 for ; Thu, 3 May 2001 13:34:51 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA12466 for ; Thu, 3 May 2001 13:34:51 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 15:34:50 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECEBF@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'James Kempf'" , Cain Brian-BCAIN1 , pcalhoun@diameter.org Cc: mjones@bridgewatersystems.com, aaa-wg@merit.edu, diameter@diameter.org, dave@frascone.com Subject: RE: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Date: Thu, 3 May 2001 15:34:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > > ... > >> wouldn't be able to describe it. Does the information not > architecturally > >> belong in a dictionary? ... > >My inclination is to leave that information out of the dictionary. > > > > Actually, if construction of the Java command parser is to be > completely > driven by the dictionary, then this information will have to > be in the > dictionary. Otherwise, the parser won't be able to flag when > a command arrives > with an error. If all that Pat's asking for is that it (it being the command format) be defined in a file that is not the dictionary, then it's probably a non-issue. Just add another configuration file, right? I don't see any reason why the command format information should not be in a file, but I can see why it might not belong with certain other types of information. -Brian From owner-aaa-bof@merit.edu Thu May 3 16:43:56 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09399 for ; Thu, 3 May 2001 16:43:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3AEA85DFAA; Thu, 3 May 2001 16:39:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 26B625DFA7; Thu, 3 May 2001 16:39:29 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 81B375DE1D for ; Thu, 3 May 2001 16:39:27 -0400 (EDT) Received: (qmail 14926 invoked by uid 500); 3 May 2001 20:29:15 -0000 Date: Thu, 3 May 2001 13:29:15 -0700 From: Pat Calhoun To: Cain Brian-BCAIN1 Cc: "'James Kempf'" , mjones@bridgewatersystems.com, aaa-wg@merit.edu, diameter@diameter.org, dave@frascone.com Subject: Re: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Message-ID: <20010503132915.W26582@charizard.diameter.org> Mail-Followup-To: Cain Brian-BCAIN1 , 'James Kempf' , mjones@bridgewatersystems.com, aaa-wg@merit.edu, diameter@diameter.org, dave@frascone.com References: <35DBB8B7AC89D4118E98009027B1009B0ECEBE@IL27EXM10.cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0ECEBE@IL27EXM10.cig.mot.com>; from Brian.Cain@motorola.com on Thu, May 03, 2001 at 03:29:12PM -0500 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, May 03, 2001 at 03:29:12PM -0500, Cain Brian-BCAIN1 wrote: > > > > -----Original Message----- > > From: James Kempf [mailto:James.Kempf@sun.com] > > > > > >After taking a quick look at Erik's DTD, it seems to not include any > > >information about position/number/inclusion/exclusion of AVPs within > > >commands. This would probably line up with your desire not > ... > > > > > > > As a practical matter, I'd like to see commands and AVPs > > defined in the > > same file. I believe the working group has decided to recommend > > standardizing AVPs and commands together in extensions, and not > > My read of the DTD seemed to indicate that AVPs are defined in the same document as the commands, but whether (and where, and how often) they should be included in commands was absent. And in keeping with the sense of a "dictionary", I guess that's a good thing. But at least everything is defined in one place, like you suggest. I don't have a particular problem with including the command codes in the dictionary, if that is the wish of the WG. PatC From owner-aaa-bof@merit.edu Thu May 3 17:23:05 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10610 for ; Thu, 3 May 2001 17:23:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DEBBD5DDF5; Thu, 3 May 2001 17:18:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B9E625DE2D; Thu, 3 May 2001 17:18:20 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 913795DDF5 for ; Thu, 3 May 2001 17:18:18 -0400 (EDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f43LICg24371 for ; Thu, 3 May 2001 16:18:12 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 3 May 2001 16:17:51 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Thu, 3 May 2001 16:17:51 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213966@daeis07nok> From: Basavaraj.Patil@nokia.com To: dmitton@nortelnetworks.com Cc: aaa-wg@merit.edu, pcalhoun@diameter.org Subject: RE: [AAA-WG]: Mobile IP Extension Date: Thu, 3 May 2001 16:17:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > > Is there a plan vis-a-vis MIP v6 support?? > > Dave. > Yes. You should see an I-D on this shortly. -Basavaraj > At 5/2/01 04:18 PM -0400, Pat Calhoun wrote: > > >On Wed, May 02, 2001 at 03:08:34PM -0500, > Basavaraj.Patil@nokia.com wrote: > > > > > > Pat, > > > > > > Would you agree that the current Mobile IP extension document > > > (draft-ietf-aaa-diameter-mobileip-02.txt) > > > specifically deals with Mobile IPv4 only? > > > >I believe so > > > > > If so would you mind changing the title to : "Diameter Mobile IPv4 > > > Extensions"? > > > >Not at all. > > > > > > > > And maybe add an applicability statement (to MIPv4 only) > someplace in the > > > document. > > > >Sure. > > > >PatC > > ------------------------------------------------------------ > David Mitton ESN: 248-4570 > Advisor, Nortel Networks 978-288-4570 > Wireless Solutions, IP Mobility > Billerica, MA 01821 dmitton@nortelnetworks.com > From owner-aaa-bof@merit.edu Thu May 3 17:38:50 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10981 for ; Thu, 3 May 2001 17:38:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8F0CB5DE7D; Thu, 3 May 2001 17:38:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 70CEA5DE71; Thu, 3 May 2001 17:38:32 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id A9B5C5DE5B for ; Thu, 3 May 2001 17:38:30 -0400 (EDT) Received: (qmail 15935 invoked by uid 500); 3 May 2001 21:28:18 -0000 Date: Thu, 3 May 2001 14:28:18 -0700 From: Pat Calhoun To: Yiwen Jiang Cc: "'James Kempf'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Question on MRI Message-ID: <20010503142818.A26582@charizard.diameter.org> Mail-Followup-To: Yiwen Jiang , 'James Kempf' , aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Yiwen.Jiang@tic.siemens.ca on Thu, May 03, 2001 at 12:38:14PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, May 03, 2001 at 12:38:14PM -0400, Yiwen Jiang wrote: > What about another error condition where none of the extensions that the > peer advertised via DRI message is supported by the receiving server? That error condition is handled by the DSI, since it is handle on a per hop basis, and a proxy could try another server. > > 1) Version number is unrecognized. > > 2) Vendor code is unrecognized. Both of these should also be handled. I will update the -03 spec. PatC From owner-aaa-bof@merit.edu Thu May 3 17:51:30 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11226 for ; Thu, 3 May 2001 17:51:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C3B715DEAA; Thu, 3 May 2001 12:36:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B21F05DEA8; Thu, 3 May 2001 12:36:24 -0400 (EDT) Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 15DCF5DEA6 for ; Thu, 3 May 2001 12:36:23 -0400 (EDT) Received: (qmail 16342 invoked by uid 500); 3 May 2001 16:41:21 -0000 Date: Thu, 3 May 2001 11:41:21 -0500 From: David Frascone To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: transport MUSTs Message-ID: <20010503114121.A16328@newman.frascone.com> Mail-Followup-To: Pat Calhoun , aaa-wg@merit.edu References: <3AF14635.A7D6A7E6@lmf.ericsson.se> <20010503070855.E26582@charizard.diameter.org> <3AF16B06.12B89B10@lmf.ericsson.se> <20010503073155.J26582@charizard.diameter.org> <20010503084241.L26582@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010503084241.L26582@charizard.diameter.org>; from pcalhoun@diameter.org on Thu, May 03, 2001 at 08:42:41AM -0700 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, May 03, 2001 at 08:42:41AM -0700, Pat Calhoun wrote: > How does the following sound? > > " The base Diameter protocol is run on port TBD of both TCP [27] and > SCTP [26] transport protocols (for interoperability test purposes > port 1812 will be used until April 2001). Diameter clients SHOULD > support SCTP, but MUST support TCP if SCTP is not available. future > versions of this specification may mandate that clients support SCTP. > Diameter servers MUST support both TCP and SCTP." > Works for me. From owner-aaa-bof@merit.edu Thu May 3 18:06:35 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11515 for ; Thu, 3 May 2001 18:06:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ABF7F5DD94; Thu, 3 May 2001 15:01:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 960965DDEF; Thu, 3 May 2001 15:01:09 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id DE3F65DD94 for ; Thu, 3 May 2001 15:01:07 -0400 (EDT) Received: (qmail 12349 invoked by uid 500); 3 May 2001 18:50:56 -0000 Date: Thu, 3 May 2001 11:50:56 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Proposed Session text Message-ID: <20010503115056.R26582@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, As discussed in another thread, I am proposing the following text to replace section 11.0 and 11.1 in the -02 version. This text is to handle the fact that an application can make use of accounting only. Comments? PatC ---- 11.0 "User" Sessions Diameter can provide two different type of services to applications. The first involves authentication and authorization, and can optionally make use of accounting. The second only makes use of accounting. When a service makes use of the authentication and/or authorization portion of an extension, and a user requests access to the network, the Diameter client issues an auth request to its local server. The auth request is defined in a service specific Diameter extension (e.g. NASREQ). The request contains a Session-Id AVP, which is used in subsequent messages (e.g. subsequent authorization, accounting, etc) relating to the user's session. The Session-Id AVP is a means for the client and servers to correlate a Diameter message with a user session. When a Diameter server authorizes a user to use network resources, it SHOULD add the Authorization-Lifetime AVP to the response. The Authorization-Lifetime AVP defines the maximum amount of time a user MAY make use of the resources before another authorization request is to be transmitted to the server. If the server does not receive another authorization request before the timeout occurs, it SHOULD release any state information related to the user's session. Note that the Authorization-Lifetime AVP implies how long the Diameter server is willing to pay for the services rendered, therefore a Diameter client SHOULD NOT expect payment for services rendered past the session expiration time. The base protocol does not include any authorization request messages, since these are largely application-specific and are defined in a Diameter protocol extension document. However, the base protocol does define a set of messages that are used to terminate user sessions. These are used to allow servers that maintain state information to free resources. When a service only makes use of the Accounting portion of the Diameter protocol, even in combination with an extension, the Session-Id is still used to identify user sessions. However, the session termination messages are not used, since a session is signalled as being terminated by issuing an accounting stop message. 11.1 Authorization Session State Machine This section contains a finite state machine, representing the life cycle of Diameter sessions, and MUST be observed by all Diameter implementations that makes use of the authentication and/or authorization portion of a Diameter extension. The term Service- Specific below refers to a message defined in a Diameter extension (e.g. Mobile IP, NASREQ). The following table contains the authorization session state machine. State Event Action New State ------------------------------------------------------------- Idle Client or Device Requests send serv. Pending access specific auth req Idle Service-Specific authorization send serv. Open request received, and specific successfully processed response Pending Successful Service-Specific Grant Open Authorization response Access received Open Authorization-Lifetime expires send serv. Open specific auth req Open Successful Service-Specific Extend Open Authorization response Access received Open Accounting message sent or process Open received Open Failed Service-Specific Discon. Closed Authorization response user/device received. Open Session-Timeout Expires on send STR Discon Access Device Open STI Received send STR Discon Open Session-Timeout Expires on send STI Discon home AAA server Discon STI Received ignore Discon Discon STR Received Send STA Closed Discon STA Received Discon. Closed user/device Closed Transition to state Cleanup When the Cleanup action is invoked, the Diameter node MAY attempt to release all resources for the particular session. Any event not listed above MUST be considered as an error condition, and a response, if applicable, MUST be returned to the originator of the message. 11.2 Authorization Session State Machine For applications that only require accounting services, the following state machine MUST be supported. State Event Action New State ------------------------------------------------------------- Idle Client or device requests send Pending access accounting start req. Idle Accounting start request send Open received, and successfully accounting processed. start answer Pending Successful accounting grant Open start answer received access Open User service terminated send Discon accounting stop req. Open Accounting stop request send Closed received, and successfully accounting processed stop answer Discon Successful accounting discon. Closed stop answer received user/device From owner-aaa-bof@merit.edu Thu May 3 18:12:06 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11659 for ; Thu, 3 May 2001 18:12:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A14965DDF3; Thu, 3 May 2001 17:31:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8EF955DDF1; Thu, 3 May 2001 17:31:22 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 94FFE5DDE7 for ; Thu, 3 May 2001 17:31:20 -0400 (EDT) Received: (qmail 15853 invoked by uid 500); 3 May 2001 21:21:08 -0000 Date: Thu, 3 May 2001 14:21:08 -0700 From: Pat Calhoun To: Paul Funk , aaa-wg@merit.edu, Patrice Calhoun Subject: Re: [AAA-WG]: Session Termination Issues Message-ID: <20010503142107.Y26582@charizard.diameter.org> Mail-Followup-To: Paul Funk , aaa-wg@merit.edu, Patrice Calhoun References: <4.1.20010501195709.017b4e90@cairo.funk.com> <20010502134919.H4672@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010502134919.H4672@charizard.diameter.org>; from pcalhoun@diameter.org on Wed, May 02, 2001 at 01:49:19PM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, May 02, 2001 at 01:49:19PM -0700, Pat Calhoun wrote: > On Tue, May 01, 2001 at 07:58:47PM -0400, Paul Funk wrote: > > I have several issues/questions relating to session > > termination. > > > > Clarity of the draft > > -------------------- > > I think that the draft (11.8) can give the impression > > that session termination has to do only with explicit > > termination at the request of the server (STI), and > > the STR/STA is merely a means of acknowledgement. > > hmmmm... that is bad. > > > > > My understanding of the actual intent is that whenever > > a session terminates, the client is supposed to issue > > an STR to notify the server. The server is not meant > > to rely on accounting for such notifications. Thus, > > session termination serves two purposes -- to allow > > the client to notify the server of session state and > > to allow the server to explicitly terminate a session. > > If so, this should be made explicit. > > yes, I will look over 11.8 again, and clean up the text. Here is the text that I have come up with: "The Diameter Base Protocol provides a set of messages that MUST be used by any peer to explicitly request that a previously authenticated and/or authorized session be terminated. Since the Session-Id is typically tied to a particular service (i.e. Mobile IP, NASREQ, etc), the session termination messages are used to request that the service tied to the Session Id be terminated. Session Termination MAY be initiated by a Diameter server, by issuing a Session-Termination-Ind (STI) message to the access device. An access device MUST issue a Session-Termination-Request (STR) message either upon receipt of an STI, or when service to a particular user is terminated. A Diameter server MUST be prepared to clean up resources if a session's authorization lifetime has expired, and no STR was received. This event could occur if an access device was to unexectedly reboot. An access device MUST issue Session-Termination-Request messages for all active session prior to an orderly reboot." As far as eliminating the STI, in favor for allowing the STR to be initiated by either the server or the client, I haven't received comments from the WG in favor of this approach. PatC From owner-aaa-bof@merit.edu Thu May 3 18:12:34 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11685 for ; Thu, 3 May 2001 18:12:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4BB1D5DD8C; Wed, 2 May 2001 23:26:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3860E5DDBF; Wed, 2 May 2001 23:26:27 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 2B6535DD8C for ; Wed, 2 May 2001 23:26:25 -0400 (EDT) Received: (qmail 27621 invoked by uid 500); 3 May 2001 03:16:15 -0000 Date: Wed, 2 May 2001 20:16:15 -0700 From: Pat Calhoun To: Jeff Meyer Cc: Pat Calhoun , Paul Funk , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Vendor-Specific Values Message-ID: <20010502201614.A26582@charizard.diameter.org> Mail-Followup-To: Jeff Meyer , Pat Calhoun , Paul Funk , aaa-wg@merit.edu References: <4.1.20010501200021.01798580@cairo.funk.com> <20010502140348.I4672@charizard.diameter.org> <3AF0CEAD.D3510BFC@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AF0CEAD.D3510BFC@hp.com>; from jeff_meyer2@hp.com on Wed, May 02, 2001 at 08:21:17PM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk Yes, it was discussed, and abandoned. Again, I don't believe this is a problem that must be solved. Registering a new value with IANA is close to painless. PatC On Wed, May 02, 2001 at 08:21:17PM -0700, Jeff Meyer wrote: > Hi, > > Was there ever a consideration of using Object Id's > versus a flat id space? > > Vendors would then only need to perform one petitioning > exercise with IANA (to get an Enterprise Id, if they don't > already have one). > > Oid's also make partitioning the various numeric > identifiers easier, because it is hierarchical, > and allows the ids to be organized into meaningful > groups. > > As far as dictionaries and registration, Harald Tveit Alvestrand, > maintains a directory (albeit incomplete) at: > > http://www.alvestrand.no/harald/objectid/top.html > > The hierarchical nature lends itself to distributed > directories (perhaps even DNS). I'm not aware of any > standards work in this area, but IANA registration for > each new attribute doesn't sound that scaleable. > > The obvious downside is that OIDs require more bytes > to be encoded than a single 32-bit integer. However > SNMP and LDAP seemed to be pretty successful using them. > > In theory the universe of OIDs already defined for > various SNMP attributes could be reused as is if/when > appropriate. > > > Regards, > > Jeff Meyer > Hewlett-Packard > jeff_meyer2@hp.com > > > Pat Calhoun wrote: > > > > On Tue, May 01, 2001 at 08:03:35PM -0400, Paul Funk wrote: > > > I'd like to trot out a suggestion that was first made within > > > the RADIUS group. > > > > > > A "Vendor-Specific Value" is an AVP whose attribute is a > > > standard one but whose value has semantics defined by a > > > particular vendor. Such extensibility is useful for > > > Unsigned32 types that are really enumerations, such as > > > Service-Type and Accounting-Record-Type. > > > > > > For example, a vendor may offer services other than "Login", > > > "Framed", etc., and may wish to extend the Service-Type > > > AVP with the values it requires. Or, a vendor may wish to > > > define an Accounting-Record-Type other than start, stop, > > > etc. > > > > sure. > > > > > > > > Vendors and service providers routinely have such > > > requirements, have always satisfied these requirements by > > > defining what they pleased, and have not always bothered > > > to go to IANA for permission. > > > > well, that is problematic. If vendors want to encode a new value > > in an existing RADIUS attribute, and pick an unused value without > > registering with IANA, then conflicts will occur. > > > > > > > > One might argue that the workaround is to define the > > > enumerations within a separate VSA. But this is problematic > > > for a couple reasons. > > > > > > First, it is useful for a Diameter server to recognize that > > > a particular value is a Service-Type naturally, without > > > having to figure out that Acme-Service-Type carries service > > > type information. > > > > correct. > > > > > > > > Second, and more problematic, is that AVPs such as > > > Service-Type and Accounting-Record-Type are defined as > > > required AVPs within the Diameter command, and any vendor > > > that replaced these AVPs with their own would be instantly > > > non-compliant. > > > > right. > > > > > > > > By adopting VSVs there is an added benefit that relates > > > specifically to Diameter: > > > > > > Currently, the only way for a vendor to define a new extension > > > is to apply to the IANA. But by allowing VSVs, any vendor would > > > be able to define its own values for Extension-Id. I think this > > > ability is critical to motivate widespread use of Diameter for new > > > applications. > > > > An interesting, if not dangerous, proposal. > > > > > > > > Command codes and attributes are already extensible by > > > vendors, but enumerated values and extensions are not. > > > VSVs effectively make Diameter completely vendor- > > > extensible, at the cost of a single bit in the AVP Flags. > > > > I hear you, but question whether this is really necessary. I can appreciate > > the desire to have a truly flexible protocol, but this can lead to many > > other undesirable side effects. > > > > The -03 base now includes lots of new text that is the result of conversations > > I've had with IESG members and the chairs. Specifically, the following > > section has been created: > > > > 2.3.1 Defining new AVP Values > > > > Defining a new AVP value is the best approach when a new application > > needs to make use of an existing Diameter extension, but requires that an > > existing AVP communicate different service-specific information (e.g. > > NAS-Port-Type set to avian carriers). > > > > When an existing AVP can be used to communicate the new information, this > > approach is preferred over creating new AVPs. > > > > In order to allocate a new AVP value, a request MUST be sent to IANA, > > with a detailed explanation of the value. Furthermore, if the command > > code on which the AVP value is to be used would require a different set of > > mandatory AVPs be present, the list of AVPs must accompany the request. > > > > Now I am in the process of checking how complex it is to request a new > > value since I sent an e-mail to iana@iana.org to request a new value for > > a RADIUS attribute. If all goes well, the pain to register a new value > > is near zero. > > > > So I'd like to punt this one to the chairs and see what they think. > > > > PatC > From owner-aaa-bof@merit.edu Thu May 3 18:14:40 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11760 for ; Thu, 3 May 2001 18:14:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4AEDD5E155; Thu, 3 May 2001 18:02:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 781815DF2B; Thu, 3 May 2001 18:01:24 -0400 (EDT) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id CB05F5DF51 for ; Thu, 3 May 2001 17:55:54 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id RAA31057; Thu, 3 May 2001 17:49:58 -0400 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id RAA03037; Thu, 3 May 2001 17:56:42 -0400 (EDT) From: "Mark Jones" To: "James Kempf" , , Cc: , , Subject: RE: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Date: Thu, 3 May 2001 17:58:38 -0400 MIME-Version: 1.0 Message-ID: <01fd01c0d41c$35686220$2096a8c0@mjones.bridgewatersys.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_01F2_01C0D3FA.AD3F1090"; micalg=SHA-1 Importance: Normal In-Reply-To: <200105032040.NAA06347@heliopolis.eng.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01F2_01C0D3FA.AD3F1090 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I wanted to exclude expressing the command format simply because I was struggling with how it could be expressed without using XML Schema. Last time I looked, it was difficult to find a C++ parsing library that supported XML Schema. Without using XML schema, the XML for: Example-Command ::= < Diameter-Header: 9999999 > { User-Name } * { Origin-FQDN } * [ AVP ] would be: using the following DTD: Comments? Regards, Mark ------=_NextPart_000_01F2_01C0D3FA.AD3F1090 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw ggH9oAMCAQICAwS4ODANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDUwMTE4MTgwOFoXDTAyMDUwMTE4MTgwOFowTzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdbWpvbmVzQGJyaWRnZXdhdGVyc3lzdGVt cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMemr5diJO/8+r2Hj3Opr9LbaVAXFgo2 Fhu0tfSSdvlMy52Y67GMoJbv0I282FWO9z4bsnuSIU7y3arEmyA78mwjTSdt2GK5QJHT6jKOqF6M 81Q5j2fU3dQwCPiCQZlOqUJEA3PySRjUQNOgnRUhoSuzGd7IMJ3Y6oeMtE8a02nTAgMBAAGjOjA4 MCgGA1UdEQQhMB+BHW1qb25lc0BicmlkZ2V3YXRlcnN5c3RlbXMuY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEANyubKv2ajV9VxVe4xUDaqZbQ2DEXgGKSFWwsdC06zUucuCmeHHqT vLcoUnI8/dCbSnSwRrELpemSoqTv/99uW+jS6cN5320w1ZEBsC2RSVrSJd8LqxKALmMexgbywYvF /hMe120ctocvwnfbeZmzBIKSF7BDs8YPGzSWgsa5gKUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2 17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP 6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9 edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O +PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R hGvk+NHOd6KBMYICmzCCApcCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDBLg4MAkGBSsOAwIaBQCgggFWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDUwMzIxNTgzNlowIwYJKoZIhvcNAQkEMRYEFK1jZYGLeveSC+JnHe4FpOaBY0RJ MEkGCSqGSIb3DQEJDzE8MDowCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMAIDBLg4MA0GCSqGSIb3DQEBAQUABIGAqUudPVQo1qLEzeC7ujPJ+3Lj 2XNuyR+pN82VnbXGq+sGtlc91nts+RT73MtcSjXX0eDiJlXyIL5eLWJgRD6fOlk0fnwL+saWlGgN MCQjrOPHYgUm4FYek4Snt7LJyF5vgEOqvj+r3sijdPZpsWdR93Uc5AG0MsV99tj2vuwnP1wAAAAA AAA= ------=_NextPart_000_01F2_01C0D3FA.AD3F1090-- From owner-aaa-bof@merit.edu Thu May 3 18:14:42 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11771 for ; Thu, 3 May 2001 18:14:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B94E45E18C; Thu, 3 May 2001 18:02:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 09E5E5E047; Thu, 3 May 2001 18:01:31 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 32C875DF79 for ; Thu, 3 May 2001 18:00:37 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id SAA22477; Thu, 3 May 2001 18:00:36 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma022475; Thu, 3 May 01 18:00:20 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id SAA05610; Thu, 3 May 2001 18:00:19 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma005420; Thu, 3 May 01 17:59:09 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <2XDRF6NM>; Thu, 3 May 2001 17:58:51 -0400 Message-ID: From: Yiwen Jiang To: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Proposed Session text Date: Thu, 3 May 2001 17:58:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, Thanks for the update... One thing I noticed is that there is a cut and paste error for 11.2 title, should be accounting session state machine, rather than authorization state machine? > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Thursday, May 03, 2001 2:51 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Proposed Session text > > > All, > > As discussed in another thread, I am proposing the following text to > replace section 11.0 and 11.1 in the -02 version. This text > is to handle > the fact that an application can make use of accounting only. > > Comments? > > PatC > ---- > 11.0 "User" Sessions > > Diameter can provide two different type of services to > applications. > The first involves authentication and authorization, and can > optionally make use of accounting. The second only makes use of > accounting. > > When a service makes use of the authentication and/or authorization > portion of an extension, and a user requests access to the network, > the Diameter client issues an auth request to its local server. The > auth request is defined in a service specific Diameter extension > (e.g. NASREQ). The request contains a Session-Id AVP, which is used > in subsequent messages (e.g. subsequent authorization, accounting, > etc) relating to the user's session. The Session-Id AVP is a means > for the client and servers to correlate a Diameter message with a > user session. > > When a Diameter server authorizes a user to use network > resources, it > SHOULD add the Authorization-Lifetime AVP to the response. The > Authorization-Lifetime AVP defines the maximum amount of > time a user > MAY make use of the resources before another authorization > request is > to be transmitted to the server. If the server does not receive > another authorization request before the timeout occurs, it SHOULD > release any state information related to the user's session. Note > that the Authorization-Lifetime AVP implies how long the Diameter > server is willing to pay for the services rendered, therefore a > Diameter client SHOULD NOT expect payment for services > rendered past > the session expiration time. > > The base protocol does not include any authorization request > messages, since these are largely application-specific and are > defined in a Diameter protocol extension document. > However, the base > protocol does define a set of messages that are used to terminate > user sessions. These are used to allow servers that maintain state > information to free resources. > > When a service only makes use of the Accounting portion of the > Diameter protocol, even in combination with an extension, the > Session-Id is still used to identify user sessions. However, the > session termination messages are not used, since a session is > signalled as being terminated by issuing an accounting > stop message. > > > 11.1 Authorization Session State Machine > > This section contains a finite state machine, representing the life > cycle of Diameter sessions, and MUST be observed by all Diameter > implementations that makes use of the authentication and/or > authorization portion of a Diameter extension. The term Service- > Specific below refers to a message defined in a Diameter extension > (e.g. Mobile IP, NASREQ). > > The following table contains the authorization session > state machine. > > State Event Action New State > ------------------------------------------------------------- > Idle Client or Device Requests send serv. Pending > access specific > auth req > Idle Service-Specific authorization send serv. Open > request received, and specific > successfully processed response > > Pending Successful Service-Specific Grant Open > Authorization response Access > received > > Open Authorization-Lifetime expires send serv. Open > specific > auth req > Open Successful Service-Specific Extend Open > Authorization response Access > received > > Open Accounting message sent or process Open > received > > Open Failed Service-Specific Discon. Closed > Authorization response user/device > received. > > Open Session-Timeout Expires on send STR Discon > Access Device > > Open STI Received send STR Discon > > Open Session-Timeout Expires on send STI Discon > home AAA server > > Discon STI Received ignore Discon > > Discon STR Received Send STA Closed > > Discon STA Received Discon. Closed > user/device > Closed Transition to state Cleanup > > When the Cleanup action is invoked, the Diameter node MAY > attempt to > release all resources for the particular session. Any event not > listed above MUST be considered as an error condition, and a > response, if applicable, MUST be returned to the originator of the > message. > > > 11.2 Authorization Session State Machine > > For applications that only require accounting services, > the following > state machine MUST be supported. > > State Event Action New State > ------------------------------------------------------------- > Idle Client or device requests send Pending > access accounting > start req. > Idle Accounting start request send Open > received, and successfully accounting > processed. start > answer > Pending Successful accounting grant Open > start answer received access > > Open User service terminated send Discon > accounting > stop req. > Open Accounting stop request send Closed > received, and successfully accounting > processed stop answer > > Discon Successful accounting discon. Closed > stop answer received user/device > > From owner-aaa-bof@merit.edu Thu May 3 18:23:02 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11926 for ; Thu, 3 May 2001 18:23:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 38E8E5DE3D; Thu, 3 May 2001 18:21:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 22A435DEDB; Thu, 3 May 2001 18:21:08 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 88E8D5DE3D for ; Thu, 3 May 2001 18:20:41 -0400 (EDT) Received: (qmail 16706 invoked by uid 500); 3 May 2001 22:10:29 -0000 Date: Thu, 3 May 2001 15:10:29 -0700 From: Pat Calhoun To: Mark Jones Cc: James Kempf , Brian.Cain@motorola.com, pcalhoun@diameter.org, aaa-wg@merit.edu, diameter@diameter.org, dave@frascone.com Subject: Re: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Message-ID: <20010503151029.B26582@charizard.diameter.org> Mail-Followup-To: Mark Jones , James Kempf , Brian.Cain@motorola.com, pcalhoun@diameter.org, aaa-wg@merit.edu, diameter@diameter.org, dave@frascone.com References: <200105032040.NAA06347@heliopolis.eng.sun.com> <01fd01c0d41c$35686220$2096a8c0@mjones.bridgewatersys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01fd01c0d41c$35686220$2096a8c0@mjones.bridgewatersys.com>; from mjones@bridgewatersystems.com on Thu, May 03, 2001 at 05:58:38PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk The DTD below needs to be fixed to allow one to specify that an AVP MUST come first, and last. PatC On Thu, May 03, 2001 at 05:58:38PM -0400, Mark Jones wrote: > I wanted to exclude expressing the command format simply because I was > struggling with how it could be expressed without using XML Schema. Last > time I looked, it was difficult to find a C++ parsing library that > supported XML Schema. > > Without using XML schema, the XML for: > > Example-Command ::= < Diameter-Header: 9999999 > > { User-Name } > * { Origin-FQDN } > * [ AVP ] > > would be: > > > > > > > > using the following DTD: > > ArbitraryAVP)+> > name CDATA #REQUIRED > code CDATA #REQUIRED > > > > > avpName IDREFS #REQUIRED > occurance (One | Many) "One" > minOccurs CDATA #IMPLIED > maxOccurs CDATA #IMPLIED > > > > avpName IDREFS #REQUIRED > occurance (One | Many) "One" > minOccurs CDATA #IMPLIED > maxOccurs CDATA #IMPLIED > > > > avpName IDREFS #REQUIRED > occurance (One | Many) "One" > minOccurs CDATA #IMPLIED > maxOccurs CDATA #IMPLIED > > > > > occurance (One | Many) "One" > minOccurs CDATA #IMPLIED > maxOccurs CDATA #IMPLIED > > > > Comments? > > Regards, > Mark From owner-aaa-bof@merit.edu Thu May 3 19:08:12 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13643 for ; Thu, 3 May 2001 19:08:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 15C9B5E04F; Thu, 3 May 2001 19:06:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9484B5E0A0; Thu, 3 May 2001 19:06:47 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id A3B255DF3A for ; Thu, 3 May 2001 19:05:56 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id QAA20823 for ; Thu, 3 May 2001 16:05:56 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id QAA06082 for ; Thu, 3 May 2001 16:05:56 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 18:05:56 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECEC3@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'Mark Jones'" , James Kempf , Cain Brian-BCAIN1 , pcalhoun@diameter.org Cc: aaa-wg@merit.edu, diameter@diameter.org, dave@frascone.com Subject: RE: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Date: Thu, 3 May 2001 18:05:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > -----Original Message----- > From: Mark Jones [mailto:mjones@bridgewatersystems.com] > > I wanted to exclude expressing the command format simply because I was > struggling with how it could be expressed without using XML > Schema. Last > time I looked, it was difficult to find a C++ parsing library that > supported XML Schema. > > Without using XML schema, the XML for: > > Example-Command ::= < Diameter-Header: 9999999 > > { User-Name } > * { Origin-FQDN } > * [ AVP ] > > would be: > > > > > > > > using the following DTD: > > ArbitraryAVP)+> How about something along these lines: Which would make the XML look like: This will address a couple of concerns: first, the ability to create inconsistent attributes is removed (occurance="One" minOccurs="0" maxOccurs="0"), fixed AVPs are also possible at the end of the message, and it's impossible to create a fixed AVP that follows a required AVP but precedes an optional AVP. I think the occurance attribute is somewhat redundant, and may only be useful as a shorthand for minOccurs and maxOccurs. I'm not familiar enough w/DTD syntax to state with certainty that you can have the #IMPLIED part of the CDATA attributes, like I suggest, though. But, if we can force a structure that won't allow as many internal inconsistencies, we'll probably be better off, right? I don't like that my suggestion requires one attribute (maximum) to logically take on an integer or string value (maximum can be "3" or "Many" -- this seems bad). The only other thing I could offer would be to have "-1" as a possibility to represent an occurance frequency without a maximum (maximum="Many"). The format "(FixedAVP | RequiredAVP | OptionalAVP | ArbitraryAVP)+" will probably match the message below: , which is illegal. FixedAVPs may occur only at the beginning or the end of a command, and RequiredAVPs must occur before ArbitraryAVPs, etc. Plus, the ArbitraryAVP should only show up once in a command definition, or not at all. My suggestion for the DTD does not enforce that at least one AVP is included in every command definition. I don't know of a way to do that within the framework I've set up. Feedback? -Brian From owner-aaa-bof@merit.edu Thu May 3 20:07:24 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15751 for ; Thu, 3 May 2001 20:07:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3A0A55DDE7; Thu, 3 May 2001 20:01:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F16675DE85; Thu, 3 May 2001 20:01:04 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 491905DDE7 for ; Thu, 3 May 2001 20:01:03 -0400 (EDT) Received: (qmail 18267 invoked by uid 500); 3 May 2001 23:50:51 -0000 Date: Thu, 3 May 2001 16:50:51 -0700 From: Pat Calhoun To: aaa-wg@merit.edu, diameter@diameter.org Subject: [AAA-WG]: Latest round of drafts available Message-ID: <20010503165050.F26582@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu, diameter@diameter.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, I have just submitted the latest set of WG Diameter Internet Drafts to the secretariat. The following were submitted: draft-ietf-aaa-diameter-03.txt draft-ietf-aaa-diameter-nasreq-03.txt draft-ietf-aaa-diameter-mobileip-03.txt draft-ietf-aaa-diameter-e2e-sec-01.txt I believe that these documents address all of the discussions that have occurred on the mailing list up to date, with a few exceptions noted below. Furthermore, these drafts have new IANA considerations sections, so if people have a chance to look those sections over, I would appreciate it. The rules in these new sections come from discussions I have had with certain IESG members and the chairs. Pending Issues: - The Mobile IP "handoff" problem. Conference call details will be released tomorrow. - The watchdog/failover section. I am still waiting for some new text for this section. - The MRI problem identified by Paul Funk yesterday. This problem does need attention, and I urge people to take a look at the problem and comment. It is very important, and may require some significant protocol changes. As usual, the new versions are available on www.diameter.org Thanks, PatC From owner-aaa-bof@merit.edu Thu May 3 21:13:10 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16564 for ; Thu, 3 May 2001 21:13:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 109E75DF17; Thu, 3 May 2001 21:11:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F13565DE5A; Thu, 3 May 2001 21:11:27 -0400 (EDT) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 447595DDF6 for ; Thu, 3 May 2001 21:11:26 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id VAA31802; Thu, 3 May 2001 21:05:26 -0400 Received: from preston (cisconas247.bridgewatersys.com [192.168.150.247]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id VAA04662; Thu, 3 May 2001 21:12:06 -0400 (EDT) From: "Mark Jones" To: "Cain Brian-BCAIN1" , "James Kempf" , Cc: , , Subject: RE: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Date: Thu, 3 May 2001 21:13:59 -0400 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0029_01C0D415.F316BFD0"; protocol="application/x-pkcs7-signature" Importance: Normal In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0ECEC3@IL27EXM10.cig.mot.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C0D415.F316BFD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Brian, Great! Your proposed structure addresses the AVP ordering problem that I was struggling with(including the FixedAVP ordering issue that Pat pointed out earlier). Unfortunately, I doubt we are going to be able to completely enforce the Diameter message format without using XML Schema to provide the missing constraints. Will a heavily commented DTD which states these constraints be sufficient? > This will address a couple of concerns: first, the ability to > create inconsistent attributes is removed (occurance="One" > minOccurs="0" maxOccurs="0"), I don't think you have removed the ability to create inconsistent attributes: + A RequiredAVP with maximum="0" + An OptionalAVP with minimum="1" + minimum="10", maximum="1" + minimum="many" > I think the occurance attribute is somewhat redundant, and may > only be useful as a shorthand for minOccurs and maxOccurs. Correct, it is shorthand. I figured the vaste majority of attribute definitions would not be specifying minimum or maximum occurences. I was also trying to avoid assigning a "special" value to 'maxOccurs' for "Many". > I'm not familiar enough w/DTD syntax to state with certainty that you > can have the #IMPLIED part of the CDATA attributes, like I > suggest, though. #IMPLIED means that no default value is provided. If you intended 'minimum' and 'maximum' to have a value of 1 if they were not specified in the XML then you just need: minimum CDATA "1" maximum CDATA "1" Regards, Mark ------=_NextPart_000_0029_01C0D415.F316BFD0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFxTCCApQw ggH9oAMCAQICAwS4ODANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDUwMTE4MTgwOFoXDTAyMDUwMTE4MTgwOFowTzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdbWpvbmVzQGJyaWRnZXdhdGVyc3lzdGVt cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMemr5diJO/8+r2Hj3Opr9LbaVAXFgo2 Fhu0tfSSdvlMy52Y67GMoJbv0I282FWO9z4bsnuSIU7y3arEmyA78mwjTSdt2GK5QJHT6jKOqF6M 81Q5j2fU3dQwCPiCQZlOqUJEA3PySRjUQNOgnRUhoSuzGd7IMJ3Y6oeMtE8a02nTAgMBAAGjOjA4 MCgGA1UdEQQhMB+BHW1qb25lc0BicmlkZ2V3YXRlcnN5c3RlbXMuY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEANyubKv2ajV9VxVe4xUDaqZbQ2DEXgGKSFWwsdC06zUucuCmeHHqT vLcoUnI8/dCbSnSwRrELpemSoqTv/99uW+jS6cN5320w1ZEBsC2RSVrSJd8LqxKALmMexgbywYvF /hMe120ctocvwnfbeZmzBIKSF7BDs8YPGzSWgsa5gKUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2 17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gxggKOMIICigIB ATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgw JgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMEuDgwCQYFKw4DAhoFAKCC AUkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwNTA0MDExMzUw WjAjBgkqhkiG9w0BCQQxFgQUTMqBTownAbY+387WnvpA/Ge+RcMwPAYJKoZIhvcNAQkPMS8wLTAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqwYJKwYBBAGCNxAE MYGdMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMx KDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwS4ODANBgkqhkiG9w0B AQEFAASBgIlnNxUtRpMUjUKFIdOVufFg68qdQVNr7T7zekbj3xrK6rLBl3IrPgGdNVtH70gLTECj R3bxVCPlpb3WOQnaqXYTIuqKsC29CiBx/1Y51QC85ZLNbypQY/3rwgqTa5wDjjI0lTZf54jQMlhb DpQeOIMoe8AfnTdSqUEFLAbZ04ekAAAAAAAA ------=_NextPart_000_0029_01C0D415.F316BFD0-- From owner-aaa-bof@merit.edu Thu May 3 23:00:07 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19566 for ; Thu, 3 May 2001 23:00:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A011D5DDBF; Thu, 3 May 2001 11:58:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8D52A5DDA8; Thu, 3 May 2001 11:58:56 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 3F7595DDB1 for ; Thu, 3 May 2001 11:58:54 -0400 (EDT) Received: (qmail 5673 invoked by uid 500); 3 May 2001 15:48:42 -0000 Date: Thu, 3 May 2001 08:48:42 -0700 From: Pat Calhoun To: Jari Arkko Cc: Patrice Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: A resolution to the Accounting problem Message-ID: <20010503084842.M26582@charizard.diameter.org> Mail-Followup-To: Jari Arkko , Patrice Calhoun , aaa-wg@merit.edu References: <3AF1797C.18A2F57B@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AF1797C.18A2F57B@lmf.ericsson.se>; from Jari.Arkko@lmf.ericsson.se on Thu, May 03, 2001 at 06:30:04PM +0300 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, May 03, 2001 at 06:30:04PM +0300, Jari Arkko wrote: > First, I support schemes to allow separate accounting > flows, based on seeing a number of important > applications that demand it. We really need to > do this! good. > > Then, to your proposal Pat. I think it's good > and a like the dynamic no-configuration-in-the- > normal-case -approach in it. I would like to > add, though, that we also need to state clearly > in 11.0 and 13.1 that separate accounting flows > are allowed. In fact, that's perhaps the first > thing we must do, and then the Accounting-Extension-Id > AVP would be nice addition to it. Right, so we need to take care of both these issues in -03. > Here's some proposed text for the 13.1 case: > > 13.1 Server Directed Model > > The server directed model means that the device generating > the accounting data gets information from either the > authorization server (if contacted) or the accounting server > regarding the way accounting data shall be forwarded. > This information includes accounting record timeliness > requirements. that works for me. > > What to do about the 11.0? Should we state at the beginning > that everything regarding the user sessions relates only > to situations deploying authorization/authentication, but > not when only accounting is used? I believe so. I guess 11.0 needs to support accounting-only applications. That means that state machine also needs to support this as well. PatC From owner-aaa-bof@merit.edu Thu May 3 23:18:59 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19727 for ; Thu, 3 May 2001 23:18:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 827FD5DF77; Thu, 3 May 2001 18:22:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6287C5DF98; Thu, 3 May 2001 18:22:05 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 5C8415DF77 for ; Thu, 3 May 2001 18:22:01 -0400 (EDT) Received: (qmail 16965 invoked by uid 500); 3 May 2001 22:11:45 -0000 Date: Thu, 3 May 2001 15:11:45 -0700 From: Pat Calhoun To: Yiwen Jiang Cc: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Proposed Session text Message-ID: <20010503151145.C26582@charizard.diameter.org> Mail-Followup-To: Yiwen Jiang , 'Pat Calhoun' , aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Yiwen.Jiang@tic.siemens.ca on Thu, May 03, 2001 at 05:58:42PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, May 03, 2001 at 05:58:42PM -0400, Yiwen Jiang wrote: > Hi Pat, > > Thanks for the update... > > One thing I noticed is that there is a cut and paste error for 11.2 title, > should be accounting session state machine, rather than authorization state > machine? I guess I should pay as much attention to headers as the rest of the text :) PatC From owner-aaa-bof@merit.edu Fri May 4 01:11: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 BAA22182 for ; Fri, 4 May 2001 01:11:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 111455DECB; Thu, 3 May 2001 14:22:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F30F25DEC2; Thu, 3 May 2001 14:22:31 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by segue.merit.edu (Postfix) with ESMTP id 3327A5DEB9 for ; Thu, 3 May 2001 14:22:30 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA09868; Thu, 3 May 2001 11:22:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f43IMRn00543; Thu, 3 May 2001 11:22:27 -0700 X-mProtect: Thu, 3 May 2001 11:22:27 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdM4Ntps; Thu, 03 May 2001 11:22:21 PDT Message-ID: <3AF1A1DF.7CE6246F@iprg.nokia.com> Date: Thu, 03 May 2001 11:22:23 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: David Mitton Cc: Basavaraj.Patil@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Mobile IP Extension References: <4.3.2.7.2.20010503141423.03686830@ZBL6C016.corpeast.baynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello David, Yes, there is at least one plan for this. As part of one possible answer, there is a AAAv6 draft with an opaque data extension, so that Binding Updates can be handled in a manner analogous to the way Registration Requests are handled for Mobile IPv4. Hopefully, the Mobile IPv6 support will not have any heavy interactions with possible BURP or EAP influences on AAA/AAAv6. Regards, Charlie P. David Mitton wrote: > > Is there a plan vis-a-vis MIP v6 support?? > > Dave. > > At 5/2/01 04:18 PM -0400, Pat Calhoun wrote: > > >On Wed, May 02, 2001 at 03:08:34PM -0500, Basavaraj.Patil@nokia.com wrote: > > > > > > Pat, > > > > > > Would you agree that the current Mobile IP extension document > > > (draft-ietf-aaa-diameter-mobileip-02.txt) > > > specifically deals with Mobile IPv4 only? > > > >I believe so > > > > > If so would you mind changing the title to : "Diameter Mobile IPv4 > > > Extensions"? > > > >Not at all. > > > > > > > > And maybe add an applicability statement (to MIPv4 only) someplace in the > > > document. > > > >Sure. > > > >PatC > > ------------------------------------------------------------ > David Mitton ESN: 248-4570 > Advisor, Nortel Networks 978-288-4570 > Wireless Solutions, IP Mobility > Billerica, MA 01821 dmitton@nortelnetworks.com From owner-aaa-bof@merit.edu Fri May 4 03:06: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 DAA06078 for ; Fri, 4 May 2001 03:06:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 955875DEE7; Thu, 3 May 2001 16:41:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 83FD65DECF; Thu, 3 May 2001 16:41:14 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id B89825DE02 for ; Thu, 3 May 2001 16:41:12 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09357; Thu, 3 May 2001 13:40:59 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA06347; Thu, 3 May 2001 13:40:58 -0700 (PDT) Message-Id: <200105032040.NAA06347@heliopolis.eng.sun.com> Date: Thu, 3 May 2001 13:40:59 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft To: James.Kempf@Sun.COM, Brian.Cain@motorola.com, pcalhoun@diameter.org Cc: mjones@bridgewatersystems.com, aaa-wg@merit.edu, diameter@diameter.org, dave@frascone.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ukoIx394OuP0TBx1YOf+iw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk >... >> >> wouldn't be able to describe it. Does the information not >> architecturally >> >> belong in a dictionary? >... >> >My inclination is to leave that information out of the dictionary. >> > >> >> Actually, if construction of the Java command parser is to be >> completely >> driven by the dictionary, then this information will have to >> be in the >> dictionary. Otherwise, the parser won't be able to flag when >> a command arrives >> with an error. > >If all that Pat's asking for is that it (it being the command format) be defined in a file that is not the dictionary, then it's probably a non-issue. Just add another configuration file, right? > >I don't see any reason why the command format information should not be in a file, but I can see why it might not belong with certain other types of information. > > Sure, we could put it in another file. It's just easier programmatically to define the whole thing in one file. The parser can step through it in one chunk, rather than having to open a separate file and step through that too. And, as mentioned, if extensions are standardized along with commands and AVPs, then it sort of makes sense to me to define the extension in one place. Is there any reason why it shouldn't be in one file, except for the fact that that is the way Radius did it? jak From owner-aaa-bof@merit.edu Fri May 4 03:11: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 DAA06185 for ; Fri, 4 May 2001 03:11:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2E1A85DDD4; Thu, 3 May 2001 12:58:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1CFEF5DDB1; Thu, 3 May 2001 12:58:50 -0400 (EDT) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id E09315DD94 for ; Thu, 3 May 2001 12:58:47 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id MAA28067; Thu, 3 May 2001 12:52:52 -0400 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id MAA25374; Thu, 3 May 2001 12:59:35 -0400 (EDT) From: "Mark Jones" To: "Erik Guttman" Cc: "David Frascone" , "James Kempf" , , Subject: RE: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Date: Thu, 3 May 2001 13:01:32 -0400 MIME-Version: 1.0 Message-ID: <015101c0d3f2$b3ee0200$2096a8c0@mjones.bridgewatersys.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0146_01C0D3D1.2BA7D9A0"; micalg=SHA-1 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0146_01C0D3D1.2BA7D9A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks Erik, I knew I'd seen it somewhere. > Work went into it (making sure its reasonably complete, correct, etc) > and there's lots more to do. Unless its awefully broken, please start > work from that base. Of course. I was not proposing a competing schema. Just a starting point if none existed. The solutions draft includes the text: "Once accepted, these solutions will find their way into the relevant DIAMETER specifications." Did you have a spec in mind for your DTD? Base/API? Regards, Mark ------=_NextPart_000_0146_01C0D3D1.2BA7D9A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw ggH9oAMCAQICAwS4ODANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDUwMTE4MTgwOFoXDTAyMDUwMTE4MTgwOFowTzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdbWpvbmVzQGJyaWRnZXdhdGVyc3lzdGVt cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMemr5diJO/8+r2Hj3Opr9LbaVAXFgo2 Fhu0tfSSdvlMy52Y67GMoJbv0I282FWO9z4bsnuSIU7y3arEmyA78mwjTSdt2GK5QJHT6jKOqF6M 81Q5j2fU3dQwCPiCQZlOqUJEA3PySRjUQNOgnRUhoSuzGd7IMJ3Y6oeMtE8a02nTAgMBAAGjOjA4 MCgGA1UdEQQhMB+BHW1qb25lc0BicmlkZ2V3YXRlcnN5c3RlbXMuY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEANyubKv2ajV9VxVe4xUDaqZbQ2DEXgGKSFWwsdC06zUucuCmeHHqT vLcoUnI8/dCbSnSwRrELpemSoqTv/99uW+jS6cN5320w1ZEBsC2RSVrSJd8LqxKALmMexgbywYvF /hMe120ctocvwnfbeZmzBIKSF7BDs8YPGzSWgsa5gKUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2 17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP 6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9 edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O +PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R hGvk+NHOd6KBMYICmzCCApcCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDBLg4MAkGBSsOAwIaBQCgggFWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDUwMzE3MDEzMFowIwYJKoZIhvcNAQkEMRYEFMLwY3sVod3dLZ8RHIaiKh4d3lru MEkGCSqGSIb3DQEJDzE8MDowCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMAIDBLg4MA0GCSqGSIb3DQEBAQUABIGAHWxvuioweOV5Vp8mMPRu4sxh D6srBrGMEA7Iw0PUpH5E1t4lu7ZtIP8MuBngsZu82KdAjD7Lagi+rV29r9Yax/ZgL22PWobOiPGG tgLl8W7NGCN0PAy3cG+/nhAH1orUAq/kHW3LMBZKEaJJOMXUpCSi4m8bNDfftBM28MaRmDwAAAAA AAA= ------=_NextPart_000_0146_01C0D3D1.2BA7D9A0-- From owner-aaa-bof@merit.edu Fri May 4 03:26: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 DAA06306 for ; Fri, 4 May 2001 03:26:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DF5375DD9A; Fri, 4 May 2001 03:26:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B2C665DD9C; Fri, 4 May 2001 03:26:10 -0400 (EDT) Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 0581F5DD9A for ; Fri, 4 May 2001 03:25:54 -0400 (EDT) Received: from fredrikj (c35.local.ipunplugged.com [192.168.4.234]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id JAA30382; Fri, 4 May 2001 09:25:45 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" , "Paul Funk" , , "Patrice Calhoun" Subject: RE: [AAA-WG]: Session Termination Issues Date: Fri, 4 May 2001 09:26:34 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20010503142107.Y26582@charizard.diameter.org> Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Comments below. > >On Wed, May 02, 2001 at 01:49:19PM -0700, Pat Calhoun wrote: >> On Tue, May 01, 2001 at 07:58:47PM -0400, Paul Funk wrote: >> > I have several issues/questions relating to session >> > termination. >> > >> > Clarity of the draft >> > -------------------- >> > I think that the draft (11.8) can give the impression >> > that session termination has to do only with explicit >> > termination at the request of the server (STI), and >> > the STR/STA is merely a means of acknowledgement. >> >> hmmmm... that is bad. >> >> > >> > My understanding of the actual intent is that whenever >> > a session terminates, the client is supposed to issue >> > an STR to notify the server. The server is not meant >> > to rely on accounting for such notifications. Thus, >> > session termination serves two purposes -- to allow >> > the client to notify the server of session state and >> > to allow the server to explicitly terminate a session. >> > If so, this should be made explicit. >> >> yes, I will look over 11.8 again, and clean up the text. > >Here is the text that I have come up with: > >"The Diameter Base Protocol provides a set of messages that MUST be used >by any peer to explicitly request that a previously authenticated and/or >authorized session be terminated. Since the Session-Id is typically >tied to a particular service (i.e. Mobile IP, NASREQ, etc), the session >termination messages are used to request that the service tied to the >Session Id be terminated. > >Session Termination MAY be initiated by a Diameter server, by issuing >a Session-Termination-Ind (STI) message to the access device. An >access device >MUST issue a Session-Termination-Request (STR) message either upon >receipt of >an STI, or when service to a particular user is terminated. > >A Diameter server MUST be prepared to clean up resources if a session's >authorization lifetime has expired, and no STR was received. This event >could occur if an access device was to unexectedly reboot. > >An access device MUST issue Session-Termination-Request messages for all >active session prior to an orderly reboot." > >As far as eliminating the STI, in favor for allowing the STR to be >initiated >by either the server or the client, I haven't received comments from the WG >in favor of this approach. I believe that we can remove the STI, as far as I can see it does not add any extra value compared to sending an STR instead. And it will be one message less to keep track of, which is good. /Fredrik > >PatC From owner-aaa-bof@merit.edu Fri May 4 04:15: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 EAA06849 for ; Fri, 4 May 2001 04:15:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 944BC5DD8F; Fri, 4 May 2001 02:22:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7FBC05DDF1; Fri, 4 May 2001 02:22:08 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 0F7D75DD8F for ; Fri, 4 May 2001 02:22:07 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA11025; Thu, 3 May 2001 23:22:05 -0700 (PDT) Received: from vayne (muc-isdn-11 [129.157.164.111]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id IAA19903; Fri, 4 May 2001 08:22:03 +0200 (MET DST) Date: Fri, 4 May 2001 08:33:34 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft To: David Frascone , Mark Jones Cc: James Kempf , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <20010503130932.I16328@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 wrote: > I will author or coauthor it. Mark - want to collaborate on it? Oops - I didn't read the whole thread before responding - sorry. Mark Jones wrote: > If the goal is to define a DTD for Diameter dictionaries purely for the > purpose of attribute encoding/decoding (and NOT for validating the message > format) then I'm up for it. David Frascone wrote: > Sure, I can do it. Great - then we'll have 3 coauthors. Erik From owner-aaa-bof@merit.edu Fri May 4 04:31: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 EAA07001 for ; Fri, 4 May 2001 04:31:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7C9635DFA3; Fri, 4 May 2001 02:07:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 64F0E5DFA2; Fri, 4 May 2001 02:07:16 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id F0D795DD8F for ; Fri, 4 May 2001 02:07:14 -0400 (EDT) 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 XAA00324; Thu, 3 May 2001 23:07:11 -0700 (PDT) Received: from vayne (muc-isdn-11 [129.157.164.111]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id IAA19732; Fri, 4 May 2001 08:07:07 +0200 (MET DST) Date: Fri, 4 May 2001 08:18:38 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft To: James Kempf , Mark Jones Cc: aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <200105031731.KAA29523@heliopolis.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk >>> I would prefer that the dictionary be its own separate informational RFC. >>> It is independent of the API. > So do we have any volunteers who want to push this separate draft forward? I will author or coauthor it. Mark - want to collaborate on it? Erik From owner-aaa-bof@merit.edu Fri May 4 06:04: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 GAA07694 for ; Fri, 4 May 2001 06:04:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB5765DDB1; Thu, 3 May 2001 16:29:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8F27A5DDEC; Thu, 3 May 2001 16:29:33 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 938E45DDB1 for ; Thu, 3 May 2001 16:29:27 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA16285; Thu, 3 May 2001 13:29:24 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA05756; Thu, 3 May 2001 13:29:22 -0700 (PDT) Message-Id: <200105032029.NAA05756@heliopolis.eng.sun.com> Date: Thu, 3 May 2001 13:29:23 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft To: Brian.Cain@motorola.com, pcalhoun@diameter.org Cc: mjones@bridgewatersystems.com, James.Kempf@Sun.COM, aaa-wg@merit.edu, diameter@diameter.org, dave@frascone.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: kURa9whH4x+wUuC572OLzQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk >> After taking a quick look at Erik's DTD, it seems to not include any >> information about position/number/inclusion/exclusion of AVPs within >> commands. This would probably line up with your desire not to have the >> message's format validated by the DTD. What I don't understand is why it's >> desirable for this information to be absent. Is there another file format >> that is recommended for describing message formats? I don't see why XML >> wouldn't be able to describe it. Does the information not architecturally >> belong in a dictionary? > >Well, not dictionary in the historical sense. If a Diameter dictionary is more >than just a list of AVPs, then perhaps it should. > >My inclination is to leave that information out of the dictionary. > Actually, if construction of the Java command parser is to be completely driven by the dictionary, then this information will have to be in the dictionary. Otherwise, the parser won't be able to flag when a command arrives with an error. It is, of course, possible to programmatically insert that information into the command dictionary, but this would require the application extension code to deal with syntax instead of just semantics. Currently, the Java API allows the application extension code to just deal with the semantics of the command, and not have to set up the command dictionary for syntax. jak From owner-aaa-bof@merit.edu Fri May 4 08:36: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 IAA10931 for ; Fri, 4 May 2001 08:36:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 744865DEE6; Fri, 4 May 2001 08:32:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 615425DEE4; Fri, 4 May 2001 08:32:23 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 929AC5DEE3 for ; Fri, 4 May 2001 08:32:21 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id IAA04623; Fri, 4 May 2001 08:31:49 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma004621; Fri, 4 May 01 08:31:32 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id IAA18164; Fri, 4 May 2001 08:31:31 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma018044; Fri, 4 May 01 08:30:15 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <2XDRF6WL>; Fri, 4 May 2001 08:29:56 -0400 Message-ID: From: Balazs Czoma To: aaa-wg@merit.edu, diameter@diameter.org Subject: [AAA-WG]: Extension version Date: Fri, 4 May 2001 08:29:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hello, It shall be possible to identify/negotiate which extension version a certain application is supporting. I cannot find any hints regarding this in the Base Protocol. I think it would be necessary to define an AVP and procedures for this purpose. Regards: Balazs ____________________________________________ Balazs Czoma Siemens Telecom Innovation Centre mailto:Balazs.Czoma@tic.siemens.ca ____________________________________________ From owner-aaa-bof@merit.edu Fri May 4 08:42: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 IAA11101 for ; Fri, 4 May 2001 08:42:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2266C5DD9C; Fri, 4 May 2001 08:39:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0D0575DF01; Fri, 4 May 2001 08:39:48 -0400 (EDT) Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 038845DD9C for ; Fri, 4 May 2001 08:39:46 -0400 (EDT) Received: from fredrikj (c35.local.ipunplugged.com [192.168.4.234]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id OAA03272; Fri, 4 May 2001 14:40:39 +0200 From: "Fredrik Johansson" To: "Balazs Czoma" , , Subject: RE: [AAA-WG]: Extension version Date: Fri, 4 May 2001 14:41:29 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Balazs There is an AVP called ExtensionId AVP which is sent in the Device-Roboot-Indication message for this /Fredrik >-----Original Message----- >From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf >Of Balazs Czoma >Sent: den 4 maj 2001 14:30 >To: aaa-wg@merit.edu; diameter@diameter.org >Subject: [AAA-WG]: Extension version > > >Hello, > >It shall be possible to identify/negotiate which extension version >a certain >application is supporting. > >I cannot find any hints regarding this in the Base Protocol. I think it >would be necessary to define an AVP and procedures for this purpose. > >Regards: >Balazs >____________________________________________ >Balazs Czoma >Siemens Telecom Innovation Centre >mailto:Balazs.Czoma@tic.siemens.ca >____________________________________________ > > From owner-aaa-bof@merit.edu Fri May 4 09:39: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 JAA12232 for ; Fri, 4 May 2001 09:39:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6ACC85DE0E; Fri, 4 May 2001 09:31:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 489FC5DE1F; Fri, 4 May 2001 09:31:43 -0400 (EDT) Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 67F0A5DE0E for ; Fri, 4 May 2001 09:31:41 -0400 (EDT) Received: (qmail 15413 invoked by uid 500); 4 May 2001 13:36:55 -0000 Date: Fri, 4 May 2001 08:36:55 -0500 From: David Frascone To: Balazs Czoma Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: Extension version Message-ID: <20010504083655.C9177@newman.frascone.com> Mail-Followup-To: Balazs Czoma , 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 Balazs.Czoma@tic.siemens.ca on Fri, May 04, 2001 at 08:29:55AM -0400 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk I think with the huge address space given to extensions, we could just choose another extension for a different version, and servers can advertise that they accept both, or one, or the other. I think this is a better aproach than trying to do plain comparisons, so servers do not have to support older versions: For example, Mobile-IP version 27 comes out. If we include a version in the extension advertisement, then we could only state that the server supports version 27 or lower. And, any server implementor would have to implement ALL versions of Mobile-IP. But, this way, an implementor could support versions 25, 26, and 27, and would be able to advertise just that. Comments? On Fri, May 04, 2001 at 08:29:55AM -0400, Balazs Czoma wrote: > Hello, > > It shall be possible to identify/negotiate which extension version a certain > application is supporting. > > I cannot find any hints regarding this in the Base Protocol. I think it > would be necessary to define an AVP and procedures for this purpose. > > Regards: > Balazs > ____________________________________________ > Balazs Czoma > Siemens Telecom Innovation Centre > mailto:Balazs.Czoma@tic.siemens.ca > ____________________________________________ > > > From owner-aaa-bof@merit.edu Fri May 4 10:28: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 KAA13196 for ; Fri, 4 May 2001 10:28:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7A4D65DFF9; Fri, 4 May 2001 10:03:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 673BA5DFF8; Fri, 4 May 2001 10:03:52 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id A3A3C5DF39 for ; Fri, 4 May 2001 10:03:50 -0400 (EDT) Received: (qmail 29939 invoked by uid 500); 4 May 2001 13:53:35 -0000 Date: Fri, 4 May 2001 06:53:35 -0700 From: Pat Calhoun To: Mark Jones Cc: Fredrik Johansson , Balazs Czoma , aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [diameter] RE: [AAA-WG]: Extension version Message-ID: <20010504065335.J26582@charizard.diameter.org> Mail-Followup-To: Mark Jones , Fredrik Johansson , Balazs Czoma , aaa-wg@merit.edu, diameter@diameter.org References: <007101c0d4a1$b4174160$2096a8c0@mjones.bridgewatersys.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="FK65GREB+Evh/hTL" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <007101c0d4a1$b4174160$2096a8c0@mjones.bridgewatersys.com>; from mjones@bridgewatersystems.com on Fri, May 04, 2001 at 09:54:14AM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk --FK65GREB+Evh/hTL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 04, 2001 at 09:54:14AM -0400, Mark Jones wrote: > Are extension versions expected to be backwards compatible? Is support of > extension versions likely to be contiguous or will devices likely support > v1 and v3 of an extension but not v2? >=20 > Depending on the answers, we could: >=20 > 1. Get a new id from IANA for a new version of the extension. The DRI must > contain the extension id for every supported version. >=20 > 2. Replace Extension-ID in the DRI with a new Supported-Extension AVP. > This would be a Grouped AVP consisting of the Extension-Id and > Extension-Version AVPs. There would only be one per extension per DRI. > Could we assume that the Extension-Version will NOT need to be issued by > IANA since the 'owner' of the Extension-ID will issue them? (Do extensions > even have a designated 'owner' such as the draft author?) >=20 > If extensions are always backwards compatible, I vote for (2) since it is > more compact. If extension version support is unlikely to be contiguous > then (1) is my preference. I think that it would be really hard to determine at this point, or even enforce, that future versions of extensions would be "backward" compatible. If an extension is revised for security purposes, you wouldn't want to provide both the insecure (for backward compatibility reasons), and the secure version, right? PatC --FK65GREB+Evh/hTL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE68rRevcrGpbaK4X8RAkfdAJsEOm9g4oBtIS1M+MExo7xBeuo+NACfaqbd 9bGiZRxW2AaffinpwfoNUuI= =Km2z -----END PGP SIGNATURE----- --FK65GREB+Evh/hTL-- From owner-aaa-bof@merit.edu Fri May 4 10:29: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 KAA13242 for ; Fri, 4 May 2001 10:29:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C5375E003; Fri, 4 May 2001 10:14:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 793E75DFFE; Fri, 4 May 2001 10:14:44 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 4AB295DE8F for ; Fri, 4 May 2001 10:14:43 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA14682; Fri, 4 May 2001 07:14:40 -0700 (PDT) Received: from qwer (qwer [129.157.142.111]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id QAA27487; Fri, 4 May 2001 16:14:38 +0200 (MET DST) Message-Id: <200105041414.QAA27487@ehdb03-home.Germany.Sun.COM> Date: Fri, 4 May 2001 16:14:38 +0200 (MEST) From: Erik Guttman Reply-To: Erik Guttman Subject: [AAA-WG]: mailing list noise To: diameter@diameter.org, aaa-wg@merit.edu Cc: erik.guttman@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: haLkLPN1OcAT//GKmmLV2g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4m sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk I suggest that we stop CCing both diameter & aaa-wg for everything. aaa-wg: AAA standardization discussion diameter: diameter implementation, interop testing and other non-standardization, non-IETF oriented discussion If we can't do that - can we simply turn off the diameter list? It is getting really annoying to have to sort through two almost identical lists. Thanks, Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n SHORT msgs: 01728655497@d2-message.de Sr Staff Engineer, Sun Microsystems Email: erik.guttman@sun.com Altrotstrasse 31, D-69190 Walldorf Germany Mobile: +49 172 865 5497 From owner-aaa-bof@merit.edu Fri May 4 10:29: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 KAA13256 for ; Fri, 4 May 2001 10:29:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E5EF45DE12; Fri, 4 May 2001 10:29:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9E5345DE3B; Fri, 4 May 2001 10:29:06 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id E241D5DE12 for ; Fri, 4 May 2001 10:29:01 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19645; Fri, 4 May 2001 07:28:59 -0700 (PDT) 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 HAA00289; Fri, 4 May 2001 07:28:57 -0700 (PDT) Received: from darius (darius [152.70.40.121]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA23418; Fri, 4 May 2001 07:28:50 -0700 (PDT) Date: Fri, 4 May 2001 07:28:58 -0700 (PDT) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: mailing list noise To: Erik Guttman Cc: diameter@diameter.org, aaa-wg@merit.edu, erik.guttman@sun.com In-Reply-To: "Your message with ID" <200105041414.QAA27487@ehdb03-home.Germany.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Erik, I have been trying to figure out what to do with the diameter list as well, and I believe that you have a great suggestion. So I agree that the the IETF mailing list should be used for comments and questions on the I-Ds, while the diameter list is used for interop, where can I find implementations, how do you code..., and other similar questions. I will try to direct people when I catch them slipping up. PatC > > I suggest that we stop CCing both diameter & aaa-wg for everything. > > aaa-wg: AAA standardization discussion > diameter: diameter implementation, interop testing and other > non-standardization, non-IETF oriented discussion > > If we can't do that - can we simply turn off the diameter list? > > It is getting really annoying to have to sort through two almost > identical lists. > > Thanks, > > Erik > > ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. > E r i k G u t t m a n SHORT msgs: 01728655497@d2-message.de > Sr Staff Engineer, Sun Microsystems Email: erik.guttman@sun.com > Altrotstrasse 31, D-69190 Walldorf Germany Mobile: +49 172 865 5497 > > From owner-aaa-bof@merit.edu Fri May 4 11:32: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 LAA14470 for ; Fri, 4 May 2001 11:32:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BBA3A5DDEB; Fri, 4 May 2001 11:29:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A3C895DDED; Fri, 4 May 2001 11:29:59 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 6F93C5DDEB for ; Fri, 4 May 2001 11:29:58 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA18259; Fri, 4 May 2001 08:29:39 -0700 (PDT) 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 IAA08488; Fri, 4 May 2001 08:29:38 -0700 (PDT) Received: from darius (darius [152.70.40.121]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA23870; Fri, 4 May 2001 08:29:35 -0700 (PDT) Date: Fri, 4 May 2001 08:29:43 -0700 (PDT) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: transport MUSTs To: Bernard Aboba Cc: David Frascone , Jari Arkko , aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > > Also, section 1.1 says that Diameter should be > > > transported over SCTP. How should this be > > > interpreted with respect to the first information > > > piece above. Or does this statement mean that > > > when multiple transports are available, SCTP > > > should be used? > > > > I believe that was the intent. SCTP is the preferred Diameter transport. > > > > The wording in section 1.1 is inconsistent with the decision of the > Interim meeting as well as WG consensus at IETF 50. SCTP support on the > client is not a SHOULD. Please reread the interim meeting minutes and fix > this. > Looks like you missed my response. This paragraph has been deleted from section 1.1, since there is a whole section on transports that addresses the decision made at the interim meeting. Look at -03 for more details. PatC From owner-aaa-bof@merit.edu Fri May 4 11:40: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 LAA14660 for ; Fri, 4 May 2001 11:40:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 77ABD5DFAF; Fri, 4 May 2001 10:08:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5A4175DFAE; Fri, 4 May 2001 10:08:48 -0400 (EDT) Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 93A0C5DE9C for ; Fri, 4 May 2001 10:08:46 -0400 (EDT) Received: (qmail 23722 invoked by uid 500); 4 May 2001 14:14:01 -0000 Date: Fri, 4 May 2001 09:14:01 -0500 From: David Frascone To: pcalhoun@diameter.org Cc: diameter@diameter.org, aaa-wg@merit.edu Subject: Re: [diameter] RE: [AAA-WG]: Extension version Message-ID: <20010504091401.F9177@newman.frascone.com> Mail-Followup-To: pcalhoun@diameter.org, diameter@diameter.org, aaa-wg@merit.edu References: <007101c0d4a1$b4174160$2096a8c0@mjones.bridgewatersys.com> <20010504065335.J26582@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010504065335.J26582@charizard.diameter.org>; from pcalhoun@diameter.org on Fri, May 04, 2001 at 06:53:35AM -0700 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk > I think that it would be really hard to determine at this point, or even > enforce, that future versions of extensions would be "backward" compatible. > If an extension is revised for security purposes, you wouldn't want to > provide both the insecure (for backward compatibility reasons), and the > secure version, right? > Good Point. From owner-aaa-bof@merit.edu Fri May 4 11:42: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 LAA14736 for ; Fri, 4 May 2001 11:42:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2CAF55DE45; Fri, 4 May 2001 11:33:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1BB515DE3C; Fri, 4 May 2001 11:33:43 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id EF4185DDFC for ; Fri, 4 May 2001 11:33:40 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA02834; Fri, 4 May 2001 08:25:51 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 4 May 2001 08:25:50 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: Jari Arkko , aaa-wg@merit.edu Subject: Re: [AAA-WG]: transport MUSTs In-Reply-To: <20010503070855.E26582@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > correct, however, the actual text for clients is: > > "Diameter clients MUST > support TCP, but are warned that future versions of this specification > may mandate SCTP support." > > So clients should use TCP (but can, of course, use SCTP if they support it), > and servers communicate with each other using SCTP. > Given the differing interpretations it probably makes sense to clarify what transports are to be used when both are available, and how client and servers can determine which transports are in use. Remember, mandatory to implement does NOT imply mandatory to use. So even if SCTP is available on a server or client, it may not be enabled: a. How does a client (or server) determine what transports are supported on the other system? Is DNS SRV used for this? b. What happens if a server sends a message to client using SCTP and a "port unreachable" is returned? Does the server retry using TCP? c. What happens if a client sends a message to a server using TCP and a "port unreachable" is returned. Does the client retry using SCTP? > Thanks for that. The last paragraph in section 1.1 needs to be deleted. > Yup. From owner-aaa-bof@merit.edu Fri May 4 11:43: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 LAA14749 for ; Fri, 4 May 2001 11:43:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3E3765DEA8; Fri, 4 May 2001 11:36:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2BB985DEA6; Fri, 4 May 2001 11:36:53 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by segue.merit.edu (Postfix) with SMTP id D657B5DEA5 for ; Fri, 4 May 2001 11:36:51 -0400 (EDT) Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id LAA04028; Fri, 4 May 2001 11:36:47 -0400 Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Fri, 4 May 2001 11:36:37 -0400 Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KHAN73CQ; Fri, 4 May 2001 11:36:34 -0400 Received: from mitton.nortelnetworks.com (47.16.86.121 [47.16.86.121]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KBYWFX8K; Fri, 4 May 2001 11:36:35 -0400 Message-Id: <4.3.2.7.2.20010504113236.00d279a0@ZBL6C016.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C016.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 May 2001 11:38:27 -0400 To: Patrice Calhoun From: "David Mitton" Subject: [AAA-WG]: Re: mailing list noise Cc: diameter@diameter.org, aaa-wg@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Sender: owner-aaa-bof@merit.edu Precedence: bulk I second this. Furthermore, Please do not cross-post, I cannot filter properly on subject lines that contain both [diameter] and [AAA-WG] and I end up with double copies in one folder. It's much more annoying when the two lists get merged together, and I have to spend time trying to figure which got posted and replied to where. Something just got fixed in Nortel email (however temporarily) and I just got 2 days worth of AAA and Diameter all at once. Dave. At 5/4/01 10:28 AM -0400, Patrice Calhoun wrote: >Erik, > >I have been trying to figure out what to do with the diameter list as well, >and I believe that you have a great suggestion. > >So I agree that the the IETF mailing list should be used for comments and >questions on the I-Ds, while the diameter list is used for interop, where can >I find implementations, how do you code..., and other similar questions. > >I will try to direct people when I catch them slipping up. > >PatC > > > > I suggest that we stop CCing both diameter & aaa-wg for everything. > > > > aaa-wg: AAA standardization discussion > > diameter: diameter implementation, interop testing and other > > non-standardization, non-IETF oriented discussion > > > > If we can't do that - can we simply turn off the diameter list? > > > > It is getting really annoying to have to sort through two almost > > identical lists. > > ------------------------------------------------------------ David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Wireless Solutions, IP Mobility Billerica, MA 01821 dmitton@nortelnetworks.com From owner-aaa-bof@merit.edu Fri May 4 12:36:37 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16339 for ; Fri, 4 May 2001 12:36:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B5B235DDF1; Fri, 4 May 2001 12:30:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6E6C15DDFA; Fri, 4 May 2001 12:30:14 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 0755C5DDF1 for ; Fri, 4 May 2001 12:30:09 -0400 (EDT) Received: (qmail 2127 invoked by uid 500); 4 May 2001 16:19:55 -0000 Date: Fri, 4 May 2001 09:19:55 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: A proposal for the elimination of MRI Message-ID: <20010504091955.O26582@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, Following an e-mail by Paul Funk a few days ago, it is clear that the MRI message can be problematic (see the earlier message for details). I have been thinking about this for a couple of days now, and have come to the conclusion that the MRI message can be completely eliminated. This e-mail contains the necessary justifications. Currently, the base draft contains four error conditions that cause an MRI. They are: 1. Poorly formatted message. I would argue that a poorly formatted message is really a per-hop problem, since the first hop would recognize that the message is malformed, and would return an error to the originator of the message. So this error condition could be handled by the DSI. 2. Unknown command code. This error occurs when a proxy receives the message, but has no servers that supports the extension in the home domain. The initial reason why the MRI was used, instead of the natural request's answer, was that the proxy may not recognize the request, and wouldn't know what to set the command code to. However, in -03, it is now mandatory that servers support all extensions, so it is now possible for the proxy to simply return the natural answer with an error condition stating that the message couldn't be delivered. I therefore believe that this use of the MRI is no longer needed. 3. AVP marked mandatory is unsupported. This error can occur in two directions; towards the home domain (request) and towards the NAS (response) [note, of course for server initiated messages, this would be inversed, but I am just using this terminology for clarity]. If a proxy had received a request, and it contained an unrecognized AVP with the 'M' bit set, it would have to return an error. Again, since servers must support all extensions, the proxy can now return the natural answer with the Result-Code AVP set to the correct value. If a proxy had received an answer, and it contained the same error, the proxy would have to overwrite the Result-Code AVP with the local error. This means that the Result-Code AVP MAY appear more than once in a message. I would also prefer to see the Result-Code combined with the Error-Reporting-FQDN AVP. Perhaps this is needed as a Grouped AVP? So now a NAS would have to look at more than one possible Result- Code AVP, and if one contained an error, it would have to reject the answer. Now a new problem presents itself. How does the home server know that the answer was rejected? We can do one of two things: 1. Introduce a new -Ind message that is used to inform the home server that an answer was bad, and therefore ignored. This is hard, and has the same issues as the MRI one that were discussed on the list. 2. Have the NAS issue an STR, with a Termination-Cause. This seems to be the best approach. 4. An AVP is received with an unknown or illegal value I would argue that this error is VERY similar to case #3, and should be handled the same way. So as you can see, now that the Diameter protocol has evolved, the need for the MRI isn't there anymore. So I would propose that we make the necessary changes described above, and eliminate the command code. Thoughts? PatC From owner-aaa-bof@merit.edu Fri May 4 12:45:42 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16618 for ; Fri, 4 May 2001 12:45:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9492E5DDF7; Fri, 4 May 2001 09:51:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 82B545DDF2; Fri, 4 May 2001 09:51:31 -0400 (EDT) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 953FD5DDF1 for ; Fri, 4 May 2001 09:51:29 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id JAA01696; Fri, 4 May 2001 09:45:34 -0400 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id JAA12785; Fri, 4 May 2001 09:52:18 -0400 (EDT) From: "Mark Jones" To: "Fredrik Johansson" , "Balazs Czoma" , , Subject: RE: [AAA-WG]: Extension version Date: Fri, 4 May 2001 09:54:14 -0400 MIME-Version: 1.0 Message-ID: <007101c0d4a1$b4174160$2096a8c0@mjones.bridgewatersys.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; micalg=SHA-1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0066_01C0D480.2BF12420" In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0066_01C0D480.2BF12420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Are extension versions expected to be backwards compatible? Is support of extension versions likely to be contiguous or will devices likely support v1 and v3 of an extension but not v2? Depending on the answers, we could: 1. Get a new id from IANA for a new version of the extension. The DRI must contain the extension id for every supported version. 2. Replace Extension-ID in the DRI with a new Supported-Extension AVP. This would be a Grouped AVP consisting of the Extension-Id and Extension-Version AVPs. There would only be one per extension per DRI. Could we assume that the Extension-Version will NOT need to be issued by IANA since the 'owner' of the Extension-ID will issue them? (Do extensions even have a designated 'owner' such as the draft author?) If extensions are always backwards compatible, I vote for (2) since it is more compact. If extension version support is unlikely to be contiguous then (1) is my preference. Regards, Mark ------=_NextPart_000_0066_01C0D480.2BF12420 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw ggH9oAMCAQICAwS4ODANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDUwMTE4MTgwOFoXDTAyMDUwMTE4MTgwOFowTzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdbWpvbmVzQGJyaWRnZXdhdGVyc3lzdGVt cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMemr5diJO/8+r2Hj3Opr9LbaVAXFgo2 Fhu0tfSSdvlMy52Y67GMoJbv0I282FWO9z4bsnuSIU7y3arEmyA78mwjTSdt2GK5QJHT6jKOqF6M 81Q5j2fU3dQwCPiCQZlOqUJEA3PySRjUQNOgnRUhoSuzGd7IMJ3Y6oeMtE8a02nTAgMBAAGjOjA4 MCgGA1UdEQQhMB+BHW1qb25lc0BicmlkZ2V3YXRlcnN5c3RlbXMuY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEANyubKv2ajV9VxVe4xUDaqZbQ2DEXgGKSFWwsdC06zUucuCmeHHqT vLcoUnI8/dCbSnSwRrELpemSoqTv/99uW+jS6cN5320w1ZEBsC2RSVrSJd8LqxKALmMexgbywYvF /hMe120ctocvwnfbeZmzBIKSF7BDs8YPGzSWgsa5gKUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2 17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP 6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9 edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O +PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R hGvk+NHOd6KBMYICmzCCApcCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDBLg4MAkGBSsOAwIaBQCgggFWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDUwNDEzNTQxMlowIwYJKoZIhvcNAQkEMRYEFBuNRz+sp3CWtoDIf2tMXjsZcI1q MEkGCSqGSIb3DQEJDzE8MDowCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMAIDBLg4MA0GCSqGSIb3DQEBAQUABIGACzSj94n4wzm0kxvEhoMJz2J1 p0G//8zob4WbTgZrFFs3F4amU3Fi/V5iRYeRNGl8Qy7CKo4yZ6f+K5wBss1li40OhxOhngLXHEaf q+gYb3Fb3ryalwgLndyzs6Vpls/mZ86r5QsbSt1YW/TXE0/pzmfHxNPtx5MdRq7rS2cUfuAAAAAA AAA= ------=_NextPart_000_0066_01C0D480.2BF12420-- From owner-aaa-bof@merit.edu Fri May 4 13:18:48 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17351 for ; Fri, 4 May 2001 13:18:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C1F145DE7B; Thu, 3 May 2001 17:36:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A502B5DE71; Thu, 3 May 2001 17:36:41 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 15C155DE5B for ; Thu, 3 May 2001 17:36:40 -0400 (EDT) Received: (qmail 15911 invoked by uid 500); 3 May 2001 21:26:28 -0000 Date: Thu, 3 May 2001 14:26:27 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'Patrice Calhoun'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Msg Header Identifiers?? Message-ID: <20010503142627.Z26582@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , 'Patrice Calhoun' , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA01D7FFBF@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA01D7FFBF@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Thu, May 03, 2001 at 11:38:50AM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, May 03, 2001 at 11:38:50AM +0200, Martin Julien (ECE) wrote: > > A home server may want to minimize processing unnecessary > > packets, and the E2E > > ID would allow it to queue recently sent responses. Of course, the > > Record-Route AVPs and Proxy-State (now Proxy-Info) should > > have to change. > > Ok, I see that we might want to keep the e2e identifier. However, it > remains unclear to me how a duplicate message should be handled by a > server that detects it. If it only discards the Request/Query/Indication > messages, then I guess that the dowstream proxy will retry sending it > again and again, which is not right. req/query/ind are not dropped. They are responded to. Answer and Responses are dropped. Therefore, since requests aren't dropped, it is likely that it will receive multiple responses. > Should it be informed that it is > a duplicate message that is already being processed? I guess that we are > having the same problem with duplicate answer/response messages. Not at all. Duplication requests could occur due to node failures or network congestion. So, if multiple copies of a request makes it to a home server, that's ok. One will surely make it back. This isn't a process that goes on and on. A request that a max lifetime, and when it expires, a DSI is returned. PatC From owner-aaa-bof@merit.edu Fri May 4 13:24:30 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17454 for ; Fri, 4 May 2001 13:24:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6520C5DF15; Fri, 4 May 2001 13:22:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 524875DF12; Fri, 4 May 2001 13:22:51 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id E7FB85DF0A for ; Fri, 4 May 2001 13:22:48 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id NAA08132; Fri, 4 May 2001 13:22:47 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma008127; Fri, 4 May 01 13:22:24 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id NAA25061; Fri, 4 May 2001 13:22:24 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma024891; Fri, 4 May 01 13:21:22 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <2XDRF7B9>; Fri, 4 May 2001 13:21:03 -0400 Message-ID: From: Yiwen Jiang To: "'Pat Calhoun'" Cc: "'James Kempf'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question on MRI Date: Fri, 4 May 2001 13:21:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, > > What about another error condition where none of the > extensions that the > > peer advertised via DRI message is supported by the > receiving server? > > That error condition is handled by the DSI, since it is > handle on a per > hop basis, and a proxy could try another server. I went read through the events listed under DSI, but couldn't find an event that maps to the scenario above. :( I'm not sure why this would be related to proxy though... You see, if peer A tries to connect to a peer B that is completely incompatible (extension wise) with A, where the Destination-FQDN AVP for the DRI message is peer B. There will be no proxy involved, since proxying implies different realm, right? Or did I mis-understood? To me, this scenario is a valid one, and it is not being handled... Sorry for asking the same question many times, I'm just a bit confused.. :( From owner-aaa-bof@merit.edu Fri May 4 13:40:18 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17780 for ; Fri, 4 May 2001 13:40:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7BD2E5DD9F; Fri, 4 May 2001 13:36:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5FA415DDED; Fri, 4 May 2001 13:36:53 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D1C8A5DD9F for ; Fri, 4 May 2001 13:36:51 -0400 (EDT) Received: (qmail 3486 invoked by uid 500); 4 May 2001 17:26:37 -0000 Date: Fri, 4 May 2001 10:26:37 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: New version of sun ping available Message-ID: <20010504102637.Q26582@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, The new version of the Sun-Ping Diameter extension is available at www.diameter.org. Given that we have found this extension crucial in Diameter proxy chain troubleshooting, is there anyone out there that has found this extension generally useful? Thanks, PatC From owner-aaa-bof@merit.edu Fri May 4 15:19:01 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19477 for ; Fri, 4 May 2001 15:19:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7569B5DF2B; Fri, 4 May 2001 11:50:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4103C5DF2D; Fri, 4 May 2001 11:50:50 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 3A1345DF2B for ; Fri, 4 May 2001 11:50:46 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA02847; Fri, 4 May 2001 08:42:35 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 4 May 2001 08:42:35 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: Jeff Meyer , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Vendor-Specific Values In-Reply-To: <20010503065823.C26582@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > This requirement was introduced by some folks that have had prior > experience with accounting using SNMP, and the problems that occured (they > can chime in at this point, if they like). > Response bloating was one of the more significant problems uncovered with SNMP usage in accounting. In cases where inbound traffic to the NAS is causing congestion (more likely than outbound, in general), multiplying the size of the Accounting Response by a factor of 3 or 4 is likely to result in packet loss. > > I'm asking, because IPDR.org is looking at means to effectively > > create unique attribute identifiers for bulk self-describing delivery > > of accounting information and Diameter's flat structure > > seems problematic in an environment where lots of new > > attributes will be defined. Note that IPDR is strictly > > interested in the accounting aspect and not authorization/authen. > Actually, DIAMETER's attribute space is not limiting in this situation. Just create a DIAMETER attribute that serves as an "opaque" bag within which you can package your accounting data in the format of your choosing. The rest of the DIAMETER Accounting Message can be thought of as an "envelope" for that bag. Within the IPDR vendor-specific AVP you can do whatever you want. Note that Accounting servers often write the accounting message to disk rather than examining the attributes in detail; in such implementations, all accounting attributes are non-mandatory. Thus, it may not even be necessary for the accounting server to support IPDR -- if the accounting server implementation just writes the IPDR information to disk, a separate module can be written to parse it and process the information after it has been stored by the accounting server. > > The simplicity of just using integer identifiers seems > > appealing, but if the space of attributes grows like > > the space of attributes for SNMP, not having a hierarchical > > structure seems like a problem. Perhaps this type of > > growth isn't expected. > Not really. If an "opaque bag" is used as described above, then you'll only need 1 DIAMETER AVP no matter how big the space of attributes gets. From owner-aaa-bof@merit.edu Fri May 4 16:48:54 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20425 for ; Fri, 4 May 2001 16:48:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E6FA5DF6A; Fri, 4 May 2001 10:01:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D324D5DF69; Fri, 4 May 2001 10:01:16 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E575A5DF59 for ; Fri, 4 May 2001 10:01:06 -0400 (EDT) Received: (qmail 29681 invoked by uid 500); 4 May 2001 13:50:52 -0000 Date: Fri, 4 May 2001 06:50:52 -0700 From: Pat Calhoun To: Balazs Czoma Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: [AAA-WG]: Re: [diameter] Extension version Message-ID: <20010504065051.I26582@charizard.diameter.org> Mail-Followup-To: Balazs Czoma , 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 Balazs.Czoma@tic.siemens.ca on Fri, May 04, 2001 at 08:29:55AM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, May 04, 2001 at 08:29:55AM -0400, Balazs Czoma wrote: > Hello, > > It shall be possible to identify/negotiate which extension version a certain > application is supporting. > > I cannot find any hints regarding this in the Base Protocol. I think it > would be necessary to define an AVP and procedures for this purpose. In the event that an extension, which has already been RFCed, is updated, and contains new mandatory AVPs in some of the commands, it will be necessary to assign it a new extension identifier. PatC From owner-aaa-bof@merit.edu Fri May 4 17:36:54 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21246 for ; Fri, 4 May 2001 17:36:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C3D1A5DE2F; Fri, 4 May 2001 14:38:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AEF1B5DEBC; Fri, 4 May 2001 14:38:07 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id E4A995DE2F for ; Fri, 4 May 2001 14:38:05 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id OAA08936; Fri, 4 May 2001 14:38:05 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma008932; Fri, 4 May 01 14:37:36 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id OAA03779; Fri, 4 May 2001 14:37:36 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma003647; Fri, 4 May 01 14:36:26 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <2XDRF712>; Fri, 4 May 2001 14:36:07 -0400 Message-ID: From: Yiwen Jiang To: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: A proposal for the elimination of MRI and comments on -03. Date: Fri, 4 May 2001 14:36:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, > 2. Unknown command code. > > This error occurs when a proxy receives the message, but has no > servers that supports the extension in the home domain. The > initial reason why the MRI was used, instead of the natural > request's answer, was that the proxy may not recognize the > request, and wouldn't know what to set the command code to. > > However, in -03, it is now mandatory that servers support > all extensions, so it is now possible for the proxy to > simply return the natural answer with an error condition stating > that the message couldn't be delivered. If the servers all support all extensions, why would proxy return an error and couldn't deliver the message? > 3. AVP marked mandatory is unsupported. > > This error can occur in two directions; towards the home domain > (request) and towards the NAS (response) [note, of course for > server initiated messages, this would be inversed, but I am just > using this terminology for clarity]. > > If a proxy had received a request, and it contained an > unrecognized > AVP with the 'M' bit set, it would have to return an > error. Again, > since servers must support all extensions, the proxy can now > return the natural answer with the Result-Code AVP set to the > correct value. > > If a proxy had received an answer, and it contained the same > error, the proxy would have to overwrite the Result-Code AVP > with the local error. This means that the Result-Code AVP MAY > appear more than once in a message. I would also prefer to > see the Result-Code combined with the Error-Reporting-FQDN AVP. > Perhaps this is needed as a Grouped AVP? I agree that a group AVP is a better way to do this. > So now a NAS would have to look at more than one > possible Result- > Code AVP, and if one contained an error, it would have to > reject the answer. Maybe this already has been discussed before, but why MUST a proxy care whether it supports some AVPs for messages that is not destined to itself? I mean shouldn't a proxy first checks to see if a message's Destination-FQDN is itself, and if no, just simply forwards the message, and not care for its contents? The AVP supportability check would be only relavent and conducted by the end servers, no? > Now a new problem presents itself. How does the home server know > that the answer was rejected? We can do one of two things: > > 1. Introduce a new -Ind message that is used to inform the > home server that an answer was bad, and therefore ignored. > This is hard, and has the same issues as the MRI one that > were discussed on the list. > > 2. Have the NAS issue an STR, with a Termination-Cause. This > seems to be the best approach. But if this is the case, how is a peer to peer connection separated from a user session connection? From what I understood so far on the base protocol, peer connections and session connections are two separate entities. when a server is proxying a request, it would/should use the peer to peer connection, right? How would the receipt of STR from NAS tells the server that one of the messages it sent via the peer connection is rejected? On another note, maybe I am completely reading this wrong, but it is my feeling that as the base protocol evolves, the peer connections and session connections are evolving to be more related to each other, rather than in the initial drafts, where they are two completely separate entities? > 4. An AVP is received with an unknown or illegal value > > I would argue that this error is VERY similar to case #3, and > should be handled the same way. Could this be another item handled by the DSI? > So as you can see, now that the Diameter protocol has > evolved, the need for > the MRI isn't there anymore. So I would propose that we make > the necessary > changes described above, and eliminate the command code. As the base draft evolve, it is my personal impression that it gets bulkier, especially in the case of how extensions are associated with the Diameter server, i.e. what does a diameter server support? Initially, it was just the base, with one or more extensions, regardless of the type of the extension. Then, accounting is added as part of the server. Now, in -03, Page 11, "Diameter servers MUST support the Base protocol, which includes Accounting, and both the NASREQ and Mobile IP extensions." This sentence is quite similar to a statement in -01, when it talked about Diameter servers MUST support the Base protocol, and the accounting extensions. Does this sentence mean that any server that do not support any of the three extensions cannot be identified as a "Diameter server"? If this is the case, the Diameter server is no longer a "pluggable" server with extensions. Right? In addition, should there be a new extension Foo proposed and accepted, and a Diameter server that supports Foo is built and deployed to the network, all existing Diameter proxies will not recognize the Foo specific commands when they receive it, and will reject them. So how does new extensions server actually integrate/communicate with the existing Diameter servers on the network? Thanks! Yiwen From owner-aaa-bof@merit.edu Fri May 4 18:29:08 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21757 for ; Fri, 4 May 2001 18:29:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E36385DDD9; Fri, 4 May 2001 18:28:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CC1FA5DDFB; Fri, 4 May 2001 18:28:49 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id E42F95DDD9 for ; Fri, 4 May 2001 18:28:47 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id SAA10518; Fri, 4 May 2001 18:28:47 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma010516; Fri, 4 May 01 18:28:22 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id SAA18712; Fri, 4 May 2001 18:28:21 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma018665; Fri, 4 May 01 18:27:11 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <2XDRF7H2>; Fri, 4 May 2001 18:26:52 -0400 Message-ID: From: Yiwen Jiang To: "'Pat Calhoun'" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: A proposal for the elimination of MRI and comments on -03. Date: Fri, 4 May 2001 18:26:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, > > > 2. Unknown command code. > > > > > > This error occurs when a proxy receives the message, but has no > > > servers that supports the extension in the home domain. The > > > initial reason why the MRI was used, instead of the natural > > > request's answer, was that the proxy may not recognize the > > > request, and wouldn't know what to set the command code to. > > > > > > However, in -03, it is now mandatory that servers support > > > all extensions, so it is now possible for the proxy to > > > simply return the natural answer with an error condition stating > > > that the message couldn't be delivered. > > If the servers all support all extensions, why would proxy > return an error > > and couldn't deliver the message? > > Just because a server supports all extensions, they aren't necessarily > enabled (turned on). So, it is possible for no servers in the > home domain > to advertise a given extension. Hmm... When would this scenario happen? It won't be in peer to peer case, because to establish that connection, both peer must support the same extension. Would this be to deal with unsolicited messages? or is this specific to Mobile-IP extension for roaming? > > > > > So now a NAS would have to look at more than one > > > possible Result- > > > Code AVP, and if one contained an error, it would have to > > > reject the answer. > > Maybe this already has been discussed before, but why MUST > a proxy care > > whether it supports some AVPs for messages that is not > destined to itself? I > > mean shouldn't a proxy first checks to see if a message's > Destination-FQDN > > is itself, and if no, just simply forwards the message, and > not care for its > > contents? The AVP supportability check would be only > relavent and conducted > > by the end servers, no? > > Some proxies do more than just forward. Some maintain state > information, > some do policy checks, etc. So it is feasible for a proxy to > care what's > inside a message. But if a proxy doesn't recognize an AVP, why can it not just ignore it and care about the ones it does understand, but still forward the request to the next hop? > Let me try again. A NAS issues a request, and the home server > sends back > a response. The NAS receives the response, but doesn't like > its contents. > It has to signal to the home server that the session was > never started, so > it issues an STR, with a Termination-Cause of "Didn't like > your AVP set", > or some such error. Okay, that made sense. Thanks! But relate back to the discussion earlier how NAS would examine the packet received, and parse through the various error Result-Code put in by the intermediate proxies that didn't understand some of the AVPs, right? My idea is, that if those unknown AVP related result code weren't there, the only Result-Code is there, should be the result from the end server, and this makes the logic in NAS much simpler.. Or does NAS really have to know that the intermediate proxies do not support some AVPs it uses? > > > 4. An AVP is received with an unknown or illegal value > > > > > > I would argue that this error is VERY similar to case #3, and > > > should be handled the same way. > > Could this be another item handled by the DSI? > > Only if an intermediate proxy determines this. In any case, > this error has > to be signaled back to the NAS, so a per-hop behavior is the > wrong approach. > A response with the Result-Code set to "no way joe" is the > right thing to do. Agreed. > > Now, in -03, Page 11, "Diameter servers MUST support the > Base protocol, > > which includes Accounting, and both the NASREQ and Mobile > IP extensions." > > This sentence is quite similar to a statement in -01, when > it talked about > > Diameter servers MUST support the Base protocol, and the accounting > > extensions. Does this sentence mean that any server that do > not support any > > of the three extensions cannot be identified as a "Diameter > server"? If this > > is the case, the Diameter server is no longer a "pluggable" > server with > > extensions. Right? > > This sentence was added based on comments generated by the > IESG. Take it up > with the ADs and the chair if you do not like this requirement. Okay, thanks for the info. > > In addition, should there be a new extension Foo proposed > and accepted, and > > a Diameter server that supports Foo is built and deployed > to the network, > > all existing Diameter proxies will not recognize the Foo > specific commands > > when they receive it, and will reject them. So how does new > extensions > > server actually integrate/communicate with the existing > Diameter servers on > > the network? > > Correct, they wouldn't be able to provide the correct response. > > There is, however, a fix to this problem. I have spent a > whole 21 seconds > thinking about this, so please exercise patience if I explain > it wrong, or > even if it doesn't make a whole lot of sense. You've been so patient with me, and I know you must be swamped, so don't worry. :) > Currently, the protocol defines command codes. Some are > Requests and others > are Answers. A proxy must know the right command code to set should it > receive a request it has a problem with. Your suggestion > above states that > if a new extension, foobar, comes out and gets deployed, and > an error is > found in a packet, a proxy that doesn't support an extension > wouldn't know > how to respond. > > What if we all request/answer commands only require a single > command code, > and the EIR bits in the header was used to determine if the > command was > a request, or an answer? This way, new extensions could be > deployed, and > if a proxy didn't support the particular extension, and found > an error in > a request, it could still return the correct response. > > Does this make sense? So you are saying, that if a proxy found an obvious error in the request that it doesn't support, it should just change the appropriate EIR bits, and reply it back to the server that sent the request using the same command code? Hmm... I think that would work... But what about errors with -Ind messages? Or does the proxy check for the validity of AVPs only with Request/Answer messages? Or another way, is to allow the proxy to skip AVPs that it does not understand, and just do the validity check with AVPs that it understands, if error, return correct response, else pass onto the next hop. Or is this really not desired behaviour? > (btw, thanks for the great scenarios you are discussing) My pleasure... It's been a great learning experience, and I'm really enjoying the discussions that are happening on the mailing list... And thanks again for your prompt responses and patient help... It's been great. :) Cheers, Yiwen From owner-aaa-bof@merit.edu Fri May 4 19:03:59 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22042 for ; Fri, 4 May 2001 19:03:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 958125DE00; Fri, 4 May 2001 11:26:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 843695DDF4; Fri, 4 May 2001 11:26:30 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 83B895DDF1 for ; Fri, 4 May 2001 11:26:28 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA02824; Fri, 4 May 2001 08:18:35 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 4 May 2001 08:18:35 -0700 (PDT) From: Bernard Aboba To: David Frascone Cc: Jari Arkko , aaa-wg@merit.edu Subject: Re: [AAA-WG]: transport MUSTs In-Reply-To: <20010503081916.F10879@newman.frascone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > Also, section 1.1 says that Diameter should be > > transported over SCTP. How should this be > > interpreted with respect to the first information > > piece above. Or does this statement mean that > > when multiple transports are available, SCTP > > should be used? > > I believe that was the intent. SCTP is the preferred Diameter transport. > The wording in section 1.1 is inconsistent with the decision of the Interim meeting as well as WG consensus at IETF 50. SCTP support on the client is not a SHOULD. Please reread the interim meeting minutes and fix this. From owner-aaa-bof@merit.edu Fri May 4 20:03:57 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22612 for ; Fri, 4 May 2001 20:03:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 628815DE82; Fri, 4 May 2001 11:48:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 383825DECE; Fri, 4 May 2001 11:48:52 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id F02BE5DE82 for ; Fri, 4 May 2001 11:48:49 -0400 (EDT) Received: (qmail 804 invoked by uid 500); 4 May 2001 15:38:35 -0000 Date: Fri, 4 May 2001 08:38:35 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Pat Calhoun , Jari Arkko , aaa-wg@merit.edu Subject: Re: [AAA-WG]: transport MUSTs Message-ID: <20010504083835.L26582@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Pat Calhoun , Jari Arkko , aaa-wg@merit.edu References: <20010503070855.E26582@charizard.diameter.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Ah9ph+G2cWRpKogL" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Fri, May 04, 2001 at 08:25:50AM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk --Ah9ph+G2cWRpKogL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 04, 2001 at 08:25:50AM -0700, Bernard Aboba wrote: > Given the differing interpretations > it probably makes sense to clarify what transports are to be used when > both are available, and how client and servers can determine which > transports are in use. Remember, mandatory to implement does NOT imply > mandatory to use. So even if SCTP is available on a server or client, it > may not be enabled: This certain is correct. >=20 > a. How does a client (or server) determine what transports are supported > on the other system? Is DNS SRV used for this?=20 That is one method, if DNS is used. >=20 > b. What happens if a server sends a message to client using SCTP and a > "port unreachable" is returned? Does the server retry using TCP? >=20 > c. What happens if a client sends a message to a server using TCP and a > "port unreachable" is returned. Does the client retry using SCTP? The text states that SCTP support on servers is mandatory, but not on clients. However, SCTP *is* supported on clients. So, I would urge the WG to consider that SCTP is tried first, and if a connection fails, TCP is tried. This favors SCTP, but does allow TCP only implementations to operate. PatC --Ah9ph+G2cWRpKogL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE68sz6vcrGpbaK4X8RAsXTAJ4xJVduSUkRtgLnewnRbeGuKRK3XwCff6pK WZt9uYW5/nOiM3TVijqvEzg= =mU+1 -----END PGP SIGNATURE----- --Ah9ph+G2cWRpKogL-- From owner-aaa-bof@merit.edu Fri May 4 21:05:17 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23148 for ; Fri, 4 May 2001 21:05:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 56B145DE64; Fri, 4 May 2001 08:49:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 430F25DE63; Fri, 4 May 2001 08:49:40 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 8D8495DE53 for ; Fri, 4 May 2001 08:49:38 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id IAA04827; Fri, 4 May 2001 08:48:55 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma004825; Fri, 4 May 01 08:48:35 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id IAA20471; Fri, 4 May 2001 08:48:35 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma020277; Fri, 4 May 01 08:47:30 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <2XDRF6X2>; Fri, 4 May 2001 08:47:11 -0400 Message-ID: From: Balazs Czoma To: aaa-wg@merit.edu, diameter@diameter.org Cc: "'Fredrik Johansson'" Subject: RE: [AAA-WG]: Extension version Date: Fri, 4 May 2001 08:47:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Extension ID identifies only the extension but not the version of an extension. For example Mobile IP extension version 2 in the future will probably support commands/AVPs that are not supported by version 1. Both of them may support the Base Protocol version 1. Regards: Balazs > -----Original Message----- > From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com] > Sent: Friday, May 04, 2001 08:41 > To: Balazs Czoma; aaa-wg@merit.edu; diameter@diameter.org > Subject: RE: [AAA-WG]: Extension version > > > Hi Balazs > > There is an AVP called ExtensionId AVP which is sent in the > Device-Roboot-Indication message for this > > /Fredrik > > >-----Original Message----- > >From: owner-aaa-bof@merit.edu > [mailto:owner-aaa-bof@merit.edu]On Behalf > >Of Balazs Czoma > >Sent: den 4 maj 2001 14:30 > >To: aaa-wg@merit.edu; diameter@diameter.org > >Subject: [AAA-WG]: Extension version > > > > > >Hello, > > > >It shall be possible to identify/negotiate which extension version > >a certain > >application is supporting. > > > >I cannot find any hints regarding this in the Base Protocol. > I think it > >would be necessary to define an AVP and procedures for this purpose. > > > >Regards: > >Balazs > >____________________________________________ > >Balazs Czoma > >Siemens Telecom Innovation Centre > >mailto:Balazs.Czoma@tic.siemens.ca > >____________________________________________ > > > > > From owner-aaa-bof@merit.edu Sat May 5 00:21:22 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA26928 for ; Sat, 5 May 2001 00:21:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E3FA65DEF1; Fri, 4 May 2001 13:52:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C5C495DEF2; Fri, 4 May 2001 13:52:08 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 145515DEF1 for ; Fri, 4 May 2001 13:52:02 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id NAA08570; Fri, 4 May 2001 13:52:01 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma008568; Fri, 4 May 01 13:51:31 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id NAA29304; Fri, 4 May 2001 13:51:31 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma029226; Fri, 4 May 01 13:50:11 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <2XDRF7DG>; Fri, 4 May 2001 13:49:53 -0400 Message-ID: From: Yiwen Jiang To: "'Pat Calhoun'" Cc: "'James Kempf'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question on MRI Date: Fri, 4 May 2001 13:49:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi again, Sorry about this email... I was using -02 as a reference... I saw the answer in -03. Sorry again. > -----Original Message----- > From: Yiwen Jiang [mailto:Yiwen.Jiang@innovation.siemens.ca] > Sent: Friday, May 04, 2001 1:21 PM > To: 'Pat Calhoun' > Cc: 'James Kempf'; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Question on MRI > > > Hi Pat, > > > > What about another error condition where none of the > > extensions that the > > > peer advertised via DRI message is supported by the > > receiving server? > > > > That error condition is handled by the DSI, since it is > > handle on a per > > hop basis, and a proxy could try another server. > I went read through the events listed under DSI, but couldn't > find an event > that maps to the scenario above. :( > > I'm not sure why this would be related to proxy though... You > see, if peer A > tries to connect to a peer B that is completely incompatible > (extension > wise) with A, where the Destination-FQDN AVP for the DRI > message is peer B. > There will be no proxy involved, since proxying implies > different realm, > right? Or did I mis-understood? > > To me, this scenario is a valid one, and it is not being > handled... Sorry > for asking the same question many times, I'm just a bit confused.. :( > From owner-aaa-bof@merit.edu Sat May 5 01:48:13 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02267 for ; Sat, 5 May 2001 01:48:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8F9B15DDFC; Fri, 4 May 2001 18:43:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7F2CC5DDFB; Fri, 4 May 2001 18:43:06 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 28CDF5DDE4 for ; Fri, 4 May 2001 18:43:04 -0400 (EDT) Received: (qmail 7280 invoked by uid 500); 4 May 2001 22:32:48 -0000 Date: Fri, 4 May 2001 15:32:48 -0700 From: Pat Calhoun To: Yiwen Jiang Cc: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: A proposal for the elimination of MRI and comments on -03. Message-ID: <20010504153248.B26582@charizard.diameter.org> Mail-Followup-To: Yiwen Jiang , 'Pat Calhoun' , aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Yiwen.Jiang@tic.siemens.ca on Fri, May 04, 2001 at 06:26:51PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, May 04, 2001 at 06:26:51PM -0400, Yiwen Jiang wrote: > > Just because a server supports all extensions, they aren't necessarily > > enabled (turned on). So, it is possible for no servers in the > > home domain > > to advertise a given extension. > Hmm... When would this scenario happen? It won't be in peer to peer case, > because to establish that connection, both peer must support the same > extension. Would this be to deal with unsolicited messages? or is this > specific to Mobile-IP extension for roaming? Correct, but consider the following scenario: +-----+ +-------+ +-------------+ | NAS |----->| Proxy |----->| Home Server | +-----+ +-------+ +-------------+ ------> ------> DRI, ext=1 DRI, ext=2 <------- <------ DRI, ext=1,2 DRI, ext=1,2 ---------> Cmd, ext=1 ------> Looks, but no ext=1 supported <-------- Error This could occur for one of two reasons. Either the home network is misconfigured, and clients from that domain are asking for services that are not available from its home net, or the home server that provides ext=1 services is not available (crashed?) > > > > Some proxies do more than just forward. Some maintain state > > information, > > some do policy checks, etc. So it is feasible for a proxy to > > care what's > > inside a message. > But if a proxy doesn't recognize an AVP, why can it not just ignore it and > care about the ones it does understand, but still forward the request to the > next hop? Because it may want to make some intermediate authorization decisions. Let's say that a broker is established, and provides roaming services for two networks, a and b. The broker's arrangment is that at any given time it will permit n users of service foo, and x users of service bar to be roaming. Now if the broker receives a request, and it contains some AVP marked as mandatory that it doesn't recognize, should it simply assume that the request falls within the negotiated business contract and allow service? I would expect not, so it would respond stating that something is weird in the packet, and it isn't willing to provide roaming services. > > > Let me try again. A NAS issues a request, and the home server > > sends back > > a response. The NAS receives the response, but doesn't like > > its contents. > > It has to signal to the home server that the session was > > never started, so > > it issues an STR, with a Termination-Cause of "Didn't like > > your AVP set", > > or some such error. > Okay, that made sense. Thanks! > > But relate back to the discussion earlier how NAS would examine the packet > received, and parse through the various error Result-Code put in by the > intermediate proxies that didn't understand some of the AVPs, right? My idea > is, that if those unknown AVP related result code weren't there, the only > Result-Code is there, should be the result from the end server, and this > makes the logic in NAS much simpler.. Or does NAS really have to know that > the intermediate proxies do not support some AVPs it uses? See the above scenario. It does care if something was bad with the packet, regardless of who complains. > > Currently, the protocol defines command codes. Some are > > Requests and others > > are Answers. A proxy must know the right command code to set should it > > receive a request it has a problem with. Your suggestion > > above states that > > if a new extension, foobar, comes out and gets deployed, and > > an error is > > found in a packet, a proxy that doesn't support an extension > > wouldn't know > > how to respond. > > > > What if we all request/answer commands only require a single > > command code, > > and the EIR bits in the header was used to determine if the > > command was > > a request, or an answer? This way, new extensions could be > > deployed, and > > if a proxy didn't support the particular extension, and found > > an error in > > a request, it could still return the correct response. > > > > Does this make sense? > So you are saying, that if a proxy found an obvious error in the request > that it doesn't support, it should just change the appropriate EIR bits, > and reply it back to the server that sent the request using the same command > code? that is the proposal. Quite radical this late in the game, I understand, but it would fix the problem. > > Hmm... I think that would work... But what about errors with -Ind messages? > Or does the proxy check for the validity of AVPs only with Request/Answer > messages? A bad -Ind message is another problem, and I suspect that perhaps the MRI could be salvaged for this purpose, or just create another bit to indicate a bad response to an -Ind. This would ONLY be sent when an -Ind was rejected, so a successful -Ind has no response. > > Or another way, is to allow the proxy to skip AVPs that it does not > understand, and just do the validity check with AVPs that it understands, if > error, return correct response, else pass onto the next hop. Or is this > really not desired behaviour? In the ideal world yes, but from the discussions that I've gathered on the list over the past years, this is a desired feature. If people agree this is not necessary, then we can simplify the protocol :) > thanks again for your prompt responses and patient help... It's been great. > :) All for the good of the Internet Community.... PatC From owner-aaa-bof@merit.edu Sat May 5 07:30:26 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13221 for ; Sat, 5 May 2001 07:30:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A54C75DE63; Fri, 4 May 2001 08:50:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9281C5DE14; Fri, 4 May 2001 08:50:20 -0400 (EDT) Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id C170D5DE2B for ; Fri, 4 May 2001 08:50:18 -0400 (EDT) Received: from fredrikj (c35.local.ipunplugged.com [192.168.4.234]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id OAA03546; Fri, 4 May 2001 14:51:12 +0200 From: "Fredrik Johansson" To: "Balazs Czoma" , , Subject: RE: [AAA-WG]: Extension version Date: Fri, 4 May 2001 14:52:02 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ok, I see what you mean, did not read the question thoroughly /Fredrik >-----Original Message----- >From: Balazs Czoma [mailto:Balazs.Czoma@tic.siemens.ca] >Sent: den 4 maj 2001 14:47 >To: aaa-wg@merit.edu; diameter@diameter.org >Cc: 'Fredrik Johansson' >Subject: RE: [AAA-WG]: Extension version > > >Extension ID identifies only the extension but not the version of an >extension. > >For example Mobile IP extension version 2 in the future will probably >support commands/AVPs that are not supported by version 1. Both of them may >support the Base Protocol version 1. > >Regards: >Balazs > >> -----Original Message----- >> From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com] >> Sent: Friday, May 04, 2001 08:41 >> To: Balazs Czoma; aaa-wg@merit.edu; diameter@diameter.org >> Subject: RE: [AAA-WG]: Extension version >> >> >> Hi Balazs >> >> There is an AVP called ExtensionId AVP which is sent in the >> Device-Roboot-Indication message for this >> >> /Fredrik >> >> >-----Original Message----- >> >From: owner-aaa-bof@merit.edu >> [mailto:owner-aaa-bof@merit.edu]On Behalf >> >Of Balazs Czoma >> >Sent: den 4 maj 2001 14:30 >> >To: aaa-wg@merit.edu; diameter@diameter.org >> >Subject: [AAA-WG]: Extension version >> > >> > >> >Hello, >> > >> >It shall be possible to identify/negotiate which extension version >> >a certain >> >application is supporting. >> > >> >I cannot find any hints regarding this in the Base Protocol. >> I think it >> >would be necessary to define an AVP and procedures for this purpose. >> > >> >Regards: >> >Balazs >> >____________________________________________ >> >Balazs Czoma >> >Siemens Telecom Innovation Centre >> >mailto:Balazs.Czoma@tic.siemens.ca >> >____________________________________________ >> > >> > >> From owner-aaa-bof@merit.edu Sat May 5 14:18:52 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17275 for ; Sat, 5 May 2001 14:18:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7FC745DDFA; Fri, 4 May 2001 16:46:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6038D5DE1A; Fri, 4 May 2001 16:46:18 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 280285DDFA for ; Fri, 4 May 2001 16:46:16 -0400 (EDT) Received: (qmail 6108 invoked by uid 500); 4 May 2001 20:36:00 -0000 Date: Fri, 4 May 2001 13:36:00 -0700 From: Pat Calhoun To: Yiwen Jiang Cc: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: A proposal for the elimination of MRI and comments on -03. Message-ID: <20010504133600.Y26582@charizard.diameter.org> Mail-Followup-To: Yiwen Jiang , 'Pat Calhoun' , aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="rQAi4ZBraoACHIeu" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Yiwen.Jiang@tic.siemens.ca on Fri, May 04, 2001 at 02:36:06PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk --rQAi4ZBraoACHIeu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 04, 2001 at 02:36:06PM -0400, Yiwen Jiang wrote: > Hi Pat, >=20 > > 2. Unknown command code. > >=20 > > This error occurs when a proxy receives the message, but has no > > servers that supports the extension in the home domain. The > > initial reason why the MRI was used, instead of the natural=20 > > request's answer, was that the proxy may not recognize the > > request, and wouldn't know what to set the command code to. > >=20 > > However, in -03, it is now mandatory that servers support > > all extensions, so it is now possible for the proxy to > > simply return the natural answer with an error condition stating > > that the message couldn't be delivered.=20 > If the servers all support all extensions, why would proxy return an error > and couldn't deliver the message? Just because a server supports all extensions, they aren't necessarily enabled (turned on). So, it is possible for no servers in the home domain to advertise a given extension. > =20 > > 3. AVP marked mandatory is unsupported. > >=20 > > This error can occur in two directions; towards the home domain > > (request) and towards the NAS (response) [note, of course for > > server initiated messages, this would be inversed, but I am just > > using this terminology for clarity]. > >=20 > > If a proxy had received a request, and it contained an=20 > > unrecognized > > AVP with the 'M' bit set, it would have to return an=20 > > error. Again, > > since servers must support all extensions, the proxy can now > > return the natural answer with the Result-Code AVP set to the > > correct value. > >=20 > > If a proxy had received an answer, and it contained the same > > error, the proxy would have to overwrite the Result-Code AVP > > with the local error. This means that the Result-Code AVP MAY > > appear more than once in a message. I would also prefer to > > see the Result-Code combined with the Error-Reporting-FQDN AVP. > > Perhaps this is needed as a Grouped AVP? > I agree that a group AVP is a better way to do this. ok. I'd like to hear from others. >=20 > > So now a NAS would have to look at more than one=20 > > possible Result- > > Code AVP, and if one contained an error, it would have to > > reject the answer. > Maybe this already has been discussed before, but why MUST a proxy care > whether it supports some AVPs for messages that is not destined to itself= ? I > mean shouldn't a proxy first checks to see if a message's Destination-FQDN > is itself, and if no, just simply forwards the message, and not care for = its > contents? The AVP supportability check would be only relavent and conduct= ed > by the end servers, no? Some proxies do more than just forward. Some maintain state information, some do policy checks, etc. So it is feasible for a proxy to care what's inside a message. >=20 > > Now a new problem presents itself. How does the home server know > > that the answer was rejected? We can do one of two things: > >=20 > > 1. Introduce a new -Ind message that is used to inform the > > home server that an answer was bad, and therefore ignored. > > This is hard, and has the same issues as the MRI one that > > were discussed on the list. > >=20 > > 2. Have the NAS issue an STR, with a Termination-Cause. This > > seems to be the best approach. > But if this is the case, how is a peer to peer connection separated from a > user session connection?=20 correct. > From what I understood so far on the base protocol, > peer connections and session connections are two separate entities. when a > server is proxying a request, it would/should use the peer to peer > connection, right? How would the receipt of STR from NAS tells the server > that one of the messages it sent via the peer connection is rejected? Let me try again. A NAS issues a request, and the home server sends back a response. The NAS receives the response, but doesn't like its contents. It has to signal to the home server that the session was never started, so it issues an STR, with a Termination-Cause of "Didn't like your AVP set", or some such error. >=20 > On another note, maybe I am completely reading this wrong, but it is my > feeling that as the base protocol evolves, the peer connections and sessi= on > connections are evolving to be more related to each other, rather than in > the initial drafts, where they are two completely separate entities? not at all... they aren't even closely related. >=20 > > 4. An AVP is received with an unknown or illegal value > >=20 > > I would argue that this error is VERY similar to case #3, and > > should be handled the same way. > Could this be another item handled by the DSI? Only if an intermediate proxy determines this. In any case, this error has to be signaled back to the NAS, so a per-hop behavior is the wrong approach. A response with the Result-Code set to "no way joe" is the right thing to d= o. > =20 > > So as you can see, now that the Diameter protocol has=20 > > evolved, the need for > > the MRI isn't there anymore. So I would propose that we make=20 > > the necessary > > changes described above, and eliminate the command code. > As the base draft evolve, it is my personal impression that it gets bulki= er, > especially in the case of how extensions are associated with the Diameter > server, i.e. what does a diameter server support? Initially, it was just = the > base, with one or more extensions, regardless of the type of the extensio= n. > Then, accounting is added as part of the server.=20 correct. >=20 > Now, in -03, Page 11, "Diameter servers MUST support the Base protocol, > which includes Accounting, and both the NASREQ and Mobile IP extensions." > This sentence is quite similar to a statement in -01, when it talked about > Diameter servers MUST support the Base protocol, and the accounting > extensions. Does this sentence mean that any server that do not support a= ny > of the three extensions cannot be identified as a "Diameter server"? If t= his > is the case, the Diameter server is no longer a "pluggable" server with > extensions. Right? This sentence was added based on comments generated by the IESG. Take it up with the ADs and the chair if you do not like this requirement. > In addition, should there be a new extension Foo proposed and accepted, a= nd > a Diameter server that supports Foo is built and deployed to the network, > all existing Diameter proxies will not recognize the Foo specific commands > when they receive it, and will reject them. So how does new extensions > server actually integrate/communicate with the existing Diameter servers = on > the network? Correct, they wouldn't be able to provide the correct response. There is, however, a fix to this problem. I have spent a whole 21 seconds thinking about this, so please exercise patience if I explain it wrong, or even if it doesn't make a whole lot of sense. Currently, the protocol defines command codes. Some are Requests and others are Answers. A proxy must know the right command code to set should it receive a request it has a problem with. Your suggestion above states that if a new extension, foobar, comes out and gets deployed, and an error is found in a packet, a proxy that doesn't support an extension wouldn't know how to respond. What if we all request/answer commands only require a single command code, and the EIR bits in the header was used to determine if the command was a request, or an answer? This way, new extensions could be deployed, and if a proxy didn't support the particular extension, and found an error in a request, it could still return the correct response. Does this make sense? (btw, thanks for the great scenarios you are discussing) PatC --rQAi4ZBraoACHIeu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE68xKvvcrGpbaK4X8RArrWAJ9ys0Nh1cGocERmdVf4+9s3E1bvJACeMtn2 MdXmYZaZtPaixlTTpgv2MIo= =Mc/M -----END PGP SIGNATURE----- --rQAi4ZBraoACHIeu-- From owner-aaa-bof@merit.edu Mon May 7 01:04:10 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19540 for ; Mon, 7 May 2001 01:04:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 89C1B5DDD8; Mon, 7 May 2001 01:00:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 73A145DDD6; Mon, 7 May 2001 01:00:48 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 61F445DDB3 for ; Mon, 7 May 2001 01:00:46 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id AAA19544; Mon, 7 May 2001 00:53:01 -0400 (EDT) Message-Id: <4.1.20010507003531.01787b60@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 07 May 2001 00:40:36 -0400 To: aaa-wg@merit.edu, Patrice Calhoun From: Paul Funk Subject: [AAA-WG]: Boot-ID in DRI Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk RADIUS servers generally use accounting as a means of tracking user sessions. In addition to Start and Stop accounting requests, a NAS can use On and Off requests to indicate it has just come up or is about to go down. A RADIUS server receiving an On or Off may then infer that resources for all user sessions controlled by that NAS can be released. In Diameter, when a connection starts up and DRIs are exchanged, there is no way for the server to know whether this represents a restart of the client or resumption of a broken connection. If it guesses wrong, it will either retain resources incorrectly, causing, for example, IP address leakage, or it will release them incorrectly, causing, for example, assignment of the same address to multiple users. The only means for the Diameter server to determine the true state of affairs would be to query the client for all current sessions. Such a mechanism, if I remember correctly, was defined as a "session management" extension once, but is not currently a AAA draft. But that is a heavyweight mechanism that may not be practical to employ, if it even gets implemented. Admittedly, the problem is less severe under Diameter than under RADIUS, since sessions have lifetimes and they eventually expire anyway. But it would still be a great improvement to be able to release resources quickly. If a client maintains thousands of sessions, a reboot of that client could put a significant dent in a Diameter server's resource pool, particularly as the affected users start to log in again. I would suggest that we define a Boot-ID AVP for use in DRI. Each Diameter peer would determine a new Boot-ID at startup. When a DRI is received with a new Boot-ID value, this means the peer has restarted since the last connection. If the Boot-ID is the same, this means that this just a resumed connection. Upon connecting with a client, a server could release all sessions created under a different Boot-ID, if the server knows that the client does not retain user sessions across reboot. I suggest we make use of Boot-ID a MAY for Diameter peers in general and a SHOULD for clients that provide session service. I suggest the following AVP definition: Boot-ID AVP The Boot-ID AVP (AVP Code ?) is of type Unsigned32 and is used to allow a Diameter peer to determine whether the issuing device has restarted since the last connection. A Diameter entity issuing this AVP must create a new value for this AVP each time it restarts. This value MUST, at least to a high degree of probability, be different from values it has used after previous restarts. This may be accomplished by using the restart time, by generating a random value at each restart, or by using an incrementing counter retained in non-volatile memory across restarts. A Diameter entity issuing this AVP MUST use a single Boot-ID value in all DRI messages between restarts with all peers it connects with. Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Mon May 7 07:01:38 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05989 for ; Mon, 7 May 2001 07:01:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E577E5DD8D; Mon, 7 May 2001 00:56:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D4A145DDB3; Mon, 7 May 2001 00:56:26 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 398EF5DD8D for ; Mon, 7 May 2001 00:56:25 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id AAA19531; Mon, 7 May 2001 00:47:52 -0400 (EDT) Message-Id: <4.1.20010507003322.0178b400@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 07 May 2001 00:35:27 -0400 To: Pat Calhoun From: Paul Funk Subject: Re: [AAA-WG]: Session Termination Issues Cc: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, At 02:21 PM 5/3/01 -0700, you wrote: >As far as eliminating the STI, in favor for allowing the STR to be initiated >by either the server or the client, I haven't received comments from the WG >in favor of this approach. I'm not proposing that either a client or a server can issue an STR. Only the entity that is providing the service -- the client -- knows when the session has terminated, and therefore only the client can issue the STR. The STR, in my view, is a notification by the client to the home server and all proxies in between that the session is over. This allows those servers to release whatever resources or session information they are holding. What I am proposing is this: If a server -- any server -- wants to abort a user's session, it issues a special request to the client, say, Session-Kill-Request, and the client responds with a Session-Kill-Answer. I prefer using two-way messaging such as SKR/SKA rather than STI. Let's call the server that issued the SKR the "terminator" server. When the client receives the SKR, it aborts the session and responds to the terminator server with an SKA. Or, it refuses to abort the session and responds with SKA indicating its refusal. Also, the client will issue an STR to the server that originally authenticated/authorized that session -- it would do this even if the session terminated normally via user logoff. So the SKR/SKA and the STR/STA are independent transactions. If the terminator server is the same server as the authenticating server or any of the proxies in between, it will see the STR; if not, it won't. But it's OK either way. Each server will receive the information that is appropriate to its role, whether authenticator, terminator, or both. Basically, what it comes down is that using Request/Answer to kill a session is superior to Indication because there is explicit acknowledgement. The terminator server doesn't have to be in the proxy chain to the authenticating server to get the acknowledgement. Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Mon May 7 10:54:45 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13633 for ; Mon, 7 May 2001 10:54:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E86625DEF5; Mon, 7 May 2001 10:52:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D43625DEB0; Mon, 7 May 2001 10:52:18 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 8E94D5DEF3 for ; Mon, 7 May 2001 10:52:14 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id KAA17908; Mon, 7 May 2001 10:52:11 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma017896; Mon, 7 May 01 10:51:45 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id KAA10800; Mon, 7 May 2001 10:51:43 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma010465; Mon, 7 May 01 10:50:35 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 7 May 2001 10:50:34 -0400 Message-ID: From: Yiwen Jiang To: "'Pat Calhoun'" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: A proposal for the elimination of MRI and comments on -03. Date: Mon, 7 May 2001 10:50:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > > > Just because a server supports all extensions, they > aren't necessarily > > > enabled (turned on). So, it is possible for no servers in the > > > home domain > > > to advertise a given extension. > > Hmm... When would this scenario happen? It won't be in peer > to peer case, > > because to establish that connection, both peer must > support the same > > extension. Would this be to deal with unsolicited messages? > or is this > > specific to Mobile-IP extension for roaming? > > Correct, but consider the following scenario: > > > +-----+ +-------+ +-------------+ > | NAS |----->| Proxy |----->| Home Server | > +-----+ +-------+ +-------------+ > > ------> ------> > DRI, ext=1 DRI, ext=2 > > <------- <------ > DRI, ext=1,2 DRI, ext=1,2 > > ---------> > Cmd, ext=1 > ------> Looks, but no ext=1 supported > <-------- > Error > > This could occur for one of two reasons. Either the home network > is misconfigured, and clients from that domain are asking for services > that are not available from its home net, or the home server that > provides ext=1 services is not available (crashed?) Ahh.... yes. That makes sense.. > > But if a proxy doesn't recognize an AVP, why can it not > just ignore it and > > care about the ones it does understand, but still forward > the request to the > > next hop? > > Because it may want to make some intermediate authorization > decisions. Let's > say that a broker is established, and provides roaming > services for two > networks, a and b. The broker's arrangment is that at any > given time it > will permit n users of service foo, and x users of service > bar to be roaming. > > Now if the broker receives a request, and it contains some > AVP marked as > mandatory that it doesn't recognize, should it simply assume that the > request falls within the negotiated business contract and > allow service? > I would expect not, so it would respond stating that > something is weird > in the packet, and it isn't willing to provide roaming services. Hmm... But wouldn't that restrict all Diameter servers to be upgraded at the same time when a new extension is deployed? Otherwise, no new extension messages can be exchanged at all since proxy will reject all of them...? Can the following be a possible solution? I would assume that a proxy will have a record of realms it can forwards requests to. Can it also maintain a list of extensions that the realm supports? This way, when a home network deploys a new extension support, the deployer will ensure that within that all the affiliated proxies are informed of such change. The deployer will also ensure that within its own network, the new extension is supported. So the intermediate proxies can use realm as another policy when performing policy checking: If there are mandatory AVPs that the destination realm does not support, proxy returns error. If the destination realm supports extension, it should have been registered with the proxy, even if the proxy does not support that extension, the proxy will forward the message. This way, if the proxy supports the extension, it can perform policy checking. Otherwise, it leaves the policy checking to the end server. > > So you are saying, that if a proxy found an obvious error > in the request > > that it doesn't support, it should just change the > appropriate EIR bits, > > and reply it back to the server that sent the request using > the same command > > code? > > that is the proposal. Quite radical this late in the game, I > understand, > but it would fix the problem. Yeah, but this means no new extension messages can be sent until all proxies supports that extension. That is really not very ideal, is it? > A bad -Ind message is another problem, and I suspect that > perhaps the MRI > could be salvaged for this purpose, or just create another > bit to indicate > a bad response to an -Ind. This would ONLY be sent when an > -Ind was rejected, > so a successful -Ind has no response. Okay. So this implies that an -Ind is a -Req but with an optional -Answer message associated with it? > > > > Or another way, is to allow the proxy to skip AVPs that it does not > > understand, and just do the validity check with AVPs that > it understands, if > > error, return correct response, else pass onto the next > hop. Or is this > > really not desired behaviour? > > In the ideal world yes, but from the discussions that I've > gathered on the > list over the past years, this is a desired feature. If > people agree this > is not necessary, then we can simplify the protocol :) I'm really not sure how much benefit this feature provides, because this makes the integration with future extensions much more difficult. Another question I have is, now that all Diameter server must support all extensions, is the mandate of having pluggable extensions a valid one? Thanks. From owner-aaa-bof@merit.edu Mon May 7 11:15:28 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14042 for ; Mon, 7 May 2001 11:15:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EF0E65DD90; Mon, 7 May 2001 10:19:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D8ED85DE08; Mon, 7 May 2001 10:19:01 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 360D95DD90 for ; Mon, 7 May 2001 10:18:59 -0400 (EDT) Received: (qmail 8256 invoked by uid 500); 7 May 2001 14:08:35 -0000 Date: Mon, 7 May 2001 07:08:35 -0700 From: Pat Calhoun To: Paul Funk Cc: aaa-wg@merit.edu, Patrice Calhoun Subject: Re: [AAA-WG]: Boot-ID in DRI Message-ID: <20010507070835.H26582@charizard.diameter.org> Mail-Followup-To: Paul Funk , aaa-wg@merit.edu, Patrice Calhoun References: <4.1.20010507003531.01787b60@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010507003531.01787b60@cairo.funk.com>; from paul@funk.com on Mon, May 07, 2001 at 12:40:36AM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA14042 On Mon, May 07, 2001 at 12:40:36AM -0400, Paul Funk wrote: > RADIUS servers generally use accounting as a means of > tracking user sessions. In addition to Start and Stop > accounting requests, a NAS can use On and Off requests > to indicate it has just come up or is about to go down. > A RADIUS server receiving an On or Off may then infer > that resources for all user sessions controlled by that > NAS can be released. > > In Diameter, when a connection starts up and DRIs are > exchanged, there is no way for the server to know > whether this represents a restart of the client or > resumption of a broken connection. If it guesses wrong, > it will either retain resources incorrectly, causing, > for example, IP address leakage, or it will release > them incorrectly, causing, for example, assignment of > the same address to multiple users. correct. > > The only means for the Diameter server to determine > the true state of affairs would be to query the client > for all current sessions. Such a mechanism, if I > remember correctly, was defined as a "session > management" extension once, but is not currently a > AAA draft. This is currently a personal draft, and I am not convinced that it really scales all that well. However, it is out there because people have asked for it. > > But that is a heavyweight mechanism that may not be > practical to employ, if it even gets implemented. > > Admittedly, the problem is less severe under Diameter > than under RADIUS, since sessions have lifetimes and > they eventually expire anyway. But it would still be > a great improvement to be able to release resources > quickly. If a client maintains thousands of sessions, > a reboot of that client could put a significant dent > in a Diameter server's resource pool, particularly as > the affected users start to log in again. ok. > > I would suggest that we define a Boot-ID AVP for use > in DRI. Each Diameter peer would determine a new > Boot-ID at startup. When a DRI is received with a new > Boot-ID value, this means the peer has restarted since > the last connection. If the Boot-ID is the same, this > means that this just a resumed connection. Upon > connecting with a client, a server could release all > sessions created under a different Boot-ID, if the > server knows that the client does not retain user > sessions across reboot. I am not sure that this actually solves the problem. In a real scenario, the NAS will communicate directly with a proxy server, which in turn will communicate with another server. For the purposes of this discussion, let's assume that the proxy communicates with a home server that is maintaining session state. If the NAS was to reboot, it would send the Boot-Id to its proxy server, but this information would never make it down to the server in the home network, right? This is really where the problem is. The home server would never know that the NAS has rebooted, *unless* a new Shoe-Id would cause the proxy to send some message to the home server informing it that the NAS had rebooted. A rather ugly scenario :( However, I believe that there is a different way around this, and we can make use of most of your proposal. If the NAS was to include the Shoe-Id in most of the authentication messages, the home server could evaluate its value with previous ones, and determine whether the NAS had rebooted or not. Of course, the home server would only be informed the next time the same NAS issues a message to that home server, so this isn't really timely. Unless, of course, the NAS supports the E2E security extension, and attempts to establish security associations with known home servers upon bootup (but I don't think this is a very likely scenario). A truly redundant NAS, which could retain all sessions across reboots, wouldn't include a new value in this AVP. > > I suggest we make use of Boot-ID a MAY for Diameter > peers in general and a SHOULD for clients that provide > session service. I suggest the following AVP definition: Heck, I'd prefer to make it a MUST. It is fairly trivial to implement, and does provide significant assistance to the home servers that maintain state. Comments? PatC From owner-aaa-bof@merit.edu Mon May 7 11:51:06 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14795 for ; Mon, 7 May 2001 11:51:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E6FE55DE6C; Mon, 7 May 2001 11:48:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D4F995DE6B; Mon, 7 May 2001 11:48:53 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id F27EB5DE6A for ; Mon, 7 May 2001 11:48:51 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id LAA18674; Mon, 7 May 2001 11:48:51 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma018672; Mon, 7 May 01 11:48:24 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id LAA18266; Mon, 7 May 2001 11:48:24 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma018168; Mon, 7 May 01 11:47:07 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 7 May 2001 11:47:06 -0400 Message-ID: From: Yiwen Jiang To: "'Pat Calhoun'" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: A proposal for the elimination of MRI and comments on -03. Date: Mon, 7 May 2001 11:46:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > Not at all. The proposal is to allow new extensions that > wouldn't be supported > by all proxies. Proxies in fact will most likely want to > route messages, and > not care about the contents of the message, but if an error > is found, it > should be able to reply back to the NAS, right? That's the goal here. Agreed. > Again, some people want to run their networks like this (and > are today), so > I don't think we can eliminate this feature since RADIUS supports it. Sorry, I didn't realize this... > Do recall, though, that this is not the "default" way the > protocol works. This > is a special configuration for special business relationships. Cool.. Thanks again for your help, Pat. From owner-aaa-bof@merit.edu Mon May 7 17:59:06 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23291 for ; Mon, 7 May 2001 17:59:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 410DB5DDC1; Mon, 7 May 2001 12:14:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2B6EE5DE01; Mon, 7 May 2001 12:14:54 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 6EACA5DDC1 for ; Mon, 7 May 2001 12:14:52 -0400 (EDT) Received: (qmail 9259 invoked by uid 500); 7 May 2001 16:04:28 -0000 Date: Mon, 7 May 2001 09:04:28 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Mobile IP Issues Conference Call Message-ID: <20010507090428.K26582@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="W1uEbMXJ1Mj4g6TI" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk --W1uEbMXJ1Mj4g6TI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable All, Below is the conference call information for Tuesday May 8th at 9AM Pacific. So far, only the following people have confirmed their attendance on the call, so I have limited the number of ports. If additional people wish to join, please send me a note asap. Attendees: Pat Hasseb=20 Fredrik Tony Call Information: Dial-In Number: (505) 242-2420 Code: 741696 Thanks, PatC --W1uEbMXJ1Mj4g6TI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE69seLvcrGpbaK4X8RAtGiAJ9QQ/yjYO7R5LaiUaE1kP0ywkiCCQCfao+0 1DPVQzLeTYDeJ+VdNoj5WCk= =VdMZ -----END PGP SIGNATURE----- --W1uEbMXJ1Mj4g6TI-- From owner-aaa-bof@merit.edu Mon May 7 18:08:09 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23367 for ; Mon, 7 May 2001 18:08:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4D6185E44E; Mon, 7 May 2001 17:38:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 429365E98E; Mon, 7 May 2001 17:36:27 -0400 (EDT) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 276935E96E for ; Mon, 7 May 2001 17:34:29 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id RAA16626; Mon, 7 May 2001 17:28:37 -0400 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id RAA10208; Mon, 7 May 2001 17:35:20 -0400 (EDT) From: "Mark Jones" To: "Pat Calhoun" , "Paul Funk" Cc: Subject: RE: [AAA-WG]: Boot-ID in DRI Date: Mon, 7 May 2001 17:37:33 -0400 MIME-Version: 1.0 Message-ID: <008501c0d73d$ecfd8b30$2096a8c0@mjones.bridgewatersys.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_007A_01C0D71C.64772580" Importance: Normal In-Reply-To: <20010507070835.H26582@charizard.diameter.org> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_007A_01C0D71C.64772580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Pat, > Heck, I'd prefer to make it a MUST. It is fairly trivial > to implement, and does provide significant assistance to the > home servers that maintain state. > > Comments? > I assume this MUST only applies to clients that provide session service. Some access wholesalers are contractually bound to send the RADIUS Acct-On/Acct-Off messages onto some of their proxy partners. Others may prefer to hide their network (and its potential flakiness) from their proxy partners. If the Boot-Id AVP was a MUST for Diameter peers in general then this would no longer be possible. It also seems a little extreme to include the Boot-Id AVP in most(?) messages given the low frequency of device reboot events. How about a new command that really is just a Device Reboot Indication and MAY be proxied depending on the proxy server policy? Following a successful capabilities exchange with the rebooted device, the proxy server MAY send this device reboot indication command to the home servers. As with other proxied commands. the Route-Record AVP would be required in the device reboot indication to prevent forwarding loops. A new AVP would also be required in the capabilities exchange command to indicate that the capabilities exchange was initiated due to a device reboot. Regards, Mark ------=_NextPart_000_007A_01C0D71C.64772580 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw ggH9oAMCAQICAwS4ODANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDUwMTE4MTgwOFoXDTAyMDUwMTE4MTgwOFowTzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdbWpvbmVzQGJyaWRnZXdhdGVyc3lzdGVt cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMemr5diJO/8+r2Hj3Opr9LbaVAXFgo2 Fhu0tfSSdvlMy52Y67GMoJbv0I282FWO9z4bsnuSIU7y3arEmyA78mwjTSdt2GK5QJHT6jKOqF6M 81Q5j2fU3dQwCPiCQZlOqUJEA3PySRjUQNOgnRUhoSuzGd7IMJ3Y6oeMtE8a02nTAgMBAAGjOjA4 MCgGA1UdEQQhMB+BHW1qb25lc0BicmlkZ2V3YXRlcnN5c3RlbXMuY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEANyubKv2ajV9VxVe4xUDaqZbQ2DEXgGKSFWwsdC06zUucuCmeHHqT vLcoUnI8/dCbSnSwRrELpemSoqTv/99uW+jS6cN5320w1ZEBsC2RSVrSJd8LqxKALmMexgbywYvF /hMe120ctocvwnfbeZmzBIKSF7BDs8YPGzSWgsa5gKUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2 17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP 6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9 edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O +PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R hGvk+NHOd6KBMYICmzCCApcCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDBLg4MAkGBSsOAwIaBQCgggFWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDUwNzIxMzczMVowIwYJKoZIhvcNAQkEMRYEFFtxd8LYL8RTof3CmNv8415NcHNt MEkGCSqGSIb3DQEJDzE8MDowCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMAIDBLg4MA0GCSqGSIb3DQEBAQUABIGARcIisHZ3/3oAU8vNpjoLFb08 r2lp+o2N7pDi0yAd16aRhkjjWjluNqm4gzfcRsDNIlEeqpfJYs8yfHXKTNBGoMb8uFA+rfbMR/Os 6RplbYI+oR21bWxF5zltz3B2HoTnGhCamQuK96hNnTnlj2J7xAn0GWHdk/t278KqmScf5OEAAAAA AAA= ------=_NextPart_000_007A_01C0D71C.64772580-- From owner-aaa-bof@merit.edu Mon May 7 18:35:40 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23574 for ; Mon, 7 May 2001 18:35:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 006105DE06; Mon, 7 May 2001 11:25:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E2E165DE01; Mon, 7 May 2001 11:25:39 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 7FF7A5DDFD for ; Mon, 7 May 2001 11:25:37 -0400 (EDT) Received: (qmail 8854 invoked by uid 500); 7 May 2001 15:15:13 -0000 Date: Mon, 7 May 2001 08:15:13 -0700 From: Pat Calhoun To: Yiwen Jiang Cc: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: A proposal for the elimination of MRI and comments on -03. Message-ID: <20010507081513.J26582@charizard.diameter.org> Mail-Followup-To: Yiwen Jiang , 'Pat Calhoun' , aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="K5z5w9fsx/Hrkgg3" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Yiwen.Jiang@tic.siemens.ca on Mon, May 07, 2001 at 10:50:24AM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk --K5z5w9fsx/Hrkgg3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 07, 2001 at 10:50:24AM -0400, Yiwen Jiang wrote: > > Now if the broker receives a request, and it contains some=20 > > AVP marked as > > mandatory that it doesn't recognize, should it simply assume that the > > request falls within the negotiated business contract and=20 > > allow service? > > I would expect not, so it would respond stating that=20 > > something is weird > > in the packet, and it isn't willing to provide roaming services. > Hmm... But wouldn't that restrict all Diameter servers to be upgraded at = the > same time when a new extension is deployed? Otherwise, no new extension > messages can be exchanged at all since proxy will reject all of them...? It would require that proxies that exhibit the above behavior be upgraded, yes. However, the number of proxies that behave this way is small, but cert= ain business relationships require this feature. >=20 > Can the following be a possible solution?=20 >=20 > I would assume that a proxy will have a record of realms it can forwards > requests to. Can it also maintain a list of extensions that the realm > supports? This way, when a home network deploys a new extension support, = the > deployer will ensure that within that all the affiliated proxies are > informed of such change. The deployer will also ensure that within its own > network, the new extension is supported. So the intermediate proxies can = use > realm as another policy when performing policy checking: If there are > mandatory AVPs that the destination realm does not support, proxy returns > error. If the destination realm supports extension, it should have been > registered with the proxy, even if the proxy does not support that > extension, the proxy will forward the message. This way, if the proxy > supports the extension, it can perform policy checking. Otherwise, it lea= ves > the policy checking to the end server. This is the way Diameter normally works. > > that is the proposal. Quite radical this late in the game, I=20 > > understand,=20 > > but it would fix the problem. > Yeah, but this means no new extension messages can be sent until all prox= ies > supports that extension. That is really not very ideal, is it? Not at all. The proposal is to allow new extensions that wouldn't be suppor= ted by all proxies. Proxies in fact will most likely want to route messages, and not care about the contents of the message, but if an error is found, it should be able to reply back to the NAS, right? That's the goal here. >=20 > > A bad -Ind message is another problem, and I suspect that=20 > > perhaps the MRI > > could be salvaged for this purpose, or just create another=20 > > bit to indicate > > a bad response to an -Ind. This would ONLY be sent when an=20 > > -Ind was rejected, > > so a successful -Ind has no response. > Okay. So this implies that an -Ind is a -Req but with an optional -Answer > message associated with it? The key difference here is that a -Req always has a response. An -Ind only has a response if an error occured. > > In the ideal world yes, but from the discussions that I've=20 > > gathered on the > > list over the past years, this is a desired feature. If=20 > > people agree this > > is not necessary, then we can simplify the protocol :) > I'm really not sure how much benefit this feature provides, because this > makes the integration with future extensions much more difficult. Another > question I have is, now that all Diameter server must support all > extensions, is the mandate of having pluggable extensions a valid one? Again, some people want to run their networks like this (and are today), so I don't think we can eliminate this feature since RADIUS supports it. Do recall, though, that this is not the "default" way the protocol works. T= his is a special configuration for special business relationships. PatC --K5z5w9fsx/Hrkgg3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE69rwAvcrGpbaK4X8RAvn6AJ0XQAzZK3m3USDciqF7atHoOiVNRwCfdhIx iYRxmtppVBHpMXlZlcXMqW4= =uqwY -----END PGP SIGNATURE----- --K5z5w9fsx/Hrkgg3-- From owner-aaa-bof@merit.edu Mon May 7 19:27:15 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24359 for ; Mon, 7 May 2001 19:27:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 332505DE15; Mon, 7 May 2001 19:03:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3E3F55DF69; Mon, 7 May 2001 18:37:19 -0400 (EDT) Received: from imr2.ericy.com (unknown [12.34.240.68]) by segue.merit.edu (Postfix) with ESMTP id D85E95E085 for ; Mon, 7 May 2001 18:00:14 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f47M0D805919; Mon, 7 May 2001 17:00:13 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f47M0DF16550; Mon, 7 May 2001 17:00:13 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA12905; Mon, 7 May 2001 17:00:12 -0500 (CDT) Received: from ericsson.com (busam64.berkeley.us.am.ericsson.se [138.85.159.214]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA27627; Mon, 7 May 2001 17:00:01 -0500 (CDT) Message-ID: <3AF71A66.4FA8E9B0@ericsson.com> Date: Mon, 07 May 2001 14:57:58 -0700 From: Tony Johansson X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: pcalhoun@diameter.org Cc: aaa-wg@merit.edu Subject: [AAA-WG]: comments on base -03 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat and all, Here are some editorial stuff that I have found in the new base protocol -03. * section 2.1 second paragraph: " A Diameter node MAY send packets from any source port, but MUST be prepared to receive packets on port TBD. When a request is received, the source and destination ports in the reply are reversed." I think text reflects what was needed in the case of UDP. With SCTP and TCP I think this statement is no longer valid. * section 6.2 third paragraph: "If a Diameter node receives a DRI message that results in an error, a Message-Reject-Ind message MUST be returned." Shouldn't this be a DSI that MUST be returned. I guess this will be changed anyway if we agree on discard the use of MRIs. * section 6.2: ::= < Diameter Header: 257 > { Origin-FQDN } { Origin-Realm } 1* { Host-IP-Address } { Vendor-Id } { Product-Name } * { Supported-Vendor-Id } * [ Auth-Extension-Id ] * [ Acct-Extension-Id ] [ Destination-FQDN ] [ Firmware-Revision ] * [ AVP ] I believe the Supported-Vendor-Id should be optional, i.e * [ Supported-Vendor-Id ] and the Auth-Extension-Id and the Acct-Extension-Id should be mandatory, i.e *{ Acct-Extension-Id } and * { Auth-Extension-Id }. * section 9.1.1.2 or section 12.3 Redirect I think we need some more text in either 9.1.1.2 or 12.3 that clarifies what the redirect server MUST include in the redirect response. I'm mean, should the redirect server include all AVPs from the request message. This means that the server that receives the redirect could use the received AVPs from the redirect message to create and resent the request on the redirected path. The other way would be that the redirect server doesn't send back all the received AVPs. The server that receives the redirect would in this case have to use his message queue to create and resent the request on the redirected path. I'm not really sure which one to favor. I guess you will have support for the last one anyway in the case of failover, so it maybe unnecessary to require that all AVPs MUST included in the redirect. Comments? * section 11.7 Max-Wait-Time AVP: I assume the maximum amount of time is in msec. Right? BR, /Tony From owner-aaa-bof@merit.edu Mon May 7 19:56:02 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24779 for ; Mon, 7 May 2001 19:56:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9DF2C5DE74; Mon, 7 May 2001 19:28:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CC13A5DE85; Mon, 7 May 2001 19:03:44 -0400 (EDT) Received: from funk.funk.com (funk.funk.com [198.186.160.66]) by segue.merit.edu (Postfix) with ESMTP id B92825E0C8 for ; Mon, 7 May 2001 18:38:11 -0400 (EDT) Received: from platform (platform.funk.com [198.186.160.76]) by funk.funk.com (8.11.2/8.11.2) with SMTP id f47LvOm13075; Mon, 7 May 2001 17:57:24 -0400 (EDT) From: "Ammo Goettsch" To: "Paul Funk (E-mail)" Cc: Subject: RE: [AAA-WG]: Boot-ID in DRI Date: Mon, 7 May 2001 18:39:52 -0400 Message-ID: <001401c0d746$a262a430$4ca0bac6@platform> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <008501c0d73d$ecfd8b30$2096a8c0@mjones.bridgewatersys.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Mark Jones [mailto:mjones@bridgewatersystems.com] > Sent: Monday, May 07, 2001 5:38 PM > To: Pat Calhoun; Paul Funk > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Boot-ID in DRI > > > Pat, > > > Heck, I'd prefer to make it a MUST. It is fairly trivial > > to implement, and does provide significant assistance to the > > home servers that maintain state. > > > > Comments? > > > > I assume this MUST only applies to clients that provide > session service. > Some access wholesalers are contractually bound to send the RADIUS > Acct-On/Acct-Off messages onto some of their proxy partners. > Others may > prefer to hide their network (and its potential flakiness) from their > proxy partners. If the Boot-Id AVP was a MUST for Diameter peers in > general then this would no longer be possible. It also seems a little > extreme to include the Boot-Id AVP in most(?) messages given the low > frequency of device reboot events. > > How about a new command that really is just a Device Reboot > Indication and > MAY be proxied depending on the proxy server policy? Following a > successful capabilities exchange with the rebooted device, the proxy > server MAY send this device reboot indication command to the > home servers. > As with other proxied commands. the Route-Record AVP would be > required in > the device reboot indication to prevent forwarding loops. A > new AVP would > also be required in the capabilities exchange command to > indicate that the > capabilities exchange was initiated due to a device reboot. 1) How would a proxy know where to proxy this reboot indication to? - home servers may have been found via brokers - home servers may have been reached via redirect - home servers may have been reached due to fail over conditions 2) How would the home server interpret this Proxied-DRI? - If the Proxied-DRI takes particularly slow proxy route to the final home server, it may arrive AFTER new sessions that were created AFTER the reboot become known to the home server. Therefore, the home server could not clear out ALL sessions from the rebooted device, because only certain ones are actually invalid. 3) Because of problems in 2), it appears that some sort of "tag" or "shoe id" is needed to identify which sessions are to be cleared out. In a scenario where different proxy routing causes re-ordering of requests, it cannot be assured that a proxied DRI is received in any timely manner. In fact, multiple reboots could occur before any new shoe id reaches the home server. For this reason, I have only been able to come up with using a NAS-local clock time as the shoe id. That is, some sort of request (an ueber-STR) would be sent from the proxy to each home server previously used for the rebooted NAS. The ueber-STR would cause "all sessions started before NAS time xx:yy" to be cleared out because there was a reboot/administrative-down at xx:yy. This would still require each proxy to track the host names of all responses sent to a NAS to build a list of all "home servers the NAS has talked to since the last reboot." Sorry for providing more problems than solutions. Ammo > Regards, > Mark Ammo Goettsch Unprincipled Architect, ISP Products Funk Software http://www.funk.com Cambridge, MA mailto:ammo@funk.com PGP: 8708A9E464A376A6DB6672314487C3FD9A085B03 From owner-aaa-bof@merit.edu Mon May 7 21:04:36 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25592 for ; Mon, 7 May 2001 21:04:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E4D175DE2E; Mon, 7 May 2001 20:55:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DF19C5DE9B; Mon, 7 May 2001 20:40:39 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 76ECE5E2A5 for ; Mon, 7 May 2001 20:24:27 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id UAA21512; Mon, 7 May 2001 20:16:09 -0400 (EDT) Message-Id: <4.1.20010507194348.017f2eb0@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 07 May 2001 20:03:44 -0400 To: Pat Calhoun From: Paul Funk Subject: Re: [AAA-WG]: Boot-ID in DRI Cc: aaa-wg@merit.edu, Patrice Calhoun In-Reply-To: <20010507070835.H26582@charizard.diameter.org> References: <4.1.20010507003531.01787b60@cairo.funk.com> <4.1.20010507003531.01787b60@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 07:08 AM 5/7/01 -0700, Pat Calhoun wrote: >On Mon, May 07, 2001 at 12:40:36AM -0400, Paul Funk wrote: >> I would suggest that we define a Boot-ID AVP for use >> in DRI. Each Diameter peer would determine a new >> Boot-ID at startup. When a DRI is received with a new >> Boot-ID value, this means the peer has restarted since >> the last connection. If the Boot-ID is the same, this >> means that this just a resumed connection. Upon >> connecting with a client, a server could release all >> sessions created under a different Boot-ID, if the >> server knows that the client does not retain user >> sessions across reboot. > >I am not sure that this actually solves the problem. In a >real scenario, the NAS will communicate directly with a >proxy server, which in turn will communicate with another server. >For the purposes of this discussion, let's assume that the >proxy communicates with a home server that is maintaining >session state. > >If the NAS was to reboot, it would send the Boot-Id to its >proxy server, but this information would never make it down >to the server in the home network, right? This is really >where the problem is. The home server would never know >that the NAS has rebooted, *unless* a new Shoe-Id would >cause the proxy to send some message to the home server informing >it that the NAS had rebooted. > >A rather ugly scenario :( Actually, it does solve the problem (as I define the problem, anyway). The problem is that without Boot-ID in DRI, nobody knows whether the NAS has rebooted, and nobody knows whether its sessions are still valid. With a Boot-ID, the local Diameter server knows when the NAS has rebooted and when to invalidate sessions. It may then use STR to inform home servers that the session is over. Come to think of it, it might be a good idea for the draft to warn that an STR need not come from the original NAS; it could be issued by a server on behalf of the NAS. Therefore, the home server receiving an STR should disregard Origin-FQDN and use only Session-ID (which is globally unique) to identify a session. > >However, I believe that there is a different way around this, >and we can make use of most of your proposal. If the NAS >was to include the Shoe-Id in most of the authentication >messages, the home server could evaluate its value with >previous ones, and determine whether the NAS had rebooted >or not. > >Of course, the home server would only be informed the next time >the same NAS issues a message to that home server, so this >isn't really timely. Unless, of course, the NAS supports the >E2E security extension, and attempts to establish security >associations with known home servers upon bootup (but I don't >think this is a very likely scenario). Your proposal is addressed to an additional problem, namely: Given that the first-hop proxy knows that a NAS has rebooted, how does it efficiently inform home servers? Your proposal minimizes (actually, eliminates) the traffic necessary to inform home servers. In my proposal, the first-hop server would have to issue an STR for each roaming session. But in general, roaming sessions can be expected to be fewer than local ones. So if a 1000 user NAS goes down, the 900 sessions handled locally could be automatically released by the first-hop server, but it would have to issue 100 STRs to other servers for the 100 roaming users. I'm not advocating one proposal over another, just drawing distinctions. Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Mon May 7 22:17:01 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27499 for ; Mon, 7 May 2001 22:17:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 45BD25E15F; Mon, 7 May 2001 22:15:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0B0DC5DE0D; Mon, 7 May 2001 22:08:04 -0400 (EDT) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 61D035DE6D for ; Mon, 7 May 2001 21:54:56 -0400 (EDT) Received: (from barney@localhost) by mx.databus.com (8.11.3/8.11.3) id f481sg069205; Mon, 7 May 2001 21:54:42 -0400 (EDT) (envelope-from barney) Date: Mon, 7 May 2001 21:54:42 -0400 From: Barney Wolff To: Paul Funk , Pat Calhoun , aaa-wg@merit.edu, Patrice Calhoun Subject: Re: [AAA-WG]: Boot-ID in DRI Message-ID: <20010507215442.A69110@mx.databus.com> References: <4.1.20010507003531.01787b60@cairo.funk.com> <4.1.20010507003531.01787b60@cairo.funk.com> <20010507070835.H26582@charizard.diameter.org> <4.1.20010507194348.017f2eb0@cairo.funk.com> <20010507172429.B12425@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010507172429.B12425@charizard.diameter.org>; from pcalhoun@diameter.org on Mon, May 07, 2001 at 05:24:30PM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk Just to add more complexity, let's remember that all these baroque solutions don't do a thing for the NAS-caught-fire scenario, where the NAS takes an extended unplanned outage. Given the impossibility of perfection, it's comforting to realize that a perfect model of the network state is seldom necessary. To start with, the server doing the modeling only has to be close to accurate when it has to make a decision, not in between. As an example, if the server wants to prevent a user from parallel sessions, it's only when the request for an apparent second session arrives that it's important to validate the continued existence of the first session. A state-keeping server needs to see interim accounting, and have a query mechansim back to the NAS to validate session survival. Any solution that imposes much more complexity than that is a loser, in my long-considered opinion. Barney Wolff From owner-aaa-bof@merit.edu Mon May 7 23:33:39 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29782 for ; Mon, 7 May 2001 23:33:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 20EB05DE5C; Mon, 7 May 2001 21:47:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AD64A5DF83; Mon, 7 May 2001 21:46:13 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id AA1825E086 for ; Mon, 7 May 2001 21:33:16 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id VAA21644; Mon, 7 May 2001 21:25:00 -0400 (EDT) Message-Id: <4.1.20010507204914.01804cf0@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 07 May 2001 21:12:33 -0400 To: Pat Calhoun From: Paul Funk Subject: Re: [AAA-WG]: Boot-ID in DRI Cc: aaa-wg@merit.edu, Patrice Calhoun In-Reply-To: <20010507172429.B12425@charizard.diameter.org> References: <4.1.20010507194348.017f2eb0@cairo.funk.com> <4.1.20010507003531.01787b60@cairo.funk.com> <4.1.20010507003531.01787b60@cairo.funk.com> <20010507070835.H26582@charizard.diameter.org> <4.1.20010507194348.017f2eb0@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 05:24 PM 5/7/01 -0700, Pat Calhoun wrote: >On Mon, May 07, 2001 at 08:03:44PM -0400, Paul Funk wrote: >> At 07:08 AM 5/7/01 -0700, Pat Calhoun wrote: >> >On Mon, May 07, 2001 at 12:40:36AM -0400, Paul Funk wrote: >> >> I would suggest that we define a Boot-ID AVP for use >> >> in DRI. Each Diameter peer would determine a new >> >> Boot-ID at startup. When a DRI is received with a new >> >> Boot-ID value, this means the peer has restarted since >> >> the last connection. If the Boot-ID is the same, this >> >> means that this just a resumed connection. Upon >> >> connecting with a client, a server could release all >> >> sessions created under a different Boot-ID, if the >> >> server knows that the client does not retain user >> >> sessions across reboot. >> > >> >I am not sure that this actually solves the problem. In a >> >real scenario, the NAS will communicate directly with a >> >proxy server, which in turn will communicate with another server. >> >For the purposes of this discussion, let's assume that the >> >proxy communicates with a home server that is maintaining >> >session state. >> > >> >If the NAS was to reboot, it would send the Boot-Id to its >> >proxy server, but this information would never make it down >> >to the server in the home network, right? This is really >> >where the problem is. The home server would never know >> >that the NAS has rebooted, *unless* a new Shoe-Id would >> >cause the proxy to send some message to the home server informing >> >it that the NAS had rebooted. >> > >> >A rather ugly scenario :( >> >> Actually, it does solve the problem (as I define the problem, anyway). >> >> The problem is that without Boot-ID in DRI, nobody knows whether the >> NAS has rebooted, and nobody knows whether its sessions are still >> valid. >> >> With a Boot-ID, the local Diameter server knows when the NAS has >> rebooted and when to invalidate sessions. It may then use STR to >> inform home servers that the session is over. >> >> Come to think of it, it might be a good idea for the draft to warn that >> an STR need not come from the original NAS; it could be issued >> by a server on behalf of the NAS. Therefore, the home server >> receiving an STR should disregard Origin-FQDN and use only >> Session-ID (which is globally unique) to identify a session. > >ok, but now we *require* that proxies maintain state, and MUST inform >home servers when a reboot has occured. What would happen if the >state was on the wrong proxy? The home server would only get half (or >worse) of the picture. > >I am assuming here a hierarchy level of three, where the proxies in the >middle (not next to the NAS) maintain state. So, I guess that if all >Diameter proxies maintain state, then this would work. > >And this is now mandatory, otherwise home servers wouldn't be able to >accurately maintain state, and could be fooled by thiking that the proxies >are in fact providing this service. > >Of course, maintaining state in ALL Diameter entities in one hell of a MUST >to introduce at this point :( I don't think it's that complicated, and I don't think it introduces any additional state requirements on intermediate proxies. The only Diameter server that would need to keep state is the one next to the NAS (not the one in the middle). This is the server that aggregates all the local NASes and either provides AAA service directly or proxies to other servers. This aggregating server would keep the state of all sessions for the NASes it serves. Part of the session state is Destination-Realm and Destination-FQDN to which an STR would have to be sent. If the NAS goes down, the aggregating server would issue an STR for each of the NAS's sessions to the appropriate Destination-Realm and Destination-FQDN. Proxies between the aggregating server and the home server need not keep session state at all; they just need to forward the STR. I wouldn't recommend that issuing STRs on behalf of a NAS be a MUST. If the aggregating server doesn't do this, home servers will leak resources, okay. Perhaps that's best left as a business issue for roaming agreements rather than a protocol issue. But yes, I agree that your proposal of having a footwear-ID in each request allows home servers to often, though not always, release stale sessions of a rebooted NAS, regardless of what the aggregating server is capable of. Its unreliability is mitigated by the fact that if the NAS is not sending any new requests to a particular home server, it probably doesn't have many leaked sessions on it anyway. Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Tue May 8 00:01:29 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00113 for ; Tue, 8 May 2001 00:01:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 41D335DFDE; Mon, 7 May 2001 21:03:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4CF875E04B; Mon, 7 May 2001 20:51:30 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C58525E529 for ; Mon, 7 May 2001 20:34:55 -0400 (EDT) Received: (qmail 14137 invoked by uid 500); 8 May 2001 00:24:30 -0000 Date: Mon, 7 May 2001 17:24:30 -0700 From: Pat Calhoun To: Paul Funk Cc: Pat Calhoun , aaa-wg@merit.edu, Patrice Calhoun Subject: Re: [AAA-WG]: Boot-ID in DRI Message-ID: <20010507172429.B12425@charizard.diameter.org> Mail-Followup-To: Paul Funk , Pat Calhoun , aaa-wg@merit.edu, Patrice Calhoun References: <4.1.20010507003531.01787b60@cairo.funk.com> <4.1.20010507003531.01787b60@cairo.funk.com> <20010507070835.H26582@charizard.diameter.org> <4.1.20010507194348.017f2eb0@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010507194348.017f2eb0@cairo.funk.com>; from paul@funk.com on Mon, May 07, 2001 at 08:03:44PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, May 07, 2001 at 08:03:44PM -0400, Paul Funk wrote: > At 07:08 AM 5/7/01 -0700, Pat Calhoun wrote: > >On Mon, May 07, 2001 at 12:40:36AM -0400, Paul Funk wrote: > >> I would suggest that we define a Boot-ID AVP for use > >> in DRI. Each Diameter peer would determine a new > >> Boot-ID at startup. When a DRI is received with a new > >> Boot-ID value, this means the peer has restarted since > >> the last connection. If the Boot-ID is the same, this > >> means that this just a resumed connection. Upon > >> connecting with a client, a server could release all > >> sessions created under a different Boot-ID, if the > >> server knows that the client does not retain user > >> sessions across reboot. > > > >I am not sure that this actually solves the problem. In a > >real scenario, the NAS will communicate directly with a > >proxy server, which in turn will communicate with another server. > >For the purposes of this discussion, let's assume that the > >proxy communicates with a home server that is maintaining > >session state. > > > >If the NAS was to reboot, it would send the Boot-Id to its > >proxy server, but this information would never make it down > >to the server in the home network, right? This is really > >where the problem is. The home server would never know > >that the NAS has rebooted, *unless* a new Shoe-Id would > >cause the proxy to send some message to the home server informing > >it that the NAS had rebooted. > > > >A rather ugly scenario :( > > Actually, it does solve the problem (as I define the problem, anyway). > > The problem is that without Boot-ID in DRI, nobody knows whether the > NAS has rebooted, and nobody knows whether its sessions are still > valid. > > With a Boot-ID, the local Diameter server knows when the NAS has > rebooted and when to invalidate sessions. It may then use STR to > inform home servers that the session is over. > > Come to think of it, it might be a good idea for the draft to warn that > an STR need not come from the original NAS; it could be issued > by a server on behalf of the NAS. Therefore, the home server > receiving an STR should disregard Origin-FQDN and use only > Session-ID (which is globally unique) to identify a session. ok, but now we *require* that proxies maintain state, and MUST inform home servers when a reboot has occured. What would happen if the state was on the wrong proxy? The home server would only get half (or worse) of the picture. I am assuming here a hierarchy level of three, where the proxies in the middle (not next to the NAS) maintain state. So, I guess that if all Diameter proxies maintain state, then this would work. And this is now mandatory, otherwise home servers wouldn't be able to accurately maintain state, and could be fooled by thiking that the proxies are in fact providing this service. Of course, maintaining state in ALL Diameter entities in one hell of a MUST to introduce at this point :( > > > > >However, I believe that there is a different way around this, > >and we can make use of most of your proposal. If the NAS > >was to include the Shoe-Id in most of the authentication > >messages, the home server could evaluate its value with > >previous ones, and determine whether the NAS had rebooted > >or not. > > > >Of course, the home server would only be informed the next time > >the same NAS issues a message to that home server, so this > >isn't really timely. Unless, of course, the NAS supports the > >E2E security extension, and attempts to establish security > >associations with known home servers upon bootup (but I don't > >think this is a very likely scenario). > > Your proposal is addressed to an additional problem, namely: > Given that the first-hop proxy knows that a NAS has rebooted, > how does it efficiently inform home servers? > > Your proposal minimizes (actually, eliminates) the traffic necessary > to inform home servers. In my proposal, the first-hop server would > have to issue an STR for each roaming session. > > But in general, roaming sessions can be expected to be fewer than > local ones. So if a 1000 user NAS goes down, the 900 sessions > handled locally could be automatically released by the first-hop > server, but it would have to issue 100 STRs to other servers for > the 100 roaming users. > > I'm not advocating one proposal over another, just drawing > distinctions. Right, none of them are perfect, and my proposal is so unreliable that I wonder whether it is even useful. However, it does eliminate the need for state in all servers. PatC From owner-aaa-bof@merit.edu Tue May 8 11:04:42 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26302 for ; Tue, 8 May 2001 11:04:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F23A05DE4B; Tue, 8 May 2001 11:00:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B1F395DE4F; Tue, 8 May 2001 11:00:46 -0400 (EDT) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 278AE5DE4B for ; Tue, 8 May 2001 11:00:40 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id KAA21017; Tue, 8 May 2001 10:54:49 -0400 Received: from preston (cisconas248.bridgewatersys.com [192.168.150.248]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id LAA21830; Tue, 8 May 2001 11:01:29 -0400 (EDT) From: "Mark Jones" To: "Ammo Goettsch" , "Paul Funk (E-mail)" Cc: Subject: RE: [AAA-WG]: Boot-ID in DRI Date: Tue, 8 May 2001 11:03:26 -0400 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <001401c0d746$a262a430$4ca0bac6@platform> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0017_01C0D7AE.7F9CFCD0" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C0D7AE.7F9CFCD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > 1) How would a proxy know where to proxy this reboot indication to? > - home servers may have been found via brokers > - home servers may have been reached via redirect > - home servers may have been reached due to fail over conditions > Apart from the redirect, these issues exist with RADIUS Acct-On/Off today and the fowarding policy is typically derived from the contractual agreement between access provider and service provider. This forwarding policy defines whether the Acct-On/Off gets sent to the service provider's server. If the service provider has multiple servers, the fowarding policy may also define whether the reboot notification must be sent to one or all. In a proxy chain, a different forwarding policy may exist at each hop. > 2) How would the home server interpret this Proxied-DRI? > - If the Proxied-DRI takes particularly slow proxy route to > the final home server, it may arrive AFTER new sessions that were > created AFTER the reboot become known to the home server. > Therefore, the home server could not clear out ALL sessions > from the rebooted device, because only certain ones are actually > invalid. > I was assuming that Paul's Sandal-Id is present in the DRI and Proxied-DRI. Hence, sessions would only be cleared out which had a different (lower?) Sandal-Id. However, I do see the problem if new sessions are setup before the DRI arrives. Doesn't the same problem exist if the Sandal-Id is sent in every request and the requests arrive at the home server in a different order? > 3) Because of problems in 2), it appears that some sort of "tag" > or "shoe id" is needed to identify which sessions are to be cleared > out. In a scenario where different proxy routing causes re-ordering > of requests, it cannot be assured that a proxied DRI is received > in any timely manner. In fact, multiple reboots could occur > before any new shoe id reaches the home server. For this > reason, I have only been able to come up with using > a NAS-local clock time as the shoe id. Without those pesky DST changes, right? Wouldn't the home server still be testing for stale sessions with (newSandalId > sessionSandalId)? So a monotonically increasing value retained in non-volatile memory across reboots would fulfill the same function. Regards, Mark ------=_NextPart_000_0017_01C0D7AE.7F9CFCD0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFxTCCApQw ggH9oAMCAQICAwS4ODANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDUwMTE4MTgwOFoXDTAyMDUwMTE4MTgwOFowTzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdbWpvbmVzQGJyaWRnZXdhdGVyc3lzdGVt cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMemr5diJO/8+r2Hj3Opr9LbaVAXFgo2 Fhu0tfSSdvlMy52Y67GMoJbv0I282FWO9z4bsnuSIU7y3arEmyA78mwjTSdt2GK5QJHT6jKOqF6M 81Q5j2fU3dQwCPiCQZlOqUJEA3PySRjUQNOgnRUhoSuzGd7IMJ3Y6oeMtE8a02nTAgMBAAGjOjA4 MCgGA1UdEQQhMB+BHW1qb25lc0BicmlkZ2V3YXRlcnN5c3RlbXMuY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEANyubKv2ajV9VxVe4xUDaqZbQ2DEXgGKSFWwsdC06zUucuCmeHHqT vLcoUnI8/dCbSnSwRrELpemSoqTv/99uW+jS6cN5320w1ZEBsC2RSVrSJd8LqxKALmMexgbywYvF /hMe120ctocvwnfbeZmzBIKSF7BDs8YPGzSWgsa5gKUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2 17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gxggKOMIICigIB ATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgw JgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMEuDgwCQYFKw4DAhoFAKCC AUkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwNTA4MTUwMzIz WjAjBgkqhkiG9w0BCQQxFgQU7oyuebLL0O7mf2P6yko3gc75xMswPAYJKoZIhvcNAQkPMS8wLTAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqwYJKwYBBAGCNxAE MYGdMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMx KDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwS4ODANBgkqhkiG9w0B AQEFAASBgHeiw4Jr0fqlT0dITX0hGTY7/4R3craC8kd1rqBBUDSfn69mb95F1Gl5jJCjuQ1lsBbl e3x8EAXqvdqsGX7YmOKrvnfmsuz6vWs1aZDkSE/DlohnfeHfSc6Cyo4shzhRG/JX+Mq22xEdRAna U+4lex8xFxtSaqLG1jm6gNiK/7/IAAAAAAAA ------=_NextPart_000_0017_01C0D7AE.7F9CFCD0-- From owner-aaa-bof@merit.edu Tue May 8 11:35:04 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27702 for ; Tue, 8 May 2001 11:35:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BABDF5E03C; Tue, 8 May 2001 11:32:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A8AE65E03B; Tue, 8 May 2001 11:32:48 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 51DBE5E039 for ; Tue, 8 May 2001 11:32:47 -0400 (EDT) Received: (qmail 20596 invoked by uid 500); 8 May 2001 15:22:09 -0000 Date: Tue, 8 May 2001 08:22:09 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issues for today's call Message-ID: <20010508082209.G12425@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk Perhaps a little late, but I just want to set the stage for today's call. This call was generated by the Previous-FA-XXXX thread, to which I replied three times. One reply was to the suggestion that a Session-Id be predictable, and can be found at http://www.merit.edu/mail.archives/aaa-wg/2001-04/msg00240.html. This suggestion goes against the principle of Diameter, as I stated in my response. My next reply was to the thread that discussed session movement. The general idea here is that a mobile node is handed off across foreign agents, and there is no easy way for the home Diameter server to know where the mobile happens to be. So, if the home server wanted to "terminate" the session, and it didn't know where the mobile was, it couldn't send an STR. My response is at http://www.merit.edu/mail.archives/aaa-wg/2001-04/msg00293.html. Note that my general feeling here is that the home Diameter server could ONLY request a disconnect via the Home Agent, not the Foreign Agent. How the AAAF requests a disconnect needs to be discussed. How are accounting records generated, and correlation is performed, when session identifiers are different across handoffs. I don't have a reply to this one, and it must be thought through carefully. Perhaps the Acct-Mutli-Sess-id (or whatever that RADIUS attribute is) would be useful. Finally, a quick summary can be found at http://www.merit.edu/mail.archives/aaa-wg/2001-04/msg00296.html. Talk to y'all in about 30 minutes (hope the mailing list is fast). PatC From owner-aaa-bof@merit.edu Wed May 9 00:19:08 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15297 for ; Wed, 9 May 2001 00:19:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4C1685E253; Tue, 8 May 2001 21:40:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3BB2E5E676; Tue, 8 May 2001 21:21:23 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 219035E114 for ; Tue, 8 May 2001 20:45:34 -0400 (EDT) Received: (qmail 22436 invoked by uid 500); 9 May 2001 00:35:05 -0000 Date: Tue, 8 May 2001 17:35:05 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Recap of our foot fetish thread Message-ID: <20010508173505.W12425@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, Here is an attempt to recap the recent Boot-Id thread. Problem: How does a Home Diameter server know when a particular NAS has rebooted? This is actually quite important if the home server maintains session state. The problem is actually not as bad as it seems, though. Unlike RADIUS, Diameter sessions have a limited lifetime, set by the home Diameter server. When a re-auth isn't received by the time a session expires, the home server can clean up resources. However, a more pro-active approach is being discussed in the mailing list. 1. Paul's proposal. In Paul's proposal, a DRI would include a Boot-Id AVP, which could be a monotonically increasing number (increases upon each reboot). When a proxy server receives a DRI, the DRI is "proxied" to all home servers that the proxy is in communication with. Of course, a DRI is "probably" the wrong message to send, but something needs to be sent. Home Servers receiving this could then lookup which one of their users were serviced by the particular NAS, and clean up session state. The only drawback that I have here is that the first hop proxy needs to maintain some state as to which home's it has communicated with in the past. If the proxy was to reboot, then all bets are off. 2. Pat's proposal. In my proposal, each auth (and acct) message would include a Boot-Id AVP. So the next time that a message was sent to the home Diameter Server, the server could determine whether the NAS has rebooted since the last time it received a message from it. This seems to have the least amount of protocol impact, but it does only work when a message is sent to the home server. In cases where traffic is light for a particular home server, sessions would have to be cleaned up via soft state. In this proposal, if the proxy reboots, it is irrelevant. Both of the above protocols are MAYs, since sending how flaky one's network is apparently not a good idea :) As Barney warns, this doesn't fix the NAS caught fire problem. Of course, one would hope that technology has advanced in the past few years, and products that do catch fire are rather rare, but it could still occur. In these cases, the home Diameter server would have to clean up via soft state. Have I missed any other proposals? Thanks, PatC From owner-aaa-bof@merit.edu Wed May 9 06:09:51 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03002 for ; Wed, 9 May 2001 06:09:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B55D25EDE1; Wed, 9 May 2001 01:52:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 853B95EDDE; Wed, 9 May 2001 01:52:00 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 0E46F5EDE1 for ; Wed, 9 May 2001 01:51:51 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id BAA24415; Wed, 9 May 2001 01:42:49 -0400 (EDT) Message-Id: <4.1.20010509012431.01800910@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 09 May 2001 01:30:24 -0400 To: Pat Calhoun , Mark Jones , aaa-wg@merit.edu From: Paul Funk Subject: Re: [AAA-WG]: Recap of our foot fetish thread In-Reply-To: <20010508173505.W12425@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, Summarizing is a good idea. But yes, you have missed a proposal. What you characterized as my proposal is actually a combination of mine and Mark Jones'. Allow me to recast the summary. But first, a description of the architectural framework: Multiple NASes are clients of an aggregating server. Some sessions are local and use resources on the aggregating server. Other sessions are proxied by the aggregating server to other home servers, and use resources on those home servers. 1 Paul's proposal In Paul's proposal, a DRI would include a Boot-Id AVP, which could be a monotonically increasing number (increases upon each reboot). When an aggregating server receives a DRI from a NAS with a higher Boot-Id than before, the aggregating server can then release all resources for that NAS's local sessions. It MAY, if it so chooses, clean up all sessions globally, by issuing STRs on behalf of that NAS for all sessions that were proxied, each directed to the appropriate home server. 2. Pat's proposal. In Pat's proposal, each auth (and acct) message would include a Boot-Id AVP. So the next time that a message was sent to the home Diameter Server, the server could determine whether the NAS has rebooted since the last time it received a message from it. 3. Mark's proposal Mark's proposal (I'm taking liberties here) is the same as Paul's proposal, except that there would be a new command, say Client-Reboot-Request or Client-Reboot-Indication, that would contain the FQDN and Boot-Id of the restarted NAS. The aggregating server MAY issue this command to each home server for which there is at least one open session. Thus, only a single message per home server, rather than a message for each session, would have to be issued in order to clean up state globally. The first thing to note is that these proposals are not mutually exclusive. I think we should at least adopt Paul's proposal, since it allows an aggregating server to clean up local state efficiently, and provides at the least the option for the aggregating server to clean up state globally via STR or Mark's new command. It is a requirement of Mark's proposal anyway, and it is a sufficiently minor addition to Pat's proposal (just a single AVP in DRI) that it would make sense to avail ourselves of it in any case. Mark's proposal of a new command would reduce traffic over the use of individual STRs in Paul's proposal. However, the reduction may not be dramatic. The number of non-local sessions may be a fraction of the total number of sessions, and if the non-local are widely distributed, the tradeoff of STRs against his more powerful command may not be compelling. Plus, it requires that a new command be supported. Both Paul's and Mark's proposals required that the aggregating server keep session state for non-local sessions in order to clean them up. Pat's proposal, as he notes, has the advantage that non-local sessions can get cleaned up even if the aggregating server does not keep their state, in fact, even if the aggregating server itself goes down. However, it is non-deterministic, and depends on the accident of the NAS starting a session on the same home server after it is rebooted. So my feeling is that we should at least adopt my humble proposal, and possibly all three. That's the strongest opinion I can muster. Paul At 05:35 PM 5/8/01 -0700, Pat Calhoun wrote: >All, > >Here is an attempt to recap the recent Boot-Id thread. > >Problem: > >How does a Home Diameter server know when a particular NAS has rebooted? This >is actually quite important if the home server maintains session state. > >The problem is actually not as bad as it seems, though. Unlike RADIUS, >Diameter sessions have a limited lifetime, set by the home Diameter server. >When a re-auth isn't received by the time a session expires, the home >server can clean up resources. > >However, a more pro-active approach is being discussed in the mailing list. > >1. Paul's proposal. > >In Paul's proposal, a DRI would include a Boot-Id AVP, which could be a >monotonically increasing number (increases upon each reboot). When a proxy >server receives a DRI, the DRI is "proxied" to all home servers that the >proxy is in communication with. Of course, a DRI is "probably" the wrong >message to send, but something needs to be sent. > >Home Servers receiving this could then lookup which one of their users >were serviced by the particular NAS, and clean up session state. > >The only drawback that I have here is that the first hop proxy needs to >maintain some state as to which home's it has communicated with in the past. >If the proxy was to reboot, then all bets are off. > >2. Pat's proposal. > >In my proposal, each auth (and acct) message would include a Boot-Id AVP. >So the next time that a message was sent to the home Diameter Server, the >server could determine whether the NAS has rebooted since the last time >it received a message from it. > >This seems to have the least amount of protocol impact, but it does only >work when a message is sent to the home server. In cases where traffic >is light for a particular home server, sessions would have to be cleaned up >via soft state. > >In this proposal, if the proxy reboots, it is irrelevant. > >Both of the above protocols are MAYs, since sending how flaky one's network >is apparently not a good idea :) > >As Barney warns, this doesn't fix the NAS caught fire problem. Of course, one >would hope that technology has advanced in the past few years, and products >that do catch fire are rather rare, but it could still occur. In these >cases, the home Diameter server would have to clean up via soft state. > >Have I missed any other proposals? > >Thanks, > >PatC Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Wed May 9 10:37:50 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08946 for ; Wed, 9 May 2001 10:37:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DA7255DEE0; Wed, 9 May 2001 10:04:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 34C9B5F9E3; Wed, 9 May 2001 10:04:31 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 0A2355F9A6 for ; Wed, 9 May 2001 10:01:54 -0400 (EDT) Received: (qmail 25990 invoked by uid 500); 9 May 2001 13:51:23 -0000 Date: Wed, 9 May 2001 06:51:23 -0700 From: Pat Calhoun To: Paul Funk Cc: Pat Calhoun , Mark Jones , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Recap of our foot fetish thread Message-ID: <20010509065123.C12425@charizard.diameter.org> Mail-Followup-To: Paul Funk , Pat Calhoun , Mark Jones , aaa-wg@merit.edu References: <20010508173505.W12425@charizard.diameter.org> <4.1.20010509012431.01800910@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010509012431.01800910@cairo.funk.com>; from paul@funk.com on Wed, May 09, 2001 at 01:30:24AM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, May 09, 2001 at 01:30:24AM -0400, Paul Funk wrote: > Pat, > > Summarizing is a good idea. But yes, you have missed a proposal. What > you characterized as my proposal is actually a combination of mine > and Mark Jones'. [snio] I guess now is probably the right time to ask whether this is a bug fix, or a new feature. The WG agreed in Minn that no new "features" would be added after the last meeting, but only fixes. So, which one is this, bug or feature? PatC From owner-aaa-bof@merit.edu Wed May 9 12:05:10 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13967 for ; Wed, 9 May 2001 12:05:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EEE445FB88; Wed, 9 May 2001 11:08:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 805085FAC7; Wed, 9 May 2001 11:08:16 -0400 (EDT) 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 851FD5FBA5 for ; Wed, 9 May 2001 11:07:48 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f49F7lN15085 for ; Wed, 9 May 2001 17:07:47 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed May 09 17:07:27 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 9 May 2001 17:07:27 +0200 Message-ID: <577066326047D41180AC00508B955DDA02C009EB@eestqnt104.es.eu.ericsson.se> From: "Yolanda Garcia-Serrano (ECE)" To: "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" Cc: "Martin Julien (ECE)" , "Marta Morant-Artazkotz (ECE)" , "Ana Sanz-Merino (ECE)" , "Alvaro Berlanga-Perez (ECE)" , "Irene Martin Cabello (ECE)" , "Guillermo Guardia-Lozano (ECE)" Subject: [AAA-WG]: Comments and questions on 03 Date: Wed, 9 May 2001 17:02:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, Pat and others I have some questions on the base: Is needed Proxy-Info AVP in MRI, STI, ASI, API ? If yes, what for? I think there is no need to keep any state for indications, so update of those messages and table in section 16 would be needed. Section 11.7 Max-Wait-Time AVP (change 'Max-Time-Wait' to Max-Wait-Time in 16.1) This AVP does not appear in any message. I think it should be 0-1 at least in DRI, and maybe in DSI, DWR, in order to inform the other peer about how your Diameter server is going to behave regarding Responses. Otherwise, it should not be an AVP but a Diameter configurable parameters? Anyway, I think its good to givethe possibility of include it in some messages. Section 10.1: {Destination-Realm] is missing in MRI Section 11.9.1: *[Route-Record] is missing in STI. Section 12.1 Realm-based Message Routing 2 first paragraphs still refers to NAIs. I think any reference to User-Name or NAI related to the routing mechanism is in the spec since the original routing mechanism was there, and it should be removed from the spec, as we have now Destination-Realm for that, and there is no need to access the realm part of User-Name AVP to route a message. Section 12.1.1 I guess Extension Id on the Real-Based Routing Table should be updated to Acc-Extension-Id and Auth-Extension-Id Section 14.3 and 14.4: I don't understand the purpose of these ASI and API messages. I guess only Diameter clients (the ones generating accounting) could sent this msg, not any Diameter Node in general, right? Then, who they send the ASI to? is per peer, or to the corresponding Accounting servers? If it is destined to a accounting server, {Destination-FQDN} is missing. In case ASI with Accounting-State=DISABLED is received by an Accounting Server, what should it do? Exactly when a Diameter client MUST sent ASI with Accounting-State=ENABLED? After a reboot, after a previously sent DISABLED one, when previous accounting sessions were opened but it is not possible to sent any more accounting info ? If the node is about to be taken out, even it can not grant the service. In case ASI ENABLED is received by an Accounting server, what should it do? API is sent by an accounting Diameter server to who? To the peers that have active accounting sessions in the accounting server? Then, if it is a message destined to concrete nodes, is not per session and should be removed? Sending an API per session-Id could overload the server and the network. It must state only one or the other: {Destination-FQDN} vs [Destination-FQDN], but not both What does the text about the warning in roaming networks mean? In case an accounting server wants to synchronize with any Diameter node generating accounting, it can know which are the one having active accounting sessions, so Destination-FQDN is known, and it is not the purpose of the message to be sent to _ANY peer, right? And some other small details IMHO to be updated : Table of Contents: chapter 6.1 is missing Section 1.3 "Downstream Server", the explanation refers to upstream, I think it should be downstream "Upstream Server", the explanation refers to downstream, I think it should be upstream "Session Record" -> I guess it should be "Accounting Record", as it has been modified in 13.5. 12.5. Instead of DIAMETER_NO_END_2_END_SECURITY, I think it has been agreed on a previous mail DIAMETER_END_2_END_SECURITY 12.6. The text applies to both statefull and stateless proxies, so remove "Stateful" on first line ? 13.0 "authorization-server" should be changed by "server" 14.1 Remove CMS-Data in ACR and ACA commands Table 16.2: API and ASI columns are interchanged, aren't they? In NASREQ 03, section 11.1, columns AAA and AAR are interchanged ? Same for 11.2.1 and 11.2.2, API and ASI columns are also interchanged? As always, thanks a lot for your attention Best Regards /Yolanda From owner-aaa-bof@merit.edu Wed May 9 12:26:21 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15100 for ; Wed, 9 May 2001 12:26:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1E8C75DD8F; Wed, 9 May 2001 12:01:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 037A55DDBE; Wed, 9 May 2001 12:01:36 -0400 (EDT) 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 918465DD8F for ; Wed, 9 May 2001 12:01:33 -0400 (EDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f49G1WO09630 for ; Wed, 9 May 2001 18:01:32 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed May 09 18:01:31 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 9 May 2001 18:01:30 +0200 Message-ID: <577066326047D41180AC00508B955DDA01D7FFD8@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" Cc: "Martin Julien (ECE)" Subject: [AAA-WG]: Comments on draft-mobileip-03 Date: Wed, 9 May 2001 17:58:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, First, I must say that I would have really liked to join the conference call held yesterday, but I must apologize for not being ready on time for it. Anyhow, I read the latest draft and have some comments. 1-Already much better than some previous versions. Thanks! 2-In the Abstract section, in the last sentence, you refer to the Diameter Accounting Extension. I guess you should make it a bit more clearer that it is not an extension anymore. 3-In the Abstract section, in the last sentence, it says that the Accounting messages should be used by the FA and the HA to report usage info. Does that mean that both need to use the same Session-Id in the accounting messages? I don't know the story around the Acct-Multi-Sess-Id AVP. Same comment applies to the 3rd par. of page 3. 4-Last paragraph of section 1.0, the attendant can also be an HA, when the MN is in the Home Domain and the HA is co-located. That should apply to all the document where you refer to the attendant, while having in parenthesis the FA. 5-In section 1.2, page 5, the last paragraph starting with "If the AAAH...", I think it is a bit confusing here. Here is what I would suggest for the last few paragraphs of page 5. "... If the Mobile Node was successfully authenticated, the AAAH checks if the Home Agent was located in the foreign domain, by checking the Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. If it is set to 1, then the Home Agent is located in the foreign domain then AAAH sends an HAR message to AAAF which contains a MIP-Reg-Request AVP. If the Home Agent was not located in the foreign domain, the AAAH checks for the MIP-Home-Agent-Address AVP. If one was specified, the AAAH checks that the address is that of a known Home Agent, and one that the Mobile Node is allowed to request. If no Home Agent was specified, and if the MIP-Feature-Vector has the Home-Agent-Requested flag set, and if allowed by policy in the home domain, the AAAH SHOULD allocate a home agent on behalf of the Mobile Node. This can be done in a variety of ways, including using a load balancing algorithm in order to keep the load on all home agents equal. The actual algorithm used and the method of discovering the home agents is outside the scope of this specification. The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains the Mobile IP Registration Request message data encapsulated in the MIP-Reg-Request AVP, to the assigned or requested Home Agent. The AAAH MAY allocate a home address for the mobile node, and include it in a MIP-Mobile-Node-Address AVP within the HAR, or else leave this allocation responsibility for the Home Agent. ..." 6- Second paragraph of page 6, I'm still wondering why a DIAMETER_ERROR_BAD_HAR is required? What is it supposed to mean? We do not have this type of generic error for any other extension, and I don't see why we should have this for MIP. If the request is rejected, I guess the normal result-code defined in the Base should be used instead. The comment applies also to section 4.1. 7- Page 8, second par., the thing is that I think that AAAH can determine that the MN has moved to a new domain by using the Origin-FQDN and the MIP-Previous-FA-FQDN. However, I'm wondering if the MIP-Previous-FA-FQDN is enough, since the FQDN is highly dependent on the realm of the MIP-Previous-FA-XXXX, right? You can only tell that the MN is moving between domain based on the Realms. And now, let's say that the HA is located in the former domain, then how can the AAAF knows that the MN has registered in an other domain? The MIP-Previous-FA-FQDN can not really help, since it will be in that domain from where it moved. The AAAF does not have any mean of knowing the originator of the AMR, AFAIK. I guess that a MIP-Registering-FA-FQDN AVP should be added for that purpose. 8-Section 2.1, I think it is not clear exactly when the FA needs to invoke the AAA infrastructure. I think it would be necessary to mention that it would be possible for a MN registration to invoke the AAA infrastructure only when a User-Name, a MIP-Home-Address, a MIP-Home-Agent-Address, a MIP-FA-Challenge or session keys are requested. Otherwise, the registration would go directly from the FA to the HA. The MIP-FA-Challenge AVP Should be added to the table in section 10.1 (0-1). Also, I guess that the MN-AAA extension should also be mention in the list of AVPs. 9-Section 2.2, the last sentence of the first paragraph is redundant with the second one. The second one is much more complete. Also the third par. should instead read as: "The AMA message MUST contain the MIP-FA-to-HA-Key, MIP-FA-to-MN-Key if they were requested in the AMR. IF they were also sent in the HAR, the HAA must also include them unchanged." 10-The AVP [MIP-MN-to-HA-Key] is listed twice in the message description. Also, the Original-Session-Id is not listed in the table 10.1 11-Section 3.1, for the DIAMETER_ERROR_AUTH_FAILURE, I guess it should say to inform the mobility agents (HA (co-located) or the FA). 12-Section 5.5 and 5.6, beside the comment #7, I would add that the MN MAY or MUST include that information? In it is only a MAY, then I guess we should not count on it for checking if the MN has moved to a new FA, unless it is specified that it MUST in the case where the MN wants to seemlessly moved to a new FA. Also, it mentions "under the same administrative domain", which would not be useful to check if the HA allocated in a previous foreign domain can still provide service to the MN. Check comment #7 again for that. 13-Section 5.7, I guess that when the MIP-Mobile-Node-Address and the MIP-Home-Agent- Address AVPs are not in the message, the AAAF and the AAAH knows that Home-Agent is requested and that a Mobile-Node-Home-Address is requested. I don't see the need for those 2 flags. 14-Page 20, par.3, I don't think it is the correct meaning. My understanding, after talking with Tony Johansson, is that the Home-Agent-In-Foreign-Network is used when the MN requests a Home-Agent, and that the AAAF detects that it is located in its foreign domain, before it forwards the AMR to the AAAH. 15-In section 5.8, I am wondering where the MN-AAA authenticator is? The MN-AAA authentication extension added by the MN does not seem to be included in any of the AVPs. Am I missing something? 16-Section 6.0, second paragraph, why do you refer to encryption? The thing is that it is a bit confusing what is required. Do you mean that either the message encryption is required via the Base protocol, or the AVP encryption is required via the E2E security extension? In fact, the session keys, in terms of AVPs, destined to the FA and the HA can NOT be encrypted in the AVP unless the E2E security is used, or the message is completely encrypted by the Base protocol. 17-Section 6.2, 2nd par., should be HAA instead of AHA. Also, the FA should add the FA-MN-authentication extension to the reg-Reply. 18-Section 6.3, the last par. is wrong. It should be the HA that should add the HA-FA-Authentication extension. 19-Section 7.0, 2nd par., the same question about the encryption??? The table should be in alphabetical order. Also, the AVP defined in section 7.2 should be added to the table. 20-Section 7.2, the figure should be updated according to the description of the grouped-AVP. 21-Section 7.2.1 and 7.2.2, refer to section 7.2 instead of 6.2. 22- Section 8.2 and 8.5, should be "by the user" instead of "to the user". 23-Some updates to the table 10.1 as follows: +-----------------------+ | Command-Code | |-----+-----+-----+-----+ Attribute Name | AMR | AMA | HAR | HAA | ------------------------------|-----+-----+-----+-----+ Authorization-Lifetime | 0-1 | 1 | 1 | 1 | Destination-FQDN | 0-1 | 1 | 0-1 | 1 | Destination-Realm | 1 | 0 | 1 | 0 | Error-Reporting-FQDN | 0 | 0-1 | 0 | 0-1 | Auth-Extension-Id | 1 | 1 | 1 | 1 | Filter-Rule | 0 | 0-1 | 0-1 | 0-1 | MIP-FA-to-HA-Key | 0 | 0-1 | 0-1 | 0-1 | MIP-FA-to-MN-Key | 0 | 0-1 | 0-1 | 0-1 | MIP-Feature-Vector | 0-1 | 0 | 0 | 0 | MIP-FA-HA-Preferred-SPI | 0-1 | 0 | 0 | 0 | MIP-FA-MN-Preferred-SPI | 0-1 | 0 | 0 | 0 | MIP-HA-to-FA-Key | 0 | 0 | 0-1 | 0 | MIP-HA-to-MN-Key | 0 | 0-1 | 0-1 | 0 | MIP-Home-Agent-Address | 0-1 | 0-1 | 0-1 | 0-1 | MIP-MN-AAA-Auth | 1 | 0 | 0 | 0 | MIP-MN-to-FA-Key | 0 | 0 | 0-1 | 0 | MIP-MN-to-HA-Key | 0 | 0-1 | 0-1 | 0 | MIP-Mobile-Node-Address | 0-1 | 0-1 | 0-1 | 0-1 | MIP-Previous-FA-Address | 0-1 | 0 | 0 | 0 | MIP-Previous-FA-FQDN | 0-1 | 0 | 0 | 0 | MIP-Reg-Reply | 0 | 0-1 | 0 | 0-1 | MIP-Reg-Request | 1 | 0 | 1 | 0 | Origin-FQDN | 1 | 1 | 1 | 1 | Origin-Realm | 1 | 1 | 1 | 1 | Proxy-Info | 0+ | 0+ | 0+ | 0+ | Result-Code | 0 | 1 | 0 | 1 | Route-Record | 0+ | 0+ | 0+ | 0+ | Session-Id | 1 | 1 | 1 | 1 | Session-Timeout | 0 | 1 | 1 | 1 | User-Name | 1 | 0 | 1 | 0 | ------------------------------|-----+-----+-----+-----| 24-Some updates to the tables 10.1 as follows: +-----------------------+ | Command-Code | |-----+-----+-----+-----+ Attribute Name | ACR | ACA | API | ASI | ------------------------------|-----+-----+-----+-----+ Accounting-Input-Octets | 1 | 0-1 | 0 | 0 | Accounting-Input-Packets | 1 | 0-1 | 0 | 0 | Accounting-Output-Octets | 1 | 0-1 | 0 | 0 | Accounting-Output-Packets | 1 | 0-1 | 0 | 0 | Accounting-Session-Time | 1 | 0-1 | 0 | 0 | Accounting-State | 0 | 0 | 1 | 0 | MIP-Feature-Vector | 1 | 0-1 | 0 | 0 | MIP-Home-Agent-Address | 1 | 0-1 | 0 | 0 | MIP-Mobile-Node-Address | 1 | 0-1 | 0 | 0 | MIP-Previous-FA-Address | 0-1 | 0-1 | 0 | 0 | MIP-Previous-FA-FQDN | 0-1 | 0-1 | 0 | 0 | ------------------------------|-----+-----+-----+-----+ I don't think the Accounting-State AVP should be here, since it is included in the Base protocol. Anyway, it should be in the ASI, not the API. Also, I don't understand why the MIP-Feature-Vector could be useful? Any idea? 25-Section 13.0, the same thing, what does the following really mean? "The keys are distributed in an encrypted format through the Diameter protocol, and SHOULD be encrypted using the methods defined in [9]." Have a good day! Martin From owner-aaa-bof@merit.edu Wed May 9 17:44:56 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26174 for ; Wed, 9 May 2001 17:44:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6AAA25DDBA; Wed, 9 May 2001 17:38:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E118B5DE3F; Wed, 9 May 2001 17:35:15 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 7FB485DE61 for ; Wed, 9 May 2001 17:18:15 -0400 (EDT) Received: (qmail 29178 invoked by uid 500); 9 May 2001 21:07:44 -0000 Date: Wed, 9 May 2001 14:07:43 -0700 From: Pat Calhoun To: Tony Johansson Cc: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: [AAA-WG]: Re: comments on base -03 Message-ID: <20010509140743.O12425@charizard.diameter.org> Mail-Followup-To: Tony Johansson , pcalhoun@diameter.org, aaa-wg@merit.edu References: <3AF71A66.4FA8E9B0@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AF71A66.4FA8E9B0@ericsson.com>; from tony.johansson@ericsson.com on Mon, May 07, 2001 at 02:57:58PM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, May 07, 2001 at 02:57:58PM -0700, Tony Johansson wrote: > * section 2.1 second paragraph: > " A Diameter node MAY send packets from any source port, but MUST > be > prepared to receive packets on port TBD. When a request is > received, > the source and destination ports in the reply are reversed." > > I think text reflects what was needed in the case of UDP. With SCTP and > TCP I think this statement is no longer valid. Partly. The new text will read: "A Diameter node MAY initiate connections from any source port, but MUST be prepared to receive connections on port TBD." > * section 6.2 third paragraph: > "If a Diameter node receives a DRI message that results in an > error, a > Message-Reject-Ind message MUST be returned." > > Shouldn't this be a DSI that MUST be returned. I guess this will be > changed anyway if we agree on discard the use of MRIs. Correct, but no agreement was made on an approach. I proposed a somewhat radical approach where a command req/answ would have only a single command code, but the bits in the header would be used to specify whether it was a request or answer. I would like some feedback on this on. I think that this will also solve some extensibility issues. > * section 6.2: > ::= < Diameter Header: 257 > > { Origin-FQDN } > { Origin-Realm } > 1* { Host-IP-Address } > { Vendor-Id } > { Product-Name } > * { Supported-Vendor-Id } > * [ Auth-Extension-Id ] > * [ Acct-Extension-Id ] > [ Destination-FQDN ] > [ Firmware-Revision ] > * [ AVP ] > > I believe the Supported-Vendor-Id should be optional, i.e * [ > Supported-Vendor-Id ] Correct. > and the Auth-Extension-Id and the > Acct-Extension-Id should be mandatory, i.e *{ Acct-Extension-Id } and * > { Auth-Extension-Id }. I had a hard time with this one, and I am glad you caught this. If I make the change you are proposing, a server will ALWAYS have to be both an auth *and* an accounting server. The reason why they are split is to allow a server to ONLY do one of the two. Making the AVPs mandatory will no longer permit that :( > > > * section 9.1.1.2 or section 12.3 Redirect > > I think we need some more text in either 9.1.1.2 or 12.3 that clarifies > what the redirect server MUST include in the redirect response. I'm > mean, should the redirect server include all AVPs from the request > message. This means that the server that receives the redirect could use > the received AVPs from the redirect message to create and resent the > request on the redirected path. > > The other way would be that the redirect server doesn't send back all > the received AVPs. The server that receives the redirect would in this > case have to use his message queue to create and resent the request on > the redirected path. > > I'm not really sure which one to favor. I guess you will have support > for the last one anyway in the case of failover, so it maybe unnecessary > to require that all AVPs MUST included in the redirect. Comments? The message to be re-directed is in the message queue, and that is the one that is re-directed. I have added the last sentence to the second paragraph, which now reads: "Successful routing table lookups will return one or more home Diameter servers that could satisfy the message. The home servers are encoded in one or more Redirect-Host AVPs, and the Command-Code field is set to Device-Status-Ind. The Hop-by-Hop field in the Diameter header is set to the value found in the message causing the redirect." And added a new paragraph at the end of the section: "The receiver of the DSI message with the DSI-Event AVP set to DIAMETER_REDIRECT_INDICATION uses the hop-by-hop field in the Diameter header to identify the message in the pending message queue (see Section 7.3) that is to be redirected." > > > * section 11.7 Max-Wait-Time AVP: > > I assume the maximum amount of time is in msec. Right? yes, and the text has been updated. PatC From owner-aaa-bof@merit.edu Wed May 9 19:08:58 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28737 for ; Wed, 9 May 2001 19:08:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4898F5E136; Wed, 9 May 2001 18:45:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3D2455DF3E; Wed, 9 May 2001 18:10:47 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id A974D5DF28 for ; Wed, 9 May 2001 17:43:42 -0400 (EDT) Received: (qmail 29420 invoked by uid 500); 9 May 2001 21:33:11 -0000 Date: Wed, 9 May 2001 14:33:11 -0700 From: Pat Calhoun To: "Yolanda Garcia-Serrano (ECE)" Cc: "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" , "Martin Julien (ECE)" , "Marta Morant-Artazkotz (ECE)" , "Ana Sanz-Merino (ECE)" , "Alvaro Berlanga-Perez (ECE)" , "Irene Martin Cabello (ECE)" , "Guillermo Guardia-Lozano (ECE)" Subject: [AAA-WG]: Re: Comments and questions on 03 Message-ID: <20010509143310.P12425@charizard.diameter.org> Mail-Followup-To: "Yolanda Garcia-Serrano (ECE)" , "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" , "Martin Julien (ECE)" , "Marta Morant-Artazkotz (ECE)" , "Ana Sanz-Merino (ECE)" , "Alvaro Berlanga-Perez (ECE)" , "Irene Martin Cabello (ECE)" , "Guillermo Guardia-Lozano (ECE)" References: <577066326047D41180AC00508B955DDA02C009EB@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA02C009EB@eestqnt104.es.eu.ericsson.se>; from yolanda.garcia-serrano@ece.ericsson.se on Wed, May 09, 2001 at 05:02:27PM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, May 09, 2001 at 05:02:27PM +0200, Yolanda Garcia-Serrano (ECE) wrote: > Is needed Proxy-Info AVP in MRI, STI, ASI, API ? If yes, what for? I think there is no need to keep any > state for indications, so update of those messages and table in section 16 would be needed. You are correct, but let's wait until we find the correct fix for the MRI. If it is as I suspect, MRI will require a Proxy-Info AVP. The others can be eliminated, I think. > > > Section 11.7 Max-Wait-Time AVP (change 'Max-Time-Wait' to Max-Wait-Time in 16.1) > This AVP does not appear in any message. I think it should be 0-1 at least in DRI, and maybe in DSI, > DWR, in order to inform the other peer about how your Diameter server is going to behave regarding > Responses. > Otherwise, it should not be an AVP but a Diameter configurable parameters? Anyway, I think its good to > givethe possibility of include it in some messages. Right. I think that it SHOULD be present in the STR, and ACR messages, at a minimum. As far as DWR, I am not sure that it really makes a whole lot of sense since this message isn't proxyable. > > Section 10.1: {Destination-Realm] is missing in MRI The AVP is present in -03, but as [optional]. Are you stating that it should be {mandatory}? > > > Section 11.9.1: *[Route-Record] is missing in STI. Correct, but the routes added MUST NOT be in the STR. I will add text to make sure this is clear. > > > Section 12.1 Realm-based Message Routing > 2 first paragraphs still refers to NAIs. I think any reference to User-Name or NAI related to the > routing mechanism is in the spec since the original routing mechanism was there, and it should be > removed from the spec, as we have now Destination-Realm for that, and there is no need to access > the realm part of User-Name AVP to route a message. Wow, how did I miss that one. The two new paragraphs read: "Diameter request, query and indication message routing is done via realms. A Diameter entity creating a message that is proxyable MUST include the realm in the Destination-Realm AVP. The realm MAY be retrieved from the User-Name AVP, which is in the form of a Network Access Identifier (NAI). The realm portion of the NAI is inserted in the Destination-Realm AVP. 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 (see section 12.1.1)." > > Section 12.1.1 I guess Extension Id on the Real-Based Routing Table should be updated to Acc-Extension-Id > and Auth-Extension-Id yes it now reads: "- Extension Identifier. It is possible for a routing entry to have a different destination based on the Auth-Extension-Id (for accounting messages) or Acct-Extension-Id (for non-accounting messages) of the message. This field is typically used as a secondary key field in routing table lookups." > > > Section 14.3 and 14.4: I don't understand the purpose of these ASI and API messages. > I guess only Diameter clients (the ones generating accounting) could sent this msg, not any Diameter > Node in general, right? Then, who they send the ASI to? is per peer, or to the corresponding Accounting servers? > If it is destined to a accounting server, {Destination-FQDN} is missing. > > In case ASI with Accounting-State=DISABLED is received by an Accounting Server, what should it do? > > Exactly when a Diameter client MUST sent ASI with Accounting-State=ENABLED? After a reboot, after > a previously sent DISABLED one, when previous accounting sessions were opened but it is not possible to > sent any more accounting info ? If the node is about to be taken out, even it can not grant the service. > > In case ASI ENABLED is received by an Accounting server, what should it do? All good questions, and I wonder about it's usefulness as well. Perhaps people that use this functionality in RADIUS could help me out? To answer the routing of the message, though. I believe that this message ONLY makes it to the first hop proxy. It is not proxyable. > > API is sent by an accounting Diameter server to who? To the peers that have active accounting sessions in the > accounting server? Then, if it is a message destined to concrete nodes, is not per session and should > be removed? Sending an API per session-Id could overload the server and the network. > It must state only one or the other: {Destination-FQDN} vs [Destination-FQDN], but not both > What does the text about the warning in roaming networks mean? Because I think this message stinks, and it doesn't scale in roaming networks. This is my attempt to warn people NOT to use this message, but it appears that there are people that find this useful. Again, could those people please speak up? > In case an accounting server wants to synchronize with any Diameter node generating accounting, > it can know which are the one having active accounting sessions, so Destination-FQDN is known, and it is not > the purpose of the message to be sent to _ANY peer, right? Right, but would a server poll ALL access devices in the 'net? That's the point. So the Destination-FQDN is known, and MUST be present (according to the ABNF). > > > And some other small details IMHO to be updated : > > Table of Contents: chapter 6.1 is missing thanks. > > Section 1.3 > "Downstream Server", the explanation refers to upstream, I think it should be downstream > "Upstream Server", the explanation refers to downstream, I think it should be upstream These were changed because the text in the draft uses this particular direction when refering to the terms. > "Session Record" -> I guess it should be "Accounting Record", as it has been modified > in 13.5. yes. > > 12.5. Instead of DIAMETER_NO_END_2_END_SECURITY, I think it has been agreed on a previous > mail DIAMETER_END_2_END_SECURITY yes, I changed the code, but not the text :( > > 12.6. The text applies to both statefull and stateless proxies, so remove "Stateful" on first line ? yes. > > 13.0 "authorization-server" should be changed by "server" right. > > 14.1 Remove CMS-Data in ACR and ACA commands correct. > > Table 16.2: API and ASI columns are interchanged, aren't they? OOps > > In NASREQ 03, section 11.1, columns AAA and AAR are interchanged ? > Same for 11.2.1 and 11.2.2, API and ASI columns are also interchanged? correct. Thanks for your comments. Very helpful. PatC From owner-aaa-bof@merit.edu Wed May 9 20:46:01 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00037 for ; Wed, 9 May 2001 20:46:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D0F905E043; Wed, 9 May 2001 19:54:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 46B115E1C8; Wed, 9 May 2001 19:08:25 -0400 (EDT) Received: from imr2.ericy.com (unknown [12.34.240.68]) by segue.merit.edu (Postfix) with ESMTP id 5CC6B5E0F8 for ; Wed, 9 May 2001 18:44:57 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f49Miu824281; Wed, 9 May 2001 17:44:56 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f49MiuR01474; Wed, 9 May 2001 17:44:56 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA07849; Wed, 9 May 2001 17:44:55 -0500 (CDT) Received: from ericsson.com (tsgw1c010.exu.ericsson.se [138.85.130.20]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA24581; Wed, 9 May 2001 17:44:47 -0500 (CDT) Message-ID: <3AF9C7EF.E911DE91@ericsson.com> Date: Wed, 09 May 2001 15:42:55 -0700 From: Tony Johansson X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Re: comments on base -03 References: <3AF71A66.4FA8E9B0@ericsson.com> <20010509140743.O12425@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > > and the Auth-Extension-Id and the > > Acct-Extension-Id should be mandatory, i.e *{ Acct-Extension-Id } and * > > { Auth-Extension-Id }. > > I had a hard time with this one, and I am glad you caught this. If I make > the change you are proposing, a server will ALWAYS have to be both an auth > *and* an accounting server. The reason why they are split is to allow a > server to ONLY do one of the two. Making the AVPs mandatory will no longer > permit that :( > Uoops, I think I was to quick here. I do think it should be possible for a server to be configured to do only one of them. So please keep them within []. /Tony From owner-aaa-bof@merit.edu Wed May 9 21:14:06 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00425 for ; Wed, 9 May 2001 21:14:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 47B105E00E; Wed, 9 May 2001 20:26:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C511E5E032; Wed, 9 May 2001 19:49:20 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 3C32A5E6C9 for ; Wed, 9 May 2001 19:32:11 -0400 (EDT) Received: (qmail 30997 invoked by uid 500); 9 May 2001 23:21:39 -0000 Date: Wed, 9 May 2001 16:21:39 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Comments on draft-mobileip-03 Message-ID: <20010509162138.S12425@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA01D7FFD8@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA01D7FFD8@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Wed, May 09, 2001 at 05:58:01PM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, May 09, 2001 at 05:58:01PM +0200, Martin Julien (ECE) wrote: > 1-Already much better than some previous versions. Thanks! No, thank you! Seriously, if it wasn't for all the great comments that are sent on the list, the specs wouldn't be as good as they are. > > 2-In the Abstract section, in the last sentence, you refer to the > Diameter Accounting Extension. I guess you should make it a bit more > clearer that it is not an extension anymore. check. > > 3-In the Abstract section, in the last sentence, it says that the > Accounting messages should be used by the FA and the HA to report > usage info. Does that mean that both need to use the same Session-Id > in the accounting messages? I don't know the story around the > Acct-Multi-Sess-Id AVP. ok, well there is a fair amount of new text that was generated yesterday following the call, and how session ids were handled was one area of concern. Here is an example (pardon the nroff commands :) During the creation of the HAR, the AAAH MUST use a different session identifier than the one used in the AMR/AMA (see figure 2). Of course, the AAAH MUST use the same session identifier for all HARs initiated on behalf of a given mobile node's session. A mobile node's session is identified via its identity in the User-Name AVP, the MIP-Mobile-Node-Address and MIP-Home-Agent-Address AVPs. This is necessary in order to allow the session state machine, defined in the base protocol [1], to be used unmodified with this extension. Therefore, an STR from a foreign agent would free the session from the foreign agent, but not the one towards the home agent (see figure 3). .in 6 .KS .nf STR, Session-Id = foo STR, Session-Id = bar ---------------------> <-------------------- +----+ +------+ +------+ +----+ | FA | | AAAF | | AAAH | | HA | +----+ +------+ +------+ +----+ <--------------------- ---------------------> STA, Session-Id = foo STA, Session-Id = bar .ce Figure 3: Session Termination and Session Identifiers .fi .KE > Same comment applies to the 3rd par. of page 3. I suspect our page lengths are different because I don't have paragraphs on page 3 (just a table of contents). Could you be more specific? > > 4-Last paragraph of section 1.0, the attendant can also be an HA, when > the MN is in the Home Domain and the HA is co-located. That should apply > to all the document where you refer to the attendant, while having in > parenthesis the FA. ok. I fixed the main document, but section 1.0 is giving me some problems. I currently have: "In this document, the role of the "attendant" [3] is performed by either the home or foreign agent for the Mobile-IP Extension, and these terms will be used interchangeably." > > 5-In section 1.2, page 5, the last paragraph starting with "If the AAAH...", > I think it is a bit confusing here. Here is what I would suggest for the last > few paragraphs of page 5. > > "... > > If the Mobile Node was successfully authenticated, the AAAH checks > if the Home Agent was located in the foreign domain, by checking > the Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. > If it is set to 1, then the Home Agent is located in the foreign > domain then AAAH sends an HAR message to AAAF which contains a > MIP-Reg-Request AVP. > > If the Home Agent was not located in the foreign domain, the AAAH checks > for the MIP-Home-Agent-Address AVP. If one was specified, the AAAH > checks that the address is that of a known Home Agent, and one that > the Mobile Node is allowed to request. If no Home Agent was > specified, and if the MIP-Feature-Vector has the Home-Agent-Requested > flag set, and if allowed by policy in the home domain, the AAAH > SHOULD allocate a home agent on behalf of the Mobile Node. This can > be done in a variety of ways, including using a load balancing > algorithm in order to keep the load on all home agents equal. The > actual algorithm used and the method of discovering the home agents > is outside the scope of this specification. > > The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains the > Mobile IP Registration Request message data encapsulated in the > MIP-Reg-Request AVP, to the assigned or requested Home Agent. The AAAH > MAY allocate a home address for the mobile node, and include it in a > MIP-Mobile-Node-Address AVP within the HAR, or else leave this allocation > responsibility for the Home Agent. > > ..." yup, much better. Thanks. > > 6- Second paragraph of page 6, I'm still wondering why a DIAMETER_ERROR_BAD_HAR > is required? What is it supposed to mean? We do not have this type of generic > error for any other extension, and I don't see why we should have this for MIP. If a Home Agent was requested, and the home agent is not available, then the error is returned. This could occur if the mobile requested a home agent that it is not allowed to, or if the home agent is no longer available. > If the request is rejected, I guess the normal result-code defined in the Base > should be used instead. The comment applies also to section 4.1. But MIP is special since the AAAH forward a message to the diameter client that is requested by the mobile. So if the Diameter client is not accessible, we could either return a non-reachable error, but I would prefer a more specific MIP error. Others? > > 7- Page 8, second par., the thing is that I think that AAAH can determine that > the MN has moved to a new domain by using the Origin-FQDN and the > MIP-Previous-FA-FQDN. However, I'm wondering if the MIP-Previous-FA-FQDN is > enough, since the FQDN is highly dependent on the realm of the MIP-Previous-FA-XXXX, > right? You can only tell that the MN is moving between domain based on the Realms. Correct, so you will have to remove all the data, and the first dot, in the fqdn, and that will produce the realm. Did I miss the question? > > And now, let's say that the HA is located in the former domain, then how can the > AAAF knows that the MN has registered in an other domain? The MIP-Previous-FA-FQDN > can not really help, since it will be in that domain from where it moved. The > AAAF does not have any mean of knowing the originator of the AMR, AFAIK. I guess > that a MIP-Registering-FA-FQDN AVP should be added for that purpose. I really don't understand the problem (sorry, a little dense today), but I see that you believe that a new AVP would be required that contains the identity of the foreign agent, right? And why is that? > > 8-Section 2.1, I think it is not clear exactly when the FA needs to invoke the > AAA infrastructure. I think it would be necessary to mention that it would > be possible for a MN registration to invoke the AAA infrastructure only when > a User-Name, a MIP-Home-Address, a MIP-Home-Agent-Address, a MIP-FA-Challenge > or session keys are requested. Otherwise, the registration would go directly > from the FA to the HA. I believe that the new text that was added following yesterday's call now makes this much clearer. I am waiting for some comments from my co-author, and will release a preview for comments. The base spec is quite clear though that the AAA infrastructure would be contacted when the Authorization-Lifetime has expired. > > The MIP-FA-Challenge AVP Should be added to the table in section 10.1 (0-1). > > Also, I guess that the MN-AAA extension should also be mention in the list of > AVPs. yes. > > 9-Section 2.2, the last sentence of the first paragraph is redundant with the > second one. The second one is much more complete. Also the third par. should instead > read as: > > "The AMA message MUST contain the MIP-FA-to-HA-Key, MIP-FA-to-MN-Key > if they were requested in the AMR. IF they were also sent in the HAR, > the HAA must also include them unchanged." fixed both, thanks. > > 10-The AVP [MIP-MN-to-HA-Key] is listed twice in the message description. > Also, the Original-Session-Id is not listed in the table 10.1 ok, and the Original-Session-Id goes away in the next base, as a result of the conference call. > > 11-Section 3.1, for the DIAMETER_ERROR_AUTH_FAILURE, I guess it should say to > inform the mobility agents (HA (co-located) or the FA). correct. > > 12-Section 5.5 and 5.6, beside the comment #7, I would add that the MN MAY or MUST > include that information? In it is only a MAY, then I guess we should not > count on it for checking if the MN has moved to a new FA, unless it is > specified that it MUST in the case where the MN wants to seemlessly moved > to a new FA. Also, it mentions "under the same administrative domain", which > would not be useful to check if the HA allocated in a previous foreign domain > can still provide service to the MN. Check comment #7 again for that. My parser unfortunately cannot decode comment 7, but I see your point. The issue here, is that a MUST will rule out *any* mobile that doesn't support this yet to be defined AVP (actually, I think it is in the route optimization) I-D, and requiring support of RO would be a mistake. > > 13-Section 5.7, I guess that when the MIP-Mobile-Node-Address and the MIP-Home-Agent- > Address AVPs are not in the message, the AAAF and the AAAH knows that Home-Agent is > requested and that a Mobile-Node-Home-Address is requested. I don't see the need for > those 2 flags. ok, I see your point. The information is redundant. However, I don't really like that a zero HA or home address doesn't require that the AVP be present, since a -1 value DOES require that it be present. Do others agree that these two bits should be removed? > > 14-Page 20, par.3, I don't think it is the correct meaning. My understanding, after > talking with Tony Johansson, is that the Home-Agent-In-Foreign-Network is used when > the MN requests a Home-Agent, and that the AAAF detects that it is located in its > foreign domain, before it forwards the AMR to the AAAH. It now reads: "If the mobile node requests a home agent in the foreign network either by setting the home address field to all ones, or by specifying 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." > > 15-In section 5.8, I am wondering where the MN-AAA authenticator is? The MN-AAA > authentication extension added by the MN does not seem to be included in any > of the AVPs. Am I missing something? You use MIP-Authenticator-Offset to find the MN-AAA authenticator data in the Registration Request, which is found in MIP-Reg-Request. > > 16-Section 6.0, second paragraph, why do you refer to encryption? The thing is that > it is a bit confusing what is required. Do you mean that either the message encryption > is required via the Base protocol, or the AVP encryption is required via the E2E security > extension? In fact, the session keys, in terms of AVPs, destined to the FA and the HA > can NOT be encrypted in the AVP unless the E2E security is used, or the message is completely > encrypted by the Base protocol. correct, I forgot to remove this text. The new text reads: "If the AAAH does not communicate directly with the foreign agent, and it does not wish for intermediate proxies to have access to the session keys, they SHOULD be protected using the end-to-end security extension [9]." > > 17-Section 6.2, 2nd par., should be HAA instead of AHA. Also, the FA should add the > FA-MN-authentication extension to the reg-Reply. correct. > > 18-Section 6.3, the last par. is wrong. It should be the HA that should add the > HA-FA-Authentication extension. correct. > > 19-Section 7.0, 2nd par., the same question about the encryption??? The table should > be in alphabetical order. That whole paragraph can go away, and the table should be in order. Also, the AVP defined in section 7.2 should be added to the > table. What table? I see all AVPs present in the table. > > 20-Section 7.2, the figure should be updated according to the description of the grouped-AVP. correct. > > 21-Section 7.2.1 and 7.2.2, refer to section 7.2 instead of 6.2. ooops > > 22- Section 8.2 and 8.5, should be "by the user" instead of "to the user". Output packets and octets are those sent to the user, not by the user. You are confusing these with the input counters. > > 23-Some updates to the table 10.1 as follows: > > +-----------------------+ > | Command-Code | > |-----+-----+-----+-----+ > Attribute Name | AMR | AMA | HAR | HAA | > ------------------------------|-----+-----+-----+-----+ > Authorization-Lifetime | 0-1 | 1 | 1 | 1 | > Destination-FQDN | 0-1 | 1 | 0-1 | 1 | > Destination-Realm | 1 | 0 | 1 | 0 | > Error-Reporting-FQDN | 0 | 0-1 | 0 | 0-1 | > Auth-Extension-Id | 1 | 1 | 1 | 1 | > Filter-Rule | 0 | 0-1 | 0-1 | 0-1 | No, you can have more than on Filter-Rule AVP. > MIP-FA-to-HA-Key | 0 | 0-1 | 0-1 | 0-1 | > MIP-FA-to-MN-Key | 0 | 0-1 | 0-1 | 0-1 | > MIP-Feature-Vector | 0-1 | 0 | 0 | 0 | > MIP-FA-HA-Preferred-SPI | 0-1 | 0 | 0 | 0 | > MIP-FA-MN-Preferred-SPI | 0-1 | 0 | 0 | 0 | > MIP-HA-to-FA-Key | 0 | 0 | 0-1 | 0 | > MIP-HA-to-MN-Key | 0 | 0-1 | 0-1 | 0 | > MIP-Home-Agent-Address | 0-1 | 0-1 | 0-1 | 0-1 | > MIP-MN-AAA-Auth | 1 | 0 | 0 | 0 | > MIP-MN-to-FA-Key | 0 | 0 | 0-1 | 0 | > MIP-MN-to-HA-Key | 0 | 0-1 | 0-1 | 0 | > MIP-Mobile-Node-Address | 0-1 | 0-1 | 0-1 | 0-1 | > MIP-Previous-FA-Address | 0-1 | 0 | 0 | 0 | > MIP-Previous-FA-FQDN | 0-1 | 0 | 0 | 0 | > MIP-Reg-Reply | 0 | 0-1 | 0 | 0-1 | > MIP-Reg-Request | 1 | 0 | 1 | 0 | > Origin-FQDN | 1 | 1 | 1 | 1 | > Origin-Realm | 1 | 1 | 1 | 1 | > Proxy-Info | 0+ | 0+ | 0+ | 0+ | > Result-Code | 0 | 1 | 0 | 1 | > Route-Record | 0+ | 0+ | 0+ | 0+ | > Session-Id | 1 | 1 | 1 | 1 | > Session-Timeout | 0 | 1 | 1 | 1 | > User-Name | 1 | 0 | 1 | 0 | > ------------------------------|-----+-----+-----+-----| > > 24-Some updates to the tables 10.1 as follows: > > +-----------------------+ > | Command-Code | > |-----+-----+-----+-----+ > Attribute Name | ACR | ACA | API | ASI | > ------------------------------|-----+-----+-----+-----+ > Accounting-Input-Octets | 1 | 0-1 | 0 | 0 | > Accounting-Input-Packets | 1 | 0-1 | 0 | 0 | > Accounting-Output-Octets | 1 | 0-1 | 0 | 0 | > Accounting-Output-Packets | 1 | 0-1 | 0 | 0 | > Accounting-Session-Time | 1 | 0-1 | 0 | 0 | > Accounting-State | 0 | 0 | 1 | 0 | > MIP-Feature-Vector | 1 | 0-1 | 0 | 0 | > MIP-Home-Agent-Address | 1 | 0-1 | 0 | 0 | > MIP-Mobile-Node-Address | 1 | 0-1 | 0 | 0 | > MIP-Previous-FA-Address | 0-1 | 0-1 | 0 | 0 | > MIP-Previous-FA-FQDN | 0-1 | 0-1 | 0 | 0 | > ------------------------------|-----+-----+-----+-----+ > > I don't think the Accounting-State AVP should be here, since it is included in the Base protocol. The ASI and API can be removed, as can that AVP. > Anyway, it should be in the ASI, not the API. Also, I don't understand why the MIP-Feature-Vector > could be useful? Any idea? One could wish to know what services were requested by the user. Home Agent allocation? Home Address allocation? Perhaps it is more expensive to request a home agent in a visited network? Having said this, it is a GREAT reason to leave those two items in the Feature-Vector. > > 25-Section 13.0, the same thing, what does the following really mean? > "The keys are distributed in an encrypted > format through the Diameter protocol, and SHOULD be encrypted using > the methods defined in [9]." That sentence is fixed to: "The keys SHOULD be be protected using the methods defined in [9]." Thanks for the great feedback! PatC From owner-aaa-bof@merit.edu Wed May 9 21:30:56 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00622 for ; Wed, 9 May 2001 21:30:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3370D5E657; Wed, 9 May 2001 20:43:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E877E5E066; Wed, 9 May 2001 19:55:07 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 399245E232 for ; Wed, 9 May 2001 19:10:24 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id TAA26232; Wed, 9 May 2001 19:01:25 -0400 (EDT) Message-Id: <4.1.20010509184516.01777650@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 09 May 2001 18:48:57 -0400 To: Pat Calhoun From: Paul Funk Subject: Re: [AAA-WG]: Recap of our foot fetish thread Cc: Pat Calhoun , Mark Jones , aaa-wg@merit.edu In-Reply-To: <20010509065123.C12425@charizard.diameter.org> References: <4.1.20010509012431.01800910@cairo.funk.com> <20010508173505.W12425@charizard.diameter.org> <4.1.20010509012431.01800910@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, Bug, bug, bug, bug ... Not handling this situation means a capability available in RADIUS will not be available in Diameter. If there's a concern about adding stuff at this point, we should go with my simple fix. Just add a Boot-ID to DRI. The aggregating server can do something with it or not, just as in RADIUS. Paul At 06:51 AM 5/9/01 -0700, Pat Calhoun wrote: >On Wed, May 09, 2001 at 01:30:24AM -0400, Paul Funk wrote: >> Pat, >> >> Summarizing is a good idea. But yes, you have missed a proposal. What >> you characterized as my proposal is actually a combination of mine >> and Mark Jones'. > >[snio] > >I guess now is probably the right time to ask whether this is a bug fix, >or a new feature. The WG agreed in Minn that no new "features" would be >added after the last meeting, but only fixes. > >So, which one is this, bug or feature? > >PatC Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Wed May 9 21:51:51 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01746 for ; Wed, 9 May 2001 21:51:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 47CD25DEA0; Wed, 9 May 2001 21:12:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 073005DE5E; Wed, 9 May 2001 20:25:55 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 8F9BF5DE33 for ; Wed, 9 May 2001 19:43:29 -0400 (EDT) Received: (qmail 31055 invoked by uid 500); 9 May 2001 23:32:57 -0000 Date: Wed, 9 May 2001 16:32:57 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Urgent Diameter Issues still pending Message-ID: <20010509163257.V12425@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, This is just to recap the list of issues that are still pending, which we really need to get some closure on in the next few days. I would like to have the specs out to the WG well before the Interim Meeting this month. As far as memory serves, the following issues are still pending, and I am waiting for comments: 1. Problem with MRI - I proposed a solution to reduce req/answ cmds to only require a single command code, and make use of the EIR bits. This would remove the MRI. 2. Problem with MRI - How do we deal with -Ind messages that cause a failure? Should a new message be created that is used ONLY to respond to bad -Ind messages??? (we could re-use the MRI for this). 3. Boot-Id - People insist that this bug is to be fixed, and three alternatives have been proposed (note that they are not mutually exclusive). I would appreciate some comments on these proposals. Thanks, PatC From owner-aaa-bof@merit.edu Wed May 9 22:13:21 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02020 for ; Wed, 9 May 2001 22:13:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 435475DFB0; Wed, 9 May 2001 21:28:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 451A65DFD1; Wed, 9 May 2001 20:40:14 -0400 (EDT) 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 07A005DFD5 for ; Wed, 9 May 2001 19:53:02 -0400 (EDT) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f49Nr5913563 for ; Wed, 9 May 2001 16:53:05 -0700 (PDT) Received: from cisco.com (mchiba-pc.cisco.com [171.69.71.42]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AAH00057; Wed, 9 May 2001 16:53:00 -0700 (PDT) Message-ID: <3AF9D82F.7020208@cisco.com> Date: Wed, 09 May 2001 16:52:15 -0700 From: "M. S. Chiba" User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; 0.7) Gecko/20010316 X-Accept-Language: en MIME-Version: 1.0 Cc: aaa-wg Subject: Re: [AAA-WG]: separated authorization and accounting servers 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 So what is the final outcome of this discussion? Thanks, Murtaza Patrice Calhoun wrote: >> Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes: >> >> >>>> I do agree with a separate point Jari makes in a later message, >>> >>> there will >>> >>>> be people that will want to implement Accounting for accounting's sake, >>>> independent of the Auth/Auth stream. Perhaps we need to call >>> >>> out that as >>> >>>> a different "application". >>>> >>> >>> Why does this sound like I'll be spliting the base back into two >>> documents... >>> :( >> >> Changing the format of the documents doesn't solve the problem. > > > When accounting was separate, it had its own extension. When an accounting > message was en-route towards the home domain, a specific accounting server > could advertise itself in the home network, and we could guarantee that all > accounting messages would be sent to that particular server. > > As it stands right now, accounting messages would be sent to *any* server in > the home domain, unless the proxies were (manually) configured for a specific > Accounting server, which is how RADIUS works today. > > Perhaps this is enough. > > PatC From owner-aaa-bof@merit.edu Wed May 9 23:59:00 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04472 for ; Wed, 9 May 2001 23:58:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 89D375DF58; Wed, 9 May 2001 23:56:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 91D775DEFE; Wed, 9 May 2001 23:39:28 -0400 (EDT) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id AB3CB5E134 for ; Wed, 9 May 2001 22:48:13 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id WAA32683; Wed, 9 May 2001 22:42:22 -0400 Received: from preston (cisconas248.bridgewatersys.com [192.168.150.248]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id WAA25594; Wed, 9 May 2001 22:49:03 -0400 (EDT) From: "Mark Jones" To: "Paul Funk" , "Pat Calhoun" , Subject: RE: [AAA-WG]: Recap of our foot fetish thread Date: Wed, 9 May 2001 22:51:01 -0400 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; boundary="----=_NextPart_000_0007_01C0D8D8.E9BA2540"; protocol="application/x-pkcs7-signature"; micalg=SHA1 In-Reply-To: <4.1.20010509012431.01800910@cairo.funk.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C0D8D8.E9BA2540 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks for the summary, Paul. > Both Paul's and Mark's proposals required that the aggregating server keep > session state for non-local sessions in order to clean them up. My proposal does not require the aggregating server keep session state in order to clean up the non-local sessions. It could use the less elegant but equally effective method of sending the Proxied-DRI to next hop servers regardless of whether the rebooted NAS was hosting their sessions. However, your colleague Ammo did bring up a valid point in that post-reboot session requests may arrive at a home server before the Proxied-DRI and so get cleaned up in error. I considered requiring the aggregating server to wait until the Proxied-DRI had been acknowledged by the home server(s) before sending its own DRI back to the NAS but the delay would be unacceptable for long proxy chains. I also rejected the solutions using timestamps since they require tight time synchronization between the aggregating server and home server(s). Admittedly this same issue exists in RADIUS today with Acct-On/Off but I don't want to propagate it to Diameter. I am not overly enthusiastic about a mechanism which requires that the aggregating server keep session state for non-local sessions in order to clean them up. Keeping accurate session state despite failover is non-trivial so we need to be careful about introducing mechanisms which mandate it. We may end up requiring a routing proxy server to keep session state purely for the sake of handling reboot events. My objection to Pat's proposal was it required the addition of a new Boot-Id AVP in every session request but it appears reliable and is simple to implement. Would it be possible to include the boot identifier in the Session-Id AVP format? This would also ensure that the Session-Id AVP is globally unique over time rather than relying on the random value assigned to the 'monotonically increasing 32-bit value' on reboot. The Session-Id AVP format remains a SHOULD so those manufacturing devices that reboot frequently can avoid using it ;) Regards, Mark ------=_NextPart_000_0007_01C0D8D8.E9BA2540 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFxTCCApQw ggH9oAMCAQICAwS4ODANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDUwMTE4MTgwOFoXDTAyMDUwMTE4MTgwOFowTzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdbWpvbmVzQGJyaWRnZXdhdGVyc3lzdGVt cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMemr5diJO/8+r2Hj3Opr9LbaVAXFgo2 Fhu0tfSSdvlMy52Y67GMoJbv0I282FWO9z4bsnuSIU7y3arEmyA78mwjTSdt2GK5QJHT6jKOqF6M 81Q5j2fU3dQwCPiCQZlOqUJEA3PySRjUQNOgnRUhoSuzGd7IMJ3Y6oeMtE8a02nTAgMBAAGjOjA4 MCgGA1UdEQQhMB+BHW1qb25lc0BicmlkZ2V3YXRlcnN5c3RlbXMuY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEANyubKv2ajV9VxVe4xUDaqZbQ2DEXgGKSFWwsdC06zUucuCmeHHqT vLcoUnI8/dCbSnSwRrELpemSoqTv/99uW+jS6cN5320w1ZEBsC2RSVrSJd8LqxKALmMexgbywYvF /hMe120ctocvwnfbeZmzBIKSF7BDs8YPGzSWgsa5gKUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2 17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gxggKOMIICigIB ATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgw JgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMEuDgwCQYFKw4DAhoFAKCC AUkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwNTEwMDIzOTMx WjAjBgkqhkiG9w0BCQQxFgQUJSMSji16HLEl/a1khRXRgzILrKQwPAYJKoZIhvcNAQkPMS8wLTAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqwYJKwYBBAGCNxAE MYGdMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMx KDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwS4ODANBgkqhkiG9w0B AQEFAASBgE5SxmTPqZq1ymMa0WTfvkKwXPAgR9H4cNFHg5VGTfkuk1ZMQcYAaUzX6j8RHUpJOM5x K21OmpuIs1dAn2ymX+GaOt+200yCbb8y/sooy4Fn24XnR6DV6R+NE6RzVmE68Xn2dmzniN7c0N32 1jcNyJB+xwkqZRrvjlviriH8FwgrAAAAAAAA ------=_NextPart_000_0007_01C0D8D8.E9BA2540-- From owner-aaa-bof@merit.edu Thu May 10 01:44:07 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09997 for ; Thu, 10 May 2001 01:44:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 374AD5DD9E; Thu, 10 May 2001 01:43:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E9D805DD9C; Thu, 10 May 2001 01:43:48 -0400 (EDT) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id E4D7E5DF07 for ; Thu, 10 May 2001 01:43:42 -0400 (EDT) Received: from gwzpc (shinjuku-equant-dynamic60.cisco.com [64.104.42.60]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id WAA03458; Wed, 9 May 2001 22:43:12 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "David Frascone" , , Subject: RE: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft Date: Wed, 9 May 2001 22:43:09 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20010503122735.C16328@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: > I agree. Ditto. > > On Thu, May 03, 2001 at 10:01:10AM -0700, Pat Calhoun wrote: > > On Thu, May 03, 2001 at 10:02:11AM -0700, James Kempf wrote: > > > > > > > > > > >Did you have a spec in mind for your DTD? Base/API? > > > > > > > > > > If the working group agrees, we could put it into the API draft as > > > the basis for the command/AVP dictionary format, like we had the > > > previous one. > > > > I would prefer that the dictionary be its own separate > informational RFC. It > > is independent of the API. > > > > PatC > > > > From owner-aaa-bof@merit.edu Thu May 10 01:44:42 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10085 for ; Thu, 10 May 2001 01:44:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 10E265DDD9; Thu, 10 May 2001 01:44:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E4B465DDD1; Thu, 10 May 2001 01:44:14 -0400 (EDT) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 760555DDB9 for ; Thu, 10 May 2001 01:44:10 -0400 (EDT) Received: from gwzpc (shinjuku-equant-dynamic60.cisco.com [64.104.42.60]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id WAA03373; Wed, 9 May 2001 22:43:05 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "David Frascone" , "Pat Calhoun" Cc: Subject: RE: [AAA-WG]: transport MUSTs Date: Wed, 9 May 2001 22:43:04 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20010503114121.A16328@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: > On Thu, May 03, 2001 at 08:42:41AM -0700, Pat Calhoun wrote: > > How does the following sound? > > > > " The base Diameter protocol is run on port TBD of both TCP [27] and > > SCTP [26] transport protocols (for interoperability test purposes > > port 1812 will be used until April 2001). Hmm. Seems like it's May 2001 currently; does that mean no more testing until the real numbers are assigned? Probably not ;-). So how about " The base Diameter protocol is run on port TBD of both TCP [27] and SCTP [26] transport protocols (for interoperability test purposes port 1812 will be used until the official numbers are assigned). " > > Diameter clients SHOULD > > support SCTP, but MUST support TCP if SCTP is not available. future > > versions of this specification may mandate that clients support SCTP. > > Diameter servers MUST support both TCP and SCTP." > > > > Works for me. > > From owner-aaa-bof@merit.edu Thu May 10 02:15:35 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19861 for ; Thu, 10 May 2001 02:15:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B69E35DF88; Wed, 9 May 2001 23:56:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9333E5E002; Wed, 9 May 2001 23:39:31 -0400 (EDT) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 013995E139 for ; Wed, 9 May 2001 22:48:20 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id WAA32687; Wed, 9 May 2001 22:42:25 -0400 Received: from preston (cisconas248.bridgewatersys.com [192.168.150.248]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id WAA25597; Wed, 9 May 2001 22:49:06 -0400 (EDT) From: "Mark Jones" To: "Pat Calhoun" , "Paul Funk" Cc: Subject: RE: [AAA-WG]: Recap of our foot fetish thread Date: Wed, 9 May 2001 22:51:03 -0400 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; boundary="----=_NextPart_000_000B_01C0D8DA.82307DA0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 In-Reply-To: <20010509065123.C12425@charizard.diameter.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C0D8DA.82307DA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Pat, > I guess now is probably the right time to ask whether this is a bug fix, > or a new feature. The WG agreed in Minn that no new "features" would be > added after the last meeting, but only fixes. > > So, which one is this, bug or feature? I think it is a bug that the DRI is missing an AVP which indicates the reason for the capabilities exchange (with device reboot being one of the reasons). I think we should address this bug even if the WG does not reach consensus on the foot fetish proposals. Regards, Mark ------=_NextPart_000_000B_01C0D8DA.82307DA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFxTCCApQw ggH9oAMCAQICAwS4ODANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDUwMTE4MTgwOFoXDTAyMDUwMTE4MTgwOFowTzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdbWpvbmVzQGJyaWRnZXdhdGVyc3lzdGVt cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMemr5diJO/8+r2Hj3Opr9LbaVAXFgo2 Fhu0tfSSdvlMy52Y67GMoJbv0I282FWO9z4bsnuSIU7y3arEmyA78mwjTSdt2GK5QJHT6jKOqF6M 81Q5j2fU3dQwCPiCQZlOqUJEA3PySRjUQNOgnRUhoSuzGd7IMJ3Y6oeMtE8a02nTAgMBAAGjOjA4 MCgGA1UdEQQhMB+BHW1qb25lc0BicmlkZ2V3YXRlcnN5c3RlbXMuY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEANyubKv2ajV9VxVe4xUDaqZbQ2DEXgGKSFWwsdC06zUucuCmeHHqT vLcoUnI8/dCbSnSwRrELpemSoqTv/99uW+jS6cN5320w1ZEBsC2RSVrSJd8LqxKALmMexgbywYvF /hMe120ctocvwnfbeZmzBIKSF7BDs8YPGzSWgsa5gKUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2 17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gxggKOMIICigIB ATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgw JgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMEuDgwCQYFKw4DAhoFAKCC AUkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwNTEwMDI1MDU2 WjAjBgkqhkiG9w0BCQQxFgQU1rPXG/IN1CYGYBQHaVZBMx+wh6swPAYJKoZIhvcNAQkPMS8wLTAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqwYJKwYBBAGCNxAE MYGdMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMx KDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwS4ODANBgkqhkiG9w0B AQEFAASBgFltW5riQ5c7Md6n/rUgeBh5iFBKjsNeKnwokNkgMbpQNjtvM+GjD+bJw9bJ7Sl3Z+rf OXpmHPLI30jg0yCwrNngKsxScDCe/MJYigC+siICxJyAWrFpGPiW2IABQfbihdTexDZPdFNiF9xG Ir0mw1wHXM2J1VvQM695ftaL+rimAAAAAAAA ------=_NextPart_000_000B_01C0D8DA.82307DA0-- From owner-aaa-bof@merit.edu Thu May 10 05:37:42 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21653 for ; Thu, 10 May 2001 05:37:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 16D915DD91; Thu, 10 May 2001 05:34:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F1A065DDA8; Thu, 10 May 2001 05:34:09 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id D787A5DD91 for ; Thu, 10 May 2001 05:34:03 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA18303 for ; Thu, 10 May 2001 01:34:54 -0700 (PDT) Received: from vayne (muc-isdn-11 [129.157.164.111]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id KAA14380 for ; Thu, 10 May 2001 10:34:52 +0200 (MET DST) Date: Thu, 10 May 2001 10:46:25 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: [AAA-WG]: List data type discussion To: aaa-wg@merit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Under discussion, still not finally resolved is whether we should have a base 'List' data type, which would essentially allow 'N' identical items to follow. We have no concrete examples of where this would be useful. There are issues with the List data type: (1) Length ambiguity In this case of a List of 'N' Integer32 values, an AVP length would be the following # of bytes: 8 [+ 4 (if 'V'endor ID included) ] + 4 * N By observing the AVP length (and whether the 'V' bit is set), the receiver can calculate how many Integer32 values follow. This would allow the efficient encoding of the data [Header] [Int32-0]...[Int32-(N-1)] In the case of data types OctetString, Address, Group and List it will not be possible to determine how many data items follow simply by observing the AVP length field. To make it possible to parse individual items in the list, we need to separate them into individual units of {Length,Data} or perhaps better yet {AVP header,Data}. (2) Why use a List AVP at all? But if we are going to do that, what is the use of the List data type? Where do we gain by having, say, ::= { Origin-Host-List } Origin-Host-List AVP = 1* Origin-Host AVP Origin-Host AVP has type Address which leads to the encoding of: [Origin-Host-List AVP header] [Origin-Host AVP Header 0] Address 0 ... [Origin-Host AVP Header N-1] Address N-1 instead of just having 0 or more Origin-Host AVPs in the message: ::= 1* { Origin-Host } Using the same definition of Origin host as above, Origin-Host AVP has type Address This leads to the encoding: [Origin-Host AVP Header 0] Address 0 ... [Origin-Host AVP Header N-1] Address N-1 Which is exactly what we had before, but there is no 'wrapping' List AVP. What we gain here is that there is a definite group - one will be able to transmit a 'column' of data, like a SMIv2 'SEQUENCE OF', a facility our grammar currently lacks. The question remains - do we need List? Let's try to reach final working group concensus on this now. If in favor of the proposal, please send concrete examples of why it is needed. Thanks, Erik From owner-aaa-bof@merit.edu Thu May 10 07:01:47 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22491 for ; Thu, 10 May 2001 07:01:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1AD6D5DDF5; Thu, 10 May 2001 06:18:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 093D95DDF2; Thu, 10 May 2001 06:18:24 -0400 (EDT) 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 EE8235DDEF for ; Thu, 10 May 2001 06:18:21 -0400 (EDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f4AAIKO11265 for ; Thu, 10 May 2001 12:18:20 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu May 10 12:18:19 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 10 May 2001 12:18:18 +0200 Message-ID: <577066326047D41180AC00508B955DDA01D7FFDB@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'M. S. Chiba'" Cc: aaa-wg Subject: RE: [AAA-WG]: separated authorization and accounting servers Date: Thu, 10 May 2001 12:17:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk You should refer to the thread "A resolution to the Accounting problem". Martin > -----Original Message----- > From: M. S. Chiba [mailto:mchiba@cisco.com] > Sent: Thursday, May 10, 2001 1:52 AM > Cc: aaa-wg > Subject: Re: [AAA-WG]: separated authorization and accounting servers > > > > So what is the final outcome of this discussion? > > > Thanks, > Murtaza > > Patrice Calhoun wrote: > > >> Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes: > >> > >> > >>>> I do agree with a separate point Jari makes in a later message, > >>> > >>> there will > >>> > >>>> be people that will want to implement Accounting for > accounting's sake, > >>>> independent of the Auth/Auth stream. Perhaps we need to call > >>> > >>> out that as > >>> > >>>> a different "application". > >>>> > >>> > >>> Why does this sound like I'll be spliting the base back into two > >>> documents... > >>> :( > >> > >> Changing the format of the documents doesn't solve the problem. > > > > > > When accounting was separate, it had its own extension. > When an accounting > > message was en-route towards the home domain, a specific > accounting server > > could advertise itself in the home network, and we could > guarantee that all > > accounting messages would be sent to that particular server. > > > > As it stands right now, accounting messages would be sent > to *any* server in > > the home domain, unless the proxies were (manually) > configured for a specific > > Accounting server, which is how RADIUS works today. > > > > Perhaps this is enough. > > > > PatC > > > From owner-aaa-bof@merit.edu Thu May 10 10:20:00 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28014 for ; Thu, 10 May 2001 10:19:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E51705DE1A; Thu, 10 May 2001 10:18:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D4ACB5DE16; Thu, 10 May 2001 10:18:02 -0400 (EDT) Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 535B05DE14 for ; Thu, 10 May 2001 10:18:01 -0400 (EDT) Received: (qmail 22058 invoked by uid 500); 10 May 2001 14:24:49 -0000 Date: Thu, 10 May 2001 09:24:49 -0500 From: David Frascone To: Erik Guttman Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: List data type discussion Message-ID: <20010510092448.K5143@newman.frascone.com> Mail-Followup-To: Erik Guttman , 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 Erik.Guttman@Sun.COM on Thu, May 10, 2001 at 10:46:25AM +0200 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk Actually, I don't remember hearing a compeling argument on why Grouped AVP definitions had to be static. I did notice several people who thought they should be left open, like the Diameter message itself. Did my delete finger just go crazy, or did no one really want statically defined group AVPs? -Dave On Thu, May 10, 2001 at 10:46:25AM +0200, Erik Guttman wrote: > > Under discussion, still not finally resolved is whether we should have > a base 'List' data type, which would essentially allow 'N' identical > items to follow. We have no concrete examples of where this would be > useful. > > There are issues with the List data type: > > (1) Length ambiguity > > In this case of a List of 'N' Integer32 values, an AVP length would > be the following # of bytes: > > 8 [+ 4 (if 'V'endor ID included) ] + 4 * N > > By observing the AVP length (and whether the 'V' bit is set), the > receiver can calculate how many Integer32 values follow. This would > allow the efficient encoding of the data > > [Header] [Int32-0]...[Int32-(N-1)] > > In the case of data types OctetString, Address, Group and List > it will not be possible to determine how many data items follow > simply by observing the AVP length field. To make it possible to > parse individual items in the list, we need to separate them into > individual units of {Length,Data} or perhaps better yet > {AVP header,Data}. > > > (2) Why use a List AVP at all? > > But if we are going to do that, what is the use of the List data > type? Where do we gain by having, say, > > ::= > { Origin-Host-List } > > Origin-Host-List AVP = 1* Origin-Host AVP > Origin-Host AVP has type Address > > which leads to the encoding of: > > [Origin-Host-List AVP header] > [Origin-Host AVP Header 0] > Address 0 > ... > [Origin-Host AVP Header N-1] > Address N-1 > > instead of just having 0 or more Origin-Host AVPs in the message: > > ::= > 1* { Origin-Host } > > > Using the same definition of Origin host as above, > > Origin-Host AVP has type Address > > This leads to the encoding: > > [Origin-Host AVP Header 0] > Address 0 > ... > [Origin-Host AVP Header N-1] > Address N-1 > > Which is exactly what we had before, but there is no 'wrapping' > List AVP. > > What we gain here is that there is a definite group - one will > be able to transmit a 'column' of data, like a SMIv2 'SEQUENCE OF', > a facility our grammar currently lacks. > > The question remains - do we need List? Let's try to reach final > working group concensus on this now. If in favor of the proposal, > please send concrete examples of why it is needed. > > Thanks, > > Erik > > From owner-aaa-bof@merit.edu Thu May 10 10:20:14 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28036 for ; Thu, 10 May 2001 10:20:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8355A5DE16; Thu, 10 May 2001 10:19:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 71DB15DE24; Thu, 10 May 2001 10:19:48 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id F1CAD5DE16 for ; Thu, 10 May 2001 10:19:46 -0400 (EDT) Received: (qmail 3240 invoked by uid 500); 10 May 2001 14:09:13 -0000 Date: Thu, 10 May 2001 07:09:13 -0700 From: Pat Calhoun To: Glen Zorn Cc: David Frascone , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: transport MUSTs Message-ID: <20010510070913.B12425@charizard.diameter.org> Mail-Followup-To: Glen Zorn , David Frascone , Pat Calhoun , aaa-wg@merit.edu References: <20010503114121.A16328@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 gwz@cisco.com on Wed, May 09, 2001 at 10:43:04PM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, May 09, 2001 at 10:43:04PM -0700, Glen Zorn wrote: > David Frascone [mailto:dave@frascone.com] writes: > > > On Thu, May 03, 2001 at 08:42:41AM -0700, Pat Calhoun wrote: > > > How does the following sound? > > > > > > " The base Diameter protocol is run on port TBD of both TCP [27] and > > > SCTP [26] transport protocols (for interoperability test purposes > > > port 1812 will be used until April 2001). > > Hmm. Seems like it's May 2001 currently; does that mean no more testing > until the real numbers are assigned? Probably not ;-). So how about > > " The base Diameter protocol is run on port TBD of both TCP [27] and > SCTP [26] transport protocols (for interoperability test purposes > port 1812 will be used until the official numbers are assigned). " A little behind in our e-mail :) The following text is currently in version -03: "The base Diameter protocol is run on port TBD of both TCP [27] and SCTP [26] transport protocols (for interoperability test purposes port 1812 will be used until IANA assigns a port to the protocol)." Thanks, PatC From owner-aaa-bof@merit.edu Thu May 10 10:24:02 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28149 for ; Thu, 10 May 2001 10:23:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9B5C85DDB1; Thu, 10 May 2001 10:23:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8655F5DDC2; Thu, 10 May 2001 10:23:20 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 04F675DDB1 for ; Thu, 10 May 2001 10:23:19 -0400 (EDT) Received: (qmail 3278 invoked by uid 500); 10 May 2001 14:12:45 -0000 Date: Thu, 10 May 2001 07:12:45 -0700 From: Pat Calhoun To: Mark Jones Cc: Paul Funk , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Recap of our foot fetish thread Message-ID: <20010510071245.C12425@charizard.diameter.org> Mail-Followup-To: Mark Jones , Paul Funk , Pat Calhoun , aaa-wg@merit.edu References: <4.1.20010509012431.01800910@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjones@bridgewatersystems.com on Wed, May 09, 2001 at 10:51:01PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, May 09, 2001 at 10:51:01PM -0400, Mark Jones wrote: > I am not overly enthusiastic about a mechanism which requires that the > aggregating server keep session state for non-local sessions in order to > clean them up. Keeping accurate session state despite failover is > non-trivial so we need to be careful about introducing mechanisms which > mandate it. agreed. > My objection to Pat's proposal was it required the addition of a new > Boot-Id AVP in every session request but it appears reliable and is simple > to implement. Would it be possible to include the boot identifier in the > Session-Id AVP format? This would also ensure that the Session-Id AVP is > globally unique over time rather than relying on the random value assigned > to the 'monotonically increasing 32-bit value' on reboot. The Session-Id > AVP format remains a SHOULD so those manufacturing devices that reboot > frequently can avoid using it ;) I'd prefer to NOT include the Boot-Id in the Session-Id. When my implementation receives a packet, it must perform a lookup based on the Session-id, and making that string longer than it currently is will only hurt performance. I'd rather have the Boot-Id as a separate, and well defined, AVP Thanks, PatC From owner-aaa-bof@merit.edu Thu May 10 11:33:28 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00688 for ; Thu, 10 May 2001 11:33:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EC6745DDF6; Thu, 10 May 2001 11:33:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D85835DDF2; Thu, 10 May 2001 11:33:05 -0400 (EDT) Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id BF7795DDF1 for ; Thu, 10 May 2001 11:33:03 -0400 (EDT) Received: from fredrikj (c35.local.ipunplugged.com [192.168.4.234]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA08693 for ; Thu, 10 May 2001 17:33:52 +0200 From: "Fredrik Johansson" To: "AAA Listan" Subject: [AAA-WG]: Comments on Base v.3 Date: Thu, 10 May 2001 17:34:48 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Here are some comments on the base protocol draft. Some of them have probably already been brought up in other threads. 1.3 Terminology Is the definition of Upstream and Downstream server switched? Should it be Downstream Diameter Proxy Servers identify a downstream server as one that is providing routing service towards the node where the message originated. Upstream Diameter Proxy Servers identify a upstream server as one that is providing routing service away from the node where the message originated. 2.0 Protocol Overview The reference to Strong Security should be End-to-End Security 4.4 Grouped AVP Values What about Paul's idea of being able to define optional AVPs in a grouped AVP? 6.0 Capability Negotiation How can you tell what extensions from a specific vendor you support. As I understand it the Supported-Vendor-Id AVP only tells you the IANA assigned number for that vendor, not what extensions from that vendor that is supported. Perhaps there should be a grouped AVP Supported-Vendor-Extensions which containing the Vendor-Id AVP and a Vendor-Extension-Id AVP that contains the Vendor specific Extension Id taken from that vendors private Extension Id space. 8.0 Peer State Machine I have not implemented the new state machine, but from the looks of it it seems complicated. Why not use a simple backoff instead of an election when a raise condition occurs. I.e. when the nodes discover the raise condition, they both disconnect and tries again after a short period of time. Sure it may take some extra time to set up the connection, but the gain by having a simpler state machine seems worth it. The backoff time does not have to be so long, RTT + some random number of msec. 10.1.3 Offending-Command-Code AVP should this realy be under MRI, an unknown command should result in an DSI according to the table in section 10 11.1 Authorization Session State Machine Open Authorization-Lifetime expires send serv. Open specific auth req How can a client send a server specific auth request? In the case of MIP does it not need to receive a MIP Reg Req? If it has not received a req from the Mip MN to update the tunnel I believe it should send a STR. Thus it should be Open Authorization-Lifetime expires send STR Discon 11.2 Accounting Session State Machine is the following state missing? Open receive Interim Record send Ack Open 16.1 Base Protocol Command AVP Table the Accounting Extension Id AVP is missing I still don't like that a Vendor Specific AVP can't be mandatory. An example. Say that I would like to distribute some configuration data to the FA in an AMA and that I require it to understand the format. If it does not understand the format I would like it to reject the session. How can I do this without setting the Mandatory bit in the AVP? And what about a company having a vendor specific extension. If the company has two sites they can not comunicate with each other since the operator that will proxy the message does not understand the extension. What I'm trying to say is that a proxy should not care about the message unless it is handled localy. Or can you advertise wildcard without supporting it locally? /Fredrik From owner-aaa-bof@merit.edu Thu May 10 12:09:13 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01638 for ; Thu, 10 May 2001 12:09:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 86C775DDC2; Thu, 10 May 2001 12:08:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 697CF5DDBC; Thu, 10 May 2001 12:08:57 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 817F25DDC2 for ; Thu, 10 May 2001 12:08:55 -0400 (EDT) Received: (qmail 3764 invoked by uid 500); 10 May 2001 15:58:21 -0000 Date: Thu, 10 May 2001 08:58:21 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Urgent Diameter Issues still pending Message-ID: <20010510085821.M12425@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu References: <20010509163257.V12425@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010509163257.V12425@charizard.diameter.org>; from pcalhoun@diameter.org on Wed, May 09, 2001 at 04:32:57PM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk It has occured to me that there is another proposal that I have forgotten. 4. Elimination of the STI. There was a proposal that the STI would be eliminated, and a new command code set would be created that would allow a server to initiate a session termination on the access device. Again, I am waiting for WG comments. I do not feel comfortable making blind changes without *any* feedback. PatC On Wed, May 09, 2001 at 04:32:57PM -0700, Pat Calhoun wrote: > All, > > This is just to recap the list of issues that are still pending, > which we really need to get some closure on in the next few days. I > would like to have the specs out to the WG well before the Interim > Meeting this month. > > As far as memory serves, the following issues are still pending, and > I am waiting for comments: > 1. Problem with MRI - I proposed a solution to reduce req/answ cmds > to only require a single command code, and make use of the EIR bits. > This would remove the MRI. > 2. Problem with MRI - How do we deal with -Ind messages that cause a > failure? Should a new message be created that is used ONLY to respond > to bad -Ind messages??? (we could re-use the MRI for this). > 3. Boot-Id - People insist that this bug is to be fixed, and three > alternatives have been proposed (note that they are not mutually > exclusive). > > I would appreciate some comments on these proposals. > > Thanks, > > PatC > From owner-aaa-bof@merit.edu Thu May 10 12:41:07 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02713 for ; Thu, 10 May 2001 12:41:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F35D15DE5F; Thu, 10 May 2001 12:40:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D76375DDF2; Thu, 10 May 2001 12:40:37 -0400 (EDT) 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 A7DB55DE5F for ; Thu, 10 May 2001 12:40:35 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f4AGeYN05255 for ; Thu, 10 May 2001 18:40:34 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Thu May 10 18:40:34 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 10 May 2001 18:40:33 +0200 Message-ID: <3DFC2DB418B2D211A1950008C7A4E1EA0D042FBC@eestqnt102> From: "Victor Manuel Avila Gonzalez (ECE)" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Sessionless dialogue Date: Thu, 10 May 2001 18:40:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA02713 Following some discussions I would like to clarify this matter Only as I hypothesis, May I define a Diameter extension to do something that has nothing to do with authentication/authorization or accounting, e.g. to query a database? If that were possible, it would be unnecessary to have a session because the server would not be authorizing anything for a period of time. In other words, may I establish a dialogue between two peers without following the user session state machine? Regards, Victor e Víctor M. Avila Systems Engineer UMTS/GSM Systems Management Ericsson España, S.A. Phone: +34 91 339 3050 Ombú, 3 Fax: +34 91 339 2538 28045 Madrid, Spain e-mail: victor-manuel.avila-gonzalez@ece.ericsson.se From owner-aaa-bof@merit.edu Thu May 10 12:47:19 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02941 for ; Thu, 10 May 2001 12:47:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D1A85DDEA; Thu, 10 May 2001 12:03:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4E8485DE03; Thu, 10 May 2001 12:03:02 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 8C5545DDEA for ; Thu, 10 May 2001 12:03:00 -0400 (EDT) Received: (qmail 3725 invoked by uid 500); 10 May 2001 15:52:26 -0000 Date: Thu, 10 May 2001 08:52:26 -0700 From: Pat Calhoun To: Fredrik Johansson Cc: AAA Listan Subject: Re: [AAA-WG]: Comments on Base v.3 Message-ID: <20010510085226.K12425@charizard.diameter.org> Mail-Followup-To: Fredrik Johansson , AAA Listan 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 fredrik.johansson@ipunplugged.com on Thu, May 10, 2001 at 05:34:48PM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, May 10, 2001 at 05:34:48PM +0200, Fredrik Johansson wrote: > Hi > > Here are some comments on the base protocol draft. Some of them > have probably already been brought up in other threads. > > 1.3 Terminology > > Is the definition of Upstream and Downstream server switched? > > Should it be > Downstream > Diameter Proxy Servers identify a downstream server as one that > is providing routing service towards the node where the message > originated. > > Upstream > Diameter Proxy Servers identify a upstream server as one that > is providing routing service away from the node where the > message originated. yup, I cut and paste too hastily :( > > 2.0 Protocol Overview > The reference to Strong Security should be End-to-End Security yes, and there were a few other places too :( > > 4.4 Grouped AVP Values > What about Paul's idea of being able to define optional AVPs > in a grouped AVP? I am waiting for WG concensus. I think that the chairs need to step in to help us out. I have two people that have asked for this, Erik has opposed it. That's not exactly what I would call concensus, so Bernard and Dave need to intervene, and help us out. > > 6.0 Capability Negotiation > > How can you tell what extensions from a specific vendor you support. > As I understand it the Supported-Vendor-Id AVP only tells you the > IANA assigned number for that vendor, not what extensions from that > vendor that is supported. Perhaps there should be a grouped AVP > Supported-Vendor-Extensions which containing the > Vendor-Id AVP and a Vendor-Extension-Id AVP > that contains the Vendor specific Extension Id taken from that vendors > private Extension Id space. We agreed, and section 2.3/4 states, that Extension Ids are not vendor specific. If a vendor needs an extension identifier, it is taken from the extension identifier namespace. > > 8.0 Peer State Machine > I have not implemented the new state machine, but from the looks > of it it seems complicated. Why not use a simple backoff instead > of an election when a raise condition occurs. I.e. when the nodes > discover the raise condition, they both disconnect and tries again > after a short period of time. Sure it may take some extra time to > set up the connection, but the gain by having a simpler state machine > seems worth it. The backoff time does not have to be so long, RTT + some > random number of msec. Because we need something that reliably works. Back-off will simply delay the connection process, and the peers could select a random number that is close enough to each other that the back-off process occurs again. I've implemented it, and it really isn't that bad at all. > > 10.1.3 Offending-Command-Code AVP > should this realy be under MRI, an unknown command should result > in an DSI according to the table in section 10 Right. I am still waiting to get some concensus on the elimination of the MRI proposal, and if we do, then the error handling sections will be consolidated. I prefer to wait until I know what's happening to the MRI before I make more temporary changes :) > > 11.1 Authorization Session State Machine > > Open Authorization-Lifetime expires send serv. Open > specific > auth req > > How can a client send a server specific auth request? In the case of MIP > does it not need to receive a MIP Reg Req? If it has not received a req > from the Mip MN to update the tunnel I believe it should send a STR. Thus > it should be serv = service. Let me clear that up. > > Open Authorization-Lifetime expires send STR Discon This would be on the server side, and this action already exists in the FSM. > > > 11.2 Accounting Session State Machine > is the following state missing? > > Open receive Interim Record send Ack Open yes it was missing. > > 16.1 Base Protocol Command AVP Table > the Accounting Extension Id AVP is missing right, and the entry was incorrect. It is now: DRI Acct-Extension-Id |0+ |0 |0 |0 |0 |0 |0 |0 | Auth-Extension-Id |0+ |0 |0 |0 |0 |0 |0 |0 | > > > > I still don't like that a Vendor Specific AVP can't be mandatory. An > example. Say that I would like to distribute some configuration data to the > FA in an AMA and that I require it to understand the format. If it does not > understand the format I would like it to reject the session. How can I do > this without setting the Mandatory bit in the AVP? The IESG is very concerned about interoperability, or lack thereof, when vendors start adding vendor-specific AVPs with the 'M' bit set. I will let them defend their position. > And what about a company having a vendor specific extension. If the company > has two sites they can not comunicate with each other since the operator > that will proxy the message does not understand the extension. What I'm > trying to say is that a proxy should not care about the message unless it is > handled localy. Or can you advertise wildcard without supporting it locally? Let's assume extention x is proprietary, * is wildcard, and FOO is the vendor specific command: A P B --- DRI ext=x ---> <--- DRI ext=x --- <-- DRI ext=* --- --- DRI ext=* ---> --- FOO ext=x ---> --- FOO ext=x ---> That would work just fine. Thanks, PatC From owner-aaa-bof@merit.edu Thu May 10 13:01:24 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03416 for ; Thu, 10 May 2001 13:01:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 24B8A5DDAA; Thu, 10 May 2001 09:06:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0E7FF5DDAB; Thu, 10 May 2001 09:06:40 -0400 (EDT) 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 EFE035DDAA for ; Thu, 10 May 2001 09:06:37 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f4AD6aN13353 for ; Thu, 10 May 2001 15:06:36 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Thu May 10 15:06:36 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 10 May 2001 15:06:35 +0200 Message-ID: <577066326047D41180AC00508B955DDA01D7FFDE@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Comments on draft-mobileip-03 Date: Thu, 10 May 2001 15:06:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk My comments enclosed. > > 4-Last paragraph of section 1.0, the attendant can also be > an HA, when > > the MN is in the Home Domain and the HA is co-located. That > should apply > > to all the document where you refer to the attendant, while > having in > > parenthesis the FA. > > ok. I fixed the main document, but section 1.0 is giving me > some problems. > I currently have: > > "In this document, the role of the "attendant" [3] is > performed by either > the home or foreign agent for the Mobile-IP Extension, and these terms > will be used interchangeably." You could specifying that it is valid only for the HA which is acting as co-located. > > 6- Second paragraph of page 6, I'm still wondering why a > DIAMETER_ERROR_BAD_HAR > > is required? What is it supposed to mean? We do not have > this type of generic > > error for any other extension, and I don't see why we > should have this for MIP. > > If a Home Agent was requested, and the home agent is not > available, then > the error is returned. This could occur if the mobile > requested a home agent > that it is not allowed to, or if the home agent is no longer > available. I thought that DIAMETER_ERROR_HA_NOT_AVAILABLE was meant for that? The thing is that with the DIAMETER_ERROR_BAD_HAR, it does not seem to be clear for the client to know what to do, for example, simply request a new HA. > > 7- Page 8, second par., the thing is that I think that AAAH > can determine that > > the MN has moved to a new domain by using the Origin-FQDN and the > > MIP-Previous-FA-FQDN. However, I'm wondering if the > MIP-Previous-FA-FQDN is > > enough, since the FQDN is highly dependent on the realm of > the MIP-Previous-FA-XXXX, > > right? You can only tell that the MN is moving between > domain based on the Realms. > > Correct, so you will have to remove all the data, and the > first dot, in the > fqdn, and that will produce the realm. > > Did I miss the question? > > > > And now, let's say that the HA is located in the former > domain, then how can the > > AAAF knows that the MN has registered in an other domain? > The MIP-Previous-FA-FQDN > > can not really help, since it will be in that domain from > where it moved. The > > AAAF does not have any mean of knowing the originator of > the AMR, AFAIK. I guess > > that a MIP-Registering-FA-FQDN AVP should be added for that purpose. > > I really don't understand the problem (sorry, a little dense > today), but > I see that you believe that a new AVP would be required that > contains the > identity of the foreign agent, right? And why is that? Rereading my question, I guess it was not really clear. Let's try it again. In fact, you should refer to page 9, the last paragraph. It is mentionned that the AAAH can used the MIP-Home-Agent-Address and the MIP-Previous-FA-FQDN to detect if the MN has moved to a new domain. Here are the problems: 1) In section 5.5, it is said that the MIP-Previous-FA-FQDN is sent by the MN while roaming within the same domain. If it remains like this, I guess it would not be possible to detect that the MN has moved to another domain based on that AVP, since it might not have beed included. 2) I think that MIP-Home-Agent-Address and the MIP-Previous-FA-FQDN AVPs are not enough to detect that the MN has moved to a new domain. I think that the only way that an AAAH can detect it, is by using the Origin-Realm and the MIP-Previous-FA-FQDN. Then, it could compare the Origin-Realm of the FA (the new) with the FQDN of the previous FA, i.e. MIP-Previous-FA-FQDN. 3) The problem with the previous comment, is that the MIP-Previous-FA-FQDN does not represent the realm of the previous domain, only the FQDN of the FA, which might be only routable by the AAAF, right? I am not sure that the discussion we had on the mailing list a while ago suggested that the FQDN (let's say ABC.com) was the realm plus another name (let's MACHINE1.ABC.com). That does not make sense to me at least. If it would have been like that, I would argue that we do not need two destination FQDN and Realm. 4) The decision to reject the access to the HA seems to be possible by the former AAAF. The thing is that I don't know how it can know that the MN has moved for sure to another domain. Based on the MIP-Previous-FA-FQDN does not help, since it will most probably be in that domain as well, since the MN has just moved out of it to another domain, right? Also, the Origin-Realm of the AMR, which identifies the originating FA, is not available in the HAR, only in the AMR. So, unless we had in the HAR an AVP for the Origin-FA, I do not see how the former AAAF could perform policies to reject such a service. I hope it is a bit clearer. > > 13-Section 5.7, I guess that when the > MIP-Mobile-Node-Address and the MIP-Home-Agent- > > Address AVPs are not in the message, the AAAF and the AAAH > knows that Home-Agent is > > requested and that a Mobile-Node-Home-Address is requested. > I don't see the need for > > those 2 flags. > > ok, I see your point. The information is redundant. However, > I don't really > like that a zero HA or home address doesn't require that the > AVP be present, > since a -1 value DOES require that it be present. > > Do others agree that these two bits should be removed? The thing is that the spec especially mentions in section 2.1, that if those flags are set, those AVPs MUST NOT be present in the message. I would tend to agree that I would prefer that decision to be left to the AAAH, or the AAAF, to decide the meaning of the content of those AVPs, instead of not sending the AVPs of setting a flag. > > 14-Page 20, par.3, I don't think it is the correct meaning. > My understanding, after > > talking with Tony Johansson, is that the > Home-Agent-In-Foreign-Network is used when > > the MN requests a Home-Agent, and that the AAAF detects > that it is located in its > > foreign domain, before it forwards the AMR to the AAAH. > > It now reads: > > "If the mobile node requests a home agent in the foreign > network either > by setting the home address field to all ones, or by specifying > 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." Then, should an AAAF return a DIAMETER_ERROR_HA_NOT_AVAILABLE when it can not allocate it? > > 22- Section 8.2 and 8.5, should be "by the user" instead of > "to the user". > > Output packets and octets are those sent to the user, not by the user. > You are confusing these with the input counters. The confusion is from what you say for Input and what you say for Output. In 8.1, you say "received by the user", and in 8.2, you say "sent to the user". Maybe you meant, in 8.1, "received from the user"? Also apply to 8.4 and 8.5. If there is something more I should know about the difference between them, maybe it would be good to add some more text in the descriptionç of those AVPs. > > > > 23-Some updates to the table 10.1 as follows: > > > > +-----------------------+ > > | Command-Code | > > |-----+-----+-----+-----+ > > Attribute Name | AMR | AMA | HAR | HAA | > > ------------------------------|-----+-----+-----+-----+ > > Authorization-Lifetime | 0-1 | 1 | 1 | 1 | > > Destination-FQDN | 0-1 | 1 | 0-1 | 1 | > > Destination-Realm | 1 | 0 | 1 | 0 | > > Error-Reporting-FQDN | 0 | 0-1 | 0 | 0-1 | > > Auth-Extension-Id | 1 | 1 | 1 | 1 | > > Filter-Rule | 0 | 0-1 | 0-1 | 0-1 | > > No, you can have more than on Filter-Rule AVP. Then, please change the message's ABNF to reflect the *. Thanks a lot for your answers. I'm impressed, as usual. Martin From owner-aaa-bof@merit.edu Thu May 10 14:03:43 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05233 for ; Thu, 10 May 2001 14:03:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 32F2C5DDE5; Thu, 10 May 2001 14:00:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 221C05DDE2; Thu, 10 May 2001 14:00:18 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id CF69B5DDC9 for ; Thu, 10 May 2001 14:00:12 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id OAA29043; Thu, 10 May 2001 14:00:11 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma029041; Thu, 10 May 01 14:00:10 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id OAA09801; Thu, 10 May 2001 14:00:10 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma009746; Thu, 10 May 01 13:59:14 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 10 May 2001 13:59:13 -0400 Message-ID: From: Yiwen Jiang To: "'Pat Calhoun'" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Urgent Diameter Issues still pending Date: Thu, 10 May 2001 13:59:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, Based on the discussion that we had last week, I thought you were proposing to change the command names to get rid of the -Ind, -Req, and -Answer, and use the EIR bits to represent the type of command to allow ease of proxy integration with new extensions ... Or did you later determine that this is no longer an issue? Thanks. > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Thursday, May 10, 2001 11:58 AM > To: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Urgent Diameter Issues still pending > > > It has occured to me that there is another proposal that I > have forgotten. > > 4. Elimination of the STI. There was a proposal that the STI would > be eliminated, and a new command code set would be created that would > allow a server to initiate a session termination on the access device. > > Again, I am waiting for WG comments. I do not feel > comfortable making blind > changes without *any* feedback. > > PatC > > On Wed, May 09, 2001 at 04:32:57PM -0700, Pat Calhoun wrote: > > All, > > > > This is just to recap the list of issues that are still pending, > > which we really need to get some closure on in the next few days. I > > would like to have the specs out to the WG well before the Interim > > Meeting this month. > > > > As far as memory serves, the following issues are still pending, and > > I am waiting for comments: > > 1. Problem with MRI - I proposed a solution to reduce req/answ cmds > > to only require a single command code, and make use of the EIR bits. > > This would remove the MRI. > > 2. Problem with MRI - How do we deal with -Ind messages that cause a > > failure? Should a new message be created that is used ONLY > to respond > > to bad -Ind messages??? (we could re-use the MRI for this). > > 3. Boot-Id - People insist that this bug is to be fixed, and three > > alternatives have been proposed (note that they are not mutually > > exclusive). > > > > I would appreciate some comments on these proposals. > > > > Thanks, > > > > PatC > > > From owner-aaa-bof@merit.edu Thu May 10 14:08:41 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05352 for ; Thu, 10 May 2001 14:08:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CBFC35DDE2; Thu, 10 May 2001 14:06:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AD49C5DE31; Thu, 10 May 2001 14:06:50 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E8CD45DDE2 for ; Thu, 10 May 2001 14:06:48 -0400 (EDT) Received: (qmail 5115 invoked by uid 500); 10 May 2001 17:56:14 -0000 Date: Thu, 10 May 2001 10:56:14 -0700 From: Pat Calhoun To: Yiwen Jiang Cc: "'Pat Calhoun'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Urgent Diameter Issues still pending Message-ID: <20010510105614.V12425@charizard.diameter.org> Mail-Followup-To: Yiwen Jiang , 'Pat Calhoun' , "'aaa-wg@merit.edu'" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Yiwen.Jiang@tic.siemens.ca on Thu, May 10, 2001 at 01:59:12PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, May 10, 2001 at 01:59:12PM -0400, Yiwen Jiang wrote: > Hi Pat, > > Based on the discussion that we had last week, I thought you were proposing > to change the command names to get rid of the -Ind, -Req, and -Answer, and > use the EIR bits to represent the type of command to allow ease of proxy > integration with new extensions ... > > Or did you later determine that this is no longer an issue? I made the proposal, but I am waiting to hear from the WG that this is the direction that we want to take. Should I assume that you are in agreement with this proposal? As we near the deadline, I am getting more cautious in making liberal changes to the spec. I would prefer to make sure that we have consensus prior to making protocol changes. PatC From owner-aaa-bof@merit.edu Thu May 10 14:19:08 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05545 for ; Thu, 10 May 2001 14:19:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AA1DD5DE2F; Thu, 10 May 2001 14:18:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 992525DE2C; Thu, 10 May 2001 14:18:04 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 2D2A55DE27 for ; Thu, 10 May 2001 14:18:03 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14055 for ; Thu, 10 May 2001 11:18:01 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA02745 for ; Thu, 10 May 2001 11:18:01 -0700 (PDT) Message-Id: <200105101818.LAA02745@heliopolis.eng.sun.com> Date: Thu, 10 May 2001 11:18:01 -0700 (PDT) From: Jonathan Wood Reply-To: Jonathan Wood Subject: Re: [AAA-WG]: Urgent Diameter Issues still pending To: aaa-wg@merit.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 1p2zMQA05QTk74/szIyzqQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk There are also two Diameter / SCTP proposals: 1. Using SCTP streams to prevent head-of-the-line blocking 2. Turning off watchdogs when using SCTP Jon > >All, > >This is just to recap the list of issues that are still pending, >which we really need to get some closure on in the next few days. I >would like to have the specs out to the WG well before the Interim >Meeting this month. > >As far as memory serves, the following issues are still pending, and >I am waiting for comments: >1. Problem with MRI - I proposed a solution to reduce req/answ cmds >to only require a single command code, and make use of the EIR bits. >This would remove the MRI. >2. Problem with MRI - How do we deal with -Ind messages that cause a >failure? Should a new message be created that is used ONLY to respond >to bad -Ind messages??? (we could re-use the MRI for this). >3. Boot-Id - People insist that this bug is to be fixed, and three >alternatives have been proposed (note that they are not mutually >exclusive). > >I would appreciate some comments on these proposals. > >Thanks, > >PatC > From owner-aaa-bof@merit.edu Thu May 10 14:40:57 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05980 for ; Thu, 10 May 2001 14:40:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BF00A5DDE8; Thu, 10 May 2001 14:40:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AEA2A5DDC9; Thu, 10 May 2001 14:40:42 -0400 (EDT) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id EDCA65DDBC for ; Thu, 10 May 2001 14:40:40 -0400 (EDT) Received: (from barney@localhost) by mx.databus.com (8.11.3/8.11.3) id f4AIeaR83208; Thu, 10 May 2001 14:40:36 -0400 (EDT) (envelope-from barney) Date: Thu, 10 May 2001 14:40:36 -0400 From: Barney Wolff To: Yiwen Jiang , "'Pat Calhoun'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Urgent Diameter Issues still pending Message-ID: <20010510144036.A83146@mx.databus.com> References: <20010510105614.V12425@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010510105614.V12425@charizard.diameter.org>; from pcalhoun@diameter.org on Thu, May 10, 2001 at 10:56:14AM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk Well if nobody else will speak up, I'll support the proposal. Loses nothing, and gains the ability to answer a request you don't understand. Barney Wolff On Thu, May 10, 2001 at 10:56:14AM -0700, Pat Calhoun wrote: > On Thu, May 10, 2001 at 01:59:12PM -0400, Yiwen Jiang wrote: > > Hi Pat, > > > > Based on the discussion that we had last week, I thought you were proposing > > to change the command names to get rid of the -Ind, -Req, and -Answer, and > > use the EIR bits to represent the type of command to allow ease of proxy > > integration with new extensions ... > > > > Or did you later determine that this is no longer an issue? > > I made the proposal, but I am waiting to hear from the WG that this is > the direction that we want to take. > > Should I assume that you are in agreement with this proposal? > > As we near the deadline, I am getting more cautious in making liberal changes > to the spec. I would prefer to make sure that we have consensus prior to > making protocol changes. > > PatC > From owner-aaa-bof@merit.edu Thu May 10 15:30:10 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06699 for ; Thu, 10 May 2001 15:30:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 19A775DDBC; Thu, 10 May 2001 15:13:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EE1EA5DDC9; Thu, 10 May 2001 15:13:24 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 122995DDBC for ; Thu, 10 May 2001 15:13:23 -0400 (EDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4AJDPg19979 for ; Thu, 10 May 2001 14:13:25 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 10 May 2001 14:13:06 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Thu, 10 May 2001 14:13:06 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B032139B7@daeis07nok> From: Basavaraj.Patil@nokia.com To: aaa-wg@merit.edu Cc: pcalhoun@diameter.org Subject: [AAA-WG]: Q: draft-ietf-aaa-diameter-mobileip-03.txt Date: Thu, 10 May 2001 14:13:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Section 1.0 of draft-ietf-aaa-diameter-mobileip-03.txt " The Mobile IP protocol [4] requires that mobile nodes have static home agent and home addresses, which is not desirable in a commercial network. " Any specific reasons on why this is not viable or desirable in a commercial network? Is the concern here specifically the limited address space? -Basavaraj From owner-aaa-bof@merit.edu Thu May 10 15:45:11 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06947 for ; Thu, 10 May 2001 15:45:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 15F825DE55; Thu, 10 May 2001 15:01:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E7B6A5DE54; Thu, 10 May 2001 15:01:06 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 6C47C5DE07 for ; Thu, 10 May 2001 15:00:53 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id PAA29663; Thu, 10 May 2001 15:00:20 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma029661; Thu, 10 May 01 15:00:17 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id PAA16105; Thu, 10 May 2001 15:00:17 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma015984; Thu, 10 May 01 14:59:30 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 10 May 2001 14:59:28 -0400 Message-ID: From: Yiwen Jiang To: "'Jonathan Wood'" , aaa-wg@merit.edu Cc: "'Pat Calhoun'" Subject: RE: [AAA-WG]: Urgent Diameter Issues still pending Date: Thu, 10 May 2001 14:59:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Wasn't there also a proposal to put all the TCP related features into one section, so that when SCTP becomes more publicly available and stable, it would be easier to identify the TCP features to be taken out? > -----Original Message----- > From: Jonathan Wood [mailto:Jonathan.Wood@Sun.COM] > Sent: Thursday, May 10, 2001 2:18 PM > To: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Urgent Diameter Issues still pending > > > > There are also two Diameter / SCTP proposals: > > 1. Using SCTP streams to prevent head-of-the-line blocking > 2. Turning off watchdogs when using SCTP > > Jon > > > > >All, > > > >This is just to recap the list of issues that are still pending, > >which we really need to get some closure on in the next few days. I > >would like to have the specs out to the WG well before the Interim > >Meeting this month. > > > >As far as memory serves, the following issues are still pending, and > >I am waiting for comments: > >1. Problem with MRI - I proposed a solution to reduce req/answ cmds > >to only require a single command code, and make use of the EIR bits. > >This would remove the MRI. > >2. Problem with MRI - How do we deal with -Ind messages that cause a > >failure? Should a new message be created that is used ONLY to respond > >to bad -Ind messages??? (we could re-use the MRI for this). > >3. Boot-Id - People insist that this bug is to be fixed, and three > >alternatives have been proposed (note that they are not mutually > >exclusive). > > > >I would appreciate some comments on these proposals. > > > >Thanks, > > > >PatC > > > > From owner-aaa-bof@merit.edu Thu May 10 15:49:11 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07014 for ; Thu, 10 May 2001 15:49:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6FD915DE33; Thu, 10 May 2001 15:46:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5792B5DE36; Thu, 10 May 2001 15:46:59 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 24A565DE33 for ; Thu, 10 May 2001 15:46:58 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA02161; Thu, 10 May 2001 12:46:39 -0700 (PDT) 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 MAA09329; Thu, 10 May 2001 12:46:30 -0700 (PDT) Received: from darius (darius [152.70.40.121]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id MAA28724; Thu, 10 May 2001 12:46:28 -0700 (PDT) Date: Thu, 10 May 2001 12:46:40 -0700 (PDT) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Q: draft-ietf-aaa-diameter-mobileip-03.txt To: Basavaraj.Patil@nokia.com Cc: aaa-wg@merit.edu, pcalhoun@diameter.org In-Reply-To: "Your message with ID" <7B5C0390ACE7D211BC9C0008C7EABA2B032139B7@daeis07nok> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > Section 1.0 of draft-ietf-aaa-diameter-mobileip-03.txt > " > The Mobile IP protocol [4] requires that mobile nodes have static home > agent and home addresses, which is not desirable in a commercial > network. > " > > Any specific reasons on why this is not viable or desirable in a commercial > network? Is the concern here specifically the limited address space? Limited v4 address space, perhaps? Imagine next generation phones all requiring a static IPv4 address. That would be bad :( PatC From owner-aaa-bof@merit.edu Thu May 10 15:58:57 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07217 for ; Thu, 10 May 2001 15:58:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 86D095DDF2; Thu, 10 May 2001 15:58:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7637B5DDEF; Thu, 10 May 2001 15:58:44 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E5E1B5DDC9 for ; Thu, 10 May 2001 15:58:42 -0400 (EDT) Received: (qmail 5583 invoked by uid 500); 10 May 2001 19:48:08 -0000 Date: Thu, 10 May 2001 12:48:08 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Query/Response Message-ID: <20010510124807.W12425@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk Anyone mind if I simply remove Query/Response messages, and just keep Request/Answer and Ind messages? We can easily fit a Query message into the Request framework. Any objections? PatC From owner-aaa-bof@merit.edu Thu May 10 16:07:41 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07375 for ; Thu, 10 May 2001 16:07:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 209935DE1F; Thu, 10 May 2001 16:04:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0DE895DE01; Thu, 10 May 2001 16:04:57 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 5485D5DDFB for ; Thu, 10 May 2001 16:04:55 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id QAA00342; Thu, 10 May 2001 16:04:54 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma000338; Thu, 10 May 01 16:04:27 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id QAA23255; Thu, 10 May 2001 16:04:27 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma023068; Thu, 10 May 01 16:03:32 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 10 May 2001 16:03:30 -0400 Message-ID: From: Yiwen Jiang To: "'Pat Calhoun'" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Query/Response Date: Thu, 10 May 2001 16:03:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk sounds great. Although generally I'm more used to the Request/Response pair (rather than Answer).. > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Thursday, May 10, 2001 3:48 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Query/Response > > > Anyone mind if I simply remove Query/Response messages, and just keep > Request/Answer and Ind messages? We can easily fit a Query > message into > the Request framework. > > Any objections? > > PatC > From owner-aaa-bof@merit.edu Thu May 10 16:11:34 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07420 for ; Thu, 10 May 2001 16:11:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AA36E5DDFB; Thu, 10 May 2001 16:11:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 996575DDEF; Thu, 10 May 2001 16:11:20 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id DFA6A5DDFA for ; Thu, 10 May 2001 16:11:18 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id NAA14062; Thu, 10 May 2001 13:02:58 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 10 May 2001 13:02:58 -0700 (PDT) From: Bernard Aboba To: "Victor Manuel Avila Gonzalez (ECE)" Cc: "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Sessionless dialogue In-Reply-To: <3DFC2DB418B2D211A1950008C7A4E1EA0D042FBC@eestqnt102> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id QAA07420 DIAMETER is being developed as a AAA protocol. Using it as a database query transport is therefore out of the scope of applicability, and ignoring the state machine would probably mean that multiple implementations would not interoperate. As a result, such usage would not be conformant to the specification that is being developed in this WG. On Thu, 10 May 2001, Victor Manuel Avila Gonzalez (ECE) wrote: > Following some discussions I would like to clarify this matter > > Only as I hypothesis, > > May I define a Diameter extension to do something that has nothing to do with authentication/authorization or accounting, e.g. to query a database? > > If that were possible, it would be unnecessary to have a session because the server would not be authorizing anything for a period of time. > > In other words, may I establish a dialogue between two peers without following the user session state machine? > > Regards, > > Victor > e > Víctor M. Avila > Systems Engineer > UMTS/GSM Systems Management > > Ericsson España, S.A. Phone: +34 91 339 3050 > Ombú, 3 Fax: +34 91 339 2538 > 28045 Madrid, Spain e-mail: victor-manuel.avila-gonzalez@ece.ericsson.se > > > > > > From owner-aaa-bof@merit.edu Thu May 10 16:11:59 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07458 for ; Thu, 10 May 2001 16:11:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4BF3A5DDFA; Thu, 10 May 2001 16:11:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 31EDF5DDEF; Thu, 10 May 2001 16:11:46 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 02CC45DE03 for ; Thu, 10 May 2001 16:11:42 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20962; Thu, 10 May 2001 13:11:34 -0700 (PDT) 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 NAA14150; Thu, 10 May 2001 13:11:34 -0700 (PDT) Received: from darius (darius [152.70.40.121]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id NAA29013; Thu, 10 May 2001 13:11:31 -0700 (PDT) Date: Thu, 10 May 2001 13:11:43 -0700 (PDT) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: Query/Response To: Yiwen Jiang Cc: "'Pat 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 The reason why I decided to use Answer is because the first character was different, so one could easily create acronyms. Imagine the Session Termination messages, you would end up with STR and STR :( So the use of Answer allows STR and STA. PatC > sounds great. > > Although generally I'm more used to the Request/Response pair (rather than > Answer).. > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Thursday, May 10, 2001 3:48 PM > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: Query/Response > > > > > > Anyone mind if I simply remove Query/Response messages, and just keep > > Request/Answer and Ind messages? We can easily fit a Query > > message into > > the Request framework. > > > > Any objections? > > > > PatC > > > From owner-aaa-bof@merit.edu Thu May 10 17:45:12 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08781 for ; Thu, 10 May 2001 17:45:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 462565DE3F; Thu, 10 May 2001 16:54:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 122AD5DE65; Thu, 10 May 2001 16:54:34 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by segue.merit.edu (Postfix) with ESMTP id 7302F5DE3F for ; Thu, 10 May 2001 16:54:32 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.92.13]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f4AKsV826839; Thu, 10 May 2001 15:54:31 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f4AKsVY00859; Thu, 10 May 2001 15:54:31 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA26774; Thu, 10 May 2001 15:54:30 -0500 (CDT) Received: from ericsson.com (busam51.berkeley.us.am.ericsson.se [138.85.159.201]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA08922; Thu, 10 May 2001 15:54:21 -0500 (CDT) Message-ID: <3AFAFF8A.911E3B76@ericsson.com> Date: Thu, 10 May 2001 13:52:26 -0700 From: Tony Johansson X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "'Pat Calhoun'" Cc: Barney Wolff , Yiwen Jiang , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Urgent Diameter Issues still pending References: <20010510105614.V12425@charizard.diameter.org> <20010510144036.A83146@mx.databus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Barney Wolff wrote: > Well if nobody else will speak up, I'll support the proposal. > Loses nothing, and gains the ability to answer a request you > don't understand. I also agree and supports this. /Tony > > > Barney Wolff > > On Thu, May 10, 2001 at 10:56:14AM -0700, Pat Calhoun wrote: > > On Thu, May 10, 2001 at 01:59:12PM -0400, Yiwen Jiang wrote: > > > Hi Pat, > > > > > > Based on the discussion that we had last week, I thought you were proposing > > > to change the command names to get rid of the -Ind, -Req, and -Answer, and > > > use the EIR bits to represent the type of command to allow ease of proxy > > > integration with new extensions ... > > > > > > Or did you later determine that this is no longer an issue? > > > > I made the proposal, but I am waiting to hear from the WG that this is > > the direction that we want to take. > > > > Should I assume that you are in agreement with this proposal? > > > > As we near the deadline, I am getting more cautious in making liberal changes > > to the spec. I would prefer to make sure that we have consensus prior to > > making protocol changes. > > > > PatC > > From owner-aaa-bof@merit.edu Thu May 10 17:52:02 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08866 for ; Thu, 10 May 2001 17:52:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3336F5DE05; Thu, 10 May 2001 17:49:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 213675DE03; Thu, 10 May 2001 17:49:11 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by segue.merit.edu (Postfix) with ESMTP id 9C2AA5DDC9 for ; Thu, 10 May 2001 17:49:09 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f4ALn9823374; Thu, 10 May 2001 16:49:09 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f4ALn9d01807; Thu, 10 May 2001 16:49:09 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA29581; Thu, 10 May 2001 16:49:08 -0500 (CDT) Received: from ericsson.com (busam51.berkeley.us.am.ericsson.se [138.85.159.201]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA09660; Thu, 10 May 2001 16:49:00 -0500 (CDT) Message-ID: <3AFB0C59.A881542A@ericsson.com> Date: Thu, 10 May 2001 14:47:05 -0700 From: Tony Johansson X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Wood Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Urgent Diameter Issues still pending References: <200105101818.LAA02745@heliopolis.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jon, Jonathan Wood wrote: > There are also two Diameter / SCTP proposals: > > 1. Using SCTP streams to prevent head-of-the-line blocking Is this really something that we would define as a bug fix to the protocol? > > 2. Turning off watchdogs when using SCTP When you say turning off watchdogs when using SCTP. Do you mean turning of the DWR and WDA? If so, didn't we agree on adding watchdogs back into the Diameter protocol again, to achive a mechanism that also checks that the diameter "application" is a live. Unless I haven't misunderstood you, this means that we would loose this mechanism when running SCTP. Right? BR, /Tony > > > Jon > > > > >All, > > > >This is just to recap the list of issues that are still pending, > >which we really need to get some closure on in the next few days. I > >would like to have the specs out to the WG well before the Interim > >Meeting this month. > > > >As far as memory serves, the following issues are still pending, and > >I am waiting for comments: > >1. Problem with MRI - I proposed a solution to reduce req/answ cmds > >to only require a single command code, and make use of the EIR bits. > >This would remove the MRI. > >2. Problem with MRI - How do we deal with -Ind messages that cause a > >failure? Should a new message be created that is used ONLY to respond > >to bad -Ind messages??? (we could re-use the MRI for this). > >3. Boot-Id - People insist that this bug is to be fixed, and three > >alternatives have been proposed (note that they are not mutually > >exclusive). > > > >I would appreciate some comments on these proposals. > > > >Thanks, > > > >PatC > > From owner-aaa-bof@merit.edu Thu May 10 21:07:19 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11019 for ; Thu, 10 May 2001 21:07:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 59C1A5DDE7; Thu, 10 May 2001 21:05:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4955A5DDFC; Thu, 10 May 2001 21:05:49 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id A08385DDE7 for ; Thu, 10 May 2001 21:05:47 -0400 (EDT) Received: (qmail 7200 invoked by uid 500); 11 May 2001 00:55:12 -0000 Date: Thu, 10 May 2001 17:55:12 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: MRI Fix posted for preview Message-ID: <20010510175512.A6925@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, Given that the fix to remove the MRI has received alot of support, I have made the change. If the WG decides that this is the wrong approach, I can back it out, but a fix is necessary, and there haven't been any alternatives proposed. Given that removing the MRI involved quite a bit of text, I am making an alpha version of the base specification available on the diameter web site. It cannot be found on the actual main web page, but can be retrieved at http://www.diameter.org/draft-ietf-aaa-diameter-04-alpha1.txt. I would really appreciate any comments. Although I have checked the document, it can always use an extra pair of eyes :) Thanks, PatC From owner-aaa-bof@merit.edu Fri May 11 02:19:00 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01122 for ; Fri, 11 May 2001 02:19:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 275CD5DE31; Fri, 11 May 2001 02:17:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 152425DE2D; Fri, 11 May 2001 02:17:12 -0400 (EDT) Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 396E25DDC5 for ; Fri, 11 May 2001 02:17:10 -0400 (EDT) Received: from fredrikj (c35.local.ipunplugged.com [192.168.4.234]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id IAA19444; Fri, 11 May 2001 08:17:53 +0200 From: "Fredrik Johansson" To: "Patrice Calhoun" , Cc: , Subject: RE: [AAA-WG]: Q: draft-ietf-aaa-diameter-mobileip-03.txt Date: Fri, 11 May 2001 08:18:49 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > >> >> Section 1.0 of draft-ietf-aaa-diameter-mobileip-03.txt >> " >> The Mobile IP protocol [4] requires that mobile nodes have static home >> agent and home addresses, which is not desirable in a commercial >> network. >> " Is this realy true? You could use the Nai extension with plain MIP and get dynamic allocation of home address. However, you still need the static home agent address, unless you do home agent dicovery for which you need your home network address. /Fredrik >> >> Any specific reasons on why this is not viable or desirable in a >commercial >> network? Is the concern here specifically the limited address space? > >Limited v4 address space, perhaps? Imagine next generation phones all >requiring a static IPv4 address. That would be bad :( > >PatC > From owner-aaa-bof@merit.edu Fri May 11 02:27:48 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01195 for ; Fri, 11 May 2001 02:27:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 489B75DE01; Fri, 11 May 2001 02:27:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 37F5D5DDCE; Fri, 11 May 2001 02:27:35 -0400 (EDT) Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 5CB625DDC5 for ; Fri, 11 May 2001 02:27:33 -0400 (EDT) Received: from fredrikj (c35.local.ipunplugged.com [192.168.4.234]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id IAA19646; Fri, 11 May 2001 08:28:19 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" Cc: "AAA Listan" Subject: RE: [AAA-WG]: Comments on Base v.3 Date: Fri, 11 May 2001 08:29:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20010510085226.K12425@charizard.diameter.org> Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> >> Here are some comments on the base protocol draft. Some of them >> have probably already been brought up in other threads. >> >> 1.3 Terminology >> >> Is the definition of Upstream and Downstream server switched? >> >> Should it be >> Downstream >> Diameter Proxy Servers identify a downstream server as one that >> is providing routing service towards the node where the message >> originated. >> >> Upstream >> Diameter Proxy Servers identify a upstream server as one that >> is providing routing service away from the node where the >> message originated. > >yup, I cut and paste too hastily :( > >> >> 2.0 Protocol Overview >> The reference to Strong Security should be End-to-End Security > >yes, and there were a few other places too :( > >> >> 4.4 Grouped AVP Values >> What about Paul's idea of being able to define optional AVPs >> in a grouped AVP? > >I am waiting for WG concensus. I think that the chairs need to step in >to help us out. I have two people that have asked for this, Erik has >opposed it. That's not exactly what I would call concensus, so Bernard >and Dave need to intervene, and help us out. Ok, then it's 2-1, not much of a WG concensus, hope that more people speaks up. > >> >> 6.0 Capability Negotiation >> >> How can you tell what extensions from a specific vendor you support. >> As I understand it the Supported-Vendor-Id AVP only tells you the >> IANA assigned number for that vendor, not what extensions from that >> vendor that is supported. Perhaps there should be a grouped AVP >> Supported-Vendor-Extensions which containing the >> Vendor-Id AVP and a Vendor-Extension-Id AVP >> that contains the Vendor specific Extension Id taken from that vendors >> private Extension Id space. > >We agreed, and section 2.3/4 states, that Extension Ids are not vendor >specific. If a vendor needs an extension identifier, it is taken from the >extension identifier namespace. Ok, that's fine with me as long as it's not to complicated to get an id assinged. What scares me is that new Ids are available for assignment via Standards Action. Doesn't it mean that it has to be standardized in the IETF, which can be quite lengthy process :-( > >> >> 8.0 Peer State Machine >> I have not implemented the new state machine, but from the looks >> of it it seems complicated. Why not use a simple backoff instead >> of an election when a raise condition occurs. I.e. when the nodes >> discover the raise condition, they both disconnect and tries again >> after a short period of time. Sure it may take some extra time to >> set up the connection, but the gain by having a simpler state machine >> seems worth it. The backoff time does not have to be so long, RTT + some >> random number of msec. > >Because we need something that reliably works. Back-off will simply delay >the connection process, and the peers could select a random number that >is close enough to each other that the back-off process occurs again. > >I've implemented it, and it really isn't that bad at all. Ok, I'll take your word for it and hope I come to the same conclusions. > >> >> 10.1.3 Offending-Command-Code AVP >> should this realy be under MRI, an unknown command should result >> in an DSI according to the table in section 10 > >Right. I am still waiting to get some concensus on the elimination of >the MRI proposal, and if we do, then the error handling sections will >be consolidated. > >I prefer to wait until I know what's happening to the MRI before I make >more temporary changes :) > >> >> 11.1 Authorization Session State Machine >> >> Open Authorization-Lifetime expires send serv. Open >> specific >> auth req >> >> How can a client send a server specific auth request? In the case of MIP >> does it not need to receive a MIP Reg Req? If it has not received a req >> from the Mip MN to update the tunnel I believe it should send a >STR. Thus >> it should be > >serv = service. Let me clear that up. >> >> Open Authorization-Lifetime expires send STR Discon > >This would be on the server side, and this action already >exists in the FSM. > >> >> >> 11.2 Accounting Session State Machine >> is the following state missing? >> >> Open receive Interim Record send Ack Open > >yes it was missing. > >> >> 16.1 Base Protocol Command AVP Table >> the Accounting Extension Id AVP is missing > >right, and the entry was incorrect. It is now: > DRI >Acct-Extension-Id |0+ |0 |0 |0 |0 |0 |0 |0 | >Auth-Extension-Id |0+ |0 |0 |0 |0 |0 |0 |0 | > >> >> >> >> I still don't like that a Vendor Specific AVP can't be mandatory. An >> example. Say that I would like to distribute some configuration >data to the >> FA in an AMA and that I require it to understand the format. If >it does not >> understand the format I would like it to reject the session. How can I do >> this without setting the Mandatory bit in the AVP? > >The IESG is very concerned about interoperability, or lack thereof, when >vendors start adding vendor-specific AVPs with the 'M' bit set. I will >let them defend their position. I don't understand why it makes the protocol not interoperable, what will happen is that the node that sends an avp with the mandatory bit set to a node that does not understand it will get an error message back saying something like "I did not understand your avp, please try again without it if you still would like to use this service" > >> And what about a company having a vendor specific extension. If >the company >> has two sites they can not comunicate with each other since the operator >> that will proxy the message does not understand the extension. What I'm >> trying to say is that a proxy should not care about the message >unless it is >> handled localy. Or can you advertise wildcard without supporting >it locally? > >Let's assume extention x is proprietary, * is wildcard, and FOO is the >vendor specific command: > > A P B > > --- DRI ext=x ---> <--- DRI ext=x --- > <-- DRI ext=* --- --- DRI ext=* ---> > --- FOO ext=x ---> --- FOO ext=x ---> > >That would work just fine. Ok, so it's ok for a node to advertise wildcard allthough it does not support all extensions locally. Then there is no problem. thanks /Fredrik > >Thanks, > >PatC From owner-aaa-bof@merit.edu Fri May 11 04:15: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 EAA02155 for ; Fri, 11 May 2001 04:15:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2DA1D5DE0F; Fri, 11 May 2001 03:45:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F3B395DE09; Fri, 11 May 2001 03:45:44 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 193815DDC5 for ; Fri, 11 May 2001 03:45:43 -0400 (EDT) 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 AAA01994; Fri, 11 May 2001 00:45:38 -0700 (PDT) Received: from vayne (muc-isdn-13 [129.157.164.113]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id JAA19039; Fri, 11 May 2001 09:45:36 +0200 (MET DST) Date: Fri, 11 May 2001 09:57:09 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: [AAA-WG]: Comments on Base v.3 To: Fredrik Johansson Cc: aaa-wg@merit.edu, paul@funk.com, dave@frascone.com, erik.guttman@sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk "Fredrik Johansson" wrote: > >> 4.4 Grouped AVP Values > >> What about Paul's idea of being able to define optional AVPs > >> in a grouped AVP? > > > >I am waiting for WG concensus. I think that the chairs need to step in > >to help us out. I have two people that have asked for this, Erik has > >opposed it. That's not exactly what I would call concensus, so Bernard > >and Dave need to intervene, and help us out. > > Ok, then it's 2-1, not much of a WG concensus, hope that more people > speaks up. We are not voting here. draft-ietf-aaa-issues-04.txt akes the case for a regular grammar for Diameter. This WG draft has gone through WG last call. It's really up to Paul and Dave to show that this *WG consensus action* is off base. The perception is that this is at the cost of some RADIUS-like flexibility. Well, Diameter allows arbitrary AVPs to be added to a message, just not to a Group value. And RADIUS didn't have Group values. So the ability to add arbitrary AVPs to Groups doesn't amount to less flexibility for Diameter than was present in RADIUS. The Grouped AVP replaces the complex data type and the Group-AVP bag. It facilitates (1) a data dictionary compatible with complex data (2) ensures that all components of complex data are present (3) eliminates the need for specialized parsing code for complex data (4) facilitates automatic parsing / message completeness checking. If Group values can include arbitrary AVPs, I do not see that they serve these 4 ends. If the constraints on Group values are truly thought to be too binding, let's just eliminate the Group type altogether and go back to the RADIUS model of 'strictly' non-organized AVPs bundled together to form a message. But let's hear some good arguments why this is preferable before revising the position supported by draft-ietf-aaa-issues-04.txt. Erik From owner-aaa-bof@merit.edu Fri May 11 04:30: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 EAA02305 for ; Fri, 11 May 2001 04:30:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 733B25DE09; Fri, 11 May 2001 03:56:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 630A35DDCB; Fri, 11 May 2001 03:56:36 -0400 (EDT) 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 3789A5DDC5 for ; Fri, 11 May 2001 03:56:34 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f4B7uXN26878 for ; Fri, 11 May 2001 09:56:33 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri May 11 09:54:29 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 11 May 2001 09:56:28 +0200 Message-ID: <577066326047D41180AC00508B955DDA02C009F1@eestqnt104.es.eu.ericsson.se> From: "Yolanda Garcia-Serrano (ECE)" To: "'Pat Calhoun'" , "Jari Arkko (LMF)" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Re: Comments and questions on 03 Date: Fri, 11 May 2001 09:55:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, Pat See interspaced comments: Thanks /YolandaG > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Wednesday, May 09, 2001 11:33 PM > To: Yolanda Garcia-Serrano (ECE) > Cc: 'pcalhoun@diameter.org'; 'aaa-wg@merit.edu'; > Subject: [AAA-WG]: Re: Comments and questions on 03 > > On Wed, May 09, 2001 at 05:02:27PM +0200, Yolanda > Garcia-Serrano (ECE) wrote: > > Section 10.1: {Destination-Realm] is missing in MRI >The AVP is present in -03, but as [optional]. Are you stating that it >should be {mandatory}? YES > > Section 12.1.1 I guess Extension Id on the Real-Based > Routing Table should be updated to Acc-Extension-Id > > and Auth-Extension-Id > > yes it now reads: > > "- Extension Identifier. It is possible for a routing entry > to have a different > destination based on the Auth-Extension-Id (for accounting > messages) or > Acct-Extension-Id (for non-accounting messages) of the > message. This field > is typically used as a secondary key field in routing table lookups." O.K. But maybe it should be mandatory (instead of 'possible' -> MUST) to support routing based on Acc-Extension-Id, in order to support routing of accounting messages. In I-D 04-alpha 1: - Extension Identifier. It is possible for a routing entry to have a different destination based on the Auth-Extension-Id (for accounting messages) or Acct-Extension-Id (for non-accounting messages) of the message. I guess it should be 'on the Auth-Extension-Id (for non-accounting messages) or Acct-Extension-Id (for accounting messages)'. > > Section 14.3 and 14.4: I don't understand the purpose of > these ASI and API messages. > > I guess only Diameter clients (the ones generating > accounting) could sent this msg, not any Diameter > > Node in general, right? Then, who they send the ASI to? is > per peer, or to the corresponding Accounting servers? > > If it is destined to a accounting server, > {Destination-FQDN} is missing. > > > > In case ASI with Accounting-State=DISABLED is received by > an Accounting Server, what should it do? > > > > Exactly when a Diameter client MUST sent ASI with > Accounting-State=ENABLED? After a reboot, after > > a previously sent DISABLED one, when previous accounting > sessions were opened but it is not possible to > > sent any more accounting info ? If the node is about to be > taken out, even it can not grant the service. > > > > In case ASI ENABLED is received by an Accounting server, > what should it do? > > All good questions, and I wonder about it's usefulness as > well. Perhaps > people that use this functionality in RADIUS could help me out? Then, waiting for responses about that. Maybe Jari can help us. > To answer the routing of the message, though. I believe that > this message > ONLY makes it to the first hop proxy. It is not proxyable. Then this needs to be clarified in the text. But in case in only to the first hop I do not understand at all the utility of it. > > API is sent by an accounting Diameter server to who? To the > peers that have active accounting sessions in the > > accounting server? Then, if it is a message destined to > concrete nodes, is not per session and should > > be removed? Sending an API per session-Id could overload > the server and the network. > > What does the text about the warning in roaming networks mean? > > Because I think this message stinks, and it doesn't scale in > roaming networks. > This is my attempt to warn people NOT to use this message, > but it appears > that there are people that find this useful. > > Again, could those people please speak up? Jari? > > In case an accounting server wants to synchronize with any > Diameter node generating accounting, > > it can know which are the one having active accounting > sessions, so Destination-FQDN is known, and it is not > > the purpose of the message to be sent to _ANY peer, right? > > Right, but would a server poll ALL access devices in the > 'net? That's the > point. So the Destination-FQDN is known, and MUST be present > (according to > the ABNF). Then only {Destination-FQDN} should state in the ABNF, and remove [Destination-FQDN] From owner-aaa-bof@merit.edu Fri May 11 05:06: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 FAA02652 for ; Fri, 11 May 2001 05:06:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6C94A5DDA3; Fri, 11 May 2001 05:05:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5844F5DDAB; Fri, 11 May 2001 05:05:31 -0400 (EDT) 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 1BCFA5DDA3 for ; Fri, 11 May 2001 05:05:29 -0400 (EDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f4B95SO22207 for ; Fri, 11 May 2001 11:05:28 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri May 11 11:05:28 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 11 May 2001 11:05:27 +0200 Message-ID: <577066326047D41180AC00508B955DDA02C009F2@eestqnt104.es.eu.ericsson.se> From: "Yolanda Garcia-Serrano (ECE)" To: "'pcalhoun@diameter.org'" Cc: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Session issues on 04-alpha1 Date: Fri, 11 May 2001 11:05:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA02652 Hi again, Pat I open a new thread on some session details in 04-alpha1: Authorization Sessions ------------------------------------------------------------------------------------ I missed another state in the Authorization State Machine: Open Authorization-Lifetime expires on ? Closed home AAA-server The action to be done when Authorization-Lifetime expires depends on a needed IMHO clarifying text on the following paragraphs: 10.0 ... Authorization-Lifetime AVP defines the maximum amount of time a user MAY make use of the resources before another authorization request is to be transmitted to the server. If the server does not receive another authorization request before the timeout occurs, it SHOULD release any state information related to the user's session. 10.9 ... A Diameter server MUST be prepared to clean up resources if a session's authorization lifetime has expired, and no STR was received. What does 'prepared to clean up resources' exactly mean? When Authorization-Lifetime expires on the server, what action has to be taken by the server? It could send a a Challenge (ACI / DEI) to force the re-authorization, or send a STI (in the same way as it is done when Session-Timeout expires). In the last case (send a STI), there would be no difference between Authrorization-Lifetime and Session-Time, which seems not very good if needed such difference. Maybe it would also help to specify in the text that Authorization-Lifetime MUST be always smaller than Session-Timeout. As well, is [Session-Timeout] missing in ABNF and AVP table for AAA, DEA, AMA, ACA messages? This would give the possibility to inform the Diameter client about the number of seconds the home AAA server is going to wait before issuing an STI. Accounting Sessions ---------------------------------------------------------------------------------- As an accounting session can exists without any related authorization on, in Accounting Session State Machine, I miss following states: Open Receive accounting interim send Open record accounting interim answer Open Session-Timeout Expires on send STR Discon Access Device Open STI Received send STR Discon Open Session-Timeout Expires on send STI Discon home AAA server Discon STR Received Send STA Closed Discon STA Received Discon. Closed user/device Session Movement ----------------------------------------------------------------------------------- In order to support these applications, when an AAA server identifies that a request is the continuation of an existing session, ... I'm wondering how could *any* server detect than an incoming request containing in principle a new Session-Id is a continuation of a previosly existing one? I guess we DO NOT ONLY allow a session per user... Thanks, Best regards /Yolanda García From owner-aaa-bof@merit.edu Fri May 11 09:56: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 JAA09927 for ; Fri, 11 May 2001 09:56:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D26615DDE0; Fri, 11 May 2001 09:56:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C03C65DDF9; Fri, 11 May 2001 09:56:44 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 22EF55DDE0 for ; Fri, 11 May 2001 09:56:43 -0400 (EDT) Received: (qmail 10197 invoked by uid 500); 11 May 2001 13:46:06 -0000 Date: Fri, 11 May 2001 06:46:05 -0700 From: Pat Calhoun To: "Yolanda Garcia-Serrano (ECE)" Cc: "'Pat Calhoun'" , "Jari Arkko (LMF)" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Re: Comments and questions on 03 Message-ID: <20010511064605.A10188@charizard.diameter.org> Mail-Followup-To: "Yolanda Garcia-Serrano (ECE)" , 'Pat Calhoun' , "Jari Arkko (LMF)" , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA02C009F1@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA02C009F1@eestqnt104.es.eu.ericsson.se>; from yolanda.garcia-serrano@ece.ericsson.se on Fri, May 11, 2001 at 09:55:44AM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, May 11, 2001 at 09:55:44AM +0200, Yolanda Garcia-Serrano (ECE) wrote: > > > Section 10.1: {Destination-Realm] is missing in MRI > >The AVP is present in -03, but as [optional]. Are you stating that it > >should be {mandatory}? > YES well, MRI is gone, so we don't have to worry about this one :) > > > > > Section 12.1.1 I guess Extension Id on the Real-Based > > Routing Table should be updated to Acc-Extension-Id > > > and Auth-Extension-Id > > > > yes it now reads: > > > > "- Extension Identifier. It is possible for a routing entry > > to have a different > > destination based on the Auth-Extension-Id (for accounting > > messages) or > > Acct-Extension-Id (for non-accounting messages) of the > > message. This field > > is typically used as a secondary key field in routing table lookups." > > O.K. But maybe it should be mandatory (instead of 'possible' -> MUST) to support > routing based on Acc-Extension-Id, in order to support routing of accounting messages. > > In I-D 04-alpha 1: > - Extension Identifier. It is possible for a routing entry to have > a different destination based on the Auth-Extension-Id (for > accounting messages) or Acct-Extension-Id (for non-accounting > messages) of the message. > > I guess it should be 'on the Auth-Extension-Id (for non-accounting > messages) or Acct-Extension-Id (for accounting messages)'. My general idea was to allow these extensions to be hard coded into the routing table. I believe that you are referring to auto config via the capabilities exchange, right? If so, then I agree that the text is confusing and needs clarification. > > > To answer the routing of the message, though. I believe that > > this message > > ONLY makes it to the first hop proxy. It is not proxyable. > > Then this needs to be clarified in the text. But in case in only to > the first hop I do not understand at all the utility of it. Where would a node proxy the message to??? How would it know which home servers it should proxy it to? So, perhaps it can "recreate" the message and forward a copy to each home server that it believes cares, but the NAS isn't going to send multiple copies to its first hop server, right? > > > > In case an accounting server wants to synchronize with any > > Diameter node generating accounting, > > > it can know which are the one having active accounting > > sessions, so Destination-FQDN is known, and it is not > > > the purpose of the message to be sent to _ANY peer, right? > > > > Right, but would a server poll ALL access devices in the > > 'net? That's the > > point. So the Destination-FQDN is known, and MUST be present > > (according to > > the ABNF). > Then only {Destination-FQDN} should state in the ABNF, and remove > [Destination-FQDN] Ah, *now* I understand the original comment. The AVP was present twice in the ABNF. I've fixed it. Thanks, PatC From owner-aaa-bof@merit.edu Fri May 11 10:05: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 KAA10282 for ; Fri, 11 May 2001 10:05:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1B9AA5DE7E; Fri, 11 May 2001 10:03:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 08B465DE7D; Fri, 11 May 2001 10:03:23 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 7C4435DE6D for ; Fri, 11 May 2001 10:03:21 -0400 (EDT) Received: (qmail 10254 invoked by uid 500); 11 May 2001 13:52:44 -0000 Date: Fri, 11 May 2001 06:52:44 -0700 From: Pat Calhoun To: Fredrik Johansson Cc: Patrice Calhoun , Basavaraj.Patil@nokia.com, aaa-wg@merit.edu, pcalhoun@diameter.org Subject: Re: [AAA-WG]: Q: draft-ietf-aaa-diameter-mobileip-03.txt Message-ID: <20010511065244.C10188@charizard.diameter.org> Mail-Followup-To: Fredrik Johansson , Patrice Calhoun , Basavaraj.Patil@nokia.com, aaa-wg@merit.edu, pcalhoun@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 fredrik.johansson@ipunplugged.com on Fri, May 11, 2001 at 08:18:49AM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, May 11, 2001 at 08:18:49AM +0200, Fredrik Johansson wrote: > > > >> > >> Section 1.0 of draft-ietf-aaa-diameter-mobileip-03.txt > >> " > >> The Mobile IP protocol [4] requires that mobile nodes have static home > >> agent and home addresses, which is not desirable in a commercial > >> network. > >> " > > Is this realy true? in [4], RFC 2002, is certainly is. Additional RFCs have come out since then, and support for this has been added over time. I could modify or even remove this sentence. It has added many years ago, and times change. PatC > You could use the Nai extension with plain MIP and get > dynamic allocation of home address. However, you still need the static home > agent address, unless you do home agent dicovery for which you need your > home > network address. > > /Fredrik > > > >> > >> Any specific reasons on why this is not viable or desirable in a > >commercial > >> network? Is the concern here specifically the limited address space? > > > >Limited v4 address space, perhaps? Imagine next generation phones all > >requiring a static IPv4 address. That would be bad :( > > > >PatC > > > From owner-aaa-bof@merit.edu Fri May 11 10:40: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 KAA11545 for ; Fri, 11 May 2001 10:40:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3321E5DE0E; Fri, 11 May 2001 10:39:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 21A065DDC5; Fri, 11 May 2001 10:39:55 -0400 (EDT) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 84F835DE0B for ; Fri, 11 May 2001 10:39:53 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id KAA12779; Fri, 11 May 2001 10:34:00 -0400 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id KAA27620; Fri, 11 May 2001 10:40:42 -0400 (EDT) From: "Mark Jones" To: Cc: "IETF AAA WG" Subject: [AAA-WG]: Typo in draft-ietf-aaa-diameter-04-alpha1.txt Date: Fri, 11 May 2001 10:42:58 -0400 Message-ID: <017401c0da28$abeb1070$2096a8c0@mjones.bridgewatersys.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; boundary="----=_NextPart_000_0169_01C0DA07.23BBA460"; protocol="application/x-pkcs7-signature"; micalg=SHA-1 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0169_01C0DA07.23BBA460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Pat, Noticed a small typo in 4.3 (AVP Data Formats) of -04-alpha1: Unsigned64 32 bit unsigned value, in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled). Should read "64 bit unsigned value". Regards, Mark ------=_NextPart_000_0169_01C0DA07.23BBA460 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw ggH9oAMCAQICAwS4ODANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDUwMTE4MTgwOFoXDTAyMDUwMTE4MTgwOFowTzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdbWpvbmVzQGJyaWRnZXdhdGVyc3lzdGVt cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMemr5diJO/8+r2Hj3Opr9LbaVAXFgo2 Fhu0tfSSdvlMy52Y67GMoJbv0I282FWO9z4bsnuSIU7y3arEmyA78mwjTSdt2GK5QJHT6jKOqF6M 81Q5j2fU3dQwCPiCQZlOqUJEA3PySRjUQNOgnRUhoSuzGd7IMJ3Y6oeMtE8a02nTAgMBAAGjOjA4 MCgGA1UdEQQhMB+BHW1qb25lc0BicmlkZ2V3YXRlcnN5c3RlbXMuY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEANyubKv2ajV9VxVe4xUDaqZbQ2DEXgGKSFWwsdC06zUucuCmeHHqT vLcoUnI8/dCbSnSwRrELpemSoqTv/99uW+jS6cN5320w1ZEBsC2RSVrSJd8LqxKALmMexgbywYvF /hMe120ctocvwnfbeZmzBIKSF7BDs8YPGzSWgsa5gKUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2 17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP 6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9 edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O +PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R hGvk+NHOd6KBMYICmzCCApcCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDBLg4MAkGBSsOAwIaBQCgggFWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDUxMTE0NDI1NlowIwYJKoZIhvcNAQkEMRYEFCK6O3lc+QqCcpxIIntV+HdcwXz+ MEkGCSqGSIb3DQEJDzE8MDowCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMAIDBLg4MA0GCSqGSIb3DQEBAQUABIGAnDTvIAqEafs3Jq+NU5pZfhuj WW7Q2fjH2E4l2F+LOGkNML/eQckkYteOZQtGHtIN5jmGMOcbdTFlls1N9sbKInRRaYXtv34tMmk0 YUrjCt/PEz4jxMzQZalgNMttgRtHuDRvBcBrEwuZTsXx+8s66PYH7jjmueUgCWA1IDIanKoAAAAA AAA= ------=_NextPart_000_0169_01C0DA07.23BBA460-- From owner-aaa-bof@merit.edu Fri May 11 10:53: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 KAA11945 for ; Fri, 11 May 2001 10:53:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0FB215DDC5; Fri, 11 May 2001 10:53:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E366C5DE1D; Fri, 11 May 2001 10:53:42 -0400 (EDT) Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 3F7ED5DDC5 for ; Fri, 11 May 2001 10:53:41 -0400 (EDT) Received: (qmail 8604 invoked by uid 500); 11 May 2001 15:01:02 -0000 Date: Fri, 11 May 2001 10:01:02 -0500 From: David Frascone To: Erik Guttman Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Comments on Base v.3 Message-ID: <20010511100101.K32596@newman.frascone.com> Mail-Followup-To: Erik Guttman , 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 Erik.Guttman@sun.com on Fri, May 11, 2001 at 09:57:09AM +0200 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk Ok, I know I opened this can of worms . . On Fri, May 11, 2001 at 09:57:09AM +0200, Erik Guttman wrote: > > "Fredrik Johansson" wrote: > > >> 4.4 Grouped AVP Values > > >> What about Paul's idea of being able to define optional AVPs > > >> in a grouped AVP? > > > > > >I am waiting for WG concensus. I think that the chairs need to step in > > >to help us out. I have two people that have asked for this, Erik has > > >opposed it. That's not exactly what I would call concensus, so Bernard > > >and Dave need to intervene, and help us out. > > > > Ok, then it's 2-1, not much of a WG concensus, hope that more people > > speaks up. > > We are not voting here. draft-ietf-aaa-issues-04.txt akes the case for > a regular grammar for Diameter. This WG draft has gone through WG last > call. It's really up to Paul and Dave to show that this *WG consensus > action* is off base. The issues draft stated that perhaps complex AVPs should be replaced with a strictly defined grouped AVP. The way I read the document was that the issues need to be solved, and that we are here to solve them. In my opinion, that issue is phrased incorrectly, and I think the complex AVPs needed to be replaced with grouped AVPs, but not strictly defined. This (IMO, as always) makes the protocol simpler, and also adds functionality by allowing the flexibility in a complex type that Diameter has in a message. If, on the otherhand, we adhere to a strict BNF, then we gain NO advantage over a complex type, except that it grows in size. > > The perception is that this is at the cost of some RADIUS-like > flexibility. Well, Diameter allows arbitrary AVPs to be added > to a message, just not to a Group value. And RADIUS didn't have > Group values. So the ability to add arbitrary AVPs to Groups doesn't > amount to less flexibility for Diameter than was present in RADIUS. > > The Grouped AVP replaces the complex data type and the Group-AVP bag. > It facilitates (1) a data dictionary compatible with complex data > (2) ensures that all components of complex data are present But, this seems like an application issue, not a transport one. (Assuming that the transport would be making these checks) > (3) eliminates the need for specialized parsing code for complex data The specialized parsing code has already been written to parse normal AVPs themselves. > (4) facilitates automatic parsing / message completeness checking. > > If Group values can include arbitrary AVPs, I do not see that they > serve these 4 ends. I agree. But, I don't think the parser/transport whould be doing completeness checking. And, I feel that if it is this strict, why are we having the overhead of the AVPs at all? Why not keep it complex. It's even easier to parse, just point a structure at it. > > If the constraints on Group values are truly thought to be too > binding, let's just eliminate the Group type altogether and go > back to the RADIUS model of 'strictly' non-organized AVPs > bundled together to form a message. But let's hear some good > arguments why this is preferable before revising the position > supported by draft-ietf-aaa-issues-04.txt. I didn't read a "position" in the draft, just a question. And, I think the question might have been stated improperly. As for arguments, I don't see why we should use the overhead of Grouping our AVPs, if we don't reap all of the benefits. In my opinion, these are the benefits to loosly defined (if at all) grouped AVPs: o) It can be parsed by anyone. (It's not a blob) o) It is extensable. If a server wants to add another avp to some grouped information, it can. Reasons why Grouped AVPs with a strict definition is better: o) It can be parsed by anyone. (It's not a blob) o) The syntax can be checked at the transport level. Reasons why complex data is better o) It is the smallest (transport wise) So, I think we are trading transport layer completeness checking with extensibility. I'd rather have extensibility. -Dave From owner-aaa-bof@merit.edu Fri May 11 11:53: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 LAA13795 for ; Fri, 11 May 2001 11:53:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2C32E5DDEE; Fri, 11 May 2001 11:53:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1AE9C5DDCB; Fri, 11 May 2001 11:53:35 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 6BD475DDA6 for ; Fri, 11 May 2001 11:53:33 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id LAA00478; Fri, 11 May 2001 11:44:40 -0400 (EDT) Message-Id: <4.1.20010511112558.0f705d80@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 11 May 2001 11:32:13 -0400 To: Pat Calhoun , aaa-wg@merit.edu From: Paul Funk Subject: Re: [AAA-WG]: MRI Fix posted for preview In-Reply-To: <20010510175512.A6925@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, The 04-alpha1 draft eliminates the confusion associated with the erstwhile EIR bits. One of the big benefits is that a proxy can determine exactly how to handle a message by examining the FAIR bits, without having to understand the command code. Plus, Query/Response were redundant and we're well rid of them. I have just a couple points: Device-Status-Ind handling -------------------------- If a proxy receives a DSI response, it may try to rescue the request by proxying (with the same Identifier) to other servers. But if all else fails, it must return a DSI to the client from whence it came. My quibble is that it must replace Origin-FQDN/Realm with its own identity. But why should the proxy take the rap for some home server that doesn't understand some command code? You wouldn't want the client to think that such a command code should not be sent via that proxy. By obfuscating the source of the error you lose valuable information. I think the proxy should be free to treat the DSI as an ordinary response and just return it as is to the peer from which it received the request. If it wants to alter the DSI-Event or other AVPs to provide better information to that peer, only then should it be required to replace Origin-FQDN/Realm; but not if it is merely the messenger of a failure not of its own making. We shouldn't get carried away by the notion that DSI is a hop-by-hop message. I think the philosophy should be that it may be intercepted at any hop, retried, revised, whatever. But it may also be forwarded upstream unmodified just as an Answer would. Failed Indications ------------------ Calling DSI an "Indication" and setting both I and F bits is misleading. Let's rename "Device-Status-Ind" to "Device-Status-Failure" and set only the F bit. There is a fundamental difference between an originated Indication such as STI or Accounting-Status-Ind and a failure indication such as DSI. For example, the originator of an STI manufactures its own Identifier, and expects its response to be proxied. But a DSI echoes the Identifier of the request, and is returned to the issuer of the request. A proxy works in fundamentally different ways in the request and response directions: in requests, it makes routing decisions based on NAI or Destination-Realm/FQDN; in responses, it uses Proxy-Info or its own saved state to return the response in the reverse direction. Paul At 05:55 PM 5/10/01 -0700, Pat Calhoun wrote: >All, > >Given that the fix to remove the MRI has received alot of >support, I have made the change. If the WG decides that this >is the wrong approach, I can back it out, but a fix is >necessary, and there haven't been any alternatives proposed. > >Given that removing the MRI involved quite a bit of text, >I am making an alpha version of the base specification >available on the diameter web site. It cannot be found >on the actual main web page, but can be retrieved at >http://www.diameter.org/draft-ietf-aaa-diameter-04-alpha1.txt. > >I would really appreciate any comments. Although I have >checked the document, it can always use an extra pair of >eyes :) > >Thanks, > >PatC Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Fri May 11 12:26: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 MAA14686 for ; Fri, 11 May 2001 12:26:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3DF745DE2B; Fri, 11 May 2001 12:26:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2C9F55DE27; Fri, 11 May 2001 12:26:24 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 5B42A5DDCB for ; Fri, 11 May 2001 12:26:18 -0400 (EDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4BGQQg12877 for ; Fri, 11 May 2001 11:26:26 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 11 May 2001 11:26:17 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Fri, 11 May 2001 11:26:17 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B032139C9@daeis07nok> From: Basavaraj.Patil@nokia.com To: pcalhoun@diameter.org Cc: fredrik.johansson@ipunplugged.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Q: draft-ietf-aaa-diameter-mobileip-03.txt Date: Fri, 11 May 2001 11:26:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, Here's a suggested change for the sentence: " The Mobile IP specification as defined in [Ref] recommends mobile nodes to have a static home address and a home agent. However this may not be always possible in certain deployment scenarios. Recent developments in areas that impact IP mobility in the IETF allow Mobile IP [Ref] to work just as well in the absence of static home agent and home address for an MN. " Feel free to change it as you please. Cheers, -Basavaraj > -----Original Message----- > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Friday, May 11, 2001 8:53 AM > To: Fredrik Johansson > Cc: Patrice Calhoun; Basavaraj.Patil@nokia.com; aaa-wg@merit.edu; > pcalhoun@diameter.org > Subject: Re: [AAA-WG]: Q: draft-ietf-aaa-diameter-mobileip-03.txt > > > On Fri, May 11, 2001 at 08:18:49AM +0200, Fredrik Johansson wrote: > > > > > >> > > >> Section 1.0 of draft-ietf-aaa-diameter-mobileip-03.txt > > >> " > > >> The Mobile IP protocol [4] requires that mobile nodes > have static home > > >> agent and home addresses, which is not desirable in a > commercial > > >> network. > > >> " > > > > Is this realy true? > > in [4], RFC 2002, is certainly is. Additional RFCs have come out since > then, and support for this has been added over time. > > I could modify or even remove this sentence. It has added > many years ago, > and times change. > > PatC > > > You could use the Nai extension with plain MIP and get > > dynamic allocation of home address. However, you still need > the static home > > agent address, unless you do home agent dicovery for which > you need your > > home > > network address. > > > > /Fredrik > > > > > > >> > > >> Any specific reasons on why this is not viable or desirable in a > > >commercial > > >> network? Is the concern here specifically the limited > address space? > > > > > >Limited v4 address space, perhaps? Imagine next generation > phones all > > >requiring a static IPv4 address. That would be bad :( > > > > > >PatC > > > > > > From owner-aaa-bof@merit.edu Fri May 11 12:45: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 MAA15119 for ; Fri, 11 May 2001 12:45:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B90A25DDA6; Fri, 11 May 2001 12:05:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A27465DE42; Fri, 11 May 2001 12:05:43 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 1F3BA5DDA6 for ; Fri, 11 May 2001 12:05:42 -0400 (EDT) Received: (qmail 10788 invoked by uid 500); 11 May 2001 15:55:04 -0000 Date: Fri, 11 May 2001 08:55:04 -0700 From: Pat Calhoun To: Fredrik Johansson Cc: Pat Calhoun , AAA Listan Subject: Re: [AAA-WG]: Comments on Base v.3 Message-ID: <20010511085504.E10188@charizard.diameter.org> Mail-Followup-To: Fredrik Johansson , Pat Calhoun , AAA Listan References: <20010510085226.K12425@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from fredrik.johansson@ipunplugged.com on Fri, May 11, 2001 at 08:29:15AM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, May 11, 2001 at 08:29:15AM +0200, Fredrik Johansson wrote: > > > >> > >> 6.0 Capability Negotiation > >> > >> How can you tell what extensions from a specific vendor you support. > >> As I understand it the Supported-Vendor-Id AVP only tells you the > >> IANA assigned number for that vendor, not what extensions from that > >> vendor that is supported. Perhaps there should be a grouped AVP > >> Supported-Vendor-Extensions which containing the > >> Vendor-Id AVP and a Vendor-Extension-Id AVP > >> that contains the Vendor specific Extension Id taken from that vendors > >> private Extension Id space. > > > >We agreed, and section 2.3/4 states, that Extension Ids are not vendor > >specific. If a vendor needs an extension identifier, it is taken from the > >extension identifier namespace. > > Ok, that's fine with me as long as it's not to complicated to get an id > assinged. > What scares me is that new Ids are available for assignment via Standards > Action. > Doesn't it mean that it has to be standardized in the IETF, which can be > quite lengthy > process :-( Correct, as requested by the IESG. However, I believe that now that the protocol has a much better way to allowing intermediate proxies to handle extensions it doesn't recognize (by setting the 'A' bit, instead of having to know what the correct command code is), this may no longer be an issue. Bernard/Dave, is this true? > > > > >> > >> 8.0 Peer State Machine > >> I have not implemented the new state machine, but from the looks > >> of it it seems complicated. Why not use a simple backoff instead > >> of an election when a raise condition occurs. I.e. when the nodes > >> discover the raise condition, they both disconnect and tries again > >> after a short period of time. Sure it may take some extra time to > >> set up the connection, but the gain by having a simpler state machine > >> seems worth it. The backoff time does not have to be so long, RTT + some > >> random number of msec. > > > >Because we need something that reliably works. Back-off will simply delay > >the connection process, and the peers could select a random number that > >is close enough to each other that the back-off process occurs again. > > > >I've implemented it, and it really isn't that bad at all. > > Ok, I'll take your word for it and hope I come to the same conclusions. Well, I had originally implemented a state machine that was exchanged as private e-mail, and was radically different from what is in -03. It took me one day to modify my code to support the new state machine, and with the exception of the function that does the look up, based on event/state that required changes, the rest was a re-write. It took me about a day to implement/test. > > > >The IESG is very concerned about interoperability, or lack thereof, when > >vendors start adding vendor-specific AVPs with the 'M' bit set. I will > >let them defend their position. > > I don't understand why it makes the protocol not interoperable, what will > happen > is that the node that sends an avp with the mandatory bit set to a node that > does not understand it will get an error message back saying something like > "I did not understand your avp, please try again without it if you still > would > like to use this service" They are worried about vendors abusing the protocol, as many have done with other protocols, and ending up with non-interoperable solutions. If you feel the need to create a vendor-specific solution, then create your own extension. > >Let's assume extention x is proprietary, * is wildcard, and FOO is the > >vendor specific command: > > > > A P B > > > > --- DRI ext=x ---> <--- DRI ext=x --- > > <-- DRI ext=* --- --- DRI ext=* ---> > > --- FOO ext=x ---> --- FOO ext=x ---> > > > >That would work just fine. > > Ok, so it's ok for a node to advertise wildcard allthough it does not > support > all extensions locally. Then there is no problem. correct. PatC From owner-aaa-bof@merit.edu Fri May 11 13:43: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 NAA16656 for ; Fri, 11 May 2001 13:43:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 970F85DDC6; Fri, 11 May 2001 13:42:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7C7A65DDCA; Fri, 11 May 2001 13:42:48 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 9196E5DDC6 for ; Fri, 11 May 2001 13:42:46 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id NAA00805; Fri, 11 May 2001 13:34:45 -0400 (EDT) Message-Id: <4.1.20010511120603.017f5ca0@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 11 May 2001 13:22:17 -0400 To: aaa-wg@merit.edu, Erik Guttman , Fredrik Johansson , Patrice Calhoun , dave@frascone.com From: Paul Funk Subject: RE: [AAA-WG]: Comments on Base v.3 In-Reply-To: References: <"Your message with ID" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk The issue of flexibility in the ABNF for a grouped AVP is clearly one that Dave Frascone and I feel strongly about, and Erik Guttman has ardently spoken against. The way the draft is written now, if you wanted to define a grouped AVP, you'd have to specify the exact sequence of AVPs it must contain. If you realize later than additional information would useful, you'd have to define a brand new grouped AVP. If you want to collect a set of attributes in a group but allow some to be present and some not, you'd have to define a separate grouped AVP for each possible combination. One argument against polymorphic groups is that we have no concrete examples of a hard requirement for it. Well, it we wait for the dispositive example to come along, we may be out of luck when it does. Meanwhile, there are many reasons to anticipate polymorphic groups will become necessary in the future. How will we be able to return complex policy or hierarchical accounting data without flexibility in grouping? People have been told to use XML inside a Diameter AVP or just package some other accounting format within a Diameter AVP, because Diameter as a protocol is too "flat" to handle their data. But if we allow polymorphic groups, we'd be able to render the XML data model perfectly when that becomes necessary. Plus, my original email on the subject raised an issue which no one has yet attempted to address: The draft states that when a Redirect DSI is issued, it provides the addresses/ports of one or more home servers to redirect to in the Redirect-Host grouped AVP, and it may also provide certificates for the home server. The question is, if different home servers have different certificates, how do you associate each home server with the appropriate certificate without extending the Redirect-Host AVP. Pat, any thoughts on this question? Erik, I responded to your points in line. Paul At 09:57 AM 5/11/01 +0200, Erik Guttman wrote: > >"Fredrik Johansson" wrote: >> >> 4.4 Grouped AVP Values >> >> What about Paul's idea of being able to define optional AVPs >> >> in a grouped AVP? >> > >> >I am waiting for WG concensus. I think that the chairs need to step in >> >to help us out. I have two people that have asked for this, Erik has >> >opposed it. That's not exactly what I would call concensus, so Bernard >> >and Dave need to intervene, and help us out. >> >> Ok, then it's 2-1, not much of a WG concensus, hope that more people >> speaks up. > >We are not voting here. draft-ietf-aaa-issues-04.txt akes the case for >a regular grammar for Diameter. This WG draft has gone through WG last >call. It's really up to Paul and Dave to show that this *WG consensus >action* is off base. We can argue about the rules of the game, or we can argue about the issues. And, since Fred revived the question, I'm wondering whether it isn't 3-1 by now. Is this the beginnings of a groundswell? > >The perception is that this is at the cost of some RADIUS-like >flexibility. Well, Diameter allows arbitrary AVPs to be added >to a message, just not to a Group value. And RADIUS didn't have >Group values. So the ability to add arbitrary AVPs to Groups doesn't >amount to less flexibility for Diameter than was present in RADIUS. The only grouping concept in RADIUS is tagged tunnel attributes. But in RADIUS, you can have a subset of the tunnel attributes in a tag group, not necessarily all of them. And, if new tunnel attributes are defined, they can be added to the tag group. So that hack of a mechanism in RADIUS provides more flexibility than what we have defined for Diameter. > >The Grouped AVP replaces the complex data type and the Group-AVP bag. >It facilitates (1) a data dictionary compatible with complex data >(2) ensures that all components of complex data are present >(3) eliminates the need for specialized parsing code for complex data >(4) facilitates automatic parsing / message completeness checking. > >If Group values can include arbitrary AVPs, I do not see that they >serve these 4 ends. First, let's be precise. I never proposed that grouped AVPs can include arbitrary AVPs. I proposed that grouped AVPs be defined via ABNF, just as the Diameter message itself is. The ABNF can be as flexible or restrictive as is deemed necessary. I would hope that people would define new AVPs flexibly. But they could still have rules for required attributes, sequencing, etc. I think that an ABNF-specified group absolutely does meet the four goals listed above. > >If the constraints on Group values are truly thought to be too >binding, let's just eliminate the Group type altogether and go >back to the RADIUS model of 'strictly' non-organized AVPs >bundled together to form a message. But let's hear some good >arguments why this is preferable before revising the position >supported by draft-ietf-aaa-issues-04.txt. Obviously, no one is saying we should eliminate grouped AVPs entirely. Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Fri May 11 13:52: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 NAA17021 for ; Fri, 11 May 2001 13:52:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 258FE5DE3B; Fri, 11 May 2001 13:51:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 098B25DE42; Fri, 11 May 2001 13:51:48 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 0875D5DE3B for ; Fri, 11 May 2001 13:51:46 -0400 (EDT) Received: (qmail 11514 invoked by uid 500); 11 May 2001 17:41:08 -0000 Date: Fri, 11 May 2001 10:41:08 -0700 From: Pat Calhoun To: "Yolanda Garcia-Serrano (ECE)" Cc: "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Re: Session issues on 04-alpha1 Message-ID: <20010511104108.H10188@charizard.diameter.org> Mail-Followup-To: "Yolanda Garcia-Serrano (ECE)" , "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA02C009F2@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA02C009F2@eestqnt104.es.eu.ericsson.se>; from yolanda.garcia-serrano@ece.ericsson.se on Fri, May 11, 2001 at 11:05:21AM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, May 11, 2001 at 11:05:21AM +0200, Yolanda Garcia-Serrano (ECE) wrote: > > Authorization Sessions > ------------------------------------------------------------------------------------ > I missed another state in the Authorization State Machine: > Open Authorization-Lifetime expires on ? Closed > home AAA-server Actually, I changed: Open Session-Timeout Expires on send STI Discon home AAA server to: Open Session-Timeout or send STI Discon Authorization-Lifetime expires on home AAA server > > The action to be done when Authorization-Lifetime expires depends on a needed IMHO > clarifying text on the following paragraphs: > > 10.0 > ... > Authorization-Lifetime AVP defines the maximum amount of time a user > MAY make use of the resources before another authorization request is > to be transmitted to the server. If the server does not receive > another authorization request before the timeout occurs, it SHOULD > release any state information related to the user's session. > > 10.9 > ... > A Diameter server MUST be prepared to clean up resources if a > session's authorization lifetime has expired, and no STR was > received. > > What does 'prepared to clean up resources' exactly mean? quite vague, and changed to: "A Diameter server MUST clean up resources (e.g. session state) if a session's authorization lifetime has expired, and no STR was received. This event could occur if an access device was to unexpectedly reboot." > When Authorization-Lifetime > expires on the server, what action has to be taken by the server? It should send an STI (see the above new state table entry). > It could send a a Challenge (ACI / DEI) to force the re-authorization, or send a STI > (in the same way as it is done when Session-Timeout expires). In the last case (send > a STI), there would be no difference between Authrorization-Lifetime and Session-Time, > which seems not very good if needed such difference. The main difference, which apparently needs clarification, is that the Session-Timeout is returned from the server when it will not "re-authorize" a session. Once the Session-Timeout has expired, the user is disconnected. When the Authorization-Lifetime has expired, the access device MAY request re-authorization. For instance, a RADIUS home server would never return an Authorization-Lifetime AVP, since RADIUS doesn't have the concept of re-authorization, so it would only include the Session-Timeout. hence: Open Session-Timeout Expires on send STR Discon Access Device and: Open Authorization-Lifetime about send Open to expire on access device service specific auth req The Authorization-Lifetime text already stated that a re-auth was required after expiration, but the Session-Timeout text was a tad vague. I have changed it to: 10.5 Session-Timeout AVP The Session-Timeout AVP (AVP Code 27) [1] is of type Unsigned32 and contains the maximum number of seconds of service to be provided to the user before termination of the session. A session terminated due to the Session-Timeout expiration MUST NOT generate a re-authentication and/or re-authorization. A value of zero, or the absence of this AVP, means that this session has an unlimited number of seconds before termination. [...] > > Maybe it would also help to specify in the text that Authorization-Lifetime MUST be > always smaller than Session-Timeout. or the same, if the access device doesn't support re-auth. 10.4 Authorization-Lifetime AVP [...] If both this AVP and the Session-Timeout AVP are present in a message, the value of the latter MUST NOT be smaller than the Authorization-Lifetime AVP. > > As well, is [Session-Timeout] missing in ABNF and AVP table for AAA, DEA, AMA, ACA messages? > This would give the possibility to inform the Diameter client about the number of > seconds the home AAA server is going to wait before issuing an STI. cool, thanks. > > > Accounting Sessions > ---------------------------------------------------------------------------------- > As an accounting session can exists without any related authorization on, in > Accounting Session State Machine, I miss following states: > > > Open Receive accounting interim send Open > record accounting > interim > answer This one is already covered, right? > > Open Session-Timeout Expires on send STR Discon > Access Device > > Open STI Received send STR Discon > > Open Session-Timeout Expires on send STI Discon > home AAA server > > Discon STR Received Send STA Closed > > Discon STA Received Discon. Closed > user/device no you seem to have missed the point of the state machine. If accounting ONLY is done, a Stop accounting record is the only termination you need. ST* messages are only used when auth is performed. So, if you have two separate servers handling both auth and acct, one will get the auth and STR message for cleanup, while the other will receive the acct start and the stop for cleanup. Requiring an STR would mean tha the access device would have to know that two separate servers were used, and would have to issue two STRs. See the problem? > Session Movement > ----------------------------------------------------------------------------------- > In order to support these applications, when an > AAA server identifies that a request is the continuation of an > existing session, ... > I'm wondering how could *any* server detect than an incoming request containing in > principle a new Session-Id is a continuation of a previosly existing one? I guess > we DO NOT ONLY allow a session per user... Actually, this was added to the base in -03 to try to fix some issues with the Mobile IP extension, but due to our recent conference call, we came to the conclusion that this AVP is no longer necessary. So the actual -04 will no longer include the Session Movement section and sub-sections. Thanks, PatC From owner-aaa-bof@merit.edu Fri May 11 13:54: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 NAA17070 for ; Fri, 11 May 2001 13:54:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 098DC5DE27; Fri, 11 May 2001 13:54:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EC2045DE12; Fri, 11 May 2001 13:54:11 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 3B3115DDAB for ; Fri, 11 May 2001 13:54:10 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA03191; Fri, 11 May 2001 10:54:01 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA00741; Fri, 11 May 2001 10:54:01 -0700 (PDT) Message-Id: <200105111754.KAA00741@heliopolis.eng.sun.com> Date: Fri, 11 May 2001 10:54:01 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [AAA-WG]: Comments on Base v.3 To: aaa-wg@merit.edu, Erik.Guttman@Sun.COM, fredrik.johansson@ipunplugged.com, pcalhoun@nasnfs.eng.sun.com, dave@frascone.com, paul@funk.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0qMbAXJHJGxtoXuMCWZoFQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk Afraid I'll have to side with Erik here. The current Diameter types are very simple, based purely on syntax. This proposal seems to be returning to the idea of having more complex, semantic based types. I think the spec should stick to one or the other. If you want to have a complex AVP, then you should be using a data definition language like XML (but not confined to XML) to define it. Grouped should be for a predefined collection of AVPs, not for defining complex hierarchies. jak >Delivered-To: aaa-wg-outgoing@merit.edu >X-Sender: paul@cairo.funk.com >Date: Fri, 11 May 2001 13:22:17 -0400 >To: aaa-wg@merit.edu, Erik Guttman , Fredrik Johansson , Patrice Calhoun , dave@frascone.com >From: Paul Funk >Subject: RE: [AAA-WG]: Comments on Base v.3 > >The issue of flexibility in the ABNF for a grouped AVP is clearly one that >Dave Frascone and I feel strongly about, and Erik Guttman has ardently >spoken against. > >The way the draft is written now, if you wanted to define a grouped AVP, >you'd have to specify the exact sequence of AVPs it must contain. If you >realize later than additional information would useful, you'd have to define >a brand new grouped AVP. If you want to collect a set of attributes in a >group but allow some to be present and some not, you'd have to define a >separate grouped AVP for each possible combination. > >One argument against polymorphic groups is that we have no concrete >examples of a hard requirement for it. Well, it we wait for the dispositive >example to come along, we may be out of luck when it does. > >Meanwhile, there are many reasons to anticipate polymorphic groups will >become necessary in the future. > >How will we be able to return complex policy or hierarchical accounting >data without flexibility in grouping? > >People have been told to use XML inside a Diameter AVP or just package >some other accounting format within a Diameter AVP, because Diameter >as a protocol is too "flat" to handle their data. But if we allow polymorphic >groups, we'd be able to render the XML data model perfectly when that >becomes necessary. > >Plus, my original email on the subject raised an issue which no one has >yet attempted to address: > >The draft states that when a Redirect DSI is issued, it provides the >addresses/ports of one or more home servers to redirect to in the >Redirect-Host grouped AVP, and it may also provide certificates >for the home server. The question is, if different home servers have >different certificates, how do you associate each home server with >the appropriate certificate without extending the Redirect-Host AVP. >Pat, any thoughts on this question? > >Erik, I responded to your points in line. > >Paul > > >At 09:57 AM 5/11/01 +0200, Erik Guttman wrote: >> >>"Fredrik Johansson" wrote: >>> >> 4.4 Grouped AVP Values >>> >> What about Paul's idea of being able to define optional AVPs >>> >> in a grouped AVP? >>> > >>> >I am waiting for WG concensus. I think that the chairs need to step in >>> >to help us out. I have two people that have asked for this, Erik has >>> >opposed it. That's not exactly what I would call concensus, so Bernard >>> >and Dave need to intervene, and help us out. >>> >>> Ok, then it's 2-1, not much of a WG concensus, hope that more people >>> speaks up. >> >>We are not voting here. draft-ietf-aaa-issues-04.txt akes the case for >>a regular grammar for Diameter. This WG draft has gone through WG last >>call. It's really up to Paul and Dave to show that this *WG consensus >>action* is off base. > >We can argue about the rules of the game, or we can argue about the >issues. > >And, since Fred revived the question, I'm wondering whether it isn't 3-1 by >now. Is this the beginnings of a groundswell? > >> >>The perception is that this is at the cost of some RADIUS-like >>flexibility. Well, Diameter allows arbitrary AVPs to be added >>to a message, just not to a Group value. And RADIUS didn't have >>Group values. So the ability to add arbitrary AVPs to Groups doesn't >>amount to less flexibility for Diameter than was present in RADIUS. > >The only grouping concept in RADIUS is tagged tunnel attributes. But >in RADIUS, you can have a subset of the tunnel attributes in a tag >group, not necessarily all of them. And, if new tunnel attributes are >defined, they can be added to the tag group. So that hack of a >mechanism in RADIUS provides more flexibility than what we have >defined for Diameter. > >> >>The Grouped AVP replaces the complex data type and the Group-AVP bag. >>It facilitates (1) a data dictionary compatible with complex data >>(2) ensures that all components of complex data are present >>(3) eliminates the need for specialized parsing code for complex data >>(4) facilitates automatic parsing / message completeness checking. >> >>If Group values can include arbitrary AVPs, I do not see that they >>serve these 4 ends. > >First, let's be precise. I never proposed that grouped AVPs can include >arbitrary AVPs. I proposed that grouped AVPs be defined via ABNF, just >as the Diameter message itself is. The ABNF can be as flexible or >restrictive as is deemed necessary. I would hope that people would >define new AVPs flexibly. But they could still have rules for required >attributes, sequencing, etc. > >I think that an ABNF-specified group absolutely does meet the four >goals listed above. > >> >>If the constraints on Group values are truly thought to be too >>binding, let's just eliminate the Group type altogether and go >>back to the RADIUS model of 'strictly' non-organized AVPs >>bundled together to form a message. But let's hear some good >>arguments why this is preferable before revising the position >>supported by draft-ietf-aaa-issues-04.txt. > >Obviously, no one is saying we should eliminate grouped AVPs >entirely. > > >Paul Funk >Funk Software, Inc. >617 497-6339 >paul@funk.com > > From owner-aaa-bof@merit.edu Fri May 11 13:55: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 NAA17120 for ; Fri, 11 May 2001 13:55:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6EF325DE26; Fri, 11 May 2001 13:55:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5A4375DE12; Fri, 11 May 2001 13:55:06 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id DB8465DDAB for ; Fri, 11 May 2001 13:55:04 -0400 (EDT) Received: (qmail 11544 invoked by uid 500); 11 May 2001 17:44:27 -0000 Date: Fri, 11 May 2001 10:44:27 -0700 From: Pat Calhoun To: Paul Funk Cc: aaa-wg@merit.edu, Erik Guttman , Fredrik Johansson , Patrice Calhoun , dave@frascone.com Subject: Re: [AAA-WG]: Comments on Base v.3 Message-ID: <20010511104427.I10188@charizard.diameter.org> Mail-Followup-To: Paul Funk , aaa-wg@merit.edu, Erik Guttman , Fredrik Johansson , Patrice Calhoun , dave@frascone.com References: <"Your <4.1.20010511120603.017f5ca0@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010511120603.017f5ca0@cairo.funk.com>; from paul@funk.com on Fri, May 11, 2001 at 01:22:17PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, May 11, 2001 at 01:22:17PM -0400, Paul Funk wrote: [staying away from this one as much as I can, but have the following comment] > The draft states that when a Redirect DSI is issued, it provides the > addresses/ports of one or more home servers to redirect to in the > Redirect-Host grouped AVP, and it may also provide certificates > for the home server. The question is, if different home servers have > different certificates, how do you associate each home server with > the appropriate certificate without extending the Redirect-Host AVP. > Pat, any thoughts on this question? Certificates are distributed as specified in the end-to-end security draft. A certificate includes the owner's identity. Therefore, there is no need to combine the certs in the Grouped-AVP because matching the server with the cert occurs by looking at the details of the cert. PatC From owner-aaa-bof@merit.edu Fri May 11 14:43: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 OAA18095 for ; Fri, 11 May 2001 14:43:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EAC3F5DE36; Fri, 11 May 2001 14:42:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DAADB5DE1D; Fri, 11 May 2001 14:42:50 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id F399F5DDAB for ; Fri, 11 May 2001 14:42:48 -0400 (EDT) Received: (qmail 11680 invoked by uid 500); 11 May 2001 18:32:11 -0000 Date: Fri, 11 May 2001 11:32:11 -0700 From: Pat Calhoun To: Thomas Panagiotis-PTHOMAS1 Cc: "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: End-2-End security Message-ID: <20010511113210.J10188@charizard.diameter.org> Mail-Followup-To: Thomas Panagiotis-PTHOMAS1 , "'aaa-wg@merit.edu'" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from panos.thomas@motorola.com on Fri, May 11, 2001 at 01:29:25PM -0500 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, May 11, 2001 at 01:29:25PM -0500, Thomas Panagiotis-PTHOMAS1 wrote: > "2.0 Protocol Overview > ... > Diameter servers MUST support the Base protocol, which includes Accounting, > and both the NASREQ and Mobile IP extensions. Diameter Clients MUST support > the Base protocol, including Accounting, and MAY support any other extension > that would be required to provide service." > > So End-2-End security is a MAY for Clients and Servers, right? The way the text currently reads, yes I guess so. How do others feel? PatC From owner-aaa-bof@merit.edu Fri May 11 14:46: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 OAA18217 for ; Fri, 11 May 2001 14:46:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 185085DE12; Fri, 11 May 2001 14:29:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0759E5DDAD; Fri, 11 May 2001 14:29:35 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id 97BD55DDAB for ; Fri, 11 May 2001 14:29:28 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id LAA05101 for ; Fri, 11 May 2001 11:29:28 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id LAA03851 for ; Fri, 11 May 2001 11:29:27 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Fri, 11 May 2001 13:29:27 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: End-2-End security Date: Fri, 11 May 2001 13:29:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, "2.0 Protocol Overview ... Diameter servers MUST support the Base protocol, which includes Accounting, and both the NASREQ and Mobile IP extensions. Diameter Clients MUST support the Base protocol, including Accounting, and MAY support any other extension that would be required to provide service." So End-2-End security is a MAY for Clients and Servers, right? -Panos From owner-aaa-bof@merit.edu Fri May 11 14:49:32 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18243 for ; Fri, 11 May 2001 14:49:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 44BFF5DE44; Fri, 11 May 2001 14:46:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2AAC75DE45; Fri, 11 May 2001 14:46:08 -0400 (EDT) Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 55DDB5DE44 for ; Fri, 11 May 2001 14:46:06 -0400 (EDT) Received: (qmail 28751 invoked by uid 500); 11 May 2001 18:53:23 -0000 Date: Fri, 11 May 2001 13:53:23 -0500 From: David Frascone To: Thomas Panagiotis-PTHOMAS1 , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: End-2-End security Message-ID: <20010511135322.H30974@newman.frascone.com> Mail-Followup-To: Thomas Panagiotis-PTHOMAS1 , "'aaa-wg@merit.edu'" References: <20010511113210.J10188@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010511113210.J10188@charizard.diameter.org>; from pcalhoun@diameter.org on Fri, May 11, 2001 at 11:32:11AM -0700 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk I like keeping it a MAY On Fri, May 11, 2001 at 11:32:11AM -0700, Pat Calhoun wrote: > On Fri, May 11, 2001 at 01:29:25PM -0500, Thomas Panagiotis-PTHOMAS1 wrote: > > "2.0 Protocol Overview > > ... > > Diameter servers MUST support the Base protocol, which includes Accounting, > > and both the NASREQ and Mobile IP extensions. Diameter Clients MUST support > > the Base protocol, including Accounting, and MAY support any other extension > > that would be required to provide service." > > > > So End-2-End security is a MAY for Clients and Servers, right? > > The way the text currently reads, yes I guess so. How do others feel? > > PatC > From owner-aaa-bof@merit.edu Fri May 11 14:51: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 OAA18272 for ; Fri, 11 May 2001 14:51:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 11D9B5DE6E; Fri, 11 May 2001 14:48:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F403C5DE6B; Fri, 11 May 2001 14:48:22 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 3849E5DE5D for ; Fri, 11 May 2001 14:48:21 -0400 (EDT) Received: (qmail 11700 invoked by uid 500); 11 May 2001 18:37:43 -0000 Date: Fri, 11 May 2001 11:37:43 -0700 From: Pat Calhoun To: Michael Chen Cc: Mark Jones , IETF AAA WG , pcalhoun@diameter.org, tony.johansson@ericsson.com Subject: Re: [AAA-WG]: Route-Record AVP in Failed Indication in 04-alpha1 Message-ID: <20010511113743.K10188@charizard.diameter.org> Mail-Followup-To: Michael Chen , Mark Jones , IETF AAA WG , pcalhoun@diameter.org, tony.johansson@ericsson.com References: <017401c0da28$abeb1070$2096a8c0@mjones.bridgewatersys.com> <3AFC31F5.CF274809@erilab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AFC31F5.CF274809@erilab.com>; from cchen@erilab.com on Fri, May 11, 2001 at 11:39:49AM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, May 11, 2001 at 11:39:49AM -0700, Michael Chen wrote: > Hi > > According to base protocol > "A Diameter server that proxies a message of type Request, Query or > Indication MUST append a Route-Record AVP, which includes its > identity." sigh. My eyes were open for "Responses", and I completely missed the Queries. Anyways all references to Query messages have now been removed. > What should we do with Failed Indication to avoid loop detection if we > follow the above rule? A failed response is handled just like an answer, so this is not an issue. > How about change Failed Indication to another name but still use the same > command code? What name would you propose? PatC From owner-aaa-bof@merit.edu Fri May 11 14:53: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 OAA18292 for ; Fri, 11 May 2001 14:53:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2EC005DE8E; Fri, 11 May 2001 14:49:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1CD325DE4F; Fri, 11 May 2001 14:49:38 -0400 (EDT) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id D72D45DE4D for ; Fri, 11 May 2001 14:49:30 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id OAA16461; Fri, 11 May 2001 14:49:29 -0400 (EDT) Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1) id xma016457; Fri, 11 May 01 14:49:27 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id OAA18953; Fri, 11 May 2001 14:49:27 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma018740; Fri, 11 May 01 14:48:15 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 11 May 2001 14:48:12 -0400 Message-ID: From: Yiwen Jiang To: "'Pat Calhoun'" , Thomas Panagiotis-PTHOMAS1 Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: End-2-End security Date: Fri, 11 May 2001 14:48:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Would this issue not leading back to whether a small diameter base protocol with many plugin extensions should be defined ? Maybe if we settle on a concensus on this issue, the question would answer itself? > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Friday, May 11, 2001 2:32 PM > To: Thomas Panagiotis-PTHOMAS1 > Cc: 'aaa-wg@merit.edu' > Subject: Re: [AAA-WG]: End-2-End security > > > On Fri, May 11, 2001 at 01:29:25PM -0500, Thomas > Panagiotis-PTHOMAS1 wrote: > > "2.0 Protocol Overview > > ... > > Diameter servers MUST support the Base protocol, which > includes Accounting, > > and both the NASREQ and Mobile IP extensions. Diameter > Clients MUST support > > the Base protocol, including Accounting, and MAY support > any other extension > > that would be required to provide service." > > > > So End-2-End security is a MAY for Clients and Servers, right? > > The way the text currently reads, yes I guess so. How do others feel? > > PatC > From owner-aaa-bof@merit.edu Fri May 11 14:53: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 OAA18318 for ; Fri, 11 May 2001 14:53:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3F0315DDAB; Fri, 11 May 2001 14:52:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 270C65DE3C; Fri, 11 May 2001 14:52:26 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 4BB895DDAB for ; Fri, 11 May 2001 14:52:24 -0400 (EDT) Received: (qmail 11744 invoked by uid 500); 11 May 2001 18:41:46 -0000 Date: Fri, 11 May 2001 11:41:46 -0700 From: Pat Calhoun To: Yiwen Jiang Cc: "'Pat Calhoun'" , Thomas Panagiotis-PTHOMAS1 , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: End-2-End security Message-ID: <20010511114146.M10188@charizard.diameter.org> Mail-Followup-To: Yiwen Jiang , 'Pat Calhoun' , Thomas Panagiotis-PTHOMAS1 , "'aaa-wg@merit.edu'" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Yiwen.Jiang@tic.siemens.ca on Fri, May 11, 2001 at 02:48:09PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, May 11, 2001 at 02:48:09PM -0400, Yiwen Jiang wrote: > > Would this issue not leading back to whether a small diameter base protocol > with many plugin extensions should be defined ? Maybe if we settle on a > concensus on this issue, the question would answer itself? This *is* still supported by the protocol. However, the IESG is concerned about Diameter servers coming out with some extensions, and not others, causing confusion in the market. This is why they have asked that all servers support NASREQ and Mobile IP extensions. PatC > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Friday, May 11, 2001 2:32 PM > > To: Thomas Panagiotis-PTHOMAS1 > > Cc: 'aaa-wg@merit.edu' > > Subject: Re: [AAA-WG]: End-2-End security > > > > > > On Fri, May 11, 2001 at 01:29:25PM -0500, Thomas > > Panagiotis-PTHOMAS1 wrote: > > > "2.0 Protocol Overview > > > ... > > > Diameter servers MUST support the Base protocol, which > > includes Accounting, > > > and both the NASREQ and Mobile IP extensions. Diameter > > Clients MUST support > > > the Base protocol, including Accounting, and MAY support > > any other extension > > > that would be required to provide service." > > > > > > So End-2-End security is a MAY for Clients and Servers, right? > > > > The way the text currently reads, yes I guess so. How do others feel? > > > > PatC > > From owner-aaa-bof@merit.edu Fri May 11 15:08: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 PAA18511 for ; Fri, 11 May 2001 15:08:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0A22D5DED5; Fri, 11 May 2001 15:06:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EB67A5DED4; Fri, 11 May 2001 15:06:27 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id BC4E65DEC4 for ; Fri, 11 May 2001 15:06:26 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24174; Fri, 11 May 2001 12:06:18 -0700 (PDT) Received: from germany.sun.com (muc-isdn-18 [129.157.164.118]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with ESMTP id VAA18329; Fri, 11 May 2001 21:05:53 +0200 (MET DST) Message-ID: <3AFC3AC6.F4B27C7A@germany.sun.com> Date: Fri, 11 May 2001 21:17:26 +0200 From: Erik Guttman Reply-To: Erik.Guttman@sun.com Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: de-DE, fr-FR, en MIME-Version: 1.0 To: David Frascone Cc: Erik Guttman , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Comments on Base v.3 References: <20010511100101.K32596@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 Davem David Frascone wrote: > > We are not voting here. draft-ietf-aaa-issues-04.txt akes the case for > > a regular grammar for Diameter. This WG draft has gone through WG last > > call. It's really up to Paul and Dave to show that this *WG consensus > > action* is off base. > > The issues draft stated that perhaps complex AVPs should be replaced > with a strictly defined grouped AVP. The way I read the document was that > the issues need to be solved, and that we are here to solve them. > > In my opinion, that issue is phrased incorrectly, and I think the complex > AVPs needed to be replaced with grouped AVPs, but not strictly defined. > This (IMO, as always) makes the protocol simpler, and also adds functionality > by allowing the flexibility in a complex type that Diameter has in a message. > > If, on the otherhand, we adhere to a strict BNF, then we gain NO advantage > over a complex type, except that it grows in size. The advantages are that a strict, standard BNF can be expressed in formal notation which is easily interpreted without knowing anything more. draft-ietf-issues-04.txt, section 9.3 Formal notation for application specific data types The use of a formal notation for the definition of (potentially complex) application specific data types has proven to be valuable, especially if a protocol is designed the be extensible. A formal notation enables tools that can (a) verify the correctness of data definitions, (b) automate some of the implementation process, (c) help in debugging scenarios, and (d) enable implementations that can be easily adapted to vendor specific extensions. Furthermore, the separation of the data definitions from the core protocol specification allows extension writers to re-use existing data definitions (e.g. for addressing types) and it thus promotes consistency across a variety of management protocols. The formal notation will serve the extensibility of AAA implementations in terms of their data storage, interpretation, validation, display, etc. Support for the formal notation is in this sense an implementation option to enhance support ease the integration of extensions, but not required for compliance. If data types are not specified by strict rules, like what is there and what the order is, there is no way to satisfy (a)-(d) in a straightforward way. Just saying there may be an ABNF written for any arbitrary message doesn't mean that existing software will have access to it. Note that the ABNF rules and grammar I wrote, which is used in the Diameter spec is helpful for elucidating the protocol, but it is *not* standard ABNF. It is probably extremely difficult for a machine to process the special rules, like for the AVPs surrounded by '[' ']'. > > The perception is that this is at the cost of some RADIUS-like > > flexibility. Well, Diameter allows arbitrary AVPs to be added > > to a message, just not to a Group value. And RADIUS didn't have > > Group values. So the ability to add arbitrary AVPs to Groups doesn't > > amount to less flexibility for Diameter than was present in RADIUS. > > > > The Grouped AVP replaces the complex data type and the Group-AVP bag. > > It facilitates (1) a data dictionary compatible with complex data > > (2) ensures that all components of complex data are present > > But, this seems like an application issue, not a transport one. (Assuming > that the transport would be making these checks) I agree. Also from section 9.3 of draft-ietf-aaa-issues-04.txt: The formal notation is not intended to define the transfer encoding (the on-the-wire byte formatting). The DIAMETER specifications of the base types include these definitions and rules. > > (3) eliminates the need for specialized parsing code for complex data > > The specialized parsing code has already been written to parse normal > AVPs themselves. You are missing the point. Regular grammar plus atomic data types eliminate the need for specialized parsers to be used on arbitrary new commands and AVPs. Generic code could be used for (a) checking AVP records in memory or storage, (b) display and analysis for sniffers, (c) diameter servers which do not need to interpret a particular AVP, but will otherwise process them, etc. Also, although this is not the primary intent, it would be possible to write code to encode and decode arbitrary AVPs from the wire on the basis of a data dictionary - provided that the data dictionary rules were simple and regular enough. > > (4) facilitates automatic parsing / message completeness checking. > > > > If Group values can include arbitrary AVPs, I do not see that they > > serve these 4 ends. > > I agree. But, I don't think the parser/transport whould be doing > completeness checking. It would be easy to generate a parser purely from the definition of the AVP, provided all data types were regular (atomic or composed of atomic components in a fixed manner). > And, I feel that if it is this strict, why are we having the overhead of > the AVPs at all? Why not keep it complex. It's even easier to parse, just > point a structure at it. This requires specialized software, as it cannot be expressed as a regular composition of atomic data types. (If we follow your argument to its conclusion, why have AVPs at all? We can just define a new protocol for each attribute.) > > If the constraints on Group values are truly thought to be too > > binding, let's just eliminate the Group type altogether and go > > back to the RADIUS model of 'strictly' non-organized AVPs > > bundled together to form a message. But let's hear some good > > arguments why this is preferable before revising the position > > supported by draft-ietf-aaa-issues-04.txt. > > I didn't read a "position" in the draft, just a question. And, I think > the question might have been stated improperly. The position is in draft-ietf-aaa-issues-04.txt, Section 9.3.1. The goals for developing a formal notation would be to facilitate the implementation of various functions, such as a data dictionary, a packet filter or an extensible administrative console. Such facilities have been shown to be useful in RADIUS implementations. The facilities based on formal notation for supported AVP would: - make it possible to add new AVP storage, type checking, etc. support without changing code. - make it easier to extend functionality to sniffers, debuggers management tools and DIAMETER implementations (potentially without adding code). Non-goals are to define a formal notation which can express any possible (i.e., non-DIAMETER) message. We only need to express DIAMETER messages which have been currently defined and those messages which are likely to be defined, given experience with RADIUS. It is thought that support for extensible functions would be a useful but not mandatory feature for DIAMETER implementations. > As for arguments, I don't see why we should use the overhead of Grouping > our AVPs, if we don't reap all of the benefits. > > In my opinion, these are the benefits to loosly defined (if at all) grouped > AVPs: > > o) It can be parsed by anyone. (It's not a blob) > o) It is extensable. If a server wants to add another avp > to some grouped information, it can. > > Reasons why Grouped AVPs with a strict definition is better: > o) It can be parsed by anyone. (It's not a blob) > o) The syntax can be checked at the transport level. And at the spec level, and at the code level, and at the storage level, and... > Reasons why complex data is better > o) It is the smallest (transport wise) Diameter is already quite verbose. The maximum that is added is the 8 (possibly 12) byte header. For an Unsigned32 this is a considerable overhead in percentage terms, but overall, considering the number of AVPs present in a message, the savings of Complex over Group is nominal. I checked out the difference in the Diameter commands (at that time) and found the difference - all AVPs considered - to be less than 10% in all cases. > So, I think we are trading transport layer completeness checking with > extensibility. We are trading formality for extensibility. draft-ietf-aaa-issues-04.txt, 9.4 Ordering of Data The current DIAMETER specification says that AVPs can be added arbitrarily as long as the required AVPs are included and AVPs which introduce special requirements and even dependencies between AVPs. (The Session-Id AVPs SHOULD appear first, Integrity-Check-Value AVPs must follow the data to be protected, the Nonce AVP must appear before an Integrity-Check-Value AVP, the last Nonce AVP before an Encrypted-Payload AVP is significant for MD5 payload hiding and so on.) It seems useful to formally define the ordering constraints, potentially restricting the "AVPs can be added arbitrarily" rule to simplify the validation of messages. Note that it is necessary to provide for optional AVPs within a message so that the optional AVPs can be protected by an Integrity-Check-Value AVP. > I'd rather have extensibility. Please address how - without the current grammar for Grouped AVPs - and with *only one* published grammar for each AVP - we can achieve the objectives we set out to achieve in the issues draft. (And if you disagree with the 'issues' draft - please clarify how). Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n SHORT msgs: 01728655497@d2-message.de Sr Staff Engineer, Sun Microsystems Email: erik.guttman@sun.com Altrotstrasse 31, D-69190 Walldorf Germany Mobile: +49 172 865 5497 From owner-aaa-bof@merit.edu Fri May 11 15:30: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 PAA18779 for ; Fri, 11 May 2001 15:30:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7D89F5DE2D; Fri, 11 May 2001 14:41:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6B2B25DE1D; Fri, 11 May 2001 14:41:56 -0400 (EDT) Received: from forsete.erilab.com (forsete.erilab.com [208.224.156.105]) by segue.merit.edu (Postfix) with ESMTP id 776775DDB5 for ; Fri, 11 May 2001 14:41:54 -0400 (EDT) Received: from erilab.com (eblcl50.erilab.com [192.168.174.190]) by forsete.erilab.com (8.11.0/8.11.0) with ESMTP id f4BIfPG10580; Fri, 11 May 2001 11:41:25 -0700 (PDT) Message-ID: <3AFC31F5.CF274809@erilab.com> Date: Fri, 11 May 2001 11:39:49 -0700 From: Michael Chen X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Jones , IETF AAA WG Cc: pcalhoun@diameter.org, tony.johansson@ericsson.com Subject: [AAA-WG]: Route-Record AVP in Failed Indication in 04-alpha1 References: <017401c0da28$abeb1070$2096a8c0@mjones.bridgewatersys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi According to base protocol "A Diameter server that proxies a message of type Request, Query or Indication MUST append a Route-Record AVP, which includes its identity." What should we do with Failed Indication to avoid loop detection if we follow the above rule? How about change Failed Indication to another name but still use the same command code? -Michael Mark Jones wrote: > Pat, > > Noticed a small typo in 4.3 (AVP Data Formats) of -04-alpha1: > > Unsigned64 > 32 bit unsigned value, in network byte order. The AVP Length > field MUST be set to 16 (20 if the 'V' bit is enabled). > > Should read "64 bit unsigned value". > > Regards, > Mark From owner-aaa-bof@merit.edu Fri May 11 15:44:29 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19114 for ; Fri, 11 May 2001 15:44:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8619E5DD96; Fri, 11 May 2001 15:44:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6D5C05DDAE; Fri, 11 May 2001 15:44:15 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D9E035DD96 for ; Fri, 11 May 2001 15:44:12 -0400 (EDT) Received: (qmail 11882 invoked by uid 500); 11 May 2001 19:33:35 -0000 Date: Fri, 11 May 2001 12:33:35 -0700 From: Pat Calhoun To: Paul Funk Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: MRI Fix posted for preview Message-ID: <20010511123335.O10188@charizard.diameter.org> Mail-Followup-To: Paul Funk , Pat Calhoun , aaa-wg@merit.edu References: <20010510175512.A6925@charizard.diameter.org> <4.1.20010511112558.0f705d80@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010511112558.0f705d80@cairo.funk.com>; from paul@funk.com on Fri, May 11, 2001 at 11:32:13AM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, May 11, 2001 at 11:32:13AM -0400, Paul Funk wrote: > Device-Status-Ind handling > -------------------------- > If a proxy receives a DSI response, it may try to rescue the > request by proxying (with the same Identifier) to other servers. > But if all else fails, it must return a DSI to the client from > whence it came. > > My quibble is that it must replace Origin-FQDN/Realm with its > own identity. But why should the proxy take the rap for some > home server that doesn't understand some command code? You > wouldn't want the client to think that such a command code > should not be sent via that proxy. By obfuscating the source > of the error you lose valuable information. > > I think the proxy should be free to treat the DSI as an ordinary > response and just return it as is to the peer from which it > received the request. If it wants to alter the DSI-Event or other > AVPs to provide better information to that peer, only then should > it be required to replace Origin-FQDN/Realm; but not if it is > merely the messenger of a failure not of its own making. > > We shouldn't get carried away by the notion that DSI is a > hop-by-hop message. I think the philosophy should be that > it may be intercepted at any hop, retried, revised, whatever. > But it may also be forwarded upstream unmodified just as > an Answer would. Ok, I can buy your argument. In fact, I thought a distinction was required to differentiate the MRI from the DSI. However, looking at the list of DSI-Events, and the fact that responding to requests (or indications) doesn't require support of the extension, I would argue that all DSI-Events should either: 1. be folded into the Result-Code AVP, or 2. Kept as a separate AVP, but included in normal responses. My biggest issue with the removal of the DSI, is interoperability. If some new extension is developed later on, and some new "events" are created, proxies that do not support the extension wouldn't know how to handle the event notification. Comments? > > Failed Indications > ------------------ > Calling DSI an "Indication" and setting both I and F bits is > misleading. Let's rename "Device-Status-Ind" to > "Device-Status-Failure" and set only the F bit. There is a > fundamental difference between an originated Indication such as > STI or Accounting-Status-Ind and a failure indication such as > DSI. I have added text in section 3.3.2 and in the individual definition of the commands. I have added text to cover this. PatC From owner-aaa-bof@merit.edu Fri May 11 15:49: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 PAA19220 for ; Fri, 11 May 2001 15:49:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 63F075DE5D; Fri, 11 May 2001 15:46:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 533C35DE59; Fri, 11 May 2001 15:46:38 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C9CE65DE4D for ; Fri, 11 May 2001 15:46:36 -0400 (EDT) Received: (qmail 11917 invoked by uid 500); 11 May 2001 19:35:59 -0000 Date: Fri, 11 May 2001 12:35:59 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Failed-Command-Code Message-ID: <20010511123559.Q10188@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, The Failed-Command-Code AVP is no longer required, since the command code is always the same in a response message, so the command code is obvious. Therefore, this AVP will be removed. PatC From owner-aaa-bof@merit.edu Fri May 11 16:04: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 QAA19523 for ; Fri, 11 May 2001 16:04:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E52A95DDD6; Fri, 11 May 2001 16:00:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CEF525DDAD; Fri, 11 May 2001 16:00:33 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id C250E5DDC7 for ; Fri, 11 May 2001 16:00:30 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id PAA01318; Fri, 11 May 2001 15:52:08 -0400 (EDT) Message-Id: <4.1.20010511153642.017c3330@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 11 May 2001 15:39:41 -0400 To: Pat Calhoun From: Paul Funk Subject: Re: [AAA-WG]: Comments on Base v.3 Cc: aaa-wg@merit.edu, Patrice Calhoun In-Reply-To: <20010511104427.I10188@charizard.diameter.org> References: <4.1.20010511120603.017f5ca0@cairo.funk.com> <"Your <4.1.20010511120603.017f5ca0@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 10:44 AM 5/11/01 -0700, Pat Calhoun wrote: >On Fri, May 11, 2001 at 01:22:17PM -0400, Paul Funk wrote: > >[staying away from this one as much as I can, but have the following comment] >> The draft states that when a Redirect DSI is issued, it provides the >> addresses/ports of one or more home servers to redirect to in the >> Redirect-Host grouped AVP, and it may also provide certificates >> for the home server. The question is, if different home servers have >> different certificates, how do you associate each home server with >> the appropriate certificate without extending the Redirect-Host AVP. >> Pat, any thoughts on this question? > >Certificates are distributed as specified in the end-to-end security >draft. A certificate includes the owner's identity. Therefore, there >is no need to combine the certs in the Grouped-AVP because matching >the server with the cert occurs by looking at the details of the cert. I presume the cert would include the name of the server, but not its IP address. But Redirect-Host contains IP address. So I still don't get it. Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Fri May 11 18: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 SAA21679 for ; Fri, 11 May 2001 18:05:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 16E655DDBB; Fri, 11 May 2001 18:05:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 04AE55DDAF; Fri, 11 May 2001 18:05:06 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 48F8F5DDAD for ; Fri, 11 May 2001 18:05:04 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id OAA15770; Fri, 11 May 2001 14:56:33 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 11 May 2001 14:56:33 -0700 (PDT) From: Bernard Aboba To: Jeff Meyer Cc: dmitton@nortelnetworks.com, aaa-wg@merit.edu, Pat Calhoun Subject: [AAA-WG]: Re: AAA Mailing List In-Reply-To: <3AFAF8CE.C9587D5A@hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > In addition it appears that > to "keep the group focused" I've been blocked from posting > to the list. > You have not been blocked -- however, the mailing list does prevent non-members from posting. We've also had intervals where members were unsubscribed, seemingly without justification (I was one of those). We've never gotten a good justification for why this is happening, but given your message and those of others, it seems to have become a significant problem. > However I've asked this question of both Pat and Bernard > and have not gotten any response. Which I interpret to > mean, "Yes you are blocked and I don't want to talk to you" We most certainly want to hear from you, especially if your reason for speaking up is that your messages are being dropped by the mailing list ;) > As Chief Architect for HP's IP Accounting Mediation product, > and someone who has worked with a large number of billing > providers, and lead of IPDR's Protocol Working Group, I > think I have some experience which would be valuable for > your group. > By all means, go ahead and speak up. Note that I did send a reply to your last message which appears not to have made it to the list. We'll see if this reply makes it (I cc'd the list). In general, I'd go ahead and assume that the reason for a lack of response is either a mailing list issue or lack of time/large incoming mail load. Go ahead and resend if you don't get a response within a few days. From owner-aaa-bof@merit.edu Fri May 11 19:00: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 TAA22469 for ; Fri, 11 May 2001 19:00:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D6BB35DE86; Fri, 11 May 2001 15:18:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BDBE55DE61; Fri, 11 May 2001 15:18:04 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id CFFD95DE84 for ; Fri, 11 May 2001 15:18:02 -0400 (EDT) Received: (qmail 11803 invoked by uid 500); 11 May 2001 19:07:25 -0000 Date: Fri, 11 May 2001 12:07:25 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'Pat Calhoun'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Comments on draft-mobileip-03 Message-ID: <20010511120724.N10188@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , 'Pat Calhoun' , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA01D7FFDE@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA01D7FFDE@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Thu, May 10, 2001 at 03:06:27PM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Thu, May 10, 2001 at 03:06:27PM +0200, Martin Julien (ECE) wrote: > > > > 6- Second paragraph of page 6, I'm still wondering why a > > DIAMETER_ERROR_BAD_HAR > > > is required? What is it supposed to mean? We do not have > > this type of generic > > > error for any other extension, and I don't see why we > > should have this for MIP. > > > > If a Home Agent was requested, and the home agent is not > > available, then > > the error is returned. This could occur if the mobile > > requested a home agent > > that it is not allowed to, or if the home agent is no longer > > available. > > I thought that DIAMETER_ERROR_HA_NOT_AVAILABLE was meant for that? > The thing is that with the DIAMETER_ERROR_BAD_HAR, it does not > seem to be clear for the client to know what to do, for example, > simply request a new HA. oops, I was a little too quick in responding to the question, and you are correct, the error message *BAD_HAR is really not required, as there are more useful error messages in the base protocol. > > > > 7- Page 8, second par., the thing is that I think that AAAH > > can determine that > > > the MN has moved to a new domain by using the Origin-FQDN and the > > > MIP-Previous-FA-FQDN. However, I'm wondering if the > > MIP-Previous-FA-FQDN is > > > enough, since the FQDN is highly dependent on the realm of > > the MIP-Previous-FA-XXXX, > > > right? You can only tell that the MN is moving between > > domain based on the Realms. > > > > Correct, so you will have to remove all the data, and the > > first dot, in the > > fqdn, and that will produce the realm. > > > > Did I miss the question? > > > > > > And now, let's say that the HA is located in the former > > domain, then how can the > > > AAAF knows that the MN has registered in an other domain? > > The MIP-Previous-FA-FQDN > > > can not really help, since it will be in that domain from > > where it moved. The > > > AAAF does not have any mean of knowing the originator of > > the AMR, AFAIK. I guess > > > that a MIP-Registering-FA-FQDN AVP should be added for that purpose. > > > > I really don't understand the problem (sorry, a little dense > > today), but > > I see that you believe that a new AVP would be required that > > contains the > > identity of the foreign agent, right? And why is that? > > Rereading my question, I guess it was not really clear. Let's > try it again. > > In fact, you should refer to page 9, the last paragraph. It is > mentionned that the AAAH can used the MIP-Home-Agent-Address and > the MIP-Previous-FA-FQDN to detect if the MN has moved to a new > domain. Here are the problems: > > 1) In section 5.5, it is said that the MIP-Previous-FA-FQDN is > sent by the MN while roaming within the same domain. If it remains > like this, I guess it would not be possible to detect that the MN > has moved to another domain based on that AVP, since it might not > have beed included. sure. > > 2) I think that MIP-Home-Agent-Address and the MIP-Previous-FA-FQDN > AVPs are not enough to detect that the MN has moved to a new domain. > I think that the only way that an AAAH can detect it, is by using > the Origin-Realm and the MIP-Previous-FA-FQDN. Then, it could compare > the Origin-Realm of the FA (the new) with the FQDN of the previous FA, > i.e. MIP-Previous-FA-FQDN. yes, this does make sense, and I have made the change. > > 3) The problem with the previous comment, is that the MIP-Previous-FA-FQDN > does not represent the realm of the previous domain, only the FQDN of the > FA, which might be only routable by the AAAF, right? I am not sure that > the discussion we had on the mailing list a while ago suggested that the > FQDN (let's say ABC.com) was the realm plus another name > (let's MACHINE1.ABC.com). That does not make sense to me at least. If it > would have been like that, I would argue that we do not need two > destination FQDN and Realm. It is, and the reason why we have two separate AVPs is to reduce the amount of work done on proxies. This has been done in RADIUS via some vendor-specific AVPs, because otherwise each proxy must extract the FQDN, and retrieve the Realm. Not alot of work, but very repetitive, so let's save some CPU cycles while we can. And, btw, if we only had the Destination-FQDN, it wouldimplies that a message would have to be sent to a specific Diameter entity, not any one in a given domain. > > 4) The decision to reject the access to the HA seems to be possible by > the former AAAF. The thing is that I don't know how it can know that > the MN has moved for sure to another domain. Based on the > MIP-Previous-FA-FQDN does not help, since it will most probably be > in that domain as well, since the MN has just moved out of it to > another domain, right? Also, the Origin-Realm of the AMR, which > identifies the originating FA, is not available in the HAR, only > in the AMR. So, unless we had in the HAR an AVP for the Origin-FA, > I do not see how the former AAAF could perform policies to reject > such a service. yes, I agree that this is required to make the necessary policy decisions. > > ok, I see your point. The information is redundant. However, > > I don't really > > like that a zero HA or home address doesn't require that the > > AVP be present, > > since a -1 value DOES require that it be present. > > > > Do others agree that these two bits should be removed? > > The thing is that the spec especially mentions in section > 2.1, that if those flags are set, those AVPs MUST NOT be > present in the message. not sure this really needs to be a MUST NOT. > > I would tend to agree that I would > prefer that decision to be left to the AAAH, or the AAAF, > to decide the meaning of the content of those AVPs, instead of > not sending the AVPs of setting a flag. Well, the flags *are* necessary for accounting purposes. No way around that. The Feature-Vector in the accounting message will provide some details on the type of session being provided. At the same time, you want the home address and agent to be in the accounting record, so including the zero or all ones in the accounting message would be bad. So, bits are necessary. The real question is whether it really makes sense to state that the AVPs MUST NOT be included if the bits are set. Anyone? > > > > 14-Page 20, par.3, I don't think it is the correct meaning. > > My understanding, after > > > talking with Tony Johansson, is that the > > Home-Agent-In-Foreign-Network is used when > > > the MN requests a Home-Agent, and that the AAAF detects > > that it is located in its > > > foreign domain, before it forwards the AMR to the AAAH. > > > > It now reads: > > > > "If the mobile node requests a home agent in the foreign > > network either > > by setting the home address field to all ones, or by specifying > > 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." > > Then, should an AAAF return a DIAMETER_ERROR_HA_NOT_AVAILABLE > when it can not allocate it? yes. > > > > 22- Section 8.2 and 8.5, should be "by the user" instead of > > "to the user". > > > > Output packets and octets are those sent to the user, not by the user. > > You are confusing these with the input counters. > > The confusion is from what you say for Input and what you say for > Output. In 8.1, you say "received by the user", and in 8.2, you say > "sent to the user". Maybe you meant, in 8.1, "received from the user"? > Also apply to 8.4 and 8.5. so "received by the user" -> "received from the user" "sent to the user" stays the way it is. right? > > If there is something more I should know about the difference between > them, maybe it would be good to add some more text in the descriptionç > of those AVPs. no, just poor choice of english words on my part :( Thanks again, PatC From owner-aaa-bof@merit.edu Fri May 11 20:15:23 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23268 for ; Fri, 11 May 2001 20:15:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D6F65DE3E; Fri, 11 May 2001 16:03:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4FAB85DE54; Fri, 11 May 2001 16:03:04 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B97FD5DE3E for ; Fri, 11 May 2001 16:03:02 -0400 (EDT) Received: (qmail 11956 invoked by uid 500); 11 May 2001 19:52:25 -0000 Date: Fri, 11 May 2001 12:52:24 -0700 From: Pat Calhoun To: Paul Funk Cc: Pat Calhoun , aaa-wg@merit.edu, Patrice Calhoun Subject: Re: [AAA-WG]: Comments on Base v.3 Message-ID: <20010511125224.R10188@charizard.diameter.org> Mail-Followup-To: Paul Funk , Pat Calhoun , aaa-wg@merit.edu, Patrice Calhoun References: <4.1.20010511120603.017f5ca0@cairo.funk.com> <"Your <4.1.20010511120603.017f5ca0@cairo.funk.com> <20010511104427.I10188@charizard.diameter.org> <4.1.20010511153642.017c3330@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010511153642.017c3330@cairo.funk.com>; from paul@funk.com on Fri, May 11, 2001 at 03:39:41PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, May 11, 2001 at 03:39:41PM -0400, Paul Funk wrote: > At 10:44 AM 5/11/01 -0700, Pat Calhoun wrote: > >On Fri, May 11, 2001 at 01:22:17PM -0400, Paul Funk wrote: > > > >[staying away from this one as much as I can, but have the following comment] > >> The draft states that when a Redirect DSI is issued, it provides the > >> addresses/ports of one or more home servers to redirect to in the > >> Redirect-Host grouped AVP, and it may also provide certificates > >> for the home server. The question is, if different home servers have > >> different certificates, how do you associate each home server with > >> the appropriate certificate without extending the Redirect-Host AVP. > >> Pat, any thoughts on this question? > > > >Certificates are distributed as specified in the end-to-end security > >draft. A certificate includes the owner's identity. Therefore, there > >is no need to combine the certs in the Grouped-AVP because matching > >the server with the cert occurs by looking at the details of the cert. > > I presume the cert would include the name of the server, but not its IP > address. But Redirect-Host contains IP address. So I still don't get it. > The obvious fix is for the Redirect-Host AVP to contain an FQDN instead, which can be resolved via DNS anyways. Would this fix the problem? PatC From owner-aaa-bof@merit.edu Fri May 11 20:22: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 UAA23311 for ; Fri, 11 May 2001 20:22:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D80845DDE6; Fri, 11 May 2001 20:22:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C16365DDDB; Fri, 11 May 2001 20:22:24 -0400 (EDT) Received: from forsete.erilab.com (forsete.erilab.com [208.224.156.105]) by segue.merit.edu (Postfix) with ESMTP id 367EE5DDAD for ; Fri, 11 May 2001 20:22:23 -0400 (EDT) Received: from erilab.com (eblcl50.erilab.com [192.168.174.190]) by forsete.erilab.com (8.11.0/8.11.0) with ESMTP id f4C0M5G10917; Fri, 11 May 2001 17:22:05 -0700 (PDT) Message-ID: <3AFC8189.B21A5F7E@erilab.com> Date: Fri, 11 May 2001 17:19:21 -0700 From: Michael Chen X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: IETF AAA WG , tony.johansson@ericsson.com Subject: Re: [AAA-WG]: Route-Record AVP in Failed Indication in 04-alpha1 References: <017401c0da28$abeb1070$2096a8c0@mjones.bridgewatersys.com> <3AFC31F5.CF274809@erilab.com> <20010511113743.K10188@charizard.diameter.org> Content-Type: multipart/alternative; boundary="------------82B3F9E33A686EAB686B8775" Sender: owner-aaa-bof@merit.edu Precedence: bulk --------------82B3F9E33A686EAB686B8775 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pat, It seems that I didn't properly state my question in previous email, let me try again and explain in an example. (Route-Record=dia1.mno.net) (Route-Record=dia1.mno.net) (Route-Record=dia2.xyz.com) +------+ ------> +------+ ------> +------+ | | (STI indication) | | (STI indication) | | | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | | | | | | | +------+ <------ +------+ <------ +------+ mno.net xyz.com (Failed Indication) abc.com Route-Record=????? DIA1 add route-record and send the STI indication to DIA2 DIA2 add route-record and send the STI indication to DIA3 DIA3 received the STI and don't like the message and send STI failed indication back. What about the route-record avp? 1. Should the DIA3 remove the route-record avps in received STI and add its own, i.e treat it as a new Indication. This means that route path back may be different. 2. Or, should the DIA3 handle the STI message just like an Answer, in other words the DIA3 send the STI Failed Indication to the destination in last route-record avp and do NOT add its own? -Michael Pat Calhoun wrote: > On Fri, May 11, 2001 at 11:39:49AM -0700, Michael Chen wrote: > > Hi > > > > According to base protocol > > "A Diameter server that proxies a message of type Request, Query or > > Indication MUST append a Route-Record AVP, which includes its > > identity." > > sigh. My eyes were open for "Responses", and I completely missed > the Queries. Anyways all references to Query messages have now been > removed. > > > What should we do with Failed Indication to avoid loop detection if we > > follow the above rule? > > A failed response is handled just like an answer, so this is not an > issue. > > > How about change Failed Indication to another name but still use the same > > command code? > > What name would you propose? > > PatC --------------82B3F9E33A686EAB686B8775 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Pat,

   It seems that I didn't properly state my question in previous email,
let me try again and explain in an example.
 

         (Route-Record=dia1.mno.net)   (Route-Record=dia1.mno.net)
                                       (Route-Record=dia2.xyz.com)
      +------+      ------>      +------+      ------>      +------+
      |      |  (STI indication) |      |  (STI indication) |      |
      | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 |
      |      |                   |      |                   |      |
      +------+      <------      +------+      <------      +------+
      mno.net                    xyz.com  (Failed Indication) abc.com
                                        Route-Record=?????
 

DIA1 add route-record and send the STI indication to DIA2
DIA2 add route-record and send the STI indication to DIA3
DIA3 received the STI and don't like the message and
send STI failed indication back.

What about the route-record avp?

1. Should the DIA3 remove the route-record avps in received STI and add its own,
   i.e treat it as a new Indication. This means that route path back may be different.
 
2. Or, should the DIA3 handle the STI message just like an Answer, in other words
the DIA3 send the STI Failed Indication to the destination in last route-record
avp and do NOT add its own?
 

-Michael
 
 
 
 
 
 
 

Pat Calhoun wrote:

On Fri, May 11, 2001 at 11:39:49AM -0700, Michael Chen wrote:
> Hi
>
> According to base protocol
>    "A Diameter server that proxies a message of type Request, Query or
>    Indication MUST append a Route-Record AVP, which includes its
>    identity."

sigh. My eyes were open for "Responses", and I completely missed
the Queries. Anyways all references to Query messages have now been
removed.

> What should we do with Failed Indication to avoid loop detection if we
> follow the above rule?

A failed response is handled just like an answer, so this is not an
issue.

> How about change Failed Indication to another name but still use the same
> command code?

What name would you propose?

PatC

--------------82B3F9E33A686EAB686B8775-- From owner-aaa-bof@merit.edu Fri May 11 20:37: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 UAA23430 for ; Fri, 11 May 2001 20:37:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DDD845DDAD; Fri, 11 May 2001 20:37:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BF7C85DDDB; Fri, 11 May 2001 20:37:03 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 2F7775DDAD for ; Fri, 11 May 2001 20:37:02 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id UAA01861; Fri, 11 May 2001 20:28:38 -0400 (EDT) Message-Id: <4.1.20010511192031.0177dc50@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 11 May 2001 20:16:09 -0400 To: Pat Calhoun From: Paul Funk Subject: Re: [AAA-WG]: Comments on Base v.3 Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010511125224.R10188@charizard.diameter.org> References: <4.1.20010511153642.017c3330@cairo.funk.com> <4.1.20010511120603.017f5ca0@cairo.funk.com> <"Your <4.1.20010511120603.017f5ca0@cairo.funk.com> <20010511104427.I10188@charizard.diameter.org> <4.1.20010511153642.017c3330@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 12:52 PM 5/11/01 -0700, Pat Calhoun wrote: >On Fri, May 11, 2001 at 03:39:41PM -0400, Paul Funk wrote: >> At 10:44 AM 5/11/01 -0700, Pat Calhoun wrote: >> >On Fri, May 11, 2001 at 01:22:17PM -0400, Paul Funk wrote: >> > >> >[staying away from this one as much as I can, but have the following >comment] >> >> The draft states that when a Redirect DSI is issued, it provides the >> >> addresses/ports of one or more home servers to redirect to in the >> >> Redirect-Host grouped AVP, and it may also provide certificates >> >> for the home server. The question is, if different home servers have >> >> different certificates, how do you associate each home server with >> >> the appropriate certificate without extending the Redirect-Host AVP. >> >> Pat, any thoughts on this question? >> > >> >Certificates are distributed as specified in the end-to-end security >> >draft. A certificate includes the owner's identity. Therefore, there >> >is no need to combine the certs in the Grouped-AVP because matching >> >the server with the cert occurs by looking at the details of the cert. >> >> I presume the cert would include the name of the server, but not its IP >> address. But Redirect-Host contains IP address. So I still don't get it. >> >The obvious fix is for the Redirect-Host AVP to contain an FQDN instead, >which can be resolved via DNS anyways. > >Would this fix the problem? Oh well, I guess I can't goad you into taking a position on polymorphic groups. Sure, it fixes the problem, at least as we currently understand the problem. To do so, you needed to overload a single AVP with information that both dereferences an entity's address and its certificate. As long as the same FQDN can stand for both, yes, it will work. But this illustrates the problem with fixed groups -- you need to anticipate everything in advance, because you'll have no room to improvise later. If this problem was noticed a month later, we'd have to invent a alternative AVP to package up the same information in a different form, because Redirect-Host would be untouchable. Plus, we're committing to FQDN as the subjectAltName in a cert, and E2E has not even been well discussed yet. What if we want to be able to have a single cert for an entire realm, so you can sign things without knowing exactly which server it will go to? Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Fri May 11 21:20: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 VAA23813 for ; Fri, 11 May 2001 21:20:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3FC525DDDB; Fri, 11 May 2001 21:19:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2EF4B5DDF3; Fri, 11 May 2001 21:19:57 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 8B4D25DDDB for ; Fri, 11 May 2001 21:19:55 -0400 (EDT) Received: (qmail 14898 invoked by uid 500); 12 May 2001 01:09:17 -0000 Date: Fri, 11 May 2001 18:09:16 -0700 From: Pat Calhoun To: Michael Chen Cc: Pat Calhoun , IETF AAA WG , tony.johansson@ericsson.com Subject: Re: [AAA-WG]: Route-Record AVP in Failed Indication in 04-alpha1 Message-ID: <20010511180916.W10188@charizard.diameter.org> Mail-Followup-To: Michael Chen , Pat Calhoun , IETF AAA WG , tony.johansson@ericsson.com References: <017401c0da28$abeb1070$2096a8c0@mjones.bridgewatersys.com> <3AFC31F5.CF274809@erilab.com> <20010511113743.K10188@charizard.diameter.org> <3AFC8189.B21A5F7E@erilab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AFC8189.B21A5F7E@erilab.com>; from cchen@erilab.com on Fri, May 11, 2001 at 05:19:21PM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, May 11, 2001 at 05:19:21PM -0700, Michael Chen wrote: > Pat, > > It seems that I didn't properly state my question in previous email, > let me try again and explain in an example. > > > (Route-Record=dia1.mno.net) (Route-Record=dia1.mno.net) > (Route-Record=dia2.xyz.com) > +------+ ------> +------+ ------> +------+ > | | (STI indication) | | (STI indication) | | > | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | > | | | | | | > +------+ <------ +------+ <------ +------+ > mno.net xyz.com (Failed Indication) abc.com > Route-Record=????? > > > DIA1 add route-record and send the STI indication to DIA2 First off, the text specifically states: Figure 2 depicts an example where DIA1 is an access device and receives a request for network access from jow@abc.com... So, DIA1 is an access device, and therefore does not add a record route. The Origin-FQDN is sufficient, just like a Request. > DIA2 add route-record and send the STI indication to DIA3 > DIA3 received the STI and don't like the message and > send STI failed indication back. ok > > What about the route-record avp? > > 1. Should the DIA3 remove the route-record avps in received STI and add its > own, > i.e treat it as a new Indication. This means that route path back may be > different. no > > 2. Or, should the DIA3 handle the STI message just like an Answer, in other > words > the DIA3 send the STI Failed Indication to the destination in last route-record > > avp and do NOT add its own? correct. Is a separate figure, or text stating that an Indication/Failed Indication is the same as Request and answer? PatC From owner-aaa-bof@merit.edu Fri May 11 23:45: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 XAA27857 for ; Fri, 11 May 2001 23:45:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E5F7D5DDC7; Fri, 11 May 2001 18:07:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CB8F55DDAF; Fri, 11 May 2001 18:07:24 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 0B1465DDAD for ; Fri, 11 May 2001 18:07:23 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id OAA15774; Fri, 11 May 2001 14:58:58 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 11 May 2001 14:58:58 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: Thomas Panagiotis-PTHOMAS1 , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: End-2-End security In-Reply-To: <20010511113210.J10188@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > So End-2-End security is a MAY for Clients and Servers, right? > > The way the text currently reads, yes I guess so. How do others feel? > Hmmm... didn't we decide it was a MUST at the last Interim meeting and at IETF 50? That's what the minutes say. From owner-aaa-bof@merit.edu Sun May 13 14:19:37 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13358 for ; Sun, 13 May 2001 14:19:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C39965DD8C; Sun, 13 May 2001 14:18:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A922F5DE9A; Sun, 13 May 2001 14:18:01 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id EB5405DD8C for ; Sun, 13 May 2001 14:17:59 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id OAA04018; Sun, 13 May 2001 14:10:00 -0400 (EDT) Message-Id: <4.1.20010513135510.0178e7c0@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 13 May 2001 13:57:33 -0400 To: aaa-wg@merit.edu, Patrice Calhoun From: Paul Funk Subject: [AAA-WG]: DWR retransmission Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Since Diameter is defined over a reliable transport, sending more than one DWR seems unnecessary. If the peer does not respond to the first DWR with a DWA within a reasonable interval, it can be assumed to be DOA. Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Sun May 13 19:17:38 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15099 for ; Sun, 13 May 2001 19:17:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 81CCD5DE74; Sun, 13 May 2001 18:56:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 64C005DE73; Sun, 13 May 2001 18:56:27 -0400 (EDT) Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id C1DD15DDA5 for ; Sun, 13 May 2001 18:56:25 -0400 (EDT) Received: (qmail 9521 invoked by uid 500); 13 May 2001 23:04:28 -0000 Date: Sun, 13 May 2001 18:04:27 -0500 From: David Frascone To: anand@samsung.co.kr Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Re: [diameter] C++ API Message-ID: <20010513180427.C6548@newman.frascone.com> Mail-Followup-To: anand@samsung.co.kr, 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 anand@samsung.co.kr on Fri, May 11, 2001 at 02:22:35AM +0900 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk [ moving to aaa-wg, since this is a WG document now ] There is no C++ API . . . yet. There definately needs to be one though. I belive a section needs to be added to the AAA-API. On Fri, May 11, 2001 at 02:22:35AM +0900, anand@samsung.co.kr wrote: > > Hi, > Is anyone aware of the presence of a C++ version > of the Diameter API. Please let me know. > > regards, > anand > From owner-aaa-bof@merit.edu Mon May 14 04:09:10 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05325 for ; Mon, 14 May 2001 04:09:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6595E5DEBE; Mon, 14 May 2001 04:08:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 471A05DEC5; Mon, 14 May 2001 04:08:48 -0400 (EDT) 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 E4E875DEBE for ; Mon, 14 May 2001 04:08:45 -0400 (EDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f4E88jO07708 for ; Mon, 14 May 2001 10:08:45 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon May 14 10:08:44 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 10:08:43 +0200 Message-ID: <577066326047D41180AC00508B955DDA01D7FFE3@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Comments on draft-mobileip-03 Date: Mon, 14 May 2001 10:08:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk See comments enclosed. > > 3) The problem with the previous comment, is that the > MIP-Previous-FA-FQDN > > does not represent the realm of the previous domain, only > the FQDN of the > > FA, which might be only routable by the AAAF, right? I am > not sure that > > the discussion we had on the mailing list a while ago > suggested that the > > FQDN (let's say ABC.com) was the realm plus another name > > (let's MACHINE1.ABC.com). That does not make sense to me at > least. If it > > would have been like that, I would argue that we do not need two > > destination FQDN and Realm. > > It is, and the reason why we have two separate AVPs is to > reduce the amount > of work done on proxies. This has been done in RADIUS via > some vendor-specific > AVPs, because otherwise each proxy must extract the FQDN, and > retrieve the > Realm. Not alot of work, but very repetitive, so let's save some CPU > cycles while we can. > > And, btw, if we only had the Destination-FQDN, it wouldimplies that a > message would have to be sent to a specific Diameter entity, not > any one in a given domain. My understanding was that the FQDN can be also a machine on a different domain then the one publish by the proxy. I mean that the back-end of the proxy could connect to several internal domains, which are not related at all with the one of the proxy. Let's say I have some servers within my corporate network defined in one domain (ABC.COM), while my proxy domain shows another one (ACME.COM). I was not expecting the servers on my corporate network to be defined as DIA1.ACME.COM. Also, I assume that it would not be allowed to define an FQDN for my corporate servers like DIA1.net1.ACME.COM, for the case you are referring to, right? > > I would tend to agree that I would > > prefer that decision to be left to the AAAH, or the AAAF, > > to decide the meaning of the content of those AVPs, instead of > > not sending the AVPs of setting a flag. > > Well, the flags *are* necessary for accounting purposes. No way > around that. The Feature-Vector in the accounting message will > provide some details on the type of session being provided. At > the same time, you want the home address and agent to be in the > accounting record, so including the zero or all ones in the > accounting message would be bad. So, if it is bad, then why are you asking the question in the next paragraph, whether AVPs with 0.0.0.0 or 255.255.255.255 should at all be included in the message? > So, bits are necessary. The real question is whether it really makes > sense to state that the AVPs MUST NOT be included if the bits are > set. > > Anyone? I really don't mind which way it has to work, even though I still think it makes more sense to simply add AVPs to the AMR messages about the Home Agent and Home Address that correspond to the content of the MIP message, rather than the FA playing around with the meaning of them itself. > > > > 22- Section 8.2 and 8.5, should be "by the user" instead of > > > "to the user". > > > > > > Output packets and octets are those sent to the user, not > by the user. > > > You are confusing these with the input counters. > > > > The confusion is from what you say for Input and what you say for > > Output. In 8.1, you say "received by the user", and in 8.2, you say > > "sent to the user". Maybe you meant, in 8.1, "received from > the user"? > > Also apply to 8.4 and 8.5. > > so "received by the user" -> "received from the user" > "sent to the user" stays the way it is. > > right? Perfect. Thanks a lot! Martin From owner-aaa-bof@merit.edu Mon May 14 04:48:09 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05622 for ; Mon, 14 May 2001 04:48:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DC43F5DF07; Mon, 14 May 2001 04:38:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2F9905DEE7; Mon, 14 May 2001 04:38:00 -0400 (EDT) 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 8911B5DED9 for ; Mon, 14 May 2001 04:36:59 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f4E8awO06103 for ; Mon, 14 May 2001 10:36:58 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon May 14 10:36:57 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 10:36:57 +0200 Message-ID: <577066326047D41180AC00508B955DDA01D7FFE4@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , Yiwen Jiang Cc: Thomas Panagiotis-PTHOMAS1 , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: End-2-End security Date: Mon, 14 May 2001 10:36:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > > Would this issue not leading back to whether a small > diameter base protocol > > with many plugin extensions should be defined ? Maybe if we > settle on a > > concensus on this issue, the question would answer itself? > > This *is* still supported by the protocol. However, the IESG > is concerned > about Diameter servers coming out with some extensions, and > not others, > causing confusion in the market. This is why they have asked that all > servers support NASREQ and Mobile IP extensions. > > PatC Even though the NasReq and Mobile-IP extensions will be the first 2 extensions to be used on top of Diameter, I really do not see any point of making the Base protocol dependent on its extensions. Maybe what you meant is that AAA servers need to support Diameter and those 2 extensions, not necessarily all Diameter nodes. I suspect that the original concerns of the IESG behind supporting those 2 extensions was for proxy servers, who would not necessarily be capable of supporting policies for those extensions. Now that the EIR flags have been fixed for supporting all types of messages, the only thing that remains for proxy servers to support extensions in their policies, is to add the required AVPs in their AVP dictionary. I'd prefer Diameter nodes supporting the Base protocol, and whatever extensions they need, which is standardized and controlled by IANA, as far as I know. Regards, Martin > > > -----Original Message----- > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > Sent: Friday, May 11, 2001 2:32 PM > > > To: Thomas Panagiotis-PTHOMAS1 > > > Cc: 'aaa-wg@merit.edu' > > > Subject: Re: [AAA-WG]: End-2-End security > > > > > > > > > On Fri, May 11, 2001 at 01:29:25PM -0500, Thomas > > > Panagiotis-PTHOMAS1 wrote: > > > > "2.0 Protocol Overview > > > > ... > > > > Diameter servers MUST support the Base protocol, which > > > includes Accounting, > > > > and both the NASREQ and Mobile IP extensions. Diameter > > > Clients MUST support > > > > the Base protocol, including Accounting, and MAY support > > > any other extension > > > > that would be required to provide service." > > > > > > > > So End-2-End security is a MAY for Clients and Servers, right? > > > > > > The way the text currently reads, yes I guess so. How do > others feel? > > > > > > PatC > > > > From owner-aaa-bof@merit.edu Mon May 14 13:47:48 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19658 for ; Mon, 14 May 2001 13:47:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 497265E679; Mon, 14 May 2001 11:50:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 901B35E609; Mon, 14 May 2001 11:43:42 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 43ED65E071 for ; Mon, 14 May 2001 09:53:10 -0400 (EDT) Received: (qmail 26989 invoked by uid 500); 14 May 2001 13:42:23 -0000 Date: Mon, 14 May 2001 06:42:23 -0700 From: Pat Calhoun To: Stephen Farrell Cc: Bernard Aboba , Pat Calhoun , Thomas Panagiotis-PTHOMAS1 , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: End-2-End security Message-ID: <20010514064223.H10188@charizard.diameter.org> Mail-Followup-To: Stephen Farrell , Bernard Aboba , Pat Calhoun , Thomas Panagiotis-PTHOMAS1 , "'aaa-wg@merit.edu'" References: <3AFFD560.787BE3DF@baltimore.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AFFD560.787BE3DF@baltimore.ie>; from stephen.farrell@baltimore.ie on Mon, May 14, 2001 at 01:53:52PM +0100 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, May 14, 2001 at 01:53:52PM +0100, Stephen Farrell wrote: > > > Bernard Aboba wrote: > > > > > > So End-2-End security is a MAY for Clients and Servers, right? > > > > > > The way the text currently reads, yes I guess so. How do others feel? > > > > > Hmmm... didn't we decide it was a MUST at the last Interim meeting and at > > IETF 50? That's what the minutes say. > > I thought the concensus at the meeting was that the e2e scheme must be specified > and must progress (WG last call etc.) alongside the base protocol. I didn't > think that it was every Diameter node MUST implement e2e. Would it be > worthwhile if we could get a more fine-grained concensus? Say, along the lines > of: "Diameter nodes which process AVPs x,y,z MUST implement e2e, those that > process AVPs u,v,w SHOULD implement e2e and others MAY implement e2e". If any such statement needs to be made, it would be more like "Diameter implementations that support extension foo or bar, not individual AVPs that comprises an extension. PatC From owner-aaa-bof@merit.edu Mon May 14 14:20:15 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20434 for ; Mon, 14 May 2001 14:20:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8DAB05E123; Mon, 14 May 2001 09:35:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 002B75E1A0; Mon, 14 May 2001 09:23:18 -0400 (EDT) Received: from balinese.baltimore.ie (pc215-8.indigo.ie [194.125.215.8]) by segue.merit.edu (Postfix) with ESMTP id 89C1D5E18E for ; Mon, 14 May 2001 08:52:00 -0400 (EDT) Received: by balinese.baltimore.ie; id NAA22721; Mon, 14 May 2001 13:51:55 +0100 (GMT/IST) Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma022286; Mon, 14 May 01 13:51:08 +0100 Received: from Baltimore-FW1 (wilde-i.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with SMTP id for ; Mon, 14 May 2001 13:49:40 +0100 Received: from baltimore.ie (ip226-24.ie.baltimore.com [10.153.24.226]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id NAA12456; Mon, 14 May 2001 13:56:39 +0100 Message-ID: <3AFFD560.787BE3DF@baltimore.ie> Date: Mon, 14 May 2001 13:53:52 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: Pat Calhoun , Thomas Panagiotis-PTHOMAS1 , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: End-2-End security 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: > > > > So End-2-End security is a MAY for Clients and Servers, right? > > > > The way the text currently reads, yes I guess so. How do others feel? > > > Hmmm... didn't we decide it was a MUST at the last Interim meeting and at > IETF 50? That's what the minutes say. I thought the concensus at the meeting was that the e2e scheme must be specified and must progress (WG last call etc.) alongside the base protocol. I didn't think that it was every Diameter node MUST implement e2e. Would it be worthwhile if we could get a more fine-grained concensus? Say, along the lines of: "Diameter nodes which process AVPs x,y,z MUST implement e2e, those that process AVPs u,v,w SHOULD implement e2e and others MAY implement e2e". Of course, if people are happy to make e2e a MUST or SHOULD for all implementations, I wouldn't have a problem with that. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-bof@merit.edu Mon May 14 14:35:04 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20932 for ; Mon, 14 May 2001 14:35:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BC3E65E31A; Mon, 14 May 2001 11:58:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3BB155E3F0; Mon, 14 May 2001 11:21:26 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id A6D4B5E2CC for ; Mon, 14 May 2001 09:50:52 -0400 (EDT) Received: (qmail 26965 invoked by uid 500); 14 May 2001 13:40:06 -0000 Date: Mon, 14 May 2001 06:40:06 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'Pat Calhoun'" , Yiwen Jiang , Thomas Panagiotis-PTHOMAS1 , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: End-2-End security Message-ID: <20010514064006.F10188@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , 'Pat Calhoun' , Yiwen Jiang , Thomas Panagiotis-PTHOMAS1 , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA01D7FFE4@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA01D7FFE4@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Mon, May 14, 2001 at 10:36:57AM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, May 14, 2001 at 10:36:57AM +0200, Martin Julien (ECE) wrote: > > > Would this issue not leading back to whether a small > > diameter base protocol > > > with many plugin extensions should be defined ? Maybe if we > > settle on a > > > concensus on this issue, the question would answer itself? > > > > This *is* still supported by the protocol. However, the IESG > > is concerned > > about Diameter servers coming out with some extensions, and > > not others, > > causing confusion in the market. This is why they have asked that all > > servers support NASREQ and Mobile IP extensions. > > > > PatC > > Even though the NasReq and Mobile-IP extensions will be the first > 2 extensions to be used on top of Diameter, I really do not see > any point of making the Base protocol dependent on its extensions. > Maybe what you meant is that AAA servers need to support Diameter > and those 2 extensions, not necessarily all Diameter nodes. I suspect > that the original concerns of the IESG behind supporting those 2 > extensions was for proxy servers, who would not necessarily be capable > of supporting policies for those extensions. Now that the EIR flags > have been fixed for supporting all types of messages, the only thing > that remains for proxy servers to support extensions in their policies, > is to add the required AVPs in their AVP dictionary. I'd prefer Diameter > nodes supporting the Base protocol, and whatever extensions they need, > which is standardized and controlled by IANA, as far as I know. You have a good point. Let me bring this back up with the IESG. PatC From owner-aaa-bof@merit.edu Mon May 14 15:05:42 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21830 for ; Mon, 14 May 2001 15:05:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F22545DEA9; Mon, 14 May 2001 14:34:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 42A835E369; Mon, 14 May 2001 11:58:50 -0400 (EDT) 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 F0D905E2F6 for ; Mon, 14 May 2001 11:03:11 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f4EF3BN29606 for ; Mon, 14 May 2001 17:03:11 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Mon May 14 17:03:10 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 17:03:10 +0200 Message-ID: <577066326047D41180AC00508B955DDA01D7FFEE@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Comments on draft-mobileip-03 Date: Mon, 14 May 2001 16:59:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > > > > 3) The problem with the previous comment, is that the > > > MIP-Previous-FA-FQDN > > > > does not represent the realm of the previous domain, only > > > the FQDN of the > > > > FA, which might be only routable by the AAAF, right? I am > > > not sure that > > > > the discussion we had on the mailing list a while ago > > > suggested that the > > > > FQDN (let's say ABC.com) was the realm plus another name > > > > (let's MACHINE1.ABC.com). That does not make sense to me at > > > least. If it > > > > would have been like that, I would argue that we do not > need two > > > > destination FQDN and Realm. > > > > > > It is, and the reason why we have two separate AVPs is to > > > reduce the amount > > > of work done on proxies. This has been done in RADIUS via > > > some vendor-specific > > > AVPs, because otherwise each proxy must extract the FQDN, and > > > retrieve the > > > Realm. Not alot of work, but very repetitive, so let's > save some CPU > > > cycles while we can. > > > > > > And, btw, if we only had the Destination-FQDN, it > wouldimplies that a > > > message would have to be sent to a specific Diameter entity, not > > > any one in a given domain. > > > > My understanding was that the FQDN can be also a machine on > a different > > domain then the one publish by the proxy. I mean that the > back-end of the > > proxy could connect to several internal domains, which are > not related > > at all with the one of the proxy. Let's say I have some > servers within > > my corporate network defined in one domain (ABC.COM), while my proxy > > domain shows another one (ACME.COM). I was not expecting the servers > > on my corporate network to be defined as DIA1.ACME.COM. Also, I > > assume that it would not be allowed to define an FQDN for my > > corporate servers like DIA1.net1.ACME.COM, for the case you are > > referring to, right? > > The Destination-FQDN is the *final* target for a message. If > your proxy > has a different domain than your home server, that's fine. When the > routing path is setup with your partners, you simply tell > them that any > messages for *.ABC.COM go through ACME.COM. This is straight forward > proxying. > > However, ther must be a way to encode the target Diameter > host, if one is > needed. There are applications where this is useful (e.g. get > the HAR to > the right Home Agent, perhaps through proxies in a visited network). Exactly. I would assume that HA must be identified in the AAAH as a Realm and FQDN, not only FQDN. The FQDN is only used for the last hop, not for routing through proxy servers. > As far as server naming, you can call it whatever you like. However, > if it isn't a real FQDN that one uses with DNS, then there is > NO possibility > for dynamic discovery. I guess that the proxy owning the domain ("Realm") is the only one worried about the server discovery within its own domain. That is easy to support. However, my point is that there might be no naming convention at all between the FQDN and the Realm, which would make the MIP-Previous-FA-FQDN AVP completely useless in the AAAH without a corresponding Realm. I would prefer having only a MIP-Previous-FA-Realm AVP instead of a MIP-Previous-FA-FQDN AVP. Anyway, is it still used in the new Mobile-IP draft? Since the AAAH always needs to be contacted, I guess it would know in which domain the MN is located and where it is roaming, based on the Origin-Realm of the AMR. Thanks! /Martin From owner-aaa-bof@merit.edu Mon May 14 15:09:48 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21923 for ; Mon, 14 May 2001 15:09:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 46B325DE1D; Mon, 14 May 2001 14:34:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EAF295E9E3; Mon, 14 May 2001 11:58:59 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E22905E31A for ; Mon, 14 May 2001 11:19:16 -0400 (EDT) Received: (qmail 28609 invoked by uid 500); 14 May 2001 15:08:30 -0000 Date: Mon, 14 May 2001 08:08:30 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Failed-Command-Code Message-ID: <20010514080830.S10188@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , 'Pat Calhoun' , aaa-wg@merit.edu References: <577066326047D41180AC00508B955DDA01D7FFEF@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA01D7FFEF@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Mon, May 14, 2001 at 05:07:53PM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, May 14, 2001 at 05:07:53PM +0200, Martin Julien (ECE) wrote: > > The Failed-Command-Code AVP is no longer required, since the > > command code > > is always the same in a response message, so the command code > > is obvious. > > > > Therefore, this AVP will be removed. > > > > PatC > > > > I guess you also meant the Offending-Command-Code AVP (section 9.5-alpha1). right. > > Also note that section 9.6 should say Offending-AVP instead of > Failed-Command-Code. > > Section 9.7 should also remove the reference to the Command-Code. check. Thanks, PatC From owner-aaa-bof@merit.edu Mon May 14 15:11:49 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22002 for ; Mon, 14 May 2001 15:11:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6E7CC5E446; Mon, 14 May 2001 11:59:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C7CB55E40D; Mon, 14 May 2001 11:27:32 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C65D95E661 for ; Mon, 14 May 2001 10:03:04 -0400 (EDT) Received: (qmail 27314 invoked by uid 500); 14 May 2001 13:52:18 -0000 Date: Mon, 14 May 2001 06:52:18 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'Pat Calhoun'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Comments on draft-mobileip-03 Message-ID: <20010514065218.K10188@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , 'Pat Calhoun' , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA01D7FFE3@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA01D7FFE3@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Mon, May 14, 2001 at 10:08:41AM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, May 14, 2001 at 10:08:41AM +0200, Martin Julien (ECE) wrote: > See comments enclosed. > > > > 3) The problem with the previous comment, is that the > > MIP-Previous-FA-FQDN > > > does not represent the realm of the previous domain, only > > the FQDN of the > > > FA, which might be only routable by the AAAF, right? I am > > not sure that > > > the discussion we had on the mailing list a while ago > > suggested that the > > > FQDN (let's say ABC.com) was the realm plus another name > > > (let's MACHINE1.ABC.com). That does not make sense to me at > > least. If it > > > would have been like that, I would argue that we do not need two > > > destination FQDN and Realm. > > > > It is, and the reason why we have two separate AVPs is to > > reduce the amount > > of work done on proxies. This has been done in RADIUS via > > some vendor-specific > > AVPs, because otherwise each proxy must extract the FQDN, and > > retrieve the > > Realm. Not alot of work, but very repetitive, so let's save some CPU > > cycles while we can. > > > > And, btw, if we only had the Destination-FQDN, it wouldimplies that a > > message would have to be sent to a specific Diameter entity, not > > any one in a given domain. > > My understanding was that the FQDN can be also a machine on a different > domain then the one publish by the proxy. I mean that the back-end of the > proxy could connect to several internal domains, which are not related > at all with the one of the proxy. Let's say I have some servers within > my corporate network defined in one domain (ABC.COM), while my proxy > domain shows another one (ACME.COM). I was not expecting the servers > on my corporate network to be defined as DIA1.ACME.COM. Also, I > assume that it would not be allowed to define an FQDN for my > corporate servers like DIA1.net1.ACME.COM, for the case you are > referring to, right? The Destination-FQDN is the *final* target for a message. If your proxy has a different domain than your home server, that's fine. When the routing path is setup with your partners, you simply tell them that any messages for *.ABC.COM go through ACME.COM. This is straight forward proxying. However, ther must be a way to encode the target Diameter host, if one is needed. There are applications where this is useful (e.g. get the HAR to the right Home Agent, perhaps through proxies in a visited network). As far as server naming, you can call it whatever you like. However, if it isn't a real FQDN that one uses with DNS, then there is NO possibility for dynamic discovery. > > Well, the flags *are* necessary for accounting purposes. No way > > around that. The Feature-Vector in the accounting message will > > provide some details on the type of session being provided. At > > the same time, you want the home address and agent to be in the > > accounting record, so including the zero or all ones in the > > accounting message would be bad. > > So, if it is bad, then why are you asking the question in the next > paragraph, whether AVPs with 0.0.0.0 or 255.255.255.255 should at all > be included in the message? In Authentication messages, they would include all ones or zeros. However, in accounting messages, they would include the assigned values. > > > So, bits are necessary. The real question is whether it really makes > > sense to state that the AVPs MUST NOT be included if the bits are > > set. > > > > Anyone? > > I really don't mind which way it has to work, even though I still > think it makes more sense to simply add AVPs to the AMR messages > about the Home Agent and Home Address that correspond to the content > of the MIP message, rather than the FA playing around with the meaning > of them itself. But their meaning is clear cut. There really isn't alot of room for interpretation, and it is useful for accounting messages. I fail to see a problem... Thanks, PatC From owner-aaa-bof@merit.edu Mon May 14 15:13:03 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22065 for ; Mon, 14 May 2001 15:13:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 443BF5EB40; Mon, 14 May 2001 12:02:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BA8BC5E56C; Mon, 14 May 2001 11:41:41 -0400 (EDT) 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 69BA85E56D for ; Mon, 14 May 2001 11:09:58 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f4EF9wN04290 for ; Mon, 14 May 2001 17:09:58 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon May 14 17:09:20 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 17:09:19 +0200 Message-ID: <577066326047D41180AC00508B955DDA01D7FFEF@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Failed-Command-Code Date: Mon, 14 May 2001 17:07:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > The Failed-Command-Code AVP is no longer required, since the > command code > is always the same in a response message, so the command code > is obvious. > > Therefore, this AVP will be removed. > > PatC > I guess you also meant the Offending-Command-Code AVP (section 9.5-alpha1). Also note that section 9.6 should say Offending-AVP instead of Failed-Command-Code. Section 9.7 should also remove the reference to the Command-Code. /Martin From owner-aaa-bof@merit.edu Mon May 14 15:51:30 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22831 for ; Mon, 14 May 2001 15:51:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EB5875E410; Mon, 14 May 2001 14:17:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C17FA5E814; Mon, 14 May 2001 11:51:02 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 9D25D5DFFB for ; Mon, 14 May 2001 11:48:58 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09831; Mon, 14 May 2001 08:48:56 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA02573; Mon, 14 May 2001 08:48:55 -0700 (PDT) Message-Id: <200105141548.IAA02573@heliopolis.eng.sun.com> Date: Mon, 14 May 2001 08:48:55 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: [AAA-WG]: Re: [diameter] C++ API To: anand@samsung.co.kr, dave@frascone.com Cc: aaa-wg@merit.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: c5bNsBR7X792O2Zow58ITw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk Actually, I disagree. The C API will work for C++ as well. Why should there be another? jak >Delivered-To: aaa-wg-outgoing@merit.edu >Date: Sun, 13 May 2001 18:04:27 -0500 >From: David Frascone >To: anand@samsung.co.kr >Cc: aaa-wg@merit.edu >Subject: [AAA-WG]: Re: [diameter] C++ API >Mail-Followup-To: anand@samsung.co.kr, aaa-wg@merit.edu >Content-Disposition: inline >User-Agent: Mutt/1.2.5i >X-encrypt-payload: no > >[ moving to aaa-wg, since this is a WG document now ] > >There is no C++ API . . . yet. There definately needs to be one though. >I belive a section needs to be added to the AAA-API. > >On Fri, May 11, 2001 at 02:22:35AM +0900, anand@samsung.co.kr wrote: >> >> Hi, >> Is anyone aware of the presence of a C++ version >> of the Diameter API. Please let me know. >> >> regards, >> anand >> > From owner-aaa-bof@merit.edu Mon May 14 15:59:08 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22991 for ; Mon, 14 May 2001 15:59:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 331725E4FF; Mon, 14 May 2001 15:04:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2824D5E40E; Mon, 14 May 2001 11:59:20 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 8F5705E2CA for ; Mon, 14 May 2001 11:24:30 -0400 (EDT) Received: (qmail 28861 invoked by uid 500); 14 May 2001 15:13:44 -0000 Date: Mon, 14 May 2001 08:13:44 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'Pat Calhoun'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Comments on draft-mobileip-03 Message-ID: <20010514081344.T10188@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , 'Pat Calhoun' , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA01D7FFEE@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA01D7FFEE@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Mon, May 14, 2001 at 04:59:30PM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, May 14, 2001 at 04:59:30PM +0200, Martin Julien (ECE) wrote: > > The Destination-FQDN is the *final* target for a message. If > > your proxy > > has a different domain than your home server, that's fine. When the > > routing path is setup with your partners, you simply tell > > them that any > > messages for *.ABC.COM go through ACME.COM. This is straight forward > > proxying. > > > > However, ther must be a way to encode the target Diameter > > host, if one is > > needed. There are applications where this is useful (e.g. get > > the HAR to > > the right Home Agent, perhaps through proxies in a visited network). > > Exactly. I would assume that HA must be identified in the AAAH as > a Realm and FQDN, not only FQDN. The FQDN is only used for the last > hop, not for routing through proxy servers. just to make sure that we are on the same page, FQDN is: host.realm So, yes, both the Destination-FQDN and the Destination-Realm would ne required in the HAR. > > > As far as server naming, you can call it whatever you like. However, > > if it isn't a real FQDN that one uses with DNS, then there is > > NO possibility > > for dynamic discovery. > > I guess that the proxy owning the domain ("Realm") is the only one worried > about the server discovery within its own domain. That is easy to > support. However, my point is that there might be no naming convention > at all between the FQDN and the Realm, which would make the > MIP-Previous-FA-FQDN AVP completely useless in the AAAH without a > corresponding Realm. I would prefer having only a > MIP-Previous-FA-Realm AVP instead of a MIP-Previous-FA-FQDN AVP. I prefer as much information as possible, and the ream can be extracted from the fqdn, if that is necessary. Since this isn't needed on each hop, for processing purposes, i would prefer to leave it as-is. others? > > Anyway, is it still used in the new Mobile-IP draft? Since the AAAH > always needs to be contacted, I guess it would know in which domain > the MN is located and where it is roaming, based on the Origin-Realm > of the AMR. In the event that you have multiple AAAHs in the home network, and state isn't replicated, it would be nice to allow for this information to be supplied. PatC From owner-aaa-bof@merit.edu Mon May 14 16:23:31 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23680 for ; Mon, 14 May 2001 16:23:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E08A95E301; Mon, 14 May 2001 15:41:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0E89B5E44F; Mon, 14 May 2001 14:52:39 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id A1F505E55E for ; Mon, 14 May 2001 14:08:41 -0400 (EDT) Received: (qmail 10462 invoked by uid 500); 14 May 2001 17:48:07 -0000 Date: Mon, 14 May 2001 10:48:07 -0700 From: Pat Calhoun To: Michael Chen Cc: Pat Calhoun , IETF AAA WG , tony.johansson@ericsson.com Subject: Re: [AAA-WG]: Route-Record AVP in Failed Indication in 04-alpha1 Message-ID: <20010514104807.I10188@charizard.diameter.org> Mail-Followup-To: Michael Chen , Pat Calhoun , IETF AAA WG , tony.johansson@ericsson.com References: <017401c0da28$abeb1070$2096a8c0@mjones.bridgewatersys.com> <3AFC31F5.CF274809@erilab.com> <20010511113743.K10188@charizard.diameter.org> <3AFC8189.B21A5F7E@erilab.com> <20010511180916.W10188@charizard.diameter.org> <3B0018B4.7163D258@erilab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B0018B4.7163D258@erilab.com>; from cchen@erilab.com on Mon, May 14, 2001 at 10:41:08AM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, May 14, 2001 at 10:41:08AM -0700, Michael Chen wrote: > Thanks for the reply, a text stating " Indication/Failed Indication should be > treated the same as Request and Answer" would be fine. By the way, in the > base spec it stated > " A Diameter server that proxies a message of type Request, Query or > *****Indication***** MUST append a Route-Record AVP, which > includes its identity." > Failed Indication should not apply to this rule, isn't it? So need clarify it. > It's been taken care of in the spec. Thanks, PatC From owner-aaa-bof@merit.edu Mon May 14 17:06:28 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24704 for ; Mon, 14 May 2001 17:06:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5405D5DDBE; Mon, 14 May 2001 16:17:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 70D975DFEF; Mon, 14 May 2001 15:17:09 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id 46D5C5E304 for ; Mon, 14 May 2001 12:53:56 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA24670 for ; Mon, 14 May 2001 09:53:56 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA19182 for ; Mon, 14 May 2001 09:53:55 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 11:53:56 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'aaa-wg@merit.edu'" Cc: Thomas Panagiotis-PTHOMAS1 Subject: [AAA-WG]: SLP Diameter Server Discovery Date: Mon, 14 May 2001 11:53:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, I'd propose changing: "2.5 Diameter Server Discovery ... SLPv2 will allow Diameter implementations to discover the location of Diameter servers in the local site, as well as their characteristics." to: "SLPv2 will allow Diameter implementations in the local site to discover the location of Diameter severs, as well as their characteristics." Unless of course, if SLP has the limitation that only servers within the same administrative domain can be discovered. -Panos From owner-aaa-bof@merit.edu Mon May 14 17:12:57 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24817 for ; Mon, 14 May 2001 17:12:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 36E4D5DFB1; Mon, 14 May 2001 16:19:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F04E95E45D; Mon, 14 May 2001 15:19:37 -0400 (EDT) Received: from forsete.erilab.com (forsete.erilab.com [208.224.156.105]) by segue.merit.edu (Postfix) with ESMTP id A3CE45E45D for ; Mon, 14 May 2001 13:39:56 -0400 (EDT) Received: from erilab.com (eblcl50.erilab.com [192.168.174.190]) by forsete.erilab.com (8.11.0/8.11.0) with ESMTP id f4EHdfG12294; Mon, 14 May 2001 10:39:41 -0700 (PDT) Message-ID: <3B0018B4.7163D258@erilab.com> Date: Mon, 14 May 2001 10:41:08 -0700 From: Michael Chen X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: IETF AAA WG , tony.johansson@ericsson.com Subject: Re: [AAA-WG]: Route-Record AVP in Failed Indication in 04-alpha1 References: <017401c0da28$abeb1070$2096a8c0@mjones.bridgewatersys.com> <3AFC31F5.CF274809@erilab.com> <20010511113743.K10188@charizard.diameter.org> <3AFC8189.B21A5F7E@erilab.com> <20010511180916.W10188@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, Thanks for the reply, a text stating " Indication/Failed Indication should be treated the same as Request and Answer" would be fine. By the way, in the base spec it stated " A Diameter server that proxies a message of type Request, Query or *****Indication***** MUST append a Route-Record AVP, which includes its identity." Failed Indication should not apply to this rule, isn't it? So need clarify it. -Michael > > > Is a separate figure, or text stating that an Indication/Failed Indication is > the same as Request and answer? > > PatC From owner-aaa-bof@merit.edu Mon May 14 17:29:02 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25037 for ; Mon, 14 May 2001 17:29:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C57EB5E07D; Mon, 14 May 2001 16:11:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F075F5E3AE; Mon, 14 May 2001 15:12:55 -0400 (EDT) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id 5EBCC5E392 for ; Mon, 14 May 2001 12:34:13 -0400 (EDT) Received: from jariws1 ([193.229.23.129]) by fep02-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010514163412.KJTK17199.fep02-app.kolumbus.fi@jariws1>; Mon, 14 May 2001 19:34:12 +0300 Message-ID: <001201c0dc93$bbe31aa0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , "Bernard Aboba" Cc: "Pat Calhoun" , "Thomas Panagiotis-PTHOMAS1" , References: <3AFFD560.787BE3DF@baltimore.ie> Subject: Re: [AAA-WG]: End-2-End security Date: Mon, 14 May 2001 19:34:23 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > So End-2-End security is a MAY for Clients and Servers, right? I would be in favor of making e2e a MAY for at least clients. Jari From owner-aaa-bof@merit.edu Mon May 14 22:04:38 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29691 for ; Mon, 14 May 2001 22:04:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 07D395E260; Mon, 14 May 2001 19:59:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5798B5DE23; Mon, 14 May 2001 18:23:00 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 3AFEE5F130 for ; Mon, 14 May 2001 17:21:55 -0400 (EDT) Received: (qmail 14774 invoked by uid 500); 14 May 2001 21:11:07 -0000 Date: Mon, 14 May 2001 14:11:07 -0700 From: Pat Calhoun To: Thomas Panagiotis-PTHOMAS1 Cc: "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: SLP Diameter Server Discovery Message-ID: <20010514141107.N10188@charizard.diameter.org> Mail-Followup-To: Thomas Panagiotis-PTHOMAS1 , "'aaa-wg@merit.edu'" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from panos.thomas@motorola.com on Mon, May 14, 2001 at 11:53:21AM -0500 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, May 14, 2001 at 11:53:21AM -0500, Thomas Panagiotis-PTHOMAS1 wrote: > Pat, > > I'd propose changing: > > "2.5 Diameter Server Discovery > ... > SLPv2 will allow Diameter implementations to discover the location of > Diameter servers in the local site, as well as their characteristics." > > to: > > "SLPv2 will allow Diameter implementations in the local site to discover > the location of Diameter severs, as well as their characteristics." > > Unless of course, if SLP has the limitation that only servers within the > same administrative domain can be discovered. My understanding is that SLP doesn't scale as an Internet protocol, and is well suited to be used within an administrative domain. Therefore, I would prefer that the text remain as it is. PatC From owner-aaa-bof@merit.edu Mon May 14 22:31:56 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00879 for ; Mon, 14 May 2001 22:31:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 459855E671; Mon, 14 May 2001 21:12:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B41FD5DE88; Mon, 14 May 2001 18:58:06 -0400 (EDT) Received: from c000.snv.cp.net (c000-h001.c000.snv.cp.net [209.228.32.65]) by segue.merit.edu (Postfix) with SMTP id 409EB5E5E1 for ; Mon, 14 May 2001 16:44:31 -0400 (EDT) Received: (cpmta 13033 invoked from network); 14 May 2001 13:44:22 -0700 Received: from h121s86a16n47.user.nortelnetworks.com (HELO mitton.mitton.com) (47.16.86.121) by smtp.mitton.com (209.228.32.65) with SMTP; 14 May 2001 13:44:22 -0700 X-Sent: 14 May 2001 20:44:22 GMT Message-Id: <4.3.2.7.2.20010514162843.00cd1d70@ZBL6C016.corpeast.baynetworks.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 May 2001 16:39:42 -0400 To: "AAA-WG" From: David Mitton Subject: [AAA-WG]: AAA WG Interim Meeting nose count Cc: aboba@internaut.com, Randy Bush Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk Hello, I need to get a rough list of people that are planning to attend the AAA WG Interim Meeting next week. - I need to make sure the room is big enough. - I may need to move to another building and room in our campus. (for various accessibility reasons) So please, send me a note indicating if you are planning to attend, and Please, pay attention for any late minute announcements. NOTE: This meeting will be a working meeting. We will not be giving any tutorial or review presentations. Attendees should have read the current drafts and be up on mailing list discussions before the meeting, and be ready to contribute on open issues at the meeting. Dave. ---------------------------------------------------- David Mitton 978-288-4570 Advisor, Nortel Networks david@mitton.com or dmitton@nortelnetworks.com From owner-aaa-bof@merit.edu Tue May 15 03:47:49 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18502 for ; Tue, 15 May 2001 03:47:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 319C25DFAA; Tue, 15 May 2001 01:59:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 233355E40E; Mon, 14 May 2001 22:25:24 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 13D3E5E4F9 for ; Mon, 14 May 2001 21:01:47 -0400 (EDT) Received: (qmail 16129 invoked by uid 500); 15 May 2001 00:50:59 -0000 Date: Mon, 14 May 2001 17:50:59 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: New Diameter IDs are now available Message-ID: <20010514175058.T10188@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, The following Internet Drafts are now available on www.diameter.org, and have been sent to the secretariat. I propose that these are the versions of the specs that we will review at next week's interim meeting. The following are the pending issues that I have been tracking: 1. watchdog/failover text 2. proposal to remove watchdog over reliable transports (Jonathan Wood) 3. proposal to kill STI (although I don't think this is really necessary anymore) 4. proposal to modify/hack/kill DSI 5. proposal to make Grouped AVPs more open 6. The various Boot-Id proposals I will have to go through the archives again to see if I've missed anything, but at a minimum we need to discuss the above issues at next week's meeting. Oh, and somehow I believe we are also going to have a document reading party. PatC From owner-aaa-bof@merit.edu Tue May 15 06:18:30 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19738 for ; Tue, 15 May 2001 06:18:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BA4CC5E178; Tue, 15 May 2001 05:03:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 054AD5E0A6; Tue, 15 May 2001 04:01:22 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 1D1065EBB0 for ; Tue, 15 May 2001 02:47:51 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA17337; Mon, 14 May 2001 23:47:49 -0700 (PDT) Received: from vayne (muc-isdn-8 [129.157.164.108]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id IAA11494; Tue, 15 May 2001 08:47:47 +0200 (MET DST) Date: Tue, 15 May 2001 08:59:22 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: [AAA-WG]: SLP Diameter Server Discovery To: Thomas Panagiotis-PTHOMAS1 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 > Pat, > > I'd propose changing: > > "2.5 Diameter Server Discovery > ... > SLPv2 will allow Diameter implementations to discover the location of > Diameter servers in the local site, as well as their characteristics." > > to: > > "SLPv2 will allow Diameter implementations in the local site to discover > the location of Diameter severs, as well as their characteristics." > > Unless of course, if SLP has the limitation that only servers within the > same administrative domain can be discovered. SLPv2 does have this limitation. SLP agents use either multicast for discovery or local configuration (to an administrative domain) the agents obtain from DHCP. The latter is important in networks where (site internal) multicast routing is not available. Erik Erik From owner-aaa-bof@merit.edu Tue May 15 07:59:07 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22639 for ; Tue, 15 May 2001 07:59:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3D44C5DFA2; Tue, 15 May 2001 07:57:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 865D45DF9C; Tue, 15 May 2001 07:57:13 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id 5187F5DF2A for ; Tue, 15 May 2001 07:57:08 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id EAA17017 for ; Tue, 15 May 2001 04:57:08 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id EAA05161 for ; Tue, 15 May 2001 04:57:08 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 May 2001 06:57:07 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: SLP Diameter Server Discovery Date: Tue, 15 May 2001 06:57:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk Eric and Pat, >> Unless of course, if SLP has the limitation that only servers within the >> same administrative domain can be discovered. > > SLPv2 does have this limitation. SLP agents use either multicast for > discovery or local configuration (to an administrative domain) the > agents obtain from DHCP. The latter is important in networks where > (site internal) multicast routing is not available. Thanks for your explanations. I think it is worth adding this information in the document, to make it more explicit to people (like me) that are not very familiar with SLP. -Panos -----Original Message----- From: Erik Guttman [mailto:Erik.Guttman@Sun.COM] Sent: 15 May 2001 01:59 To: Thomas Panagiotis-PTHOMAS1 Cc: 'aaa-wg@merit.edu' Subject: Re: [AAA-WG]: SLP Diameter Server Discovery > Pat, > > I'd propose changing: > > "2.5 Diameter Server Discovery > ... > SLPv2 will allow Diameter implementations to discover the location of > Diameter servers in the local site, as well as their characteristics." > > to: > > "SLPv2 will allow Diameter implementations in the local site to discover > the location of Diameter severs, as well as their characteristics." > > Unless of course, if SLP has the limitation that only servers within the > same administrative domain can be discovered. SLPv2 does have this limitation. SLP agents use either multicast for discovery or local configuration (to an administrative domain) the agents obtain from DHCP. The latter is important in networks where (site internal) multicast routing is not available. Erik Erik From owner-aaa-bof@merit.edu Tue May 15 09:47:53 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27060 for ; Tue, 15 May 2001 09:47:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BC0E65DDDC; Tue, 15 May 2001 09:45:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8F4785DE52; Tue, 15 May 2001 09:45:45 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 757AF5DDDC for ; Tue, 15 May 2001 09:45:42 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4FDkMv26954 for ; Tue, 15 May 2001 16:46:22 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 15 May 2001 16:45:40 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Tue, 15 May 2001 16:45:40 +0300 Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E62642@treis03nok> From: henry.haverinen@nokia.com To: aaa-wg@merit.edu Subject: [AAA-WG]: Proposed addition to Diameter NASREQ draft Date: Tue, 15 May 2001 16:45:37 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi all, Please find below a drafty description of key distribution AVP's which I'd like to propose to be included in the Diameter NASREQ draft. These AVP's would be useful for example with IEEE 802.1X. and PPP encryption (and perhaps with BURP too?). Any comments most welcome! Regards, Henry ----------- NAS-Session-Key AVP NAS session keys are the keys created by a Diameter server, which it distributes to the NAS, acting as a Diameter client. The keys can be used for integrity and confidentiality protection between the NAS and the user. The keys can be distributed to the user for example as part of the EAP authentication procedure. If strong authentication and confidentiality of the session keys is required, it is recommended that the end-to-end security extension [TBD] be used with the NAS-Session-Key AVP. Zero or more instances of the NAS-Session-Key AVP may be present in the following Diameter messages: AA-Answer (AAA) Command Diameter-EAP-Answer (DEA) Command If more than one instance of the NAS-Session-Key AVP is present, then for a certain purpose, only one of the distributed session keys must be applicable. In other words, one of the following conditions must be true for all combinations of two NAS-Session-Key AVP's: 1. Their Key-Usage AVP's are different, or 2. Their Key-Direction AVP's contain the values "downlink" and "uplink". The lifetime of the generated keys MUST be the same as the value of the Authorization-Lifetime AVP. The NAS-Session-Key AVP, described below, is of type Grouped, and therefore its value has the following ABNF format: NAS-Session-Key AVP = Peer-SPI Key-Direction Key-Usage Session-Key Peer-SPI = ; NAS-Peer-SPI, see below Key-Direction = ; NAS-Key-Direction, see below Key-Usage = ; NAS-Key-Usage, see below Session-Key = ; NAS-Key-Data, see below +---------------------------------------------------------------+ | AVP Header (AVP Code = TBD) | +---------------------------------------------------------------+ | NAS-Peer-SPI AVP | +---------------------------------------------------------------+ | NAS-Key-Direction AVP | +---------------------------------------------------------------+ | NAS-Key-Usage AVP | +---------------------------------------------------------------+ | NAS-Key Data AVP | +---------------------------------------------------------------+ NAS-Peer-SPI The NAS-Peer-SPI AVP (AVP Code TBD) is of type Unsigned32, and it contains the Security Parameter Index, selected by the Diameter server, which may be used as a key identifier. The SPI is probably not useful in PPP. NAS-Key-Direction The NAS-Key-Direction AVP (AVP Code TBD) is of type Unsigned32. It indicates if the key can be used to protect uplink traffic, downlink traffic or both uplink and downlink traffic between the user and the NAS. The following values are supported: 0 Bidirectional 1 Uplink (user to NAS traffic) 2 Downlink (NAS to user traffic) NAS-Key-Usage The NAS-Key-Usage AVP (AVP Code TBD) is of type Unsigned32. It indicates if the key is intended to be used as an integrity key or cipher key. The following values are supported: 0 Cipher key 1 Integrity key NAS-Key-Data The NAS-Key-Data AVP (AVP Code TBD) is of type OctetString and contains the session key to be used between the user and the NAS. From owner-aaa-bof@merit.edu Tue May 15 09:59:54 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27529 for ; Tue, 15 May 2001 09:59:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DF42D5DD91; Tue, 15 May 2001 09:57:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8749C5DD9C; Tue, 15 May 2001 09:56:51 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 2E9FA5DD8F for ; Tue, 15 May 2001 09:56:42 -0400 (EDT) Received: (qmail 18681 invoked by uid 500); 15 May 2001 13:45:51 -0000 Date: Tue, 15 May 2001 06:45:50 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #1: Routing of Indication messages Message-ID: <20010515064550.X10188@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, I have just begun to code the failover portion of the protocol (I was waiting because of the uncertainty of the current text), and have discovered a problem. The base protocol introduces the fact that nodes need to maintain a queue of pending request, which is used for failover purposes. Here is a snippet of text: "7.3 Failover/Failback Procedures In the event that a transport failure is detected with a peer, it is necessary for all pending request and indication messages to be forwarded to an alternate server, if possible. This is commonly referred to as failover. In order for a Diameter node to perform failover procedures, it is necessary for the node to maintain a pending message queue for a given peer. When a response is received, the message is removed from the queue. The Hop-by-Hop Identifier field MAY be used to match the corresponding response with the queued request." Furthermore, the following diagram from the specification is very useful in understanding how it works: " Request +--------+ Link Broken +-------------------------->|Diameter|----///----+ | +---------------------| | v +-----+---+ | DSI | Server | +--------+ |Diameter |<-+ (Unable to Forward) +--------+ |Diameter| |Client or| | | | Server |--+ +--------+ | Server | +---------+ | Request |Diameter| +--------+ +-------------------->| | ^ | Server |-----------+ +--------+ Figure 1 - Example of Per-Hop Error Condition" In the above figure, a Diameter node sends a packet to a server, an error is received, via a DSI, and this causes the request (or ind) to be sent to the alternate server. Section 7.3 states that the message is removed from the queue only once a response is received. So obviously this isn't much of an issue for the request/answer messages, but what about indication messages? There are three options: 1. Indication messages *always* have a response. A response to an -ind is quite simple, it only includes a minimum number of AVPs (e.g. Session-Id, Result-Code). So all Indication messages have a response, and we can transform the Failed-Ind to be this response. Call it an -Ack. 2. Write some specialized text in the document to handle -Ind messages differently from -Request. Perhaps have messages timeout from the queue. I really think this is the wrong approach, and would lead to much more complicated text. 3. Elimination of Indications altogether, and only make use of -Request and -Answer. I don't particularly like this approach because Indication messages are useful, and have a different connotation than do -Requests. So just as a clarification, Indication messages use to work fine, but with the introduction of the queueing of pending packets, it has become a problem. So, a resolution is required. Thanks, PatC From owner-aaa-bof@merit.edu Tue May 15 10:01:25 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27629 for ; Tue, 15 May 2001 10:01:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9A91E5DDF5; Tue, 15 May 2001 09:58:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8EB025DE80; Tue, 15 May 2001 09:58:25 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 9B1115DE4A for ; Tue, 15 May 2001 09:58:12 -0400 (EDT) Received: (qmail 18692 invoked by uid 500); 15 May 2001 13:47:22 -0000 Date: Tue, 15 May 2001 06:47:22 -0700 From: Pat Calhoun To: henry.haverinen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Proposed addition to Diameter NASREQ draft Message-ID: <20010515064722.Y10188@charizard.diameter.org> Mail-Followup-To: henry.haverinen@nokia.com, aaa-wg@merit.edu References: <6D1A8E7871B9D211B3B00008C7490AA504E62642@treis03nok> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <6D1A8E7871B9D211B3B00008C7490AA504E62642@treis03nok>; from henry.haverinen@nokia.com on Tue, May 15, 2001 at 04:45:37PM +0300 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Tue, May 15, 2001 at 04:45:37PM +0300, henry.haverinen@nokia.com wrote: > > Hi all, > > Please find below a drafty description of key distribution AVP's > which I'd like to propose to be included in the Diameter NASREQ draft. > These AVP's would be useful for example with IEEE 802.1X. > and PPP encryption (and perhaps with BURP too?). > > Any comments most welcome! How are the keys distributed to the user? PatC > > Regards, > Henry > > ----------- > > NAS-Session-Key AVP > > NAS session keys are the keys created by a Diameter server, which it > distributes to the NAS, acting as a Diameter client. The keys can > be used for integrity and confidentiality protection between the NAS and > the user. The keys can be distributed to the user for example > as part of the EAP authentication procedure. > > If strong authentication and confidentiality of the session keys > is required, it is recommended that the end-to-end security > extension [TBD] be used with the NAS-Session-Key AVP. > > Zero or more instances of the NAS-Session-Key AVP may be present > in the following Diameter messages: > > AA-Answer (AAA) Command > Diameter-EAP-Answer (DEA) Command > > If more than one instance of the NAS-Session-Key AVP is present, > then for a certain purpose, only one of the distributed session > keys must be applicable. In other words, one of the following > conditions must be true for all combinations of two > NAS-Session-Key AVP's: > > 1. Their Key-Usage AVP's are different, or > 2. Their Key-Direction AVP's contain the values "downlink" and > "uplink". > > The lifetime of the generated keys MUST be the same as the > value of the Authorization-Lifetime AVP. The NAS-Session-Key AVP, > described below, is of type Grouped, and therefore its value has > the following ABNF format: > > NAS-Session-Key AVP = Peer-SPI Key-Direction Key-Usage Session-Key > Peer-SPI = ; NAS-Peer-SPI, see below > Key-Direction = ; NAS-Key-Direction, see below > Key-Usage = ; NAS-Key-Usage, see below > Session-Key = ; NAS-Key-Data, see below > > +---------------------------------------------------------------+ > | AVP Header (AVP Code = TBD) | > +---------------------------------------------------------------+ > | NAS-Peer-SPI AVP | > +---------------------------------------------------------------+ > | NAS-Key-Direction AVP | > +---------------------------------------------------------------+ > | NAS-Key-Usage AVP | > +---------------------------------------------------------------+ > | NAS-Key Data AVP | > +---------------------------------------------------------------+ > > > NAS-Peer-SPI > > The NAS-Peer-SPI AVP (AVP Code TBD) is of type Unsigned32, and it > contains the Security Parameter Index, selected by the Diameter > server, which may be used as a key identifier. The SPI is probably > not useful in PPP. > > NAS-Key-Direction > > The NAS-Key-Direction AVP (AVP Code TBD) is of type Unsigned32. > It indicates if the key can be used to protect uplink traffic, > downlink traffic or both uplink and downlink traffic between > the user and the NAS. The following values are supported: > > 0 Bidirectional > 1 Uplink (user to NAS traffic) > 2 Downlink (NAS to user traffic) > > > NAS-Key-Usage > > The NAS-Key-Usage AVP (AVP Code TBD) is of type Unsigned32. > It indicates if the key is intended to be used as an > integrity key or cipher key. The following values are supported: > > 0 Cipher key > 1 Integrity key > > > NAS-Key-Data > > The NAS-Key-Data AVP (AVP Code TBD) is of type OctetString and > contains the session key to be used between the user and the NAS. > From owner-aaa-bof@merit.edu Tue May 15 10:14:15 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28107 for ; Tue, 15 May 2001 10:14:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 285095DD9A; Tue, 15 May 2001 10:10:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2A31C5DF5E; Tue, 15 May 2001 10:10:13 -0400 (EDT) Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id AEF8B5DED4 for ; Tue, 15 May 2001 10:03:25 -0400 (EDT) Received: (qmail 15489 invoked by uid 500); 15 May 2001 14:03:23 -0000 Date: Tue, 15 May 2001 09:03:22 -0500 From: David Frascone To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue #1: Routing of Indication messages Message-ID: <20010515090322.A12170@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu References: <20010515064550.X10188@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010515064550.X10188@charizard.diameter.org>; from pcalhoun@diameter.org on Tue, May 15, 2001 at 06:45:50AM -0700 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk On Tue, May 15, 2001 at 06:45:50AM -0700, Pat Calhoun wrote: [snip] > > There are three options: > 1. Indication messages *always* have a response. A response to an -ind is > quite simple, it only includes a minimum number of AVPs (e.g. Session-Id, > Result-Code). So all Indication messages have a response, and we can > transform the Failed-Ind to be this response. Call it an -Ack. I'd prefer this one. I like having a response to all messages. It just makes life easier. -Dave From owner-aaa-bof@merit.edu Tue May 15 10:49:38 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29124 for ; Tue, 15 May 2001 10:49:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E0225DDE3; Tue, 15 May 2001 10:47:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 46CD65E167; Tue, 15 May 2001 10:36:35 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 65C6A5E0FF for ; Tue, 15 May 2001 10:22:32 -0400 (EDT) Received: (qmail 18828 invoked by uid 500); 15 May 2001 14:11:42 -0000 Date: Tue, 15 May 2001 07:11:41 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #3: Sessions that do not start Message-ID: <20010515071141.A10188@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk This is another sub-thread that somehow got lost. Given that I am not making any more changes to the specs until after the Interim meeting (to allow people to read the current specs), I am adding this one as a pending issue. The issue as I understand it is that the NAS needs to inform the server when a session never started. Perhaps the user disconnected while being authenticated via AAA, or the NAS received some AVPs it didn't like, etc. In any case, the server needs to be notified of the fact that the session wasn't started, otherwise it would have to wait until the expiration of the Authorization-Lifetime. So, this requires two changes to the spec, the first one is in the state machine: State Event Action New State ------------------------------------------------------------- [...] Pending Successful Service-Specific Grant Open Authorization response Access received Pending Successful Service-Specific Send STR Discon Authorization response received, but service not provided. Pending Successful Service-Specific Send STR Discon Authorization response received, but error processing response And then a Termination-Cause AVP is required: 10.9 Termination-Cause AVP The Termination-Cause AVP (AVP Code TBD) is of type Unsigned32, and is used to indicate the reason why a session was terminated on the access device. The following values are defined: DIAMETER_LOGOUT 1 The user initiated a disconnect. DIAMETER_CLIENT_GONE 2 This value is used when the user disconnected prior to the Diameter auth response was received. DIAMETER_BAD_ANSWER 3 This value indicates that the auth response received by the access device was not processed successfully. DIAMETER_ADMINISTRATIVE 4 The user was not granted access due to administrative reasons. DIAMETER_LINK_BROKEN 5 The communication link to the user was abruptly disconnected. (any others?) PatC From owner-aaa-bof@merit.edu Tue May 15 10:50:11 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29157 for ; Tue, 15 May 2001 10:50:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 888605DD9E; Tue, 15 May 2001 10:48:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EA4BE5DF9C; Tue, 15 May 2001 10:42:42 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 2E8A25E050 for ; Tue, 15 May 2001 10:32:32 -0400 (EDT) Received: (qmail 18872 invoked by uid 500); 15 May 2001 14:21:42 -0000 Date: Tue, 15 May 2001 07:21:42 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #5: Boot Id Message-ID: <20010515072142.C10188@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk This particular issue has to be with how the access device can inform the home server that a reboot has occured. There were several proposals, and instead of attempting to paraphrase, I will simply include Paul's e-mail. PatC ---- (from http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00135.html) Allow me to recast the summary. But first, a description of the architectural framework: Multiple NASes are clients of an aggregating server. Some sessions are local and use resources on the aggregating server. Other sessions are proxied by the aggregating server to other home servers, and use resources on those home servers. 1 Paul's proposal In Paul's proposal, a DRI would include a Boot-Id AVP, which could be a monotonically increasing number (increases upon each reboot). When an aggregating server receives a DRI from a NAS with a higher Boot-Id than before, the aggregating server can then release all resources for that NAS's local sessions. It MAY, if it so chooses, clean up all sessions globally, by issuing STRs on behalf of that NAS for all sessions that were proxied, each directed to the appropriate home server. 2. Pat's proposal. In Pat's proposal, each auth (and acct) message would include a Boot-Id AVP. So the next time that a message was sent to the home Diameter Server, the server could determine whether the NAS has rebooted since the last time it received a message from it. 3. Mark's proposal Mark's proposal (I'm taking liberties here) is the same as Paul's proposal, except that there would be a new command, say Client-Reboot-Request or Client-Reboot-Indication, that would contain the FQDN and Boot-Id of the restarted NAS. The aggregating server MAY issue this command to each home server for which there is at least one open session. Thus, only a single message per home server, rather than a message for each session, would have to be issued in order to clean up state globally. The first thing to note is that these proposals are not mutually exclusive. I think we should at least adopt Paul's proposal, since it allows an aggregating server to clean up local state efficiently, and provides at the least the option for the aggregating server to clean up state globally via STR or Mark's new command. It is a requirement of Mark's proposal anyway, and it is a sufficiently minor addition to Pat's proposal (just a single AVP in DRI) that it would make sense to avail ourselves of it in any case. Mark's proposal of a new command would reduce traffic over the use of individual STRs in Paul's proposal. However, the reduction may not be dramatic. The number of non-local sessions may be a fraction of the total number of sessions, and if the non-local are widely distributed, the tradeoff of STRs against his more powerful command may not be compelling. Plus, it requires that a new command be supported. Both Paul's and Mark's proposals required that the aggregating server keep session state for non-local sessions in order to clean them up. Pat's proposal, as he notes, has the advantage that non-local sessions can get cleaned up even if the aggregating server does not keep their state, in fact, even if the aggregating server itself goes down. However, it is non-deterministic, and depends on the accident of the NAS starting a session on the same home server after it is rebooted. So my feeling is that we should at least adopt my humble proposal, and possibly all three. That's the strongest opinion I can muster. From owner-aaa-bof@merit.edu Tue May 15 10:52:02 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29214 for ; Tue, 15 May 2001 10:51:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A5D775DE84; Tue, 15 May 2001 10:10:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A16055DE64; Tue, 15 May 2001 10:10:29 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 60BB45DF39 for ; Tue, 15 May 2001 10:08:37 -0400 (EDT) Received: (qmail 18759 invoked by uid 500); 15 May 2001 13:57:47 -0000 Date: Tue, 15 May 2001 06:57:47 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #2: Proposal to modify STI Message-ID: <20010515065746.Z10188@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a recap of what I believe the issue that was reported by Paul a few weeks ago, and my comments on how this could be achieved given the new base protocol. > Use of STR as indirect means of acknowledging STI > ------------------------------------------------- > I think that the mechanism of issuing an STI to > explicitly terminate a session and relying on STR/STA > to acknowledge is problematic. > > First, it is unnatural. Unlike a two-way transaction, > there is no guarantee of a response. The server simply > hopes to receive an STR. The STR is a SHOULD, not a > MUST, so it may not be forthcoming. The base protocol has made the STR a MUST, unless an error occured (see below). > And what if the > session is not active -- does the client lie and issue > an STR anyway? If the server does not see an STR, > should it retry the STI? A Failed-Ind will be issued by the NAS, with the Result-Code set to DIAMETER_UNKNOWN_SESSION_ID. > Second, what if the server that issues the STI is not > the authenticating server? For example, you might > want to maintain a server whose whole job is to kick > people off the network. > This forces the client to > send an STR to the authenticating server, who is > holding resources, as well as to the terminator > server. This is outside the normal flow of processing. I do not believe there are any limitations in the protocol that would restrict what you describe here. > Instead of an Indication, why not use Request/Answer > to kill a session? There's no law that says requests > can only flow downstream. That way, the terminator > server gets the result of its request in a natural > way, and the client simply issues the STR to the > authenticating server as it would do anyway. A further e-mail stated that you were in fact proposing a new set of messages (e.g. Kill-Session-Request/Answer). So replacing the STI with two messages. As it stands, I do not see any problems with the STI message, *but* if it is decided that the resolution in Issue #1 (Routing of Indication messages), requires that all indication messages be responded to, then an STI would require two full round trips, making the idea of a new message set (or re-using the STRs) MAY make alot more sense. Thanks, PatC From owner-aaa-bof@merit.edu Tue May 15 10:52:28 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29230 for ; Tue, 15 May 2001 10:52:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9BC345DFF5; Tue, 15 May 2001 10:11:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D97A35DFA9; Tue, 15 May 2001 10:10:59 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 96F935DF3E for ; Tue, 15 May 2001 10:09:11 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4FE9pv08441 for ; Tue, 15 May 2001 17:09:51 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 15 May 2001 17:09:09 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Tue, 15 May 2001 17:09:09 +0300 Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E62644@treis03nok> From: henry.haverinen@nokia.com To: pcalhoun@diameter.org Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Proposed addition to Diameter NASREQ draft Date: Tue, 15 May 2001 17:09:03 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > > How are the keys distributed to the user? Some EAP types can do it as part of the authentication procedure. These include EAP TLS (RFC 2716) and EAP SRP-SHA1 (draft-ietf-pppext- eap-srp-01.txt). I don't know if there are any ways to do it with the legacy RADIUS authentication protocols. Such key distribution is already being used with RADIUS. RFC 2548 describes Microsoft vendor-specific RADIUS extensions for this. Regards, Henry From owner-aaa-bof@merit.edu Tue May 15 11:38:49 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00438 for ; Tue, 15 May 2001 11:38:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4491C5DE13; Tue, 15 May 2001 11:38:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 169295DE14; Tue, 15 May 2001 11:38:39 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 5497E5DE13 for ; Tue, 15 May 2001 11:38:37 -0400 (EDT) Received: (qmail 19062 invoked by uid 500); 15 May 2001 15:27:47 -0000 Date: Tue, 15 May 2001 08:27:47 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #6: DSI Message-ID: <20010515082746.D10188@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk Paul opened another issue in regards to the DSI, and the fact that the DSI really shouldn't claim to be a hop-by-hop error condition, and should be end-to-end, allowing each proxy to take special action on the error, if possible. See http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00183.html to see Paul's original e-mail. First, I would like to examine each error condition, and provide my thoughts: DIAMETER_STILL_WORKING This DSI-Event really doesn't make a whole lot of sense. It is used to inform a peer that a request is still pending, and no response is available in the requested time, but the request is still being processed. I would claim that if a request cannot be satisfied in the requested time, return an error and be done with it. This error condition has the disadvantage of requiring that two messages (DSI and answer) will be returned with the same hop-by-hop and end-to-end ids, requiring special code in the Diameter base to handle. suggestion: move this error to Result-Code AVP, and make it such that the request is being abandoned. DIAMETER_REDIRECT_INDICATION This event is a hop-by-hop event, and shouldn't be combined with the Result-Code AVP. DIAMETER_UNSUPPORTED_TRANSFORM This error is end-to-end, and really belongs in the Result-Code AVP. DIAMETER_INVALID_ROUTE_RECORD This error is used to inform the peer that there is a routing error. This most likely belongs in the Result-Code AVP since the protocol doesn't have a way to self correct routing problems. In fact, Diameter routing is static. DIAMETER_COMMAND_UNSUPPORTED This command could be moved to the Result-Code, and a proxy *could* attempt to send the message to another peer, if it still has time (see Max-Wait-Time AVP). A proxy MAY decide that it isn't willing to send to another proxy, and abandon the request. DIAMETER_UNABLE_TO_DELIVER Same conditions as DIAMETER_COMMAND_UNSUPPORTED. DIAMETER_REALM_NOT_SERVED Same conditions as DIAMETER_COMMAND_UNSUPPORTED. DIAMETER_TOO_BUSY Same conditions as DIAMETER_COMMAND_UNSUPPORTED. DIAMETER_CANNOT_PROCESS_IN_TIME I dont' see the difference between this event, and the first one in this list. They could be combined. DIAMETER_NO_COMMON_EXTENSION This one really is a hop-by-hop error, and can only occur as a result of DRIs being exchanged. However, it makes sense to move this one to the Result-Code, and simply have the DRI with the 'F' bit set, indicating an Indication Failure. So it really doesn't need to be a DSI-Event. DIAMETER_UNSUPPORTED_VERSION See DIAMETER_NO_COMMON_EXTENSION. [end of DSI-Events] So, of the above events, the only one that really does have some hop-by-hop implications is the redirect event. I believe that all other errors could be easily moved to the Result-Code AVP. Alternatives ------------ Move all of the relevant DSI-Events to the Result-Code, fix up the text in the base protocol to reflect this. As far as indications, we have the following options: 1. Allow proxies to pretty much ignore the Result-Code AVP for most errors above, and replace the DSI with the Redirect-Indication message. I am not sure this is a good idea, since I would prefer that proxies handle the Result-Code AVP properly, and take whatever action is necessary. 2. All of the errors in the Result-Code that require proxy action have its own class of errors. This was done in the base spec some time back, but the DSI was introduced at the interim meeting, and these messages moved to the DSI. 3. Move the errors into the Result-Code, not in a new class, and require that proxies know when they need to take special action. 4. Leave it as is, but not require that the Origin-FQDN be replaced, since this was Paul's original comment. PatC From owner-aaa-bof@merit.edu Tue May 15 11:43:38 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00548 for ; Tue, 15 May 2001 11:43:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 435135DEA5; Tue, 15 May 2001 11:43:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 28AC55DE96; Tue, 15 May 2001 11:43:29 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 87F915DE3C for ; Tue, 15 May 2001 11:43:27 -0400 (EDT) Received: (qmail 19096 invoked by uid 500); 15 May 2001 15:32:37 -0000 Date: Tue, 15 May 2001 08:32:37 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #8: ASI Messages Message-ID: <20010515083237.F10188@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk As in RADIUS, how ASI is handled by proxies is undefined. Should the first hop be the target? Should the proxy forward this message to any downstream servers? We need to identify how the ASI is to be treated, or decide to leave it to implementations to figure out. From owner-aaa-bof@merit.edu Tue May 15 12:08:53 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01538 for ; Tue, 15 May 2001 12:08:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 41FF85DEAA; Tue, 15 May 2001 12:00:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3086A5DE80; Tue, 15 May 2001 12:00:56 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 0E1425DE91 for ; Tue, 15 May 2001 12:00:52 -0400 (EDT) Received: (qmail 19886 invoked by uid 500); 15 May 2001 15:50:01 -0000 Date: Tue, 15 May 2001 08:50:01 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Cc: david@mitton.com, aboba@internaut.com, randy@psg.com Subject: [AAA-WG]: Reality of the Interim Meeting Message-ID: <20010515085001.G10188@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu, david@mitton.com, aboba@internaut.com, randy@psg.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, The original intent of the interim meeting, as I understand it, was to have a document reading party. However, the list of pending issues that we haven't been able to come to some conclusion is quite extensive, and will take a good part of both days. So, we really need to be realistic here. Either we are having a document reading party, or we are going to solve pending issues. We can't have both. If we decide, as we have no choice, to do the former, this means that our document reading party will not occur, and I believe this is really necessary prior to WG last call. Furthermore, trying to squeeze this in, while I make extensive changes to the specifications would be questionable. So, I believe that we have no choice but to schedule another interim meeting, to hold as our document reading party. I would *strongly* propose that we hold this meeting the week of June 11th, 25th, or July 9th. Location TBD. Thanks, PatC From owner-aaa-bof@merit.edu Tue May 15 12:11:20 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01703 for ; Tue, 15 May 2001 12:11:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE3175E036; Tue, 15 May 2001 12:10:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0DB645E01F; Tue, 15 May 2001 12:10:33 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 340205E036 for ; Tue, 15 May 2001 12:10:30 -0400 (EDT) Received: (qmail 19947 invoked by uid 500); 15 May 2001 15:59:39 -0000 Date: Tue, 15 May 2001 08:59:39 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #10: Proposed key addition to nasreq spec Message-ID: <20010515085939.I10188@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk In order to properly support Key distribution with NASREQ applications, such as 802.11, there seems to be a need to support key distribution within the NASREQ extension. The proposal is at http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00230.html PatC From owner-aaa-bof@merit.edu Tue May 15 12:37:03 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02435 for ; Tue, 15 May 2001 12:37:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE0C55DFC6; Tue, 15 May 2001 12:30:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DA88B5DFC5; Tue, 15 May 2001 12:30:49 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 3C32B5DFC4 for ; Tue, 15 May 2001 12:30:48 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24374; Tue, 15 May 2001 09:30:39 -0700 (PDT) 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 JAA16965; Tue, 15 May 2001 09:30:07 -0700 (PDT) Received: from darius (darius [152.70.40.121]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA16326; Tue, 15 May 2001 09:30:06 -0700 (PDT) Date: Tue, 15 May 2001 09:30:18 -0700 (PDT) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Issue #4: Grouped AVP To: Ignacio Goyret Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <3.0.5.32.20010515092221.039a3100@grigri.eng.ascend.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk thanks for the comments Ignacio. So far we have four people very vocal to changing the Grouped AVP to be more flexible, and one reason being that the protocol wouldn't be useable in today's networks. There is one person against such a proposal. I believe that the chairs will have to evaluate whether or not we have consensus, and I am not sure that all of the interested parties can make the meeting next week. PatC > At 07:17 AM 5/15/01 -0700, Pat Calhoun wrote: > >Erik has made a claim that issues against the issues draft need to be > >raised, since this draft had passed last call, with no objections. Changing > >the Grouped-AVP at this time could add significant delays. > > Maybe, but it will also make Diameter useable. As it stands, Diameter > cannot be deployed realistically on an environment that implements > tunneling (or at least, not without some serious vendor extensions). > > There are many reasons why someone will not want to specify all the > tunneling attributes. For example, we have customers that will not send > a Tunnel-Password attribute under any circumstance. They have business > reasons that can't be ignored just because they don't fit the AAA WG > schedule. > > I know you and the WG have been working extremely hard on this (the community > at large appreciates your effort) but, IMHO, ignoring the real world because > "it would add delays" essentially will condemn Diameter to be a passing fad. > RADIUS lives on simply because it is simple and very flexible. If you want > Diameter to have a long life, it MUST be flexible as well because simple, it > isn't. > > > From owner-aaa-bof@merit.edu Tue May 15 12:47:29 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02708 for ; Tue, 15 May 2001 12:47:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C8D365DE89; Tue, 15 May 2001 11:41:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7FB3D5DE5C; Tue, 15 May 2001 11:41:44 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id DB5555DE89 for ; Tue, 15 May 2001 11:41:42 -0400 (EDT) Received: (qmail 19083 invoked by uid 500); 15 May 2001 15:30:52 -0000 Date: Tue, 15 May 2001 08:30:52 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #7: Watchdogs Message-ID: <20010515083052.E10188@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk Jon Wood initiated a thread that didn't receive that much attention, but his point was that SCTP already had watchdogs, and he questioned the need for application level watchdogs. I know that this question was answered at the last Interim Meeting, but I cannot recall what it was. Paul also asked why the watchdogs are retransmitted. I am waiting for new failover text that will hopefully makes this much clearer. We should discuss this next week. PatC From owner-aaa-bof@merit.edu Tue May 15 14:36: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 OAA04849 for ; Tue, 15 May 2001 14:36:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C9C95E003; Tue, 15 May 2001 12:08:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 42C945E002; Tue, 15 May 2001 12:08:14 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E6BE25DFE4 for ; Tue, 15 May 2001 12:08:00 -0400 (EDT) Received: (qmail 19929 invoked by uid 500); 15 May 2001 15:57:10 -0000 Date: Tue, 15 May 2001 08:57:09 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #9: Certs for Redirect-Host Message-ID: <20010515085709.H10188@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk Paul brought up an interesting point that it would be nice for all the servers in a home network to share a private key, and act as redundant servers. However, could such a certificate be used, and if so, what would it look like? The E2E sec spec needs to discuss this. Furthermore, would the identities of all possible servers be in the cert? If not, how would certs be matched against hosts encoded in Redirect-Host AVPs? PatC From owner-aaa-bof@merit.edu Tue May 15 15:07: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 PAA05380 for ; Tue, 15 May 2001 15:07:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 052A35DF9A; Tue, 15 May 2001 10:40:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7D05B5E2A2; Tue, 15 May 2001 10:31:12 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id BE7035E1F9 for ; Tue, 15 May 2001 10:28:35 -0400 (EDT) Received: (qmail 18854 invoked by uid 500); 15 May 2001 14:17:44 -0000 Date: Tue, 15 May 2001 07:17:44 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #4: Grouped AVP Message-ID: <20010515071744.B10188@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk Given that this one hasn't been closed, I will open an issue so we can discuss it next week. Paul has indicated some circumstances where the strictness of the Grouped AVP is a disadvantage. Example: The tunneling Grouped AVP in NASREQ requires that ALL tunneling AVPs be present, even if they shouldn't). So either we leave it as-is, or create a group for all combinations. Erik has made a claim that issues against the issues draft need to be raised, since this draft had passed last call, with no objections. Changing the Grouped-AVP at this time could add significant delays. PatC From owner-aaa-bof@merit.edu Tue May 15 16:12: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 QAA06129 for ; Tue, 15 May 2001 16:12:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 17B985DDC1; Tue, 15 May 2001 16:09:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 844085DE83; Tue, 15 May 2001 16:01:20 -0400 (EDT) Received: from c000.snv.cp.net (c000-h001.c000.snv.cp.net [209.228.32.65]) by segue.merit.edu (Postfix) with SMTP id AF0605E01B for ; Tue, 15 May 2001 15:58:53 -0400 (EDT) Received: (cpmta 15182 invoked from network); 15 May 2001 12:58:52 -0700 Received: from h121s86a16n47.user.nortelnetworks.com (HELO mitton.mitton.com) (47.16.86.121) by smtp.mitton.com (209.228.32.65) with SMTP; 15 May 2001 12:58:52 -0700 X-Sent: 15 May 2001 19:58:52 GMT Message-Id: <4.3.2.7.2.20010515155607.00e2af00@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 May 2001 16:01:08 -0400 To: aaa-wg@merit.edu From: David Mitton Subject: [AAA-WG]: Re: Consensus Building and Meetings Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk At 5/15/01 09:30 AM -0700, you wrote: >thanks for the comments Ignacio. > >So far we have four people very vocal to changing the Grouped AVP to be more >flexible, and one reason being that the protocol wouldn't be useable in >today's >networks. There is one person against such a proposal. > >I believe that the chairs will have to evaluate whether or not we have >consensus, and I am not sure that all of the interested parties can make >the meeting next week. I would like to reinforce a point that was brought up privately... The opinion of the parties that actually attend the Interim Meeting do NOT negate any opinions of people on the list. The meeting is a venue to move the discussion along in real-time and captively gauge the opinions of those in the room. Group Consensus will be judged by the combination of all inputs. Of course, if we don't hear from you,... well you can figure it out. Dave. (at least we're not going to Florida... but that's probably a feature...) ---------------------------------------------------- David Mitton 978-288-4570 Advisor, Nortel Networks david@mitton.com or dmitton@nortelnetworks.com From owner-aaa-bof@merit.edu Tue May 15 16:29: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 QAA06327 for ; Tue, 15 May 2001 16:29:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 01F895DEBC; Tue, 15 May 2001 16:27:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2F8F75DF13; Tue, 15 May 2001 16:26:15 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 701FE5DDED for ; Tue, 15 May 2001 16:24:57 -0400 (EDT) Received: (qmail 26311 invoked by uid 500); 15 May 2001 20:14:06 -0000 Date: Tue, 15 May 2001 13:14:06 -0700 From: Pat Calhoun To: David Mitton Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Consensus Building and Meetings Message-ID: <20010515131406.L10188@charizard.diameter.org> Mail-Followup-To: David Mitton , aaa-wg@merit.edu References: <4.3.2.7.2.20010515155607.00e2af00@getmail.mitton.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010515155607.00e2af00@getmail.mitton.com>; from david@mitton.com on Tue, May 15, 2001 at 04:01:08PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Tue, May 15, 2001 at 04:01:08PM -0400, David Mitton wrote: > I would like to reinforce a point that was brought up privately... > > The opinion of the parties that actually attend the Interim Meeting do NOT > negate any opinions of people on the list. The meeting is a venue to move > the discussion along in real-time and captively gauge the opinions of those > in the room. > > Group Consensus will be judged by the combination of all inputs. > > Of course, if we don't hear from you,... well you can figure it out. sigh. The following applies only to the Grouped-AVP, because it is such a controversial topic. I do not believe that it is fair to allow people to raise their concerns at next week's meeting, if these concerns were never brought up on the list. I believe that people that cannot make the meeting should have a preview of people's concerns, so they can respond to it. I honestly do not believe that we will expedite the process by allowing people to voice their concern at the meeting, waste time going back and forth discussing this, and then have to take it back on the list anyways. We will most certainly waste alot of our time. my 2 cents, PatC From owner-aaa-bof@merit.edu Tue May 15 17:33: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 RAA07668 for ; Tue, 15 May 2001 17:33:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 046235E05D; Tue, 15 May 2001 17:30:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 80A815DE91; Tue, 15 May 2001 17:29:40 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 7ACB45DE65 for ; Tue, 15 May 2001 17:27:35 -0400 (EDT) Received: (qmail 27148 invoked by uid 500); 15 May 2001 21:16:44 -0000 Date: Tue, 15 May 2001 14:16:44 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #11: Head of Line Blocking Prevention Message-ID: <20010515141643.N10188@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk Here is an e-mail sent by Jon, identifying another unresolved issue. Although he *just* sent it to the list, I wanted a subject that will make it easier to track. PatC ---- One other proposal I made was a way to prevent head-of-the-line blocking. In terms of the spec, there are two pretty minor things that would have to be added: 1. For interoperability: All Diameter nodes MUST be prepared to receive Diameter messages on any SCTP stream in the association. 2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP streams available to the association to prevent head-of-the-line blocking. WRT 2, the striping method I proposed should be very simple and effective, but I see no reason to force implementations to use it if they think they can do better. From owner-aaa-bof@merit.edu Tue May 15 17:52: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 RAA07989 for ; Tue, 15 May 2001 17:52:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4DF5F5DF4A; Tue, 15 May 2001 16:51:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DDE385E35C; Tue, 15 May 2001 16:35:13 -0400 (EDT) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id BDF4A5DF64 for ; Tue, 15 May 2001 16:32:01 -0400 (EDT) Received: from jariws1 ([193.229.23.136]) by fep01-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010515203201.KHJJ24620.fep01-app.kolumbus.fi@jariws1>; Tue, 15 May 2001 23:32:01 +0300 Message-ID: <009601c0dd82$ebb70120$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pat Calhoun" , References: <20010515085939.I10188@charizard.diameter.org> Subject: Re: [AAA-WG]: Issue #10: Proposed key addition to nasreq spec Date: Wed, 16 May 2001 00:06:33 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > The proposal is at > http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00230.html The proposal looks good to me, and as far as I can see the functionality fulfills the usage scenarios I had in mind. Jari From owner-aaa-bof@merit.edu Tue May 15 18:02: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 SAA08106 for ; Tue, 15 May 2001 18:02:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8723D5DE83; Tue, 15 May 2001 18:00:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1DED35DF26; Tue, 15 May 2001 18:00:23 -0400 (EDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by segue.merit.edu (Postfix) with ESMTP id 65BB65DE83 for ; Tue, 15 May 2001 18:00:19 -0400 (EDT) Received: from JSCHNIZL-W2K.cisco.com (jschnizl-isdn2.cisco.com [171.68.12.75]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA20558; Tue, 15 May 2001 14:59:46 -0700 (PDT) Message-Id: <4.3.2.7.2.20010515175256.02d6cf08@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 May 2001 17:58:19 -0400 To: Pat Calhoun From: John Schnizlein Subject: Re: [AAA-WG]: Re: Consensus Building and Meetings Cc: David Mitton , aaa-wg@merit.edu In-Reply-To: <20010515131406.L10188@charizard.diameter.org> References: <4.3.2.7.2.20010515155607.00e2af00@getmail.mitton.com> <4.3.2.7.2.20010515155607.00e2af00@getmail.mitton.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Those of us who are not in the meeting have a reasonable expectation that as many issues as possible will be addressed by the most strident opinion holders during the face-to-face so that they can find common ground, explain the errors in each other's thinking, and bring a resolution back to the list. Consensus is measured on the list, but compromise often requires that people get tired and expose an unstated (and erroneous) view during the thick of the discussion. You just can't make a deal that the rest of us think is distorted. It does seem you will have fun. Good luck to you all. John At 04:14 PM 5/15/2001, Pat Calhoun wrote: >I do not believe that it is fair to allow people to raise their concerns >at next week's meeting, if these concerns were never brought up on the list. >I believe that people that cannot make the meeting should have a preview >of people's concerns, so they can respond to it. > >I honestly do not believe that we will expedite the process by allowing >people to voice their concern at the meeting, waste time going back and >forth discussing this, and then have to take it back on the list anyways. >We will most certainly waste alot of our time. From owner-aaa-bof@merit.edu Tue May 15 18:20: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 SAA08287 for ; Tue, 15 May 2001 18:20:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 06A355DE82; Tue, 15 May 2001 17:41:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 197755E0E3; Tue, 15 May 2001 17:39:56 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 035215E1E4 for ; Tue, 15 May 2001 17:33:21 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA04536 for ; Tue, 15 May 2001 14:33:19 -0700 (PDT) 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 OAA27007 for ; Tue, 15 May 2001 14:32:43 -0700 (PDT) Received: from sun.com (dsl199-239.Eng.Sun.COM [129.146.199.239]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id OAA21080 for ; Tue, 15 May 2001 14:32:42 -0700 (PDT) Message-ID: <3B0192D7.7C41713F@sun.com> Date: Tue, 15 May 2001 13:34:31 -0700 From: jonathan wood X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: New Diameter IDs are now available References: <20010514175058.T10188@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit One other proposal I made was a way to prevent head-of-the-line blocking. In terms of the spec, there are two pretty minor things that would have to be added: 1. For interoperability: All Diameter nodes MUST be prepared to receive Diameter messages on any SCTP stream in the association. 2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP streams available to the association to prevent head-of-the-line blocking. WRT 2, the striping method I proposed should be very simple and effective, but I see no reason to force implementations to use it if they think they can do better. Jonathan Pat Calhoun wrote: > > All, > > The following Internet Drafts are now available on www.diameter.org, and > have been sent to the secretariat. I propose that these are the versions > of the specs that we will review at next week's interim meeting. > > The following are the pending issues that I have been tracking: > > 1. watchdog/failover text > 2. proposal to remove watchdog over reliable transports (Jonathan Wood) > 3. proposal to kill STI (although I don't think this is really > necessary anymore) > 4. proposal to modify/hack/kill DSI > 5. proposal to make Grouped AVPs more open > 6. The various Boot-Id proposals > > I will have to go through the archives again to see if I've missed anything, > but at a minimum we need to discuss the above issues at next week's meeting. > > Oh, and somehow I believe we are also going to have a document > reading party. > > PatC From owner-aaa-bof@merit.edu Tue May 15 18:48: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 SAA08588 for ; Tue, 15 May 2001 18:48:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A68FF5DEB1; Tue, 15 May 2001 18:47:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 94CCB5DEAE; Tue, 15 May 2001 18:47:02 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 5AB6D5DE90 for ; Tue, 15 May 2001 18:47:00 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id PAA24075; Tue, 15 May 2001 15:38:05 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 15 May 2001 15:38:05 -0700 (PDT) From: Bernard Aboba To: John Schnizlein Cc: Pat Calhoun , David Mitton , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Consensus Building and Meetings In-Reply-To: <4.3.2.7.2.20010515175256.02d6cf08@diablo.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > At 04:14 PM 5/15/2001, Pat Calhoun wrote: > > >I do not believe that it is fair to allow people to raise their concerns > >at next week's meeting, if these concerns were never brought up on the list. > >I believe that people that cannot make the meeting should have a preview > >of people's concerns, so they can respond to it. > > > >I honestly do not believe that we will expedite the process by allowing > >people to voice their concern at the meeting, waste time going back and > >forth discussing this, and then have to take it back on the list anyways. > >We will most certainly waste alot of our time. > The IETF standards process requires that change control be ceded to an IETF working group for a document to be considered for standards status. That requires the establishment of an open process during which working group concerns and opinions can be voiced and responded to by the bulk of the working group. Part of the process of qualifying for standards status is the demonstration that WG consensus is reflected on the documents. To date we have followed a relatively informal process in taking change requests, establishing consensus, and reflecting changes within the document. While this has enabled us to move more quickly, it also creates the possibility of misunderstandings as to what we have agreed to and what issues remain open. As the documents get closer to completion, in order to make our milestones, we will need to tighten the requirements on taking changes. I am currently working on investigating various methods for formally tracking change requests, and documenting decisions so that we can exhibit better collective memory on what issues are open, what the discussion has been so far, what issues remain to be resolved and how far we are from completion. Given the large size of the documents we are dealing with and the huge volume of suggestions and discussion, I believe that such methods are going to be required to help keep us on track. Those of you that participating in managing software development projects should understand how valuable these tools can be. If you are interested in discussing tools (open source, please!) available for the task, send mail to me or Dave. Note that the goal here is not to shut down working group discussion, but merely to allow the group to gain better collective awareness of where we are and what decisions have been made. Since the time at the Interim meeting is valuable, we will not be able to spend time discussing all possible changes to the documents. Rather my hope is that we will clearly identify all remaining issues, and will tackle those that are most amenable to resolution within the time available. As a result, participants should not be disappointed if the group chooses not to spend time discussing one or more issues at the Interim meeting. We do however promise to track all the issues that are raised and bring them to resolution at some point. From owner-aaa-bof@merit.edu Tue May 15 20:01: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 UAA10022 for ; Tue, 15 May 2001 20:01:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 80A895DDB3; Tue, 15 May 2001 12:22:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6D5165DDA7; Tue, 15 May 2001 12:22:30 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by segue.merit.edu (Postfix) with ESMTP id 960775DDA1 for ; Tue, 15 May 2001 12:22:28 -0400 (EDT) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id JAA06148; Tue, 15 May 2001 09:21:58 -0700 (PDT) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 15 May 2001 16:22:27 UT Received: from grigri.eng.ascend.com (grigri.eng.ascend.com [135.140.53.45]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id JAA23632; Tue, 15 May 2001 09:22:26 -0700 (PDT) Received: from igoyret-pc by grigri.eng.ascend.com (8.8.8+Sun/SMI-SVR4) id JAA28191; Tue, 15 May 2001 09:22:26 -0700 (PDT) Message-Id: <3.0.5.32.20010515092221.039a3100@grigri.eng.ascend.com> X-Sender: igoyret@grigri.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 15 May 2001 09:22:21 -0700 To: Pat Calhoun From: Ignacio Goyret Subject: Re: [AAA-WG]: Issue #4: Grouped AVP Cc: aaa-wg@merit.edu In-Reply-To: <20010515071744.B10188@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 07:17 AM 5/15/01 -0700, Pat Calhoun wrote: >Erik has made a claim that issues against the issues draft need to be >raised, since this draft had passed last call, with no objections. Changing >the Grouped-AVP at this time could add significant delays. Maybe, but it will also make Diameter useable. As it stands, Diameter cannot be deployed realistically on an environment that implements tunneling (or at least, not without some serious vendor extensions). There are many reasons why someone will not want to specify all the tunneling attributes. For example, we have customers that will not send a Tunnel-Password attribute under any circumstance. They have business reasons that can't be ignored just because they don't fit the AAA WG schedule. I know you and the WG have been working extremely hard on this (the community at large appreciates your effort) but, IMHO, ignoring the real world because "it would add delays" essentially will condemn Diameter to be a passing fad. RADIUS lives on simply because it is simple and very flexible. If you want Diameter to have a long life, it MUST be flexible as well because simple, it isn't. From owner-aaa-bof@merit.edu Tue May 15 23:45: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 XAA15021 for ; Tue, 15 May 2001 23:45:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3464F5DDCC; Tue, 15 May 2001 23:15:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 231825DDCB; Tue, 15 May 2001 23:15:50 -0400 (EDT) Received: from roam.psg.com (roam.psg.com [147.28.4.2]) by segue.merit.edu (Postfix) with ESMTP id A76015DDA8 for ; Tue, 15 May 2001 23:15:48 -0400 (EDT) Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14zrdY-0000uR-00; Tue, 15 May 2001 23:06:08 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: John Schnizlein Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Consensus Building and Meetings References: <4.3.2.7.2.20010515155607.00e2af00@getmail.mitton.com> <4.3.2.7.2.20010515175256.02d6cf08@diablo.cisco.com> Message-Id: Date: Tue, 15 May 2001 23:06:08 -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Those of us who are not in the meeting have a reasonable expectation > that as many issues as possible will be addressed by the most strident > opinion holders during the face-to-face so that they can find common > ground, explain the errors in each other's thinking, and bring a resolution > back to the list. Consensus is measured on the list, but compromise often > requires that people get tired and expose an unstated (and erroneous) view > during the thick of the discussion. You just can't make a deal that the > rest of us think is distorted. bingo! you buckin' for my job? probably not, as you don't seem that foolish. :-) randy From owner-aaa-bof@merit.edu Tue May 15 23:59: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 XAA15157 for ; Tue, 15 May 2001 23:59:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 450EA5DDCB; Tue, 15 May 2001 23:59:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3351C5DDC2; Tue, 15 May 2001 23:59:17 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id DFB3C5DD9F for ; Tue, 15 May 2001 23:59:14 -0400 (EDT) Received: (qmail 28801 invoked by uid 500); 16 May 2001 03:48:22 -0000 Date: Tue, 15 May 2001 20:48:22 -0700 From: Pat Calhoun To: Bernard Aboba Cc: John Schnizlein , Pat Calhoun , David Mitton , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Consensus Building and Meetings Message-ID: <20010515204821.Q10188@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , John Schnizlein , Pat Calhoun , David Mitton , aaa-wg@merit.edu References: <4.3.2.7.2.20010515175256.02d6cf08@diablo.cisco.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 aboba@internaut.com on Tue, May 15, 2001 at 03:38:05PM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk Now really sorry I started all this mess :( On Tue, May 15, 2001 at 03:38:05PM -0700, Bernard Aboba wrote: > The IETF standards process requires that change control be ceded to an > IETF working group for a document to be considered for standards > status. That requires the establishment of an open process during which > working group concerns and opinions can be voiced and responded to by the > bulk of the working group. Part of the process of qualifying for standards > status is the demonstration that WG consensus is reflected on the > documents. Right, and my point was that alot of debate will occur next week over this very topic. And I find that in all fairness, these issues should be voiced ahead of time, just like the drafts, so people know what they are up against. I really don't think that I was asking for too much. This was in response to Dave's e-mail stating that e-mail and meeting opinions will be gathered, and a concensus will result. Perhaps I just mis-read his e-mail. > > To date we have followed a relatively informal process in taking change > requests, establishing consensus, and reflecting changes within the > document. While this has enabled us to move more quickly, it also > creates the possibility of misunderstandings as to what we have > agreed to and what issues remain open. As the documents get closer to > completion, in order to make our milestones, we will need to tighten the > requirements on taking changes. right, and as a point of clarification, I have not added any new features, but only fixed bugs in the protocol that were obvious, and no one objected to the proposed change. In the case where there wasn't complete consensus, or at least one person disagreed, I didn't make the change. These open issues were sent by me to the mailing list this morning so people can start looking at what we need to work on next week. > > I am currently working on investigating various methods for formally > tracking change requests, and documenting decisions so that we can exhibit > better collective memory on what issues are open, what the discussion has > been so far, what issues remain to be resolved and how far we are from > completion. Given the large size of the documents we are dealing with and > the huge volume of suggestions and discussion, I believe that such methods > are going to be required to help keep us on track. Those of you that > participating in managing software development projects should > understand how valuable these tools can be. If you are interested > in discussing tools (open source, please!) available for the task, send > mail to me or Dave. The current method that I have been using is this: 1. people email problem to list. 2. I respond, as do others. 3. I, or someone else, proposes new text. 4. We open discussion on the new text. 5. If no one disagrees, the text is adopted. We could, of course, use a more formal approach, but the above has worked fine so far, and can be tracked via the archives. Anyone can see the archives, and no special software is needed (well, besides a browser). Also, if people wish to have access to the nroff sources sccs files, I can make those available. Now, let's get back to work, and I appologize I opened this can or worms. PatC From owner-aaa-bof@merit.edu Wed May 16 02:16: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 CAA27260 for ; Wed, 16 May 2001 02:16:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EEFB05DDFF; Wed, 16 May 2001 02:00:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3CDA45DE00; Wed, 16 May 2001 02:00:32 -0400 (EDT) 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 6E2AB5DDC0 for ; Wed, 16 May 2001 02:00:23 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f4G60MN07316 for ; Wed, 16 May 2001 08:00:22 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Wed May 16 08:00:22 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 16 May 2001 08:00:21 +0200 Message-ID: <577066326047D41180AC00508B955DDA02C009F9@eestqnt104.es.eu.ericsson.se> From: "Yolanda Garcia-Serrano (ECE)" To: "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Accounting clarifications Date: Wed, 16 May 2001 08:00:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, Pat This time the concern is some accounting issues I would like to get clarified: 12.5. Accounting-Records What can be exactly an accounted service? Is it an extension (Mobile IP, NASREQ), or is it indicated by Service-Type AVP in NASREQ, but in Mobile IP which is the service/s? Could be the text more specific, giving some examples? 14.1 Accounting-Record-Type Are EVENT_RECORDs (one-time events) and START-STOP records mutually exclusive for the same Session-Id, i.e. if received an event record for sessionId=x.abc.com:8888:1234567890 is/is not possible to receive a Start/interim/stop one for same sessionId=x.abc.com:8888:1234567890 ? Is the type or record (EVENT vs START/INTERIM/STOP) tight to the particular kind of service, so that when some services are used, it is reported accounted info of kind EVENT, and when some other services are used, it is reported accounted info in the style Start/Interim/Stop ? Is it possible to send (Diameter client)/receive (Accounting server) several EVENT_RECORD for the same Session-Id? Same question but for measurable length services: is it possible to send/receive several START-STOP sequences for the same Session-Id? For the answer of all these questions, could be added the corresponding clarifying text on the I-D? It would be quite helpful. Thank you very much, and best regards /Yolanda Garcia From owner-aaa-bof@merit.edu Wed May 16 02:32:46 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28542 for ; Wed, 16 May 2001 02:32:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E7CB35DDD4; Wed, 16 May 2001 02:30:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C74085DDC0; Wed, 16 May 2001 02:30:46 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 687645DD9D for ; Wed, 16 May 2001 02:30:45 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA08195; Tue, 15 May 2001 23:30:43 -0700 (PDT) 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.1p1) with SMTP id IAA00657; Wed, 16 May 2001 08:30:41 +0200 (MET DST) Date: Wed, 16 May 2001 08:42:15 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: [AAA-WG]: Re: Consensus Building and Meetings To: Pat Calhoun Cc: David Mitton , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <20010515131406.L10188@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > On Tue, May 15, 2001 at 04:01:08PM -0400, David Mitton wrote: > > Group Consensus will be judged by the combination of all inputs. > The following applies only to the Grouped-AVP, because it is such a > controversial topic. > > I honestly do not believe that we will expedite the process by allowing > people to voice their concern at the meeting, waste time going back and > forth discussing this, and then have to take it back on the list anyways. > We will most certainly waste alot of our time. Let's resolve the Group AVP issue. My basic point is that if we don't have basic types which are expressable by a formal grammar, we lose the ability to automate and verify the protocol. Others have expressed that it would be unacceptable to give up flexibility. Unless there's additional support for my position, we can replace the Group type with the Bag. I will go along with rough group consensus, even if I'm the rough part. Erik From owner-aaa-bof@merit.edu Wed May 16 03:27: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 DAA00839 for ; Wed, 16 May 2001 03:27:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A6B505DD9D; Wed, 16 May 2001 03:27:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7B5F75DDC0; Wed, 16 May 2001 03:27:17 -0400 (EDT) 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 958FB5DD9D for ; Wed, 16 May 2001 03:27:14 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f4G7RDN11246 for ; Wed, 16 May 2001 09:27:13 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed May 16 09:27:12 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 16 May 2001 09:27:12 +0200 Message-ID: <577066326047D41180AC00508B955DDA01D7FFF0@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Jari Arkko'" , stephen.farrell@baltimore.ie, Bernard Aboba Cc: Pat Calhoun , Thomas Panagiotis-PTHOMAS1 , aaa-wg@merit.edu Subject: RE: [AAA-WG]: End-2-End security Date: Wed, 16 May 2001 09:27:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk I think it could be left to the Diameter server providers to support or not the e2e security extension, and left to their customers to decide whether they need it or not. It does not seem to be a MANDATORY extension to me. Proxy servers do not even need to support it, in order to carry the messages, right? I can easily see Diameter servers only counting on IPsec for their security mechanism. Furthermore, I'd prefer seeing Diameter product releases ASAP. Martin > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Monday, May 14, 2001 6:34 PM > To: stephen.farrell@baltimore.ie; Bernard Aboba > Cc: Pat Calhoun; Thomas Panagiotis-PTHOMAS1; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: End-2-End security > > > > > So End-2-End security is a MAY for Clients and Servers, right? > > I would be in favor of making e2e a MAY for at least clients. > > Jari > > > > From owner-aaa-bof@merit.edu Wed May 16 04:43: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 EAA01468 for ; Wed, 16 May 2001 04:43:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B19AB5DDEF; Wed, 16 May 2001 04:43:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A14A15DDEC; Wed, 16 May 2001 04:43:47 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id D57B75DDE8 for ; Wed, 16 May 2001 04:43:45 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id BAA24664; Wed, 16 May 2001 01:34:56 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 16 May 2001 01:34:56 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: John Schnizlein , David Mitton , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Consensus Building and Meetings In-Reply-To: <20010515204821.Q10188@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Right, and my point was that alot of debate will occur next week over this > very topic. And I find that in all fairness, these issues should be > voiced ahead of time, just like the drafts, so people know what they are > up against. This is actually not a bad idea. One way to accomplish this might be to have people submit their comments in a manner that might be easily organized and tracked. We could then compile the issues list and go through it expeditiously at the Interim. For some example tools that might enable this, see: http://www.drizzle.com/~aboba/tools/ Note: this would require sending out the comment form and getting responses back to an email address by Sunday, as well as Internet access at the Interim meeting. I assume that interim attendees are sufficiently motivated to commit to this ;) > We could, of course, use a more formal approach, but the above has worked > fine so far, and can be tracked via the archives. Anyone can see the > archives, and no special software is needed (well, besides a browser). Agree that any methods used should be simple and available to everyone (e.g. based on StarOffice formats, export to text/HTML, etc.). Take a look at the example tools -- I think they meet this criteria. Just used them in another setting to dispose of hundreds of comments in two days. > Also, if people wish to have access to the nroff sources sccs files, > I can make those available. > Don't think that would help, though thanks for the offer. From owner-aaa-bof@merit.edu Wed May 16 05:25: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 FAA01765 for ; Wed, 16 May 2001 05:25:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A00A05DDA3; Wed, 16 May 2001 05:25:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8D47E5DDEC; Wed, 16 May 2001 05:25:21 -0400 (EDT) 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 A76AD5DDA3 for ; Wed, 16 May 2001 05:25:19 -0400 (EDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f4G9PIO08843 for ; Wed, 16 May 2001 11:25:18 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed May 16 11:25:17 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 16 May 2001 11:25:17 +0200 Message-ID: <577066326047D41180AC00508B955DDA01D7FFF8@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , aaa-wg@merit.edu, "'paul@funk.com'" Cc: "Martin Julien (ECE)" Subject: RE: [AAA-WG]: Issue #2: Proposal to modify STI Date: Wed, 16 May 2001 11:24:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > This is a recap of what I believe the issue that was reported by > Paul a few weeks ago, and my comments on how this could be achieved > given the new base protocol. > > > Use of STR as indirect means of acknowledging STI > > ------------------------------------------------- > > I think that the mechanism of issuing an STI to > > explicitly terminate a session and relying on STR/STA > > to acknowledge is problematic. > > > > First, it is unnatural. Unlike a two-way transaction, > > there is no guarantee of a response. The server simply > > hopes to receive an STR. The STR is a SHOULD, not a > > MUST, so it may not be forthcoming. > > The base protocol has made the STR a MUST, unless an error occured > (see below). Then, it seems that 3 messages (STI, STR/STA) are required for a task that could be handled using a single Request/Answer message from an Authenticator server. I would prefer a simple Request/Answer type of message from the Authenticator server which would inform the Diameter client that it needs to release the resources for that session. I do not really see what we gain by having a STI apart from from the STR/STA message, in order to terminate a session on a client? > > And what if the > > session is not active -- does the client lie and issue > > an STR anyway? If the server does not see an STR, > > should it retry the STI? > > A Failed-Ind will be issued by the NAS, with the Result-Code set to > DIAMETER_UNKNOWN_SESSION_ID. > > > Second, what if the server that issues the STI is not > > the authenticating server? For example, you might > > want to maintain a server whose whole job is to kick > > people off the network. > > This forces the client to > > send an STR to the authenticating server, who is > > holding resources, as well as to the terminator > > server. This is outside the normal flow of processing. > > I do not believe there are any limitations in the protocol > that would restrict what you describe here. From what I understand, I think the desired functionality here is a terminator server sending a "killing session request" message to the Diameter client, which would then send an STR to the Home server with a reason that a "Killing session request" has been received. If the Home server accepts this, then it sends back a STA to the client, which in turn responds to the killing session request with a successful answer. I'm not sure what kind of terminator servers you have in mind, but it would be nice to hear about it, since they also need a session-Id I suppose?, unless it would be sufficient to only request to kill all sessions based on User-Name, or something else based on policies? > > Instead of an Indication, why not use Request/Answer > > to kill a session? There's no law that says requests > > can only flow downstream. That way, the terminator > > server gets the result of its request in a natural > > way, and the client simply issues the STR to the > > authenticating server as it would do anyway. > > A further e-mail stated that you were in fact proposing a new > set of messages (e.g. Kill-Session-Request/Answer). So > replacing the STI with two messages. > > As it stands, I do not see any problems with the STI message, > *but* if it is decided that the resolution in Issue #1 (Routing > of Indication messages), requires that all indication messages > be responded to, then an STI would require two full round trips, > making the idea of a new message set (or re-using the STRs) MAY > make alot more sense. > > Thanks, > > PatC > From owner-aaa-bof@merit.edu Wed May 16 09:36: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 JAA08577 for ; Wed, 16 May 2001 09:36:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AD1845DE14; Wed, 16 May 2001 09:36:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9ABAA5DE0F; Wed, 16 May 2001 09:36:28 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id EB07E5DE09 for ; Wed, 16 May 2001 09:36:26 -0400 (EDT) Received: (qmail 32608 invoked by uid 500); 16 May 2001 13:25:33 -0000 Date: Wed, 16 May 2001 06:25:33 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'Jari Arkko'" , stephen.farrell@baltimore.ie, Bernard Aboba , Pat Calhoun , Thomas Panagiotis-PTHOMAS1 , aaa-wg@merit.edu Subject: Re: [AAA-WG]: End-2-End security Message-ID: <20010516062532.A32602@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , 'Jari Arkko' , stephen.farrell@baltimore.ie, Bernard Aboba , Pat Calhoun , Thomas Panagiotis-PTHOMAS1 , aaa-wg@merit.edu References: <577066326047D41180AC00508B955DDA01D7FFF0@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA01D7FFF0@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Wed, May 16, 2001 at 09:27:11AM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, May 16, 2001 at 09:27:11AM +0200, Martin Julien (ECE) wrote: > I think it could be left to the Diameter server providers to > support or not the e2e security extension, and left to their customers > to decide whether they need it or not. It does not seem to be > a MANDATORY extension to me. Proxy servers do not even need to > support it, in order to carry the messages, right? > I can easily see Diameter servers only counting on IPsec for > their security mechanism. Furthermore, I'd prefer seeing > Diameter product releases ASAP. So if I understand correctly, you'd like to see home servers initiate the E2E Security Association. Presumably after receiving some auth request. The only issue, of course, is that the auth request could include things that the home server didn't want to receive unprotected. PatC From owner-aaa-bof@merit.edu Wed May 16 10:53: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 KAA10740 for ; Wed, 16 May 2001 10:53:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CFE175DED7; Wed, 16 May 2001 10:51:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B7B245DEE7; Wed, 16 May 2001 10:51:22 -0400 (EDT) Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by segue.merit.edu (Postfix) with ESMTP id 751CD5DED7 for ; Wed, 16 May 2001 10:51:14 -0400 (EDT) Received: (from barney@localhost) by tp.databus.com (8.11.3/8.11.3) id f4GEmw350659; Wed, 16 May 2001 10:48:58 -0400 (EDT) (envelope-from barney) Date: Wed, 16 May 2001 10:48:53 -0400 From: Barney Wolff To: "Martin Julien (ECE)" , "'Jari Arkko'" , stephen.farrell@baltimore.ie, Bernard Aboba , Pat Calhoun , Thomas Panagiotis-PTHOMAS1 , aaa-wg@merit.edu Subject: Re: [AAA-WG]: End-2-End security Message-ID: <20010516104853.A50363@tp.databus.com> References: <577066326047D41180AC00508B955DDA01D7FFF0@eestqnt104.es.eu.ericsson.se> <20010516062532.A32602@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010516062532.A32602@charizard.diameter.org>; from pcalhoun@diameter.org on Wed, May 16, 2001 at 06:25:33AM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, unless I have failed to understand e2e security, the protection would entail using the home server's public key. So if it had none, the NAS would know that it did not support e2e. Besides, I don't know what "e2e" security means if the two ends know nothing about each other. Barney On Wed, May 16, 2001 at 06:25:33AM -0700, Pat Calhoun wrote: > On Wed, May 16, 2001 at 09:27:11AM +0200, Martin Julien (ECE) wrote: > > I think it could be left to the Diameter server providers to > > support or not the e2e security extension, and left to their customers > > to decide whether they need it or not. It does not seem to be > > a MANDATORY extension to me. Proxy servers do not even need to > > support it, in order to carry the messages, right? > > I can easily see Diameter servers only counting on IPsec for > > their security mechanism. Furthermore, I'd prefer seeing > > Diameter product releases ASAP. > > So if I understand correctly, you'd like to see home servers > initiate the E2E Security Association. Presumably after receiving > some auth request. > > The only issue, of course, is that the auth request could include > things that the home server didn't want to receive unprotected. > > PatC > From owner-aaa-bof@merit.edu Wed May 16 11:06: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 LAA11018 for ; Wed, 16 May 2001 11:06:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 793A05DFFB; Wed, 16 May 2001 11:05:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 380DC5DFF3; Wed, 16 May 2001 11:05:08 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B31705DFE9 for ; Wed, 16 May 2001 11:05:02 -0400 (EDT) Received: (qmail 1960 invoked by uid 500); 16 May 2001 14:54:08 -0000 Date: Wed, 16 May 2001 07:54:08 -0700 From: Pat Calhoun To: Barney Wolff Cc: "Martin Julien (ECE)" , "'Jari Arkko'" , stephen.farrell@baltimore.ie, Bernard Aboba , Pat Calhoun , Thomas Panagiotis-PTHOMAS1 , aaa-wg@merit.edu Subject: Re: [AAA-WG]: End-2-End security Message-ID: <20010516075407.B1870@charizard.diameter.org> Mail-Followup-To: Barney Wolff , "Martin Julien (ECE)" , 'Jari Arkko' , stephen.farrell@baltimore.ie, Bernard Aboba , Pat Calhoun , Thomas Panagiotis-PTHOMAS1 , aaa-wg@merit.edu References: <577066326047D41180AC00508B955DDA01D7FFF0@eestqnt104.es.eu.ericsson.se> <20010516062532.A32602@charizard.diameter.org> <20010516104853.A50363@tp.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010516104853.A50363@tp.databus.com>; from barney@databus.com on Wed, May 16, 2001 at 10:48:53AM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, May 16, 2001 at 10:48:53AM -0400, Barney Wolff wrote: > Pat, unless I have failed to understand e2e security, the protection > would entail using the home server's public key. So if it had > none, the NAS would know that it did not support e2e. There are two messages defined in the e2e sec extension, and these can carry CMS messags. a CMS message MAY contain a cert, hence the public key. > Besides, > I don't know what "e2e" security means if the two ends know > nothing about each other. Well, they eventually do. When the E2E SA Request is sent from the NAS to the home network, a box in the home network replies. At that point, they know each other, and all packets secured for that server contains the Destination-FQDN of the home server. PatC From owner-aaa-bof@merit.edu Wed May 16 12:12: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 MAA12813 for ; Wed, 16 May 2001 12:12:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EED665E013; Wed, 16 May 2001 11:59:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3B5FD5E404; Wed, 16 May 2001 11:44:45 -0400 (EDT) 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 55A3D5E04D for ; Wed, 16 May 2001 11:38:56 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f4GFcsN18217 for ; Wed, 16 May 2001 17:38:54 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed May 16 17:38:49 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 16 May 2001 17:38:48 +0200 Message-ID: <577066326047D41180AC00508B955DDA04750734@eestqnt104.es.eu.ericsson.se> From: "Carolina Canales Valenzuela (ECE)" To: "'pcalhoun@diameter.org'" , aaa-wg@merit.edu Cc: "Tony Johansson (EUS)" Subject: [AAA-WG]: Extensions that Diameter servers MUST support Date: Wed, 16 May 2001 17:38:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hello, I have a question regarding the necessity of all Diameter servers to support certain compulsory extensions (Mobile-IP, NASREQ etc). I've read the IETF mailing list, and as far as I understand, this decision was made in order to eliminate the MRI command (discussion held mainly between Pat Calhoun and Yiwen Jiang in mails with subject "A proposal for the elimination of MRI and comments on -03"). In further company-internal discussions, it was clarified that End Servers don't need to have all those compulsory extensions activated (is this equivalent to not to implement them?) and that proxy servers must implement them *only if they want to perform certain policies* (in this case they must understand all the message, and not only pay attention to F A I R bits). Is this assumption correct? In this case, shouldn't the draft say (Section 2.0, 2nd paragraph): "Diameter proxies MUST support the Base protocol, which includes Accounting, and MUST support the NASREQ and Mobile IP extensions, ONLY in case they want to perform any kind of policies" (after clarifying the servers behavior) instead of: "Diameter servers MUST support the Base protocol, which includes Accounting, and both the NASREQ and Mobile IP extensions". Is it really necessary that every proxy server implements those extensions, even if they are not interested in them at all?. IMHO if the answer is no, it would make the protocol more pluggable. If the answer is yes, this might drive certain vendors/organizations to implement proprietary Diameter extensions and support in their proxies only those extensions, not being IETF compatible in that case. For further clarification on the problem, please see the messages attached (internal discussion). Thank you very much! BR, Carolina Canales From: Carolina Canales Valenzuela (ECE) [carolina.canales-valenzuela@ece.ericsson.se] Sent: Friday, May 11, 2001 10:14 AM To: 'Tony Johansson'; Martin Julien (ECE) Cc: 'aaa@mailserver1.ericsson.se' Subject: RE: [ERI-AAA] RE: Extensions that Diameter servers MUST support > -----Original Message----- > From: Tony Johansson [mailto:tony.johansson@ericsson.com] > Sent: Thursday, May 10, 2001 8:40 PM > To: Martin Julien (ECE) > Cc: Carolina Canales Valenzuela (ECE); 'aaa@mailserver1.ericsson.se' > Subject: Re: [ERI-AAA] RE: Extensions that Diameter servers > MUST support > > > > > "Martin Julien (ECE)" wrote: > > > See my comments enclosed. > > > > > > I have a question regarding the necessity of all Diameter > > > servers to support certain conpulsory extensions (Mobile-IP, > > > NASREQ etc). > > > > I don't think supporting it means anything more than understanding > > the set of command-codes and AVPs. It does not mean > > that every Diameter node must be able to handle NASREQ > > authentication, for example. At least, that is my understanding. > > That is my understanding too. The NASREQ authentication, for example, > could only occur if the server has negotiated support for > NASREQ in the > DRI (i.e. turned it on and also that the server has users for which it > will act as AAAH). > > > > > > > > > > I've read the IETF mailing list, and as far as I > > > > understand, this decision was made in order to eliminate the > > > > MRI command (discussion held mainly between Pat Calhoun and > > > > Yiwen Jiang in mails with subject "A proposal for the > > > > elimination of MRI and comments on -03"). > > > > That is not decided yet. > > Correct. > > > > > > > > > > In one of his mails , Yiwen Jiang suggests, FOR NEW > > > > EXTENSIONS, that proxies should be aware of what extensions > > > > are supported in what realm, and simply forward messages to > > > > those realms if they support the extension, even if the > > > > proxies don't understand the message because they don't > > > > support that extension). > > > > > In case the extension is not supported in the destination > > > > realm, the proxy should be able to send an appropriate error > > > > response, being able to understand the initial message by the > > > > EIR bits in the header (and a special response should be > > > > created for Ind messages). > > > > > This is what I understood, but please correct me if I'm wrong. > > > > That's my understanding of the suggestion as well. > > > > > > > > > > So, why not use this procedure for EVERY extension > > > > (included Mobile-IP and NASREQ), so the protocol is really > > > > pluggable and servers MUST only support the Base protocol > > > > (plus accounting), but not Mobile-IP and NASREQ? > > > > I think it is the intention. > > > > > > The realm part that Yiwen is mentioning is mainly how the > > > > protocol works today, but the new thing (or maybe I should > > > > say clarification about this) seems to be that a proxy have > > > > to check that all the AVPs in a received message are all > > > > correct and reply an error message if any errors are found in > > > > the message. > > > > In fact, a proxy would be required to validate the AVPs of the > > messages it is proxying only if it needs to perform policies. > > If it does not need to deal with policies, it can simply > > forward the messages as they are, without validating anything > > else than the minimum set of AVPs used for routing. It does > > not make sense for all proxies to validate the messages all the > > time, especially if you have 3 proxies between the client and the > > home server. > > Thanks for clarifying this Martin. You are absolutely correct. If a > proxy does not perform any policies it would only have to check the > minimum set of AVPs used for routing. So the proxy in this case would > not really have to understand MIP or NASREQ, but still be > interoperable. I thank you very much for your clarifications. But, in this case, shouldn't the draft then say (Section 2.0 Protocol Overview, 2nd paragraph ): "Diameter proxies MUST support the Base protocol, which includes Accounting, and SHOULD support the NASREQ and Mobile IP extensions, in case they want to perform any kind of policies" (after clarifying the servers behavior) instead of: "Diameter servers MUST support the Base protocol, which includes Accounting, and both the NASREQ and Mobile IP extensions". > > I think the specification would need to be clearer on this. I'm > not sure if the wording should be SHOULD or MUST, but at least > make clear that it is expected that only proxy servers that > are required to execute policies are expected to validate > Diameter messages. I guess you could bring it to the list > after a comment from Tony. > I agree. I also think that this is good to get this clarified. So please, bring it up. I'm not really sure about the wording either, but I think a MUST is the right thing to state in the case that the proxy want to perform policies (adding / changing the content of the message) because in such a case it will need to understand extension anyway. Right? BR, Carolina > > > > > > > > > This implies that a proxy server must at least know all the > > > > extension commands and AVPs from all the involved extension. > > > > So the AAAP in the figure below must check the messages (and > > > > to some degree understand the content of the messages) even > > > > though the messages are just forwarded through the AAAP to > > > the AAAHs. > > > > > > > > Please view in a fixed-width font such as Courier. > > > > > > > > > > > > nas.bar.com aaa2.foo.com > > > > +----+ +-----+ > > > > |NAS | /|AAAH | > > > > | |\ ext1 / |(NAS)| > > > > +----+ \ext1 / +-----+ > > > > \ / > > > > \ +-----+ ext1,4+-----+ / > > > > X| AAAF+-------+AAAP |X > > > > / | | | | \ > > > > / +-----+ +-----+ \ > > > > +----+ / aaa.bar.com aaa1.foo.com \ +-----+ > > > > | |/ ext4 ext4 \ |AAAH | > > > > |FA | \|(MIP)| > > > > +----+ +-----+ > > > > > > > > fa.bar.com aaa3.foo.com > > > > > > > > > > > > However, the e.g. aaa2.foo.com in the figure would never have > > > > to expect to get anything else than NASREQ related things. So > > > > to my understanding I think we still can see the protocol as > > > > partly pluggable even though the base draft says that servers > > > > must support both MIP and NASREQ, because you can always "turn > > > > off" the part that you don't want to support by not > > > > advertising this in the DRI. The exception is of course the > > > > proxy case (AAAP in the figure). > > > > Yes, that's correct. > > > > > Yes, I understand that the issue affects mainly to proxies > > > (not to end servers). > > > But what happens with the delay added, if every proxy has to > > > process the content of every message that goes through it? > > > Isn't this a problem? > > > > > > In order to provide an example, let's talk about the SLF > > > case.These are the assumptions (please correct me if I'm wrong): > > > > > > As far as I understand, this node will work as a > > > proxy/redirect server to the HSS , and I think that it is > > > only interested in the Multimedia domain (right?). > > > If we force it to implement any other extensions, it might > > > happen that in 3GPP they will decide not to support the IETF > > > protocol, but rather a proprietary protocol. Is that not a > > > problem for us? > > > > Refer to my previous comments. > > > > > > According to Pat, has the IESG and ADs requested that it is > > > > a MUST with support for both MIP and NASREQ, so it may be > > > > hard to make it more pluggable than this. > > > > > > Perhaps, if this is a decision that has been taken on another > > > level, there is nothing more to talk about...Is this the case? > > > > I would say that the IESG should at least provide some kind of > > motivations behind their decisions, no? > > > BR, > > /Tony > > > > > > > BR, > > Martin > From: Tony Johansson [tony.johansson@ericsson.com] Sent: Saturday, May 12, 2001 2:22 AM To: Martin Julien (ECE); Carolina Canales Valenzuela (ECE) Cc: 'aaa@mailserver1.ericsson.se' Subject: Re: [ERI-AAA] RE: Extensions that Diameter servers MUST support "Martin Julien (ECE)" wrote: > > > > > > > So, why not use this procedure for EVERY extension > > > > > > (included Mobile-IP and NASREQ), so the protocol is really > > > > > > pluggable and servers MUST only support the Base protocol > > > > > > (plus accounting), but not Mobile-IP and NASREQ? > > > > > > > > I think it is the intention. > > > > > > > > > > The realm part that Yiwen is mentioning is mainly how the > > > > > > protocol works today, but the new thing (or maybe I should > > > > > > say clarification about this) seems to be that a proxy have > > > > > > to check that all the AVPs in a received message are all > > > > > > correct and reply an error message if any errors are found in > > > > > > the message. > > > > > > > > In fact, a proxy would be required to validate the AVPs of the > > > > messages it is proxying only if it needs to perform policies. > > > > If it does not need to deal with policies, it can simply > > > > forward the messages as they are, without validating anything > > > > else than the minimum set of AVPs used for routing. It does > > > > not make sense for all proxies to validate the messages all the > > > > time, especially if you have 3 proxies between the client and the > > > > home server. > > > > > > Thanks for clarifying this Martin. You are absolutely correct. If a > > > proxy does not perform any policies it would only have to check the > > > minimum set of AVPs used for routing. So the proxy in this > > case would > > > not really have to understand MIP or NASREQ, but still be > > > interoparable. > > > > I thank you very much for your clarifications. > > > > But, in this case, shouldn't the draft then say (Section 2.0 > > Protocol Overview, 2nd paragraph ): > > "Diameter proxies MUST support the Base protocol, which > > includes Accounting, and SHOULD support the NASREQ and Mobile > > IP extensions, in case they want to perform any kind of > > policies" (after clarifying the servers behavior) > > > > instead of: > > > > "Diameter servers MUST support the Base protocol, which > > includes Accounting, and both the NASREQ and Mobile IP extensions". > > I think the specification would need to be clearer on this. I'm > not sure if the wording should be SHOULD or MUST, but at least > make clear that it is expected that only proxy servers that > are required to execute policies are expected to validate > Diameter messages. I guess you could bring it to the list > after a comment from Tony. > I agree. I also think that this is good to get this clarified. So please, bring it up. I'm not really sure about the wording either, but I think a MUST is the right thing to state in the case that the proxy want to perform policies (adding / changing the content of the message) because in such a case it will need to understand extension anyway. Right? /Tony > > BR, > Martin From owner-aaa-bof@merit.edu Wed May 16 14:01: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 OAA15473 for ; Wed, 16 May 2001 14:01:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6A0C85DE21; Wed, 16 May 2001 14:00:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2C9E65DE1F; Wed, 16 May 2001 14:00:35 -0400 (EDT) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id EE6CB5DE01 for ; Wed, 16 May 2001 14:00:27 -0400 (EDT) Received: from gwzpc (sjc-vpn-400.cisco.com [10.21.65.144]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id KAA19731; Wed, 16 May 2001 10:59:52 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Pat Calhoun" , Cc: , , Subject: RE: [AAA-WG]: Reality of the Interim Meeting Date: Wed, 16 May 2001 10:59:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010515085001.G10188@charizard.diameter.org> Importance: Normal 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@diameter.org] writes: > All, > > The original intent of the interim meeting, as I understand it, > was to have > a document reading party. However, the list of pending issues > that we haven't > been able to come to some conclusion is quite extensive, and will > take a good > part of both days. > > So, we really need to be realistic here. Either we are having a document > reading party, or we are going to solve pending issues. We can't > have both. > > If we decide, as we have no choice, to do the former, this means that our > document reading party will not occur, and I believe this is really > necessary prior to WG last call. Furthermore, trying to squeeze this in, > while I make extensive changes to the specifications would be > questionable. > > So, I believe that we have no choice but to schedule another > interim meeting, > to hold as our document reading party. I would *strongly* propose that we > hold this meeting the week of June 11th, 25th, or July 9th. Location TBD. I think that 11 June is likely out (< 30 days notice). That being the case, I suspect that the earliest we could meet again would be the week of 18 June, so why not make it then? > > Thanks, > > PatC > > From owner-aaa-bof@merit.edu Wed May 16 14:21: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 OAA16131 for ; Wed, 16 May 2001 14:21:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 928775DDC6; Wed, 16 May 2001 14:21:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 801505DDC5; Wed, 16 May 2001 14:21:17 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 04DDB5DDA6 for ; Wed, 16 May 2001 14:21:15 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id LAA25438; Wed, 16 May 2001 11:12:14 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 16 May 2001 11:12:14 -0700 (PDT) From: Bernard Aboba To: "Carolina Canales Valenzuela (ECE)" Cc: "'pcalhoun@diameter.org'" , aaa-wg@merit.edu, "Tony Johansson (EUS)" Subject: Re: [AAA-WG]: Extensions that Diameter servers MUST support In-Reply-To: <577066326047D41180AC00508B955DDA04750734@eestqnt104.es.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Is it really necessary that every proxy server implements those extensions, even if > they are not interested in them at all?. I'm not even sure what it means for "routing proxies" to "implement" any extension. This like talking about IP routers "implementing" TCP or an application layer protocol. It's a contradiction in terms. The purpose of a routing proxy is to forward packets. It doesn't need to "implement" any functionality except that required for forwarding. Such a proxy does *not* act as a AAA client or server. If the AVPs required for forwarding were available in the same location for all messages then the routing proxy would have no need to even understand the semantics of the messages. This is why protocols like SIP put the routing info right up at the top of the header -- so the proxy can manipulate it easily. These are the kind of benefits that you get from proper protocol layering. To fix this issue, I think we need to clearly distinguish the behavior of various types of proxies and define their behavior in the spec. From owner-aaa-bof@merit.edu Wed May 16 15:08: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 PAA17364 for ; Wed, 16 May 2001 15:08:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 76A2E5DDCA; Wed, 16 May 2001 15:08:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 624095DDC5; Wed, 16 May 2001 15:08:37 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D0A2D5DDAB for ; Wed, 16 May 2001 15:08:35 -0400 (EDT) Received: (qmail 8148 invoked by uid 500); 16 May 2001 18:57:40 -0000 Date: Wed, 16 May 2001 11:57:40 -0700 From: Pat Calhoun To: Bernard Aboba Cc: "Carolina Canales Valenzuela (ECE)" , "'pcalhoun@diameter.org'" , aaa-wg@merit.edu, "Tony Johansson (EUS)" Subject: Re: [AAA-WG]: Extensions that Diameter servers MUST support Message-ID: <20010516115740.H1870@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , "Carolina Canales Valenzuela (ECE)" , "'pcalhoun@diameter.org'" , aaa-wg@merit.edu, "Tony Johansson (EUS)" References: <577066326047D41180AC00508B955DDA04750734@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Wed, May 16, 2001 at 11:12:14AM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, May 16, 2001 at 11:12:14AM -0700, Bernard Aboba wrote: > > Is it really necessary that every proxy server implements those extensions, even if > > they are not interested in them at all?. > > I'm not even sure what it means for "routing proxies" to "implement" any > extension. This like talking about IP routers "implementing" TCP or an > application layer protocol. It's a contradiction in terms. bingo! > > The purpose of a routing proxy is to forward packets. It doesn't need to > "implement" any functionality except that required for forwarding. Such > a proxy does *not* act as a AAA client or server. If > the AVPs required for forwarding were available in the same location > for all messages then the routing proxy would have no need to even > understand the semantics of the messages. This is why protocols like SIP > put the routing info right up at the top of the header -- so the proxy can > manipulate it easily. These are the kind of benefits that you get from > proper protocol layering. > > To fix this issue, I think we need to clearly distinguish the behavior of > various types of proxies and define their behavior in the spec. Actually, proxies do not need to support *any* extensions in order for them to be useful as proxies. The mandated support paragraph came from the IESG. Having said that, the -02 release did in fact have problems with proxies not supporting extensions, since they would have to know how to respond to a bad request. This has since been fixed, and I am hoping that the IESG will agree to allow us to remove this paragraph. PatC From owner-aaa-bof@merit.edu Wed May 16 18:25:32 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20197 for ; Wed, 16 May 2001 18:25:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2C0C45DDDA; Wed, 16 May 2001 18:25:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1B2CA5DDC7; Wed, 16 May 2001 18:25:23 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id BA1295DDBB for ; Wed, 16 May 2001 18:25:21 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f4GMPLa13798; Wed, 16 May 2001 17:25:21 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f4GMPKv26263; Wed, 16 May 2001 17:25:20 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA11206; Wed, 16 May 2001 17:25:20 -0500 (CDT) Received: from ericsson.com ([138.85.159.105]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA19563; Wed, 16 May 2001 17:25:18 -0500 (CDT) Message-ID: <3B02FDC4.F18FE876@ericsson.com> Date: Wed, 16 May 2001 15:23:00 -0700 From: Tony Johansson X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue #1: Routing of Indication messages References: <20010515064550.X10188@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hey Pat, Pat Calhoun wrote: > All, > > I have just begun to code the failover portion of the protocol (I was > waiting because of the uncertainty of the current text), and have > discovered a problem. > > The base protocol introduces the fact that nodes need to maintain a > queue of pending request, which is used for failover purposes. Here is > a snippet of text: > > "7.3 Failover/Failback Procedures > > In the event that a transport failure is detected with a peer, it is > necessary for all pending request and indication messages to be > forwarded to an alternate server, if possible. This is commonly > referred to as failover. > > In order for a Diameter node to perform failover procedures, it is > necessary for the node to maintain a pending message queue for a > given peer. When a response is received, the message is removed from > the queue. The Hop-by-Hop Identifier field MAY be used to match the > corresponding response with the queued request." > > Furthermore, the following diagram from the specification is very useful > in understanding how it works: I agree, explaining figures is really helpful. > > > " Request +--------+ Link Broken > +-------------------------->|Diameter|----///----+ > | +---------------------| | v > +-----+---+ | DSI | Server | +--------+ > |Diameter |<-+ (Unable to Forward) +--------+ |Diameter| > |Client or| | | > | Server |--+ +--------+ | Server | > +---------+ | Request |Diameter| +--------+ > +-------------------->| | ^ > | Server |-----------+ > +--------+ > Figure 1 - Example of Per-Hop Error Condition" > > In the above figure, a Diameter node sends a packet to a server, an > error is received, via a DSI, and this causes the request (or ind) to be > sent to the alternate server. > > Section 7.3 states that the message is removed from the queue only once > a response is received. So obviously this isn't much of an issue for the > request/answer messages, but what about indication messages? Maybe I have misunderstood you, but why you would like to see a response sent back on the DSI in the example that you show above? I don't see any reason why the server issuing the DSI needs to get a response back in this case? It has already identified that it can't forward the request be cause of the link failure, so when it issues the DSI to the originating node it would also remove the request from it's queue (it can't proxy this request anyway). Right? Furthermore, I think the DSI would always be issued as a response. Right? However, for the STI case I do agree with you. The STI is issued like a request, so in that case we really have the need for a response. See figure below. Please view in a fixed-width font such as Courier. (store in queue in in case of DSI??!!) Link +---------+ STI +--------+ STI +---------+ Broken | Diameter|<-------+Diameter|<-------+Diameter | +--///--+ | | | | | | | Server +------->|Server | |Server | | +---------+ DSI +-- +----+ +---------+ | (Unable to Forward)| V | +---------+ | |Diameter | | | | |STI |Client | | +---------+ | ^ | | +---------+ | | STI |Diameter | | +----------+ |<--------+ |Server | +---------+ BR, /Tony > > > There are three options: > 1. Indication messages *always* have a response. A response to an -ind is > quite simple, it only includes a minimum number of AVPs (e.g. Session-Id, > Result-Code). So all Indication messages have a response, and we can > transform the Failed-Ind to be this response. Call it an -Ack. > 2. Write some specialized text in the document to handle -Ind messages > differently from -Request. Perhaps have messages timeout from the queue. > I really think this is the wrong approach, and would lead to much more > complicated text. > 3. Elimination of Indications altogether, and only make use of -Request > and -Answer. I don't particularly like this approach because Indication > messages are useful, and have a different connotation than do -Requests. > > So just as a clarification, Indication messages use to work fine, but with > the introduction of the queueing of pending packets, it has become a > problem. So, a resolution is required. > > Thanks, > > PatC From owner-aaa-bof@merit.edu Wed May 16 19:11: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 TAA20961 for ; Wed, 16 May 2001 19:11:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DDA935DE0B; Wed, 16 May 2001 19:11:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C3F795DE12; Wed, 16 May 2001 19:11:41 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 52B765DE0B for ; Wed, 16 May 2001 19:11:40 -0400 (EDT) Received: (qmail 13228 invoked by uid 500); 16 May 2001 23:00:45 -0000 Date: Wed, 16 May 2001 16:00:45 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #12: Multiple Result-Code AVPs Message-ID: <20010516160045.R1870@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk I brought up this topic some time back, but the main issue has to do with proxies adding a Result-Code AVP to a message that is protected via an E2E security AVP. If a message is sent, and it's Result-Code AVP is protected via one of the E2E security AVPs, and an intermediate proxy determines that there is an error in the message, it would have no way to add such an error to the message. Therefore, I believe that it is necessary to allow for multiple Result-Code AVPs. Furthermore, since multiple such AVPs MAY be present, it is necessary for the AVP to be Grouped, and also include the Error-Reporting-FQDN. As far as the Error-Reporting-FQDN is concerned, there is an issue: 1. If an error is sent by the Diameter node creating the packet, the Origin-FQDN will contain the exact same value as the Error-Reporting-FQDN. 2. If another Diameter node wishes to add a Result-Code, then this AVP is of value. So, should we allow for a streamlined approach, where if the host creating the message is inserting the Result-Code AVP, then it doesn't need to include the Error-Reporting-FQDN, but proxies would? If so, we could have a new Grouped AVP, called Proxy-Result-Code, which would include the Result-Code and the Error-Reporting-FQDN AVPs. The Error-Reporting-FQDN wouldn't be used outside the new Grouped AVP for the reasons discussed above. Thoughts? PatC From owner-aaa-bof@merit.edu Wed May 16 20:57: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 UAA22082 for ; Wed, 16 May 2001 20:57:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ADA985DDF9; Wed, 16 May 2001 20:57:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9CDBD5DDE6; Wed, 16 May 2001 20:57:40 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 9723B5DDAD for ; Wed, 16 May 2001 20:57:38 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id RAA25908; Wed, 16 May 2001 17:48:46 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 16 May 2001 17:48:46 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: "Carolina Canales Valenzuela (ECE)" , aaa-wg@merit.edu, "Tony Johansson (EUS)" Subject: Re: [AAA-WG]: Extensions that Diameter servers MUST support In-Reply-To: <20010516115740.H1870@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > I'm not even sure what it means for "routing proxies" to "implement" any > > extension. This like talking about IP routers "implementing" TCP or an > > application layer protocol. It's a contradiction in terms. > > bingo! > > > > Actually, proxies do not need to support *any* extensions in order for > them to be useful as proxies. The mandated support paragraph came from > the IESG. > The problem is in the terminology. Redirects, Forwarders (e.g. routing proxies), and true application layer gateways (e.g. DIAMETER to RADIUS, etc.) behave differently. The last category definitely *do* need to support extensions, the others don't. I think we need to make this clear. From owner-aaa-bof@merit.edu Thu May 17 03:34: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 DAA11712 for ; Thu, 17 May 2001 03:34:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CE7355DD8D; Thu, 17 May 2001 03:34:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9A4755DE31; Thu, 17 May 2001 03:34:45 -0400 (EDT) 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 B92395DD8D for ; Thu, 17 May 2001 03:34:42 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f4H7YfO02013 for ; Thu, 17 May 2001 09:34:41 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu May 17 09:34:38 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 17 May 2001 09:34:38 +0200 Message-ID: <577066326047D41180AC00508B955DDA04750739@eestqnt104.es.eu.ericsson.se> From: "Carolina Canales Valenzuela (ECE)" To: "'Bernard Aboba'" , "Carolina Canales Valenzuela (ECE)" Cc: "'pcalhoun@diameter.org'" , aaa-wg@merit.edu, "Tony Johansson (EUS)" Subject: RE: [AAA-WG]: Extensions that Diameter servers MUST support Date: Thu, 17 May 2001 09:34:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > > > > The purpose of a routing proxy is to forward packets. It > doesn't need to > "implement" any functionality except that required for > forwarding. Such > a proxy does *not* act as a AAA client or server. If > the AVPs required for forwarding were available in the same location > for all messages then the routing proxy would have no need to even > understand the semantics of the messages. That's what I think. This is why > protocols like SIP > put the routing info right up at the top of the header -- so > the proxy can > manipulate it easily. These are the kind of benefits that you get from > proper protocol layering. > > To fix this issue, I think we need to clearly distinguish the > behavior of > various types of proxies and define their behavior in the spec. Yes, I think that the paragraph I mentioned is a little bit confusing specially because of that "MUST" > >The problem is in the terminology. Redirects, Forwarders (e.g. routing >proxies), and true application layer gateways (e.g. DIAMETER to RADIUS, >etc.) behave differently. The last category definitely *do* need to >support extensions, the others don't. I understand and fully agree with this. I think we need to make this clear.> Further clarification would be very much appreciated. Thank you very much for your help, Carolina From owner-aaa-bof@merit.edu Thu May 17 06:43: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 GAA13037 for ; Thu, 17 May 2001 06:43:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 67AC65DE36; Thu, 17 May 2001 06:42:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4BE7E5DE3C; Thu, 17 May 2001 06:42:50 -0400 (EDT) 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 420EB5DE36 for ; Thu, 17 May 2001 06:42:48 -0400 (EDT) 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 f4HAgkN24218; Thu, 17 May 2001 12:42:46 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f4HAgjJ05069; Thu, 17 May 2001 13:42:45 +0300 (EET DST) Message-ID: <3B03AB25.E6158EF9@lmf.ericsson.se> Date: Thu, 17 May 2001 13:42:45 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Cc: jarkko@piuha.net Subject: [AAA-WG]: e2e-sec-02.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I have read and reviewed the end-to-end security draft http://www.diameter.org/draft-ietf-aaa-diameter-e2e-sec-02.txt and have the following comments and questions: - 1.0: "IPSec" => "IPsec" (elsewhere correct) - Abstract refers to non-repudiation. I seem to remember many discussions on the exact meaning of non-repudiation, perhaps it would make sense to change the text to be more specific. Like this: "..., for making it possible to prove the real sender of the data." - Figure 1, maybe the example should number the servers DIA1, DIA2, and DIA3. - Before Figure 3, you talk about the expensive transformations and the need to have a mixed security model in some cases. I agree, but shouldn't we consider this also in the discussion of where e2e extension is mandatory? I.e. not make it a must for NASes... - 1.2: I don't understand why a node that supports e2e would not advertise this. Why not? - 3.1, the ESSR&ESSA scheme: here I think lies an issue that we should discuss in-depth and make sure we make the right design choice for DIAMETER. The way that the spec is written now, it basically requires all DIAMETER nodes to initiate the ESSR&ESSA handshake for all new domains. Nodes that do not support e2e will not be able to do this. Nodes that do support e2e are forced to an additional roundtrip delay even in the case that e2e wasn't really necessary for the domain. One way to deal with these kinds of situations is to use an optimistic mechanisms which naks the use of unsecured messages when e2e is required. However, the drawback of that is that potentially some data has already been revealed. But has it? It is hard for me to see exactly what sensitive information the first DIAMETER message versus the later ones have... this may need further analysis. I also lack a proposal how to handle the mixed security case with the currently proposed ESSR&ESSA scheme, i.e. who is responsible for doing the probing, and what support is mandated for which nodes. - The caching of ESSR&ESSA information isn't discussed. Shouldn't it be? - 3.1: "digial" => "digital" - 3.1, the rfc822Address scheme: can we clarify the reason why the host name must take a special form? Is it because the CA might be the CA also for other nodes, but we want only a subset of nodes to be authorized to do DIAMETER. In other words, we are using the name field as a poor man's attribute certificate? I'm fine with it, just want to know... - 3.2, I think it would be valuable indeed to specify a more limited profile of both the PKI and CMS parts! In my opinion this work should perhaps take place now, before we publish the DIAMETER RFCs... one way to do this is to list exactly what is really required from CMS for instance... my guess is that we actually do need only a small fraction of CMS and not all variants of encapsulations. - 3.4, I would expect that the number of AVP encryptions one can do with the same symmetric key is fairly high, more like hours of use rather than minutes or few sessions. Also, perhaps the document would benefit from stating that the symmetric key optimization isn't possible for the signatures if non-repudiation is desires. (Right?) - 5,0, the flow: what happens if the DRIs from the proxy onwards indicated that e2e security is not supported? Will the proxy return back a lower level DIAMETER error, or a fake ESSA with an error code? - I suppose for the example's sake you're only signing NAS->home and only encrypting Home->NAS? But still both are possible on both directions, right? - 6.1, the S/MIME profile reuse. Doesn't this limit the CMS to a fairly small subset? I lack sufficient knowledge of the S/MIME & CMS details to say whether something relevant is taken away, but perhaps you would care to comment on this? Note that I *do* want a small subset, but am just wondering if the s/mime subset is the one that we want. - 6.1 and 6.2, the CMS object ContentInfo. May I suggest that we explicitly state here which one of the various alternative ContentInfo representations should be used? Perhaps we need just a single one, which would simplify implementation and analysis. - In 6.1 you mention the signing of an encrypted AVP to be done through the MIME type application/ pkcs7-mime. Is this really necessary, and doesn't it introduce an unnecessary temporary (and large) object creation? We couldn't we just state that the signature applies to the BER result? - I'm wondering about the SHOULD NOT in the use of the PKI certs before they have been verified. I also see the note later in the doc. But nowhere you state what such other mechanisms might be! I really wonder why we need to do PKI schemes and then not use them... if these special cases don't need strong security, couldn't they live with hop-by-hop security? - The protocol provides support (although as a MAY?) for both CRLs and OCSP. Perhaps one would be enough. Or maybe we should go even further and state that if you want online or crl functionality, you must provide these outside DIAMETER... - 6.5, I think it is better to keep the OCSP-desire and the nonce together. - 6.8, I think we should just drop the top CA since that cert must be known by the initiator anyway. - Reference [4]: dash might be in the wrong place. In conclusion I think the document looks pretty solid, given some further clarification and profiling work. Main concerns I have left include the delay aspects of the ESSR/ESSA scheme for destinations that do not need e2e, the use of this in mixed environments, and the mandatory/optional status of the e2e extension. Jari From owner-aaa-bof@merit.edu Thu May 17 10:32: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 KAA18450 for ; Thu, 17 May 2001 10:32:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3DC465DDA9; Thu, 17 May 2001 10:32:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1BA855DDBB; Thu, 17 May 2001 10:32:13 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C54845DDA9 for ; Thu, 17 May 2001 10:32:05 -0400 (EDT) Received: (qmail 19627 invoked by uid 500); 17 May 2001 14:21:08 -0000 Date: Thu, 17 May 2001 07:21:08 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #13: Mandatory Supported Extensions Message-ID: <20010517072108.A1870@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk An issue was raised where the current text in the base protocol states that all servers must support all extensions. This has caused some confusion, as described in http://www.merit.edu/mail.archives/aaa-wg/msg00911.html, and extended in http://www.merit.edu/mail.archives/aaa-wg/msg00913.html. The current paragraph in -04 reads: " Diameter servers MUST support the Base protocol, which includes Accounting, and both the NASREQ and Mobile IP extensions. Diameter Clients MUST support the Base protocol, including Accounting, and MAY support any other extension that would be required to provide service." I propose changing this paragraph to: " Diameter home servers MUST support the Base protocol, which includes Accounting, and both the NASREQ and Mobile IP extensions. Diameter proxies and redirect servers MUST support the Base protocol, and MAY support other extensions. Diameter Clients MUST support the Base protocol, including Accounting, and MAY support any other extension that would be required to provide service." (btw, the terms home server, proxy and redirect servers are all defined in section 1.3) PatC From owner-aaa-bof@merit.edu Thu May 17 10:54: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 KAA19021 for ; Thu, 17 May 2001 10:54:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E00B5DE66; Thu, 17 May 2001 10:54:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EE1ED5DE67; Thu, 17 May 2001 10:54:17 -0400 (EDT) Received: from redmailwall2.attws.com (redmailwall2.attws.com [199.108.253.116]) by segue.merit.edu (Postfix) with ESMTP id CC4B25DE66 for ; Thu, 17 May 2001 10:54:15 -0400 (EDT) Received: from viruswall1.entp.attws.com (viruswall1.entp.attws.com [135.214.40.161]) by redmailwall2.attws.com (8.9.3/8.9.3) with ESMTP id HAA09331; Thu, 17 May 2001 07:51:57 -0700 (PDT) Received: from neastmail.neast.attws.com by viruswall1.entp.attws.com (8.8.8+Sun/AT&T Wireless Services, Inc. V8 version 2) id HAA12352; Thu, 17 May 2001 07:53:40 -0700 (PDT) Received: from ner-msgbh.wireless.attws.com (ner-msgbh.wireless.attws.com [135.216.177.192]) by neastmail.neast.attws.com (8.8.8+Sun/8.8.8) with ESMTP id HAA20273; Thu, 17 May 2001 07:53:38 -0700 (PDT) Received: by ner-msgbh.wireless.attws.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 May 2001 10:53:53 -0400 Message-ID: <0D3BDFD96647D211B43A00805F15E5890508685C@ner-msg03.wireless.attws.com> From: "Kobylarz, Thaddeus" To: "'Yolanda Garcia-Serrano (ECE)'" , "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Accounting clarifications Date: Thu, 17 May 2001 10:53:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Yolanda, If the perspectives of classical telecom standards is applied, then there are at least two categories of "accounted services": 1. Bearer services - "Plain vanilla" services that merely provide a communication link. If not free, the charges for bearer services are usually based on flat rate, communication time duration, or the "volume" (# of bytes) of data. 2. Application services - These are services that add "value" to the communication link. An existing wireless example is short text messages (or short message service). The door for 3rd generation wireless application services is wide open. Ideas have ranged from purchasing vending machine soft drinks to providing detailed travel directions that pinpoint a specific street address. Charging methods for these exotic services has not yet been completely decided, but will include the bearer charging types. Thad -----Original Message----- From: Yolanda Garcia-Serrano (ECE) [mailto:yolanda.garcia-serrano@ece.ericsson.se] Sent: Wednesday, May 16, 2001 2:00 AM To: 'pcalhoun@diameter.org'; 'aaa-wg@merit.edu' Subject: [AAA-WG]: Accounting clarifications Hi, Pat This time the concern is some accounting issues I would like to get clarified: 12.5. Accounting-Records What can be exactly an accounted service? Is it an extension (Mobile IP, NASREQ), or is it indicated by Service-Type AVP in NASREQ, but in Mobile IP which is the service/s? Could be the text more specific, giving some examples? 14.1 Accounting-Record-Type Are EVENT_RECORDs (one-time events) and START-STOP records mutually exclusive for the same Session-Id, i.e. if received an event record for sessionId=x.abc.com:8888:1234567890 is/is not possible to receive a Start/interim/stop one for same sessionId=x.abc.com:8888:1234567890 ? Is the type or record (EVENT vs START/INTERIM/STOP) tight to the particular kind of service, so that when some services are used, it is reported accounted info of kind EVENT, and when some other services are used, it is reported accounted info in the style Start/Interim/Stop ? Is it possible to send (Diameter client)/receive (Accounting server) several EVENT_RECORD for the same Session-Id? Same question but for measurable length services: is it possible to send/receive several START-STOP sequences for the same Session-Id? For the answer of all these questions, could be added the corresponding clarifying text on the I-D? It would be quite helpful. Thank you very much, and best regards /Yolanda Garcia From owner-aaa-bof@merit.edu Thu May 17 14:03: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 OAB23688 for ; Thu, 17 May 2001 14:03:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AFE685DE39; Thu, 17 May 2001 14:02:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 848B05DE50; Thu, 17 May 2001 14:02:45 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7ADD45DE39 for ; Thu, 17 May 2001 14:02:38 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id KAA26994 for ; Thu, 17 May 2001 10:53:47 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 17 May 2001 10:53:47 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue]: Call for issues for discussion @Interim Meeting Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk In order to track issues pending resolution and form the basis for the Interim Meeting discussion, this is a call for AAA WG members to submit comments on the current documents for consideration at the Interim Meeting. You do not have to attend the Interim Meeting in order to submit an issue for consideration. Comments should be submitted in email to aaa-wg@merit.edu and cc:'d to myself aboba@internaut.com, and Dave Mitton david@mitton.com. If possible, please get your comments in by Saturday evening, May 19, 2001. Please submit your comments in the following format. This will make it easier for me to compile and track all the issues. Please include [issue] in the subject field so that I will be able to pick out your message easily. ========================================================================= Subject: [issue] Submitter name: Submitter email address: Date first submitted: Reference: <URL of relevant posting to AAA WG mailing list, if available> Document: <Base> | <Accounting> | <NASREQ> | <MobileIP> | <Implementation guidelines> Comment type: <E for Editorial, T for Technical> Priority: <S for SHOWSTOPPER (MUST be fixed), 1 for high priority (SHOULD be fixed), 2 for low priority (fix optional)> Section: Rationale/Explanation of issue: Requested change: ==================================================================== From owner-aaa-bof@merit.edu Fri May 18 08:52: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 IAA25292 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 08:52:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B43165DE9B; Fri, 18 May 2001 08:52:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A2FAD5DE78; Fri, 18 May 2001 08:52:33 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id C73AE5DE25 for <aaa-wg@merit.edu>; Fri, 18 May 2001 08:52:31 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id FAA28406 for <aaa-wg@merit.edu>; Fri, 18 May 2001 05:43:37 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 18 May 2001 05:43:37 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: aaa-wg@merit.edu Subject: [AAA-WG]: Transport draft -02 posted Message-ID: <Pine.BSF.4.21.0105180542210.28388-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk For discussion at the Interim meeting, I've made a copy of the -02 version of the transport draft at: http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-02.txt comments welcome. From owner-aaa-bof@merit.edu Fri May 18 11:41: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 LAA29068 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 11:41:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EA77B5DF2B; Fri, 18 May 2001 11:41:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D0FA15DF46; Fri, 18 May 2001 11:41:19 -0400 (EDT) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 2DB275DF2B for <aaa-wg@merit.edu>; Fri, 18 May 2001 11:41:18 -0400 (EDT) Received: from gwzpc (sjc-vpn-679.cisco.com [10.21.66.167]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id IAA00919; Fri, 18 May 2001 08:39:29 -0700 (PDT) Reply-To: <gwz@cisco.com> From: "Glen Zorn" <gwz@cisco.com> To: "Bernard Aboba" <aboba@internaut.com>, <aaa-wg@merit.edu> Subject: RE: [AAA-WG]: Transport draft -02 posted Date: Fri, 18 May 2001 08:38:51 -0700 Message-ID: <NDBBIHMPILAAGDHPCIOPMEKODIAA.gwz@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <Pine.BSF.4.21.0105180542210.28388-100000@internaut.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Speaking of the interim, is there an agenda available yet? How about a schedule (what time do we need to show up at Nortel)? > -----Original Message----- > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > Of Bernard Aboba > Sent: Friday, May 18, 2001 5:44 AM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Transport draft -02 posted > > > For discussion at the Interim meeting, I've made a copy of the -02 version > of the transport draft at: > > http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-02.txt > > comments welcome. > > > From owner-aaa-bof@merit.edu Fri May 18 11:52: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 LAA29413 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 11:52:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D4DAD5DFDB; Fri, 18 May 2001 11:48:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3C7935E1C1; Fri, 18 May 2001 11:46:15 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id DFB0A5E02D for <aaa-wg@merit.edu>; Fri, 18 May 2001 11:45:30 -0400 (EDT) Received: (qmail 31300 invoked by uid 500); 18 May 2001 15:34:29 -0000 Date: Fri, 18 May 2001 08:34:29 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: Glen Zorn <gwz@cisco.com> Cc: Bernard Aboba <aboba@internaut.com>, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Transport draft -02 posted Message-ID: <20010518083429.Z1870@charizard.diameter.org> Mail-Followup-To: Glen Zorn <gwz@cisco.com>, Bernard Aboba <aboba@internaut.com>, aaa-wg@merit.edu References: <Pine.BSF.4.21.0105180542210.28388-100000@internaut.com> <NDBBIHMPILAAGDHPCIOPMEKODIAA.gwz@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <NDBBIHMPILAAGDHPCIOPMEKODIAA.gwz@cisco.com>; from gwz@cisco.com on Fri, May 18, 2001 at 08:38:51AM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, May 18, 2001 at 08:38:51AM -0700, Glen Zorn wrote: > Speaking of the interim, is there an agenda available yet? How about a > schedule (what time do we need to show up at Nortel)? Given the amount of work on our plate, I vote for 8 (sorry Glen :) PatC > > > -----Original Message----- > > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > > Of Bernard Aboba > > Sent: Friday, May 18, 2001 5:44 AM > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: Transport draft -02 posted > > > > > > For discussion at the Interim meeting, I've made a copy of the -02 version > > of the transport draft at: > > > > http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-02.txt > > > > comments welcome. > > > > > > > > From owner-aaa-bof@merit.edu Fri May 18 12:27: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 MAA00325 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 12:27:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4A3F35DED4; Fri, 18 May 2001 12:27:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 959915E2A3; Fri, 18 May 2001 12:26:31 -0400 (EDT) Received: from c000.snv.cp.net (c000-h001.c000.snv.cp.net [209.228.32.65]) by segue.merit.edu (Postfix) with SMTP id F056B5E077 for <aaa-wg@merit.edu>; Fri, 18 May 2001 12:18:50 -0400 (EDT) Received: (cpmta 868 invoked from network); 18 May 2001 09:18:49 -0700 Received: from h121s86a16n47.user.nortelnetworks.com (HELO mitton.mitton.com) (47.16.86.121) by smtp.mitton.com (209.228.32.65) with SMTP; 18 May 2001 09:18:49 -0700 X-Sent: 18 May 2001 16:18:49 GMT Message-Id: <4.3.2.7.2.20010518121635.00be6f00@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 May 2001 12:21:01 -0400 To: Pat Calhoun <pcalhoun@diameter.org>, Glen Zorn <gwz@cisco.com> From: David Mitton <david@mitton.com> Subject: Re: [AAA-WG]: Transport draft -02 posted Cc: Bernard Aboba <aboba@internaut.com>, aaa-wg@merit.edu In-Reply-To: <20010518083429.Z1870@charizard.diameter.org> References: <NDBBIHMPILAAGDHPCIOPMEKODIAA.gwz@cisco.com> <Pine.BSF.4.21.0105180542210.28388-100000@internaut.com> <NDBBIHMPILAAGDHPCIOPMEKODIAA.gwz@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk I'm going to need some time to figure out the situation with the room first thing Monday morning. Show up at 9am. Don't be too surprised if you get redirected. A notice will be posted later today. Dave (up to my eyeballs in insanity) At 5/18/01 08:34 AM -0700, Pat Calhoun wrote: >On Fri, May 18, 2001 at 08:38:51AM -0700, Glen Zorn wrote: > > Speaking of the interim, is there an agenda available yet? How about a > > schedule (what time do we need to show up at Nortel)? > >Given the amount of work on our plate, I vote for 8 (sorry Glen :) > >PatC > > > > > -----Original Message----- > > > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > > > Of Bernard Aboba > > > Sent: Friday, May 18, 2001 5:44 AM > > > To: aaa-wg@merit.edu > > > Subject: [AAA-WG]: Transport draft -02 posted > > > > > > > > > For discussion at the Interim meeting, I've made a copy of the -02 > version > > > of the transport draft at: > > > > > > http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-02.txt > > > > > > comments welcome. > > > > > > > > > > > > > ---------------------------------------------------- David Mitton 978-288-4570 Advisor, Nortel Networks david@mitton.com or dmitton@nortelnetworks.com From owner-aaa-bof@merit.edu Fri May 18 14:30: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 OAA10936 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 14:30:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7FCBC5DEDF; Fri, 18 May 2001 14:29:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5458A5DF3A; Fri, 18 May 2001 14:28:32 -0400 (EDT) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 3FA705DF43 for <aaa-wg@merit.edu>; Fri, 18 May 2001 14:21:01 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA22687; Fri, 18 May 2001 14:20:17 -0400 (EDT) Date: Fri, 18 May 2001 14:21:13 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Cc: Bernard Aboba <aboba@internaut.com>, Dave Mitton <david@mitton.com> Subject: [AAA-WG]: [issue] Make FAIR flags a part of Command-Code Message-ID: <Pine.GSO.4.21.0105181418490.28045-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Submitter name: Mark Eklund Submitter email address: meklund@cisco.com Date first submitted: 18-May-2001 Reference: Document: Base Comment type: T Priority: 2 Section: 3.0 Rationale/Explanation of issue: * Initially we only had different command-codes. I.E. ACA = 272, and ACR = 271. We had to have a table of command codes and command types. This wasn't good for proxy because a proxy should not have to know what command type it is to properly proxy it. * So flags were added to state what type it is. These represented Indication, Request, Answer, Query, Response. * Between draft 3 and draft 4 three things happened. 1. Query and Response were eliminated. 2. Failed was added. 3. Requests and Answers were combined to give us one code ACA = ACR = 271 and the flags must be used to determine which type it is. This is good because it makes it easy to match a request with an answer without even knowing what protocol it is. This is bad because for known AVPs, you can no longer use a switch statement to determine the attribute. Requested change: Go the next step. Use the top 8 bits of the Command-Code for attribute type and the bottom 24 bits for the Command-Code. Now you have the best of all worlds, a command that documents what type it is, you can easily match requests with answers, and an ACA and an ACR can be distinguished in a 32 bit value. ==================================================================== From owner-aaa-bof@merit.edu Fri May 18 14:55: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 OAA11913 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 14:55:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EA9255DEF4; Fri, 18 May 2001 14:55:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0CCE15E1C0; Fri, 18 May 2001 14:53:42 -0400 (EDT) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 6B8765E275 for <aaa-wg@merit.edu>; Fri, 18 May 2001 14:41:23 -0400 (EDT) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 687097F; Fri, 18 May 2001 14:41:28 -0400 (EDT) Message-ID: <3B056C97.82EFA726@Interlinknetworks.com> Date: Fri, 18 May 2001 14:40:23 -0400 From: David Spence <DSpence@Interlinknetworks.com> Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun <pcalhoun@diameter.org> Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue #4: Grouped AVP References: <20010515071744.B10188@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think there were actually two different needs that got somewhat mixed up. I think we ought to meet both needs. The Grouped type AVP originally replaced the Complex type. RADIUS has a few attributes of a complex type, that is, the value field encompasses multiple sub-fields. The Grouped type was a way of dealing with that problem while providing stronger typing. RADIUS also introduced attribute tagging which, as I and others have argued, suffers from a number of limitations. The Grouped type also became a replacement for tagging. But these two goals are not always consistent. Sometimes you want an AVP with fixed, well-defined contents. Sometimes you just want a bag to lump some AVPs together. We could create two types -- a Grouped type (same as currently defined) and a Bagged type. Alternatively, we could simply broaden the definition of the Grouped type to allow flexible bagging, but also allow fixed groups. This would be accomplished using the ABNF. Each AVP definition for a Grouped type AVP would specify via the ABNF what degree of flexibility that particular AVP had -- possibly flexible, possibly fixed. Would that work? Pat Calhoun wrote: > > Given that this one hasn't been closed, I will open an issue so we can > discuss it next week. > > Paul has indicated some circumstances where the strictness of the Grouped > AVP is a disadvantage. > > Example: > The tunneling Grouped AVP in NASREQ requires that ALL tunneling AVPs be > present, even if they shouldn't). So either we leave it as-is, or > create a group for all combinations. > > Erik has made a claim that issues against the issues draft need to be > raised, since this draft had passed last call, with no objections. Changing > the Grouped-AVP at this time could add significant delays. > > 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 Fri May 18 15:39: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 PAA13466 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 15:39:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 548265E0FF; Fri, 18 May 2001 15:39:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 40A035E106; Fri, 18 May 2001 15:39:39 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 35F895E0FF for <aaa-wg@merit.edu>; Fri, 18 May 2001 15:39:37 -0400 (EDT) Received: (qmail 2420 invoked by uid 500); 18 May 2001 19:28:32 -0000 Date: Fri, 18 May 2001 12:28:32 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] my issues Message-ID: <20010518122832.H1870@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk These were sent to the chairs, but I thought I should probably share them with the WG. They are the same as the various e-mails I sent earlier this week. Note that most of these weren't initiated by myself, but since I collected them into e-mails, I wasn't sure if the original owners would step up, so just in case I have create an issue for each of them. See y'all next week, PatC ---- Routing of Indication messages Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: May 15, 20001 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00878.html Document: Base Comment Type: Technical Priority: S Section: (throughout) Rationale/Explanation of issue: Since successful Indication messages have no response, and these messages MUST be queued in the pending message queue, a Diameter node does not know when to remove the message from the queue. Requested change: Indication messages ALWAYS have a response. Proposal to modify STI Submitter name: Paul Funk Submitter email address: paul@funk.com Date first submitted: May, 20001 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00881.html Document: Base Comment Type: Technical Priority: 1 Section: (throughout) Rationale/Explanation of issue: There is a desire to eliminate the STI message. Currently, a server that wishes to terminate a session requires 1.5 round trips (STI, STR, STA). Requested change: Either allow the server to initiate the STR, or create a new message set (Kill-Session-Request and Kill-Session-Answer), which cannot be sent by the access device. Sessions that do not start Submitter name: Paul Funk Submitter email address: paul@funk.com Date first submitted: May, 20001 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00884.html Document: Base Comment Type: Technical Priority: S Section: 10.1, and a new 10.9 Rationale/Explanation of issue: If an access device receives an answer that it doesn't like (perhaps a protocol error, or bad configuration), it should inform the server. Requested change: There are two changes required, the first in section 10.1: State Event Action New State ------------------------------------------------------------- [...] Pending Successful Service-Specific Grant Open Authorization response Access received <new> Pending Successful Service-Specific Send STR Discon Authorization response received, but service not provided. Pending Successful Service-Specific Send STR Discon Authorization response received, but error processing response </new> and the following new section 10.9: 10.9 Termination-Cause AVP The Termination-Cause AVP (AVP Code TBD) is of type Unsigned32, and is used to indicate the reason why a session was terminated on the access device. The following values are defined: DIAMETER_LOGOUT 1 The user initiated a disconnect. DIAMETER_CLIENT_GONE 2 This value is used when the user disconnected prior to the Diameter auth response was received. DIAMETER_BAD_ANSWER 3 This value indicates that the auth response received by the access device was not processed successfully. DIAMETER_ADMINISTRATIVE 4 The user was not granted access due to administrative reasons. DIAMETER_LINK_BROKEN 5 The communication link to the user was abruptly disconnected. Grouped AVP Submitter name: Paul Funk, Dave Frascone Submitter email address: paul@funk.com, dave@frascone.com Date first submitted: May, 20001 Reference: many but look at http://www.merit.edu/mail.archives/aaa-wg/msg00883.html Document: Base Comment Type: Technical Priority: 1 or 2 (?) Section: Somewhere in section 4 Rationale/Explanation of issue: Grouped AVPs MUST NOT be fixed. The same flexibility that Diameter provides is required for Grouped AVPs. See the above URL for a problem that was discussed on the list. Not solving this problem will require that many GRouped AVPs be defined for all possible combinations. Requested change: Make Grouped AVP definitions use ABNF, same as command codes. Boot Id Submitter name: Paul Funk Submitter email address: paul@funk.com Date first submitted: May, 20001 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00135.html Document: Base Comment Type: Technical Priority: 1 or 2 (?) Section: Somewhere in section 6 Rationale/Explanation of issue: Given that the DRI message is hop-by-hop, home servers that maintain state information need to know when a particular NAS has rebooted. Requested change: See the URL above which proposes three alternatives, which are not mutually exclusive. DSI Submitter name: Paul Funk Submitter email address: paul@funk.com Date first submitted: May, 20001 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00183.html Document: Base Comment Type: Technical Priority: 1 Section: Somewhere in section 9 Rationale/Explanation of issue: The DSI is currently defined as a hop-by-hop message, but Paul believes that it is necessary to keep some of the information about the originator of the DSI (e.g. Origin-FQDN). Requested change: In fact, I'd like to see the whole DSI eliminated, and only have the Result-Code AVP. Move all DSI-Events to the Result-Code and require that proxies treat a certain class of Result-Codes. This would really simplify the protocol. Watchdogs Submitter name: Jonathan Wood Submitter email address: jonwood@eng.sun.com Date first submitted: May, 20001 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00887.html Document: Base Comment Type: Question Priority: ? Section: Somewhere in section 7 Rationale/Explanation of issue: Why are watchdogs required if the transport already provides them? Requested change: Elimination of watchdogs ASI Messages Submitter name: ??? Submitter email address: ?? Date first submitted: May, 20001 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00888.html Document: Base Comment Type: Clarification Required Priority: S Section: Somewhere in section 7 Rationale/Explanation of issue: Where are ASI messages supposed to be sent? First proxy? Requested change: Add clarifying text Redirect Server Certificates Submitter name: Paul Funk Submitter email address: paul@funk.com Date first submitted: May, 20001 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00890.html Document: End-to-End Security Comment Type: Technical Priority: S Section: Rationale/Explanation of issue: Is it possible for a single certificate to be used for all Diameter servers in a domain (essentially all sharing the same private key). If so, would the cert include some fqdn? If not, how would a match of certiciate in the CMS-Cert AVP and the Redirect-Host be made? Requested change: Add clarifying text Redirect Server Certificates Submitter name: Henry Haverinen Submitter email address: (darn archives doesn't show that) Date first submitted: May, 20001 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00230.html Document: NASREQ Comment Type: Technical Priority: ? Section: Rationale/Explanation of issue: NASREQ extension should allow for key distribution, which could be used with 802.11 and other link layers. Requested change: Add text provided in URL above. Head of Line Blocking Prevention Submitter name: Jonathan Wood Submitter email address: jonwood@eng.sun.com Date first submitted: May, 20001 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00897.html Document: Base Comment Type: Technical Priority: ? Section: Somewhere in section 7 Rationale/Explanation of issue: Should the base draft make use of streams, which would prevent head of line blocking Requested change: See URL for proposed change. Multiple Result-Code AVPs Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: May 16, 20001 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00916.html Document: Base Comment Type: Technical Priority: S Section: (throughout) Rationale/Explanation of issue: End-to-End security MAY cause the Result-Code AVP to be protected. If so, a proxy has no way to change the Result-Code AVP, since it would break message authentication. Proxies must therefore have a way to add their errors in such messages. Furthermore, The Error-Reporting-FQDN is never any different from the Origin-FQDN. Requested change: Eliminate the Error-Reporting-FQDN, and add clarifying text to the Result-Code AVP to state that the Origin-FQDN was the one that added the AVP. Create a Grouped AVP called the Proxy-Result-Code, which MUST NOT contain a successful code. It is only used by proxies to add error conditions. This AVP would include the Error-Reporting-FQDN AVP, and the Result-Code AVP. Extensions that Diameter servers MUST support Submitter name: Canales Valenzuela Submitter email address: (darn archives) Date first submitted: May 16, 20001 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00911.html Document: Base Comment Type: Editorial Priority: S Section: (throughout) Rationale/Explanation of issue: The following paragraph states that all servers MUST support extensions, which one can only assume includes proxies: " Diameter servers MUST support the Base protocol, which includes Accounting, and both the NASREQ and Mobile IP extensions. Diameter Clients MUST support the Base protocol, including Accounting, and MAY support any other extension that would be required to provide service." Requested change: Change the above paragraph to the following: " Diameter home servers MUST support the Base protocol, which includes Accounting, and both the NASREQ and Mobile IP extensions. Diameter proxies and redirect servers MUST support the Base protocol, and MAY support other extensions. Diameter Clients MUST support the Base protocol, including Accounting, and MAY support any other extension that would be required to provide service." From owner-aaa-bof@merit.edu Fri May 18 15: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 PAA14123 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 15:53:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E6B175DF01; Fri, 18 May 2001 15:53:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D52105DEF6; Fri, 18 May 2001 15:53:46 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by segue.merit.edu (Postfix) with SMTP id 29A1A5DEF8 for <aaa-wg@merit.edu>; Fri, 18 May 2001 15:53:45 -0400 (EDT) Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id PAA04177; Fri, 18 May 2001 15:53:35 -0400 Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Fri, 18 May 2001 15:53:36 -0400 Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LBWPT06J; Fri, 18 May 2001 15:53:38 -0400 Received: from mitton.nortelnetworks.com (47.16.86.121 [47.16.86.121]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KBYWF00G; Fri, 18 May 2001 15:53:37 -0400 Message-Id: <4.3.2.7.2.20010518150347.00ced910@ZBL6C016.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C016.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 May 2001 15:44:01 -0400 To: aaa-wg <aaa-wg@merit.edu> From: "David Mitton" <dmitton@nortelnetworks.com> Subject: [AAA-WG]: AAA WG Interim Meeting - 5/21-22 - Details Cc: aboba@internaut.com, Randy Bush <randy@psg.com>, "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, mankin <mankin@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: <dmitton@nortelnetworks.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk My current nose count is 18. Please drop me a note if you plan on attending. ----------------------------------------------- AAA Working Group Interim Meeting Monday & Tuesday, May 21-22nd, Santa Clara, CA ----------------------------------------------- The meeting will be held at the Nortel Networks facility (previously Bay Networks) 4401 Great America Parkway, Santa Clara, CA 95054. The meeting is reserved for Building SC1, the "Orientation Room". I'm having some unresolved issues with access changes to this building and we may have to use another nearby building (maybe SC2,or SC9). A note will be posted. Please plan on arriving by/at 9:00 am. The meeting will run at least 9-5 each day, or until we finish. The goal of the meeting is to resolve the outstanding issues in the primary WG drafts. There have been several lists of issues posted and discussed on the mailing list. We will also attempt to review the newer documents, such as End-to-End Security, and the Transport Profile. If you have any questions, email dmitton@nortelnetworks.com or david@mitton.com - Dave. ----------------------------------------------- The campus is 4 miles north of San Jose Airport and 25 miles south of San Francisco Airport off US 101. (be aware that traffic on 101 will jam during rush hours) The campus is next to Great America amusement park and the Santa Clara Convention Center. There are a number of hotels of various levels near by. Some are in walking distance. ------------------- Driving Directions From San Francisco International Airport - 101 South, 25 miles - Exit Great America Parkway, turn left onto Great America Parkway, 1/4 mile - Nortel Networks - SC1 is located at the corner of Great America Parkway & Mission College Blvd From San Jose International Airport - 101 North, 4 miles - Exit Great America Parkway, turn right onto Great America Parkway, 1/4 mile - Nortel Networks - SC1 is located at the corner of Great America Parkway & Mission College Blvd ------------------------------------------------------------ David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Wireless Solutions, IP Mobility Billerica, MA 01821 dmitton@nortelnetworks.com From owner-aaa-bof@merit.edu Fri May 18 16:28: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 QAA15483 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 16:28:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D1055DF55; Fri, 18 May 2001 16:26:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 557B65DE7E; Fri, 18 May 2001 16:26:13 -0400 (EDT) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 440D65DEE8 for <aaa-wg@merit.edu>; Fri, 18 May 2001 16:24:14 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA24441; Fri, 18 May 2001 16:23:30 -0400 (EDT) Date: Fri, 18 May 2001 16:24:27 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Cc: Bernard Aboba <aboba@internaut.com>, Dave Mitton <david@mitton.com> Subject: [AAA-WG]: [issue] Add extension-id to the Diameter Header Message-ID: <Pine.GSO.4.21.0105181616070.28064-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Submitter name: Mark Eklund Submitter email address: meklund@cisco.com Date first submitted: 18-May-2001 Reference: Document: Base Comment type: T Priority: 2 Section: 3.1 Rationale/Explanation of issue: * The following don't require either the Auth-Extension-Id nor the Acct-Extension-ID: STI STR STA DWR DWA DRI DSI * The following commands have either the Auth-Extension-ID or Acct-Extension-ID: ACA ACR API ASI AAA ACI AAR ESSR ESSA AMA AMR HAA HAR * In all likelyhood most commands in future extensions will require an extension ID. * Routing uses the extension ID and type (AA or Acct) to make routing decisions. * The second set of attributes will likely be 99% of diameter traffic. Requested change: 1. Move the extension ID to be a part of the Diameter Header. 2. Add 0 extension for STI STR STA DWR DWA DRI DSI 3. Add an C flag to the Diameter Header to state that this is an a(c)counting request. (If the FAIR flags move to the command code, this should move too.) This should eliminate two searches for the Externsion-ID avps. ==================================================================== From owner-aaa-bof@merit.edu Fri May 18 16:37:32 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15739 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 16:37:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E883D5DF46; Fri, 18 May 2001 16:36:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9172F5DF41; Fri, 18 May 2001 16:36:40 -0400 (EDT) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id A15595DF46 for <aaa-wg@merit.edu>; Fri, 18 May 2001 16:36:34 -0400 (EDT) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 6329079; Fri, 18 May 2001 16:36:39 -0400 (EDT) Message-ID: <3B058795.D1B019A0@Interlinknetworks.com> Date: Fri, 18 May 2001 16:35:33 -0400 From: David Spence <DSpence@Interlinknetworks.com> Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba <Aboba@Internaut.com>, David Mitton <David@Mitton.com>, AAA Working Group <aaa-wg@merit.edu> Cc: David Mitton <DMitton@Nortelnetworks.com> Subject: [AAA-WG]: [issue] Server Identification Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] Server Identification Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: May 18, 2001 Reference: Document: Base Comment type: T Priority: 1 Section: 5.1, 5.3, 8.4, 11.4.3, 11.7 and others Rationale/Explanation of issue: There are various places in the base protocol specification that assume that only one copy of a Diameter server can run on a host and therefore that a Diameter server can be uniquely identified by an FQDN or an IP address. It would be helpful to allow for multiple server processes to run on a host. Some of the places where this assumption is made are as follows: 1. DRI election process There is a problem in the DRI election process, where a server is identified solely by FQDN. The DRI election process resolves by comparing FQDNs and assumes that they won't be the same. 2. Origin-FQDN AVP and Destination-FQDN AVP The Origin-FQDN and Destination-FQDN AVPs are used for final hop routing. 3. Route-Record AVP The Route-Record AVP is also FQDN based and is used both for routing and for loop detection. This issue was actually raised in February on the mailing list. (See Pat Calhoun email of Friday, February 23, 2001 8:30 AM.) The thread died without resolution, but Pat's final question was "whether multiple aaad processes on a single box is a requirement?" 4. Error-Reporting-FQDN AVP The Error-Reporting-FQDN AVP is also FQDN based and is used for identifying a Diameter server. There is one place where Diameter does accommodate multiple servers per host. A redirect host is identified by a Redirect-Host grouped AVP which contains an FQDN and a port. Requested change: Invent a general way to identify an instance of a Diameter server. A combination of FQDN and TCP/SCTP port number is suggested. Use this combination in each of the above AVPs. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Fri May 18 16:46: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 QAA16010 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 16:46:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6E66A5E09E; Fri, 18 May 2001 16:43:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E21FE5E297; Fri, 18 May 2001 16:43:16 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id DC4CA5E01D for <aaa-wg@merit.edu>; Fri, 18 May 2001 16:39:52 -0400 (EDT) Received: (qmail 2548 invoked by uid 500); 18 May 2001 20:28:51 -0000 Date: Fri, 18 May 2001 13:28:51 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: David Spence <DSpence@Interlinknetworks.com> Cc: Pat Calhoun <pcalhoun@diameter.org>, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue #4: Grouped AVP Message-ID: <20010518132851.L1870@charizard.diameter.org> Mail-Followup-To: David Spence <DSpence@Interlinknetworks.com>, Pat Calhoun <pcalhoun@diameter.org>, aaa-wg@merit.edu References: <20010515071744.B10188@charizard.diameter.org> <3B056C97.82EFA726@Interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B056C97.82EFA726@Interlinknetworks.com>; from DSpence@Interlinknetworks.com on Fri, May 18, 2001 at 02:40:23PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, May 18, 2001 at 02:40:23PM -0400, David Spence wrote: > I think there were actually two different needs that got somewhat mixed up. > I think we ought to meet both needs. > > The Grouped type AVP originally replaced the Complex type. RADIUS has a few > attributes of a complex type, that is, the value field encompasses multiple > sub-fields. The Grouped type was a way of dealing with that problem while > providing stronger typing. > > RADIUS also introduced attribute tagging which, as I and others have argued, > suffers from a number of limitations. The Grouped type also became a > replacement for tagging. > > But these two goals are not always consistent. Sometimes you want an AVP > with fixed, well-defined contents. Sometimes you just want a bag to lump > some AVPs together. > > We could create two types -- a Grouped type (same as currently defined) and > a Bagged type. Alternatively, we could simply broaden the definition of the > Grouped type to allow flexible bagging, but also allow fixed groups. This > would be accomplished using the ABNF. Each AVP definition for a Grouped > type AVP would specify via the ABNF what degree of flexibility that > particular AVP had -- possibly flexible, possibly fixed. > > Would that work? Right. My preference would be to simply make use of ABNF with the Grouped type, and not introduce yet another type. PatC > > Pat Calhoun wrote: > > > > Given that this one hasn't been closed, I will open an issue so we can > > discuss it next week. > > > > Paul has indicated some circumstances where the strictness of the Grouped > > AVP is a disadvantage. > > > > Example: > > The tunneling Grouped AVP in NASREQ requires that ALL tunneling AVPs be > > present, even if they shouldn't). So either we leave it as-is, or > > create a group for all combinations. > > > > Erik has made a claim that issues against the issues draft need to be > > raised, since this draft had passed last call, with no objections. Changing > > the Grouped-AVP at this time could add significant delays. > > > > 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 Fri May 18 16:47: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 QAA16039 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 16:47:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 208985E033; Fri, 18 May 2001 16:43:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1293C5E22B; Fri, 18 May 2001 16:43:08 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id AF4045E24C for <aaa-wg@merit.edu>; Fri, 18 May 2001 16:41:52 -0400 (EDT) Received: (qmail 2563 invoked by uid 500); 18 May 2001 20:30:51 -0000 Date: Fri, 18 May 2001 13:30:51 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: David Spence <DSpence@Interlinknetworks.com> Cc: Bernard Aboba <Aboba@Internaut.com>, David Mitton <David@Mitton.com>, AAA Working Group <aaa-wg@merit.edu>, David Mitton <DMitton@Nortelnetworks.com> Subject: Re: [AAA-WG]: [issue] Server Identification Message-ID: <20010518133051.M1870@charizard.diameter.org> Mail-Followup-To: David Spence <DSpence@Interlinknetworks.com>, Bernard Aboba <Aboba@Internaut.com>, David Mitton <David@Mitton.com>, AAA Working Group <aaa-wg@merit.edu>, David Mitton <DMitton@Nortelnetworks.com> References: <3B058795.D1B019A0@Interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B058795.D1B019A0@Interlinknetworks.com>; from DSpence@Interlinknetworks.com on Fri, May 18, 2001 at 04:35:33PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, May 18, 2001 at 04:35:33PM -0400, David Spence wrote: Out of curiosity, would you mean something like the FQDN AVPs would contain: myhost.domain.com/1812 ? PatC > Subject: [issue] Server Identification > > Submitter name: David Spence > Submitter email address: DSpence@Interlinknetworks.com > Date first submitted: May 18, 2001 > Reference: > Document: Base > Comment type: T > Priority: 1 > Section: 5.1, 5.3, 8.4, 11.4.3, 11.7 and others > Rationale/Explanation of issue: > > There are various places in the base protocol specification that > assume that only one copy of a Diameter server can run on a host and > therefore that a Diameter server can be uniquely identified by an > FQDN or an IP address. It would be helpful to allow for multiple > server processes to run on a host. Some of the places where this > assumption is made are as follows: > > 1. DRI election process > > There is a problem in the DRI election process, where a server is > identified solely by FQDN. The DRI election process resolves by > comparing FQDNs and assumes that they won't be the same. > > 2. Origin-FQDN AVP and Destination-FQDN AVP > > The Origin-FQDN and Destination-FQDN AVPs are used for final hop > routing. > > 3. Route-Record AVP > > The Route-Record AVP is also FQDN based and is used both for > routing and for loop detection. > > This issue was actually raised in February on the mailing list. > (See Pat Calhoun email of Friday, February 23, 2001 8:30 AM.) The > thread died without resolution, but Pat's final question was > "whether multiple aaad processes on a single box is a > requirement?" > > 4. Error-Reporting-FQDN AVP > > The Error-Reporting-FQDN AVP is also FQDN based and is used for > identifying a Diameter server. > > There is one place where Diameter does accommodate multiple servers > per host. A redirect host is identified by a Redirect-Host grouped > AVP which contains an FQDN and a port. > > Requested change: > > Invent a general way to identify an instance of a Diameter server. A > combination of FQDN and TCP/SCTP port number is suggested. Use this > combination in each of the above AVPs. > > -- > David Spence email: DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: (734) 821-1203 > 775 Technology Drive, Suite 200 fax: (734) 821-1235 > Ann Arbor, MI 48108 > U.S.A. > From owner-aaa-bof@merit.edu Fri May 18 18:24: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 SAA17757 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 18:24:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5D8B25DE35; Fri, 18 May 2001 18:18:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DF3E55DF39; Fri, 18 May 2001 18:18:40 -0400 (EDT) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 56CE25DE35 for <aaa-wg@merit.edu>; Fri, 18 May 2001 18:18:26 -0400 (EDT) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 44B2F7A; Fri, 18 May 2001 18:18:31 -0400 (EDT) Message-ID: <3B059F74.C481A12@Interlinknetworks.com> Date: Fri, 18 May 2001 18:17:24 -0400 From: David Spence <DSpence@Interlinknetworks.com> Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba <Aboba@Internaut.com>, David@Mitton.com, AAA Working Group <aaa-wg@merit.edu> Cc: David Mitton <DMitton@Nortelnetworks.com> Subject: [AAA-WG]: [issue] 3GPP2 Accounting Requirements Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] 3GPP2 Accounting Requirements Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: May 18, 2001 Reference: http://www.3gpp2.org/Public_html/specs/P.S0001-A-1.pdf Document: Accounting, MobileIP Comment type: T Priority: ? Section: Rationale/Explanation of issue: Is it an AAA WG requirement that we meet 3GPP2 requirements? If so, then the following may be an issue. 3GPP2 document P.S0001-A-1, "Wireless IP Network Standard" specifies use of a variety of public standards to realize wireless IP service. Included in the document is a specification for how RADIUS should be used. A number of RADIUS vendor-specific attributes are defined including many accounting attributes. The standard realizes version 1 of an architecture defined in 3GPP2 document P.R0001, "Wireless IP Architecture Based on IETF Protocols". Version 2 of the architecture specified in this document goes on to define a number of AAA requirements essentially all met by Diameter with the exceptions described below. The "Wireless IP Network Standard" defines quite a number of vendor-specific accounting attributes, many of which report Radio Network counters. When a wireless handoff takes place, the counts collected at the old Radio Network need to be transmitted to the accounting server. Thus, at the end of the Packet Data Session, there may be multiple accounting sub-records. The standard specifies two ways to handle this in RADIUS. The first is to bundle the attributes of a subsession into an Accounting-Container attribute (similar to a Grouped type AVP). This requires these attributes to be held in the Packet Data Serving Node (PDSN -- the node that contains the FA) until the end of the session and then they are all sent to the AAA server in a single Accounting Stop message. To allow subsession accounting data to be forwarded to the AAA servers as generated, the standard specifies a second method. A vendor specific Correlation-ID attribute is defined to supplement the RADIUS Account-Session ID attribute. They also define a Session-Continue attribute. Each time during the session that a PDSN has accounting data to send, it generates an Accounting Stop message which includes a Session-Contine attribute with a value of True. This is immediately followed by an Accounting Start message with a new Account-Session ID which begins the next sub-session. All accounting messages sent for the Packet Data Session contain the same value of the Correlation-ID attribute which then becomes the session identifier that can be used to correlate accounting messages with authentication messages. This is messy in RADIUS and would be worse in Diameter. Requested change: 1. Define all the 3GPP2 vendor specific accounting attributes as Diameter AVPs in the MIP extension. 2. Invent a clean way to carry subsession accounting data in Diameter, perhaps by inventing a Subsession-Identifier AVP and a Subsession accounting message in the base protocol. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Fri May 18 18:58: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 SAA18451 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 18:58:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 83EE05DFC2; Fri, 18 May 2001 18:50:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 47A8C5E094; Fri, 18 May 2001 18:35:32 -0400 (EDT) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 4D1375DF4E for <aaa-wg@merit.edu>; Fri, 18 May 2001 18:31:56 -0400 (EDT) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 020C579; Fri, 18 May 2001 18:32:00 -0400 (EDT) Message-ID: <3B05A29E.FA0706D7@Interlinknetworks.com> Date: Fri, 18 May 2001 18:30:54 -0400 From: David Spence <DSpence@Interlinknetworks.com> Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun <pcalhoun@diameter.org> Cc: Bernard Aboba <Aboba@Internaut.com>, David Mitton <David@Mitton.com>, AAA Working Group <aaa-wg@merit.edu>, David Mitton <DMitton@Nortelnetworks.com> Subject: Re: [AAA-WG]: [issue] Server Identification References: <3B058795.D1B019A0@Interlinknetworks.com> <20010518133051.M1870@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: > > On Fri, May 18, 2001 at 04:35:33PM -0400, David Spence wrote: > > Out of curiosity, would you mean something like the FQDN AVPs would > contain: > > myhost.domain.com/1812 > ? Perhaps. But I would prefer to use a Grouped type AVP containing two AVPs, one of type octet string and one of type integer. We could define an FQDN AVP and a Port-Number AVP that would only appear in Grouped AVPs. Then the Origin-FQDN, Destination-FQDN, Route-Record, and Error-Reporting-FQDN AVPs would all contain an FQDN AVP and a Port-Number AVP. (Yes, I know I'm still trying to have reusable data objects, sigh, but I do think it would be nice to define the FQDN format only once.) > > PatC > > Subject: [issue] Server Identification > > > > Submitter name: David Spence > > Submitter email address: DSpence@Interlinknetworks.com > > Date first submitted: May 18, 2001 > > Reference: > > Document: Base > > Comment type: T > > Priority: 1 > > Section: 5.1, 5.3, 8.4, 11.4.3, 11.7 and others > > Rationale/Explanation of issue: > > > > There are various places in the base protocol specification that > > assume that only one copy of a Diameter server can run on a host and > > therefore that a Diameter server can be uniquely identified by an > > FQDN or an IP address. It would be helpful to allow for multiple > > server processes to run on a host. Some of the places where this > > assumption is made are as follows: > > > > 1. DRI election process > > > > There is a problem in the DRI election process, where a server is > > identified solely by FQDN. The DRI election process resolves by > > comparing FQDNs and assumes that they won't be the same. > > > > 2. Origin-FQDN AVP and Destination-FQDN AVP > > > > The Origin-FQDN and Destination-FQDN AVPs are used for final hop > > routing. > > > > 3. Route-Record AVP > > > > The Route-Record AVP is also FQDN based and is used both for > > routing and for loop detection. > > > > This issue was actually raised in February on the mailing list. > > (See Pat Calhoun email of Friday, February 23, 2001 8:30 AM.) The > > thread died without resolution, but Pat's final question was > > "whether multiple aaad processes on a single box is a > > requirement?" > > > > 4. Error-Reporting-FQDN AVP > > > > The Error-Reporting-FQDN AVP is also FQDN based and is used for > > identifying a Diameter server. > > > > There is one place where Diameter does accommodate multiple servers > > per host. A redirect host is identified by a Redirect-Host grouped > > AVP which contains an FQDN and a port. > > > > Requested change: > > > > Invent a general way to identify an instance of a Diameter server. A > > combination of FQDN and TCP/SCTP port number is suggested. Use this > > combination in each of the above AVPs. > > > > -- > > David Spence email: DSpence@Interlinknetworks.com > > Interlink Networks, Inc. phone: (734) 821-1203 > > 775 Technology Drive, Suite 200 fax: (734) 821-1235 > > Ann Arbor, MI 48108 > > U.S.A. > > -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Fri May 18 18:59: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 SAA18473 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 18:59:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B95E85DDD7; Fri, 18 May 2001 18:58:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9A29E5DEF6; Fri, 18 May 2001 18:58:37 -0400 (EDT) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 2ECA75DEC8 for <aaa-wg@merit.edu>; Fri, 18 May 2001 18:55:48 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA26068; Fri, 18 May 2001 18:55:04 -0400 (EDT) Date: Fri, 18 May 2001 18:56:00 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Cc: Bernard Aboba <aboba@internaut.com>, Dave Mitton <david@mitton.com> Subject: [AAA-WG]: [issue] Extension Compliance wording confusion Message-ID: <Pine.GSO.4.21.0105181854250.28253-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Submitter name: Mark Eklund Submitter email address: meklund@cisco.com Date first submitted: 18-May-2001 Reference: Document: Base Comment type: E Priority: 2 Section: 2.4 Rationale/Explanation of issue: The paragraph An implementation MAY support both a proprietary version of an extension by requesting an IANA extension identifier (see section 16.3), while supporting the original extension. During the capabilities exchange, a Diameter node can determine whether to exchange messages using the proprietary or standard version of the extension by inspecting the extensions advertised by the peer. can be misinterpreted to say that there is a form of capability negotiation. A slight wording change is requested. Requested change: Add the text between the (*)'s An implementation MAY support both a proprietary version of an extension by requesting an IANA extension identifier (see section 16.3), while supporting the original extension. During the capabilities exchange, (* the Diameter nodes advertises all supported extensions. After capabilities exchange, the *) Diameter node can determine whether to exchange messages using the proprietary or standard version of the extension by inspecting the extensions (* that were *) advertised by the peer. ==================================================================== From owner-aaa-bof@merit.edu Fri May 18 19:06: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 TAA18678 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 19:06:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D796D5DFC8; Fri, 18 May 2001 19:02:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D74B75DFD1; Fri, 18 May 2001 19:02:20 -0400 (EDT) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 86CA65DEB3 for <aaa-wg@merit.edu>; Fri, 18 May 2001 19:01:19 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA26129; Fri, 18 May 2001 19:00:36 -0400 (EDT) Date: Fri, 18 May 2001 19:01:32 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Cc: Bernard Aboba <aboba@internaut.com>, Dave Mitton <david@mitton.com> Subject: [AAA-WG]: [issue] Bring back UTF8 datatype. Message-ID: <Pine.GSO.4.21.0105181859060.28262-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Submitter name: Mark Eklund Submitter email address: meklund@cisco.com Date first submitted: 18-May-2001 Reference: Document: Base Comment type: T Priority: 2 Section: 4.3 Rationale/Explanation of issue: First of all, sorry to drag up old issues. Here's the thoughts. * At one time we had Data, Complex, and String formats * When the datatypes were discussed in a meeting it was decided that Data, Complex, and String were the same datatype. They were combined to be Octetstring. * Now, if something is actually UTF8 format, it will be Octetstring with the text that it is in UTF8 format. * Octetstring is defined as either some collection of data bytes, or a message in UTF8 format. * There is nothing to prevent one extension from defining an AVP as UTF8 and another extension defining it as just bunch of bytes. * The argument that an UTF8 formatted message is simply an Octetstring is akin to saying that an Integer32 and an Unsigned32 are just a two four byte numbers. Following that logic, those numbers should be combined and the AVP definition should state that the number is in signed format. Requested change: Add a new type of UTF8 and change all Octetstrings that say they are UTF8 to this type. ==================================================================== From owner-aaa-bof@merit.edu Fri May 18 19:27: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 TAA19169 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 19:27:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B41B05DF73; Fri, 18 May 2001 19:25:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DCDC75DF83; Fri, 18 May 2001 19:25:00 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 9C6505E114 for <aaa-wg@merit.edu>; Fri, 18 May 2001 19:19:38 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02504; Fri, 18 May 2001 17:19:31 -0600 (MDT) 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 QAA21930; Fri, 18 May 2001 16:19:31 -0700 (PDT) Received: from sun.com (dsl199-239.Eng.Sun.COM [129.146.199.239]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id QAA27384; Fri, 18 May 2001 16:19:30 -0700 (PDT) Message-ID: <3B05A061.EE4FCC53@sun.com> Date: Fri, 18 May 2001 15:21:21 -0700 From: jonathan wood <jonathan.wood@sun.com> X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba <aboba@internaut.com> Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Transport draft -02 posted References: <Pine.BSF.4.21.0105180542210.28388-100000@internaut.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard, In general, this document provides good coverage of AAA transport isses and solutions, but is very TCP-specific. There are a number of places where things are a bit different for SCTP. Here are some: 5.2 App layer heartbeats SCTP has transport layer heartbeats. What more do app-layer heartbeats buy you? (If you can answer this before Monday, we will have one less thing to discuss at the interim meeting :) By and large you are repeating all the work that SCTP heartbeats are doing at the app layer. Additionally, since SCTP is multihomed, you will also need to transmit app-layer heartbeats to each peer address in the association. 5.3 Nagle SCTP does not use the Nagle algorithm (see the SIGTRAN archives for a lengthy discussion on why this is). 5.8 Invalidation... Heartbeats (app or transport layers) will keep RTT and RTO information up-to-date. Congestion info, as you point out, is not kept current. SCTP congestion control is based upon number of *bytes* outstanding, not packets, so if your requests are small, you can certainly fit many of them into a CWND. So your example of it taking 6 RTTs to send 35 AAA requests may not be valid. Also the CWND can increase by as much as a factor of two per SACK if you have your CWND filled (and indeed that's when you really care about fast start-up), so a better estimate would be something like 2-3 RTTs for 35 requests. This also pertains to 5.9, Inability to use fast-retransmit: the CWND may, but probably won't, prevent fast-retransmit when using SCTP. Also, on Allison's reccomendation to reset the RTO after congestion window, this could be OK for the transport protocol to do, but I really wouldn't want an upper-layer protocol doing this. In fact, I can't imagine transport protocol implementations providing an interface for ULPs to tweak the RTO. It might be best to omit this from this document. 5.10 Head-of-the-line blocking I proposed on aaa-wg a method for using SCTP streams to prevent head-of-the- line blocking (indeed this is why SCTP has streams). When using SCTP, this method should be simpler and more efficient than limited transmit and load balancing (which are still useful for TCP, however). A nit on 4.5: Duplicate detection If duplicate are put on the wire due to spurious retransmits by the transport protocol, the recveiving end of the transport protocol (be it TCP or SCTP) will detect this and not pass the duplicates up to the app. This means that all duplicates at the AAA layer will have been generated by the AAA protocol, not spurious retransmits. Jonathan Bernard Aboba wrote: > > For discussion at the Interim meeting, I've made a copy of the -02 version > of the transport draft at: > > http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-02.txt > > comments welcome. From owner-aaa-bof@merit.edu Fri May 18 20:08:45 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20018 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 20:08:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 40FAD5DEE6; Fri, 18 May 2001 20:08:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2F4665DE43; Fri, 18 May 2001 20:08:36 -0400 (EDT) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by segue.merit.edu (Postfix) with ESMTP id 9E3B85DE25 for <aaa-wg@merit.edu>; Fri, 18 May 2001 20:08:34 -0400 (EDT) Received: from minotaur.east.isi.edu (minotaur.east.isi.edu [38.218.19.202]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id UAA09164; Fri, 18 May 2001 20:08:21 -0400 (EDT) Received: from minotaur (mankin@localhost) by minotaur.east.isi.edu (8.11.0/8.11.0) with ESMTP id f4J08Xo01668; Fri, 18 May 2001 20:08:33 -0400 Message-Id: <200105190008.f4J08Xo01668@minotaur.east.isi.edu> To: jonathan wood <jonathan.wood@sun.com> Cc: Bernard Aboba <aboba@internaut.com>, aaa-wg@merit.edu Reply-To: mankin@isi.edu Subject: Re: [AAA-WG]: Transport draft -02 posted In-reply-to: Your message of Fri, 18 May 2001 15:21:21 -0700. <3B05A061.EE4FCC53@sun.com> Date: Fri, 18 May 2001 20:08:32 -0400 From: Allison Mankin <mankin@isi.edu> Sender: owner-aaa-bof@merit.edu Precedence: bulk Jonathan, Bernard or I will discuss your app versus SCTP heartbeat point and others in a subsequent message, but here's a reply to one of your points for now: > 5.10 Head-of-the-line blocking > > I proposed on aaa-wg a method for using SCTP streams to prevent > head-of-the- > line blocking (indeed this is why SCTP has streams). When using SCTP, > this > method should be simpler and more efficient than limited transmit and > load balancing (which are still useful for TCP, however). Yes, this is exactly why SCTP is the recommended transport, required of all servers along with TCP, and why the recommendation says that TCP may be phased out in future. Allison From owner-aaa-bof@merit.edu Fri May 18 21:02: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 VAA20776 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 21:02:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7B7185DD8C; Fri, 18 May 2001 21:00:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 60EF05DDAC; Fri, 18 May 2001 21:00:34 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 15C6B5DD8C for <aaa-wg@merit.edu>; Fri, 18 May 2001 21:00:32 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14750 for <aaa-wg@merit.edu>; Fri, 18 May 2001 19:00:30 -0600 (MDT) 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 SAA01415 for <aaa-wg@merit.edu>; Fri, 18 May 2001 18:00:31 -0700 (PDT) Received: from sun.com (dsl199-239.Eng.Sun.COM [129.146.199.239]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id SAA28817 for <aaa-wg@merit.edu>; Fri, 18 May 2001 18:00:29 -0700 (PDT) Message-ID: <3B05B80D.E9DFB5D@sun.com> Date: Fri, 18 May 2001 17:02:21 -0700 From: jonathan wood <jonathan.wood@sun.com> X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Transport draft -02 posted References: <200105190008.f4J08Xo01668@minotaur.east.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > 5.10 Head-of-the-line blocking > > > > I proposed on aaa-wg a method for using SCTP streams to prevent > > head-of-the- > > line blocking (indeed this is why SCTP has streams). When using SCTP, > > this > > method should be simpler and more efficient than limited transmit and > > load balancing (which are still useful for TCP, however). > > Yes, this is exactly why SCTP is the recommended transport, required of > all servers along with TCP, and why the recommendation says that TCP > may be phased out in future. > The problem is that there is currently no provision in any AAA protocol for using SCTP streams. If implementations just use one stream, they are no better off using SCTP than TCP. If they do try to use streams and there are no ground rules in the IETF specs, there will be interoperability problems. I think for this document it is sufficient to say something like "When using SCTP, AAA protocols SHOULD take advantage of SCTP streams to prevent head-of-the-line blocking". For specific AAA protocols (like Diameter), we need to say a bit more (but not much more) to ensure interoperability. Jonathan From owner-aaa-bof@merit.edu Fri May 18 21:11: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 VAA20863 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 21:11:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 30FFB5DE0C; Fri, 18 May 2001 21:11:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1FBD75DE0A; Fri, 18 May 2001 21:11:30 -0400 (EDT) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by segue.merit.edu (Postfix) with ESMTP id C499A5DDAC for <aaa-wg@merit.edu>; Fri, 18 May 2001 21:11:28 -0400 (EDT) Received: from minotaur.east.isi.edu (minotaur.east.isi.edu [38.218.19.202]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id VAA09671; Fri, 18 May 2001 21:11:15 -0400 (EDT) Received: from minotaur (mankin@localhost) by minotaur.east.isi.edu (8.11.0/8.11.0) with ESMTP id f4J1BRP01893; Fri, 18 May 2001 21:11:28 -0400 Message-Id: <200105190111.f4J1BRP01893@minotaur.east.isi.edu> To: jonathan wood <jonathan.wood@sun.com> Cc: aaa-wg@merit.edu Reply-To: mankin@isi.edu Subject: Re: [AAA-WG]: Transport draft -02 posted In-reply-to: Your message of Fri, 18 May 2001 17:02:21 -0700. <3B05B80D.E9DFB5D@sun.com> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Fri, 18 May 2001 21:11:27 -0400 From: Allison Mankin <mankin@isi.edu> Sender: owner-aaa-bof@merit.edu Precedence: bulk > The problem is that there is currently no provision in any AAA > protocol for using SCTP streams. If implementations just use one > stream, they are no better off using SCTP than TCP. If they do > try to use streams and there are no ground rules in the IETF > specs, there will be interoperability problems. > > I think for this document it is sufficient to say something like > "When using SCTP, AAA protocols SHOULD take advantage of SCTP > streams to prevent head-of-the-line blocking". > I agree. > For specific AAA protocols (like Diameter), we need to say a bit > more (but not much more) to ensure interoperability. > Could you suggest text? Allison From owner-aaa-bof@merit.edu Fri May 18 21:23: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 VAA20976 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 21:23:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 50B345DE32; Fri, 18 May 2001 21:23:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1179A5DE74; Fri, 18 May 2001 21:23:04 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 9590D5DE32 for <aaa-wg@merit.edu>; Fri, 18 May 2001 21:22:58 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA22954; Fri, 18 May 2001 19:22:56 -0600 (MDT) 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 SAA05538; Fri, 18 May 2001 18:22:56 -0700 (PDT) Received: from sun.com (dsl199-239.Eng.Sun.COM [129.146.199.239]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id SAA28974; Fri, 18 May 2001 18:22:55 -0700 (PDT) Message-ID: <3B05BD4E.EC2B518D@sun.com> Date: Fri, 18 May 2001 17:24:46 -0700 From: jonathan wood <jonathan.wood@sun.com> X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: mankin@isi.edu Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Transport draft -02 posted References: <200105190111.f4J1BRP01893@minotaur.east.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > > For specific AAA protocols (like Diameter), we need to say a bit > > more (but not much more) to ensure interoperability. > > > > Could you suggest text? > Sure. Here's what I suggested previously with regard to the Diameter spec: 1. For interoperability: All Diameter nodes MUST be prepared to receive Diameter messages on any SCTP stream in the association. 2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP streams available to the association to prevent head-of-the-line blocking. Jonathan From owner-aaa-bof@merit.edu Fri May 18 22: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 WAA23435 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 22:39:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DEEC75DF63; Fri, 18 May 2001 22:39:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CC7885DF62; Fri, 18 May 2001 22:39:37 -0400 (EDT) Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 1CEE15DF5B for <aaa-wg@merit.edu>; Fri, 18 May 2001 22:39:36 -0400 (EDT) Received: (qmail 30709 invoked by uid 500); 19 May 2001 02:39:35 -0000 Date: Fri, 18 May 2001 21:39:35 -0500 From: David Frascone <dave@frascone.com> To: jonathan wood <jonathan.wood@sun.com> Cc: mankin@isi.edu, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Transport draft -02 posted Message-ID: <20010518213935.Q20660@newman.frascone.com> Mail-Followup-To: jonathan wood <jonathan.wood@sun.com>, mankin@isi.edu, aaa-wg@merit.edu References: <200105190111.f4J1BRP01893@minotaur.east.isi.edu> <3B05BD4E.EC2B518D@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B05BD4E.EC2B518D@sun.com>; from jonathan.wood@sun.com on Fri, May 18, 2001 at 05:24:46PM -0700 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk You should include the simple algorithm that you posted in another message too. It was a nice example of one approach to allocating streams. On Fri, May 18, 2001 at 05:24:46PM -0700, jonathan wood wrote: > > > > > For specific AAA protocols (like Diameter), we need to say a bit > > > more (but not much more) to ensure interoperability. > > > > > > > Could you suggest text? > > > > Sure. Here's what I suggested previously with regard to the > Diameter spec: > > 1. For interoperability: All Diameter nodes MUST be prepared to receive > Diameter messages on any SCTP stream in the association. > 2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP > streams available to the association to prevent head-of-the-line > blocking. > > Jonathan > From owner-aaa-bof@merit.edu Fri May 18 22:56:32 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23670 for <aaa-archive@odin.ietf.org>; Fri, 18 May 2001 22:56:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A87645DE97; Fri, 18 May 2001 22:56:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 977835DE8E; Fri, 18 May 2001 22:56:23 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 10CFA5DE7E for <aaa-wg@merit.edu>; Fri, 18 May 2001 22:56:22 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA16838; Fri, 18 May 2001 19:56:19 -0700 (PDT) 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 TAA29664; Fri, 18 May 2001 19:56:19 -0700 (PDT) Received: from sun.com (dsl199-239.Eng.Sun.COM [129.146.199.239]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id TAA29328; Fri, 18 May 2001 19:56:17 -0700 (PDT) Message-ID: <3B05D330.75D27F5F@sun.com> Date: Fri, 18 May 2001 18:58:08 -0700 From: jonathan wood <jonathan.wood@sun.com> X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: David Frascone <dave@frascone.com> Cc: mankin@isi.edu, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Transport draft -02 posted References: <200105190111.f4J1BRP01893@minotaur.east.isi.edu> <3B05BD4E.EC2B518D@sun.com> <20010518213935.Q20660@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 Frascone wrote: > > You should include the simple algorithm that you posted in another > message too. It was a nice example of one approach to allocating streams. > Here it is again -- it might help to make things clearer: (sorry about the indentation; it's from the archives.) Each diameter node should stripe its messages across the range of SCTP streams that it and its peer have agreed upon. (A lost message in one stream will not cause any other streams to block.) A trivial and effective implementation of this simply increments a counter for the stream ID to send on. When the counter reaches the maximum number of streams for the association, it resets to 0. Diameter peers must be able to accept messages on any stream. Note that streams are used *solely* to prevent head-of-the-line blocking. All identifying information is carried within the diamter payload. SCTP peers can allocate up to 65535 streams for an association. The cost for idle streams may or may not be zero, and the cost for non-idle streams is always greater than 0. So administrators may wish to limit the number of possible streams on their diameter nodes according to the resources (i.e. memory, CPU power, etc.) of a particular node. Stream IDs do not need to be preserved by proxies. For example, consider the following case, where B serves as a proxy between A and C: A --------------------- B -------------------- C 1000 streams 2000 streams msg 1: str id 0 msg 1: str id 0 msg 2: str id 1 msg 2: str id 1 ... ... msg 1000: str id 999 msg 1000: str id 999 msg 1001: str id 0 msg 1001: str id 1000 The striping acts sort of like a hash table. It is possible, yet unlikely, that two messages will end up in the same stream, and even less likely that there will be message loss resulting in blocking when this happens. If it does turn out to be a problem, local administrators can increase the number of streams on their nodes to improve performance. Questions / comments? Jonathan From owner-aaa-bof@merit.edu Sun May 20 21:48:03 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15816 for <aaa-archive@odin.ietf.org>; Sun, 20 May 2001 21:48:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6FF305DDE4; Sun, 20 May 2001 21:45:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5AFD55DDB6; Sun, 20 May 2001 21:45:31 -0400 (EDT) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id E79F25DDA1 for <aaa-wg@merit.edu>; Sun, 20 May 2001 21:45:29 -0400 (EDT) Received: from Interlinknetworks.com (pm552-09.dialip.mich.net [198.110.22.163]) by aaa.interlinknetworks.com (Postfix) with ESMTP id A770D79; Sun, 20 May 2001 21:45:32 -0400 (EDT) Message-ID: <3B0862FC.2F5EDAB0@Interlinknetworks.com> Date: Sun, 20 May 2001 17:36:12 -0700 From: David Spence <DSpence@Interlinknetworks.com> Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun <pcalhoun@diameter.org> Cc: Jari Arkko <Jari.Arkko@lmf.ericsson.se>, aaa-wg@merit.edu Subject: Re: [AAA-WG]: transport MUSTs References: <3AF14635.A7D6A7E6@lmf.ericsson.se> <20010503070855.E26582@charizard.diameter.org> <3AF16B06.12B89B10@lmf.ericsson.se> <20010503073155.J26582@charizard.diameter.org> <20010503084241.L26582@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: >... > How does the following sound? > > " The base Diameter protocol is run on port TBD of both TCP [27] and > SCTP [26] transport protocols (for interoperability test purposes > port 1812 will be used until April 2001). Diameter clients SHOULD > support SCTP, but MUST support TCP if SCTP is not available. future > versions of this specification may mandate that clients support SCTP. > Diameter servers MUST support both TCP and SCTP." What do you mean "Diameter clients... MUST support TCP if SCTP is not available"? Does this mean that Diameter clients MAY support only SCTP and not TCP as Jari requested? If so, this does not accord with the conclusion reached during the February interim meeting. The reasons that clients were required to support TCP were summarized in the February interim meeting minutes from which I quote: > 9. 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. In addition to these reasons, I believe we discussed the problem that an SCTP-compliant server may, for a while yet, be run on a non-SCTP-compliant host operating system and therefore it may not be possible to reach the server via SCTP. So I think that we still need to require that clients MUST support TCP. Sorry for the late response. I am just now catching up on some of the threads in preparation for the May Interim meeting. :-( -- 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 May 20 21:48:49 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15837 for <aaa-archive@odin.ietf.org>; Sun, 20 May 2001 21:48:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5214D5DDD1; Sun, 20 May 2001 21:45:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 36A1D5DDA4; Sun, 20 May 2001 21:45:42 -0400 (EDT) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id A8FE25DE13 for <aaa-wg@merit.edu>; Sun, 20 May 2001 21:45:34 -0400 (EDT) Received: from Interlinknetworks.com (pm552-09.dialip.mich.net [198.110.22.163]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 8C05D7A; Sun, 20 May 2001 21:45:37 -0400 (EDT) Message-ID: <3B086709.96B74A62@Interlinknetworks.com> Date: Sun, 20 May 2001 17:53:29 -0700 From: David Spence <DSpence@Interlinknetworks.com> Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba <Aboba@Internaut.com>, David@Mitton.com, AAA Working Group <aaa-wg@merit.edu> Cc: David Mitton <DMitton@Nortelnetworks.com> Subject: [AAA-WG]: [issue] Required Transports Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] Required Transports Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: May 20, 2001 Reference: From: DSpence@Interlinknetworks.com Date: May 20, 2001 Subject: Re: [AAA-WG]: transport MUSTs Document: Base Comment type: T Priority: S Section: 2.1 Rationale/Explanation of issue: The following sentence from section 2.1 is unclear: "Diameter clients SHOULD support SCTP, but MUST support TCP if SCTP is not available." It appears to allow Diameter clients not to support TCP. This would be contrary to past WG decision. Requested change: The sentence should read: "Diameter clients MUST support TCP and MAY support SCTP." -- 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 May 20 22:02:17 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15921 for <aaa-archive@odin.ietf.org>; Sun, 20 May 2001 22:02:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7CE445DFB2; Sun, 20 May 2001 22:01:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6AC595DEF1; Sun, 20 May 2001 22:01:22 -0400 (EDT) Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id A9FC35DDB6 for <aaa-wg@merit.edu>; Sun, 20 May 2001 22:01:20 -0400 (EDT) Received: (qmail 899 invoked by uid 500); 21 May 2001 02:01:19 -0000 Date: Sun, 20 May 2001 21:01:19 -0500 From: David Frascone <dave@frascone.com> To: David Spence <DSpence@Interlinknetworks.com> Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: transport MUSTs Message-ID: <20010520210119.C9294@newman.frascone.com> Mail-Followup-To: David Spence <DSpence@Interlinknetworks.com>, 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 On Sun, May 20, 2001 at 05:36:12PM -0700, David Spence wrote: > > In addition to these reasons, I believe we discussed the problem that an > SCTP-compliant server may, for a while yet, be run on a non-SCTP-compliant > host operating system and therefore it may not be possible to reach the > server via SCTP. > > So I think that we still need to require that clients MUST support TCP. But, wasn't this just so NAS's did not have to support SCTP? I read the minutes as, "If possible, NAS's should support SCTP. If they can not, then they MUST support TCP." -Dave From owner-aaa-bof@merit.edu Mon May 21 02:58:54 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02414 for <aaa-archive@odin.ietf.org>; Mon, 21 May 2001 02:58:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B26365DDBA; Mon, 21 May 2001 02:58:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A034B5DDC9; Mon, 21 May 2001 02:58:47 -0400 (EDT) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 5931F5DDBA for <aaa-wg@merit.edu>; Mon, 21 May 2001 02:58:46 -0400 (EDT) Received: from Interlinknetworks.com (user-2inirn5.dsl.mindspring.com [165.121.110.229]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 4D62C79; Mon, 21 May 2001 02:58:51 -0400 (EDT) Message-ID: <3B08BC69.4267F534@Interlinknetworks.com> Date: Sun, 20 May 2001 23:57:45 -0700 From: David Spence <DSpence@Interlinknetworks.com> Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Frascone <dave@frascone.com> Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: transport MUSTs References: <20010520210119.C9294@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 Frascone wrote: > > On Sun, May 20, 2001 at 05:36:12PM -0700, David Spence wrote: > > > > In addition to these reasons, I believe we discussed the problem that an > > SCTP-compliant server may, for a while yet, be run on a non-SCTP-compliant > > host operating system and therefore it may not be possible to reach the > > server via SCTP. > > > > So I think that we still need to require that clients MUST support TCP. > > But, wasn't this just so NAS's did not have to support SCTP? I read the > minutes as, "If possible, NAS's should support SCTP. If they can not, then > they MUST support TCP." > > -Dave That's not what the minutes say to me. I repeat the quote from the minutes: 9. 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. They say that "NASes MUST support TCP". Then it says that they "MAY support SCTP". Then it explains why, noting firewall problems and the further problems that the required security protocols have not been defined for SCTP yet. -- 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 May 21 03:07:30 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02999 for <aaa-archive@odin.ietf.org>; Mon, 21 May 2001 03:07:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F09C65DDCC; Mon, 21 May 2001 03:07:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DE8C55DDC9; Mon, 21 May 2001 03:07:22 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 9CA4F5DDB9 for <aaa-wg@merit.edu>; Mon, 21 May 2001 03:07:21 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA29948; Mon, 21 May 2001 00:07:19 -0700 (PDT) Received: from vayne (muc-isdn-17 [129.157.164.117]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id JAA17106; Mon, 21 May 2001 09:07:18 +0200 (MET DST) Date: Mon, 21 May 2001 09:18:55 +0200 (MET DST) From: Erik Guttman <Erik.Guttman@Sun.COM> Reply-To: Erik Guttman <Erik.Guttman@Sun.COM> Subject: Re: [AAA-WG]: Issue #4: Grouped AVP To: David Spence <DSpence@Interlinknetworks.com> Cc: Pat Calhoun <pcalhoun@diameter.org>, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <3B056C97.82EFA726@Interlinknetworks.com> Message-ID: <Roam.SIMC.2.0.6.990429535.15751.erikg@ehdb03-home.germany> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk David, > We could create two types -- a Grouped type (same as currently defined) and > a Bagged type. Alternatively, we could simply broaden the definition of the > Grouped type to allow flexible bagging, but also allow fixed groups. This > would be accomplished using the ABNF. Each AVP definition for a Grouped > type AVP would specify via the ABNF what degree of flexibility that > particular AVP had -- possibly flexible, possibly fixed. > > Would that work? I think so. It is a good compromise. Groups with a fixed ABNF can be dealt with automatically and verified. (Satisfies section 9 of draft-ietf-aaa-issues-04.txt) We have to be very clear which ABNF is fixed. Possibly it is enough to say if all productions are single items (i.e. there are no '*' qualifiers in the grammar). ABNFs with indefinite '*[AVP]' terms are effectively Bags. Bags can be flexible and imposes the least possible restrictions. (Satisfies RADIUS afficionados and Perl programmers :-) I guess this is better than a bunch of separate Bag types to get around the fixed grammar of the Group. No one wants an ever growing list like <Tunnel-Bag>, <Tricky-Firewall-Traversal-Bag>, etc. Erik From owner-aaa-bof@merit.edu Mon May 21 03:41:17 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03351 for <aaa-archive@odin.ietf.org>; Mon, 21 May 2001 03:41:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AA5D55DDCB; Mon, 21 May 2001 03:41:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 97DAD5DDB9; Mon, 21 May 2001 03:41:11 -0400 (EDT) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by segue.merit.edu (Postfix) with ESMTP id D7DFA5DDB9 for <aaa-wg@merit.edu>; Mon, 21 May 2001 03:41:09 -0400 (EDT) Received: from kolumbus.fi (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 2E0BA6A907; Mon, 21 May 2001 10:41:01 +0300 (EEST) Message-ID: <3B08C755.6010007@kolumbus.fi> Date: Mon, 21 May 2001 10:44:21 +0300 From: Jari Arkko <jari.arkko@kolumbus.fi> User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-ipsec i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: David Spence <DSpence@Interlinknetworks.com> Cc: David Frascone <dave@frascone.com>, aaa-wg@merit.edu Subject: Re: [AAA-WG]: transport MUSTs References: <20010520210119.C9294@newman.frascone.com> <3B08BC69.4267F534@Interlinknetworks.com> 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 David Spence wrote: > > They say that "NASes MUST support TCP". Then it says that they "MAY support > SCTP". Then it explains why, noting firewall problems and the further > problems that the required security protocols have not been defined for SCTP > yet. > I'm still in favor of allowing SCTP-only clients. I don't think the security is an issue - if the implementation can fulfill the security and the transport MUSTs, then fine. In any case the IPsec issue is an optimization issue, not a fundamental problem. Regarding firewalls, I don't treat that as a practical issue and in any case that is changing fast at least when I talk to some firewall vendors. Yes, I know there are obstacles. But on the other hand I wouldn't like to drag on old functionality which in practise may not even fulfill all the telco-standard failover etc. requirements anyway. Jari From owner-aaa-bof@merit.edu Mon May 21 17:05:28 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18712 for <aaa-archive@odin.ietf.org>; Mon, 21 May 2001 17:05:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BFFAC5DDF2; Mon, 21 May 2001 17:05:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AF77F5DDEB; Mon, 21 May 2001 17:05:24 -0400 (EDT) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by segue.merit.edu (Postfix) with ESMTP id 24D435DDEA for <aaa-wg@merit.edu>; Mon, 21 May 2001 17:05:17 -0400 (EDT) Received: from minotaur.east.isi.edu (minotaur.east.isi.edu [38.218.19.202]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id RAA06528 for <aaa-wg@merit.edu>; Mon, 21 May 2001 17:05:04 -0400 (EDT) Received: from minotaur (mankin@localhost) by minotaur.east.isi.edu (8.11.0/8.11.0) with ESMTP id f4LL5GT11585 for <aaa-wg@merit.edu>; Mon, 21 May 2001 17:05:16 -0400 Message-Id: <200105212105.f4LL5GT11585@minotaur.east.isi.edu> To: aaa-wg@merit.edu Subject: [AAA-WG]: FW: Randy Bush: dawg Reply-To: mankin@isi.edu Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Mon, 21 May 2001 17:05:15 -0400 From: Allison Mankin <mankin@isi.edu> Sender: owner-aaa-bof@merit.edu Precedence: bulk Randy's proposal of simple code for failover and failure testing if (the timer expires) { <do whatever you like to do on a single timeout> bark-count += 1 if (bark-count > max-tolerable) { fallback to another server and reset everything } } if (sending a message) and (queue is empty) { set timer to max } if (received a response) { if (this empties the queue) { send a dummy packet == hearbeat } set timer to max bark-count = 0 } From owner-aaa-bof@merit.edu Mon May 21 18:49:19 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20030 for <aaa-archive@odin.ietf.org>; Mon, 21 May 2001 18:49:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 998B95DE70; Mon, 21 May 2001 18:46:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8112E5DE6F; Mon, 21 May 2001 18:46:37 -0400 (EDT) Received: from roam.psg.com (h166s103a81n47.user.nortelnetworks.com [47.81.103.166]) by segue.merit.edu (Postfix) with ESMTP id 587FA5DE5B for <aaa-wg@merit.edu>; Mon, 21 May 2001 18:46:35 -0400 (EDT) Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 151yQm-000374-00; Mon, 21 May 2001 15:45:40 -0700 From: Randy Bush <randy@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bernard Aboba <aboba@internaut.com> Cc: Allison Mankin <mankin@isi.edu>, aaa-wg@merit.edu Subject: [AAA-WG]: new dawg, no pack of dawgs Date: Mon, 21 May 2001 13:51:43 -0700 Message-Id: <E151yQm-000374-00@roam.psg.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit timer = max if (the timer expires) { if nothing in queue { put dummy request in queue timer = max } else { fallback to another server } } if (sending a message) and (queue is empty) { timer = max } if (received a response) { set timer to max } From owner-aaa-bof@merit.edu Mon May 21 20:21:56 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21074 for <aaa-archive@odin.ietf.org>; Mon, 21 May 2001 20:21:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 894795DDAE; Mon, 21 May 2001 20:21:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 71E625DDB5; Mon, 21 May 2001 20:21:50 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A124D5DDAE for <aaa-wg@merit.edu>; Mon, 21 May 2001 20:21:48 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id RAA35690 for <aaa-wg@merit.edu>; Mon, 21 May 2001 17:12:36 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Mon, 21 May 2001 17:12:36 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: aaa-wg@merit.edu Subject: [AAA-WG]: Updated transport draft Message-ID: <Pine.BSF.4.21.0105211711470.35688-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk After Interim meeting discussion, I've put up an updated version of the transport draft: http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-03.txt From owner-aaa-bof@merit.edu Tue May 22 16:16:40 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03216 for <aaa-archive@odin.ietf.org>; Tue, 22 May 2001 16:16:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C784C5DE2A; Tue, 22 May 2001 16:16:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B58455DE18; Tue, 22 May 2001 16:16:05 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 83B905DDDD for <aaa-wg@merit.edu>; Tue, 22 May 2001 16:16:03 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id NAA37049; Tue, 22 May 2001 13:06:46 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 22 May 2001 13:06:46 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: aaa-wg@merit.edu Cc: Allison Mankin <mankin@isi.edu>, randy@psg.com, david@mitton.com Subject: [AAA-WG]: [issue] Proxy behavior In-Reply-To: <E152GnO-0004i2-00@roam.psg.com> Message-ID: <Pine.BSF.4.21.0105221225020.36910-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk I'd note that pp. 10 of the aaa-issues-04 draft from November has an action item to "properly define the terms proxy, broker, redirect server, transparent and nontransparent proxy in the Diameter specifications and describe how each type of device should function." The current base draft defines "Proxy Server" as a routing proxy, and re-direct is also defined, but other proxy types aren't. The proxy draft, http://www.ietf.org/internet-drafts/draft-ietf-aaa-proxies-01.txt also takes a shot at this, but the terminology is not consistent with the base draft or the transport draft. So at a minimum we need to clean up the terminology and definitions so that all drafts are consistent. However, I think we should probably aim higher. The operation of proxies is so basic that it is hard to understand the base spec without a mental model of how they work. So I think that the proxy draft material needs to be consolidated with the base Proxy material on pp. 59-61, and this should probably be moved closer to the front of the base draft. One interesting point made in the SIP spec is that types of proxy behavior are situational, so that a proxy may act as a routing proxy for one type of message, a re-direct for another, etc. I'm curious if this logical applies to Diameter or not. This complicates the capabilities exchange considerably, because it implies that a proxy's capabilities might vary depending on the message type, destination realm, etc. At various points in the base spec, it is hard for me to understand what type of proxy is being referred to, or whether the text applies to *all* proxy types as defined in the various drafts. Some examples: 1. pp. 21, base. "If such an AVP is received by a Proxy or Redirect Server, the message MUST be forwarded to its logical destination and MUST NOT be rejected." Do all proxy types defined in the proxy doc behave this way, or just routing proxies? Might a policy proxy NOT forward such a message? 2. pp. 27, base. "Proxies receiving messages that contain the Destination-FQDN 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." Again, do *all* proxy types behave this way, or just routing proxies? Might a policy proxy not do this? 3. pp. 28, base. "A receiver of a DRI message which does not have any extensions in common with the sender MUST return a DSI message to the peer..." Would suggest we explicitly state how proxy types are expected to behave with respect to a DRI message. It makes sense that a routing proxy MUST advertise *, as would a re-direct. A policy proxy might not advertise wildcard though, right? Is there ever a situation where a proxy might implement different capabilities based on mesage type or the realm of the request? So for mitton.com, proxy might handle MIP requests, but for internaut.com I wouldn't ('cause he only paid for dialup)? Or is this something I handle by not authorizing those types of access? Clarification on the role of capabilities exchange versus authorization would be helpful. 4. pp. 39. "An e2e error occurs when a Diameter entity sends a message and either an intermediate proxy or the home server wishes to return a failure." Term "intermediate proxy" is not defined in the glossary. Also, I thought that e2e errors were removed based on discussion at IETF50. 5. pp. 44 "The Device-Status-Ind message MUST NOT be proxied, but MAY be forwarded". If "proxy" means "routing proxy" as indicated in the glossary you'd think these two actions would be equivalent. Obviously there is some distinction here but it's not defined well, so it's hard to make out what the difference is. 6. pp. 56. Section 11.1.1 talks about the realm-based routing table. Table entries include Domain Name, Extension Identifier, Action. Making forwarding decisions based on extension seems complicated to me, and I'd prefer to do away with it if possible. I would assume that re-directs and routing proxies always have wildcard in the extension identifier, but they still need to track the extensions of their downstream neighbors, right? This is one of the reasons why having a server support all extensions would simplify things. 7. On pp. 57 it says "the local server MAY apply its local policies to the message by including new AVPs prior to forwarding". This doesn't seem like routing proxy behavior, more like a policy proxy, right? 8. pp. 57 "a message that does not contain any of the above AVPs MUST NOT be routed". Not clear about the distinction been forwarding and routing used here. Is this distinct from forwarding and proxying, and if so what operations does routing include? 9. pp. 59. This section talks about behavior of stateless and stateful proxies. I think that more detail on behavior of these types is needed up front. Given that a stateful proxy maintains session state, I think that more explicit guidance is needed on how this is done in the face of reboot indications, network partitions, etc. It's not an easy problem. From owner-aaa-bof@merit.edu Wed May 23 17:24:41 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15589 for <aaa-archive@odin.ietf.org>; Wed, 23 May 2001 17:24:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D1B875EAC1; Wed, 23 May 2001 16:53:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 866A75E388; Wed, 23 May 2001 16:29:29 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 7A8BA5E8DE for <aaa-wg@merit.edu>; Wed, 23 May 2001 16:07:53 -0400 (EDT) Received: (qmail 14177 invoked by uid 500); 23 May 2001 19:56:35 -0000 Date: Wed, 23 May 2001 12:56:35 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter Issues available Message-ID: <20010523125635.L5124@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, I just finished putting together the list of issues that were raised at the AAA interim meeting in Santa Clara this week. The list can be found on the Diameter site at http://www.diameter.org/issues.html. To the people that were present, please take a look at the page above and provide me with your updates to any issues that you have opened. Also, if you are the owner of an issue that was raised at the meeting (and there were quite a few), please send me an issue and I will update the list. Thanks, PatC From owner-aaa-bof@merit.edu Wed May 23 19:31:32 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17679 for <aaa-archive@odin.ietf.org>; Wed, 23 May 2001 19:31:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 21E265ED99; Wed, 23 May 2001 19:00:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 987AB5E49D; Wed, 23 May 2001 18:41:15 -0400 (EDT) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 3C16E5DFC4 for <aaa-wg@merit.edu>; Wed, 23 May 2001 17:37:26 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA06695; Wed, 23 May 2001 17:36:37 -0400 (EDT) Date: Wed, 23 May 2001 17:37:38 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Cc: Bernard Aboba <aboba@internaut.com>, Dave Mitton <david@mitton.com> Subject: Re: [AAA-WG]: [issue] Extension Compliance wording confusion In-Reply-To: <Pine.GSO.4.21.0105181854250.28253-100000@knox6039> Message-ID: <Pine.GSO.4.21.0105231736510.27558-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Resolution of issue: It was agreed that this wording change was acceptable. -mark On Fri, 18 May 2001, Mark Eklund wrote: > Submitter name: Mark Eklund > Submitter email address: meklund@cisco.com > Date first submitted: 18-May-2001 > Reference: > Document: Base > Comment type: E > Priority: 2 > Section: 2.4 > Rationale/Explanation of issue: > > The paragraph > > An implementation MAY support both a proprietary version of an > extension by requesting an IANA extension identifier (see section > 16.3), while supporting the original extension. During the > capabilities exchange, a Diameter node can determine whether to > exchange messages using the proprietary or standard version of the > extension by inspecting the extensions advertised by the peer. > > can be misinterpreted to say that there is a form of > capability negotiation. A slight wording change is requested. > > Requested change: > > Add the text between the (*)'s > > An implementation MAY support both a proprietary version of an > extension by requesting an IANA extension identifier (see section > 16.3), while supporting the original extension. During the > capabilities exchange, (* the Diameter nodes advertises all supported > extensions. After capabilities exchange, the *) Diameter node can > determine whether to exchange messages using the proprietary or > standard version of the extension by inspecting the extensions > (* that were *) advertised by the peer. > > ==================================================================== > > > > > From owner-aaa-bof@merit.edu Wed May 23 19:32:51 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17702 for <aaa-archive@odin.ietf.org>; Wed, 23 May 2001 19:32:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2CB515E58A; Wed, 23 May 2001 19:00:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BEC055E125; Wed, 23 May 2001 18:41:56 -0400 (EDT) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id B4F765E150 for <aaa-wg@merit.edu>; Wed, 23 May 2001 17:50:16 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA06757; Wed, 23 May 2001 17:49:28 -0400 (EDT) Date: Wed, 23 May 2001 17:50:29 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Cc: Bernard Aboba <aboba@internaut.com>, Dave Mitton <david@mitton.com> Subject: Re: [AAA-WG]: [issue] Add extension-id to the Diameter Header In-Reply-To: <Pine.GSO.4.21.0105181616070.28064-100000@knox6039> Message-ID: <Pine.GSO.4.21.0105231739060.27558-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Resolution of issue: Since you have to also search for the Destination-Realm, Destination-FQDN, and Username when routing, the efficiency added by moving the Acct-Extension-Id and Auth-Extension-Id to the header was outweighed by the inconsistency of having some routing information in the header and some in AVPs. This request was denied. -mark From owner-aaa-bof@merit.edu Wed May 23 19:33:38 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17729 for <aaa-archive@odin.ietf.org>; Wed, 23 May 2001 19:33:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D2A035DFAE; Wed, 23 May 2001 19:01:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DEBFB5E616; Wed, 23 May 2001 18:42:34 -0400 (EDT) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id C0EAE5E20B for <aaa-wg@merit.edu>; Wed, 23 May 2001 18:18:26 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA06945; Wed, 23 May 2001 18:17:38 -0400 (EDT) Date: Wed, 23 May 2001 18:18:39 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Cc: Bernard Aboba <aboba@internaut.com>, Dave Mitton <david@mitton.com> Subject: Re: [AAA-WG]: [issue] Make FAIR flags a part of Command-Code In-Reply-To: <Pine.GSO.4.21.0105181418490.28045-100000@knox6039> Message-ID: <Pine.GSO.4.21.0105231717300.27558-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Resolution of Issue: The command flags will be moved to the header as such: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Reserved | Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- The FIR flags were removed as a result of other changes. The Message Length has been increased in the event that one day something exceptionally large like fingerprint information is needed. The flags have been moved into the Command Code itself. The AVP will be also changed to have a 24 bit length to reflect the larger Message Length. -mark From owner-aaa-bof@merit.edu Wed May 23 21:38:02 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20430 for <aaa-archive@odin.ietf.org>; Wed, 23 May 2001 21:38:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 686095EAFF; Wed, 23 May 2001 20:48:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F1FCD5E911; Wed, 23 May 2001 20:26:09 -0400 (EDT) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 65EB15E347 for <aaa-wg@merit.edu>; Wed, 23 May 2001 19:50:39 -0400 (EDT) Received: from Interlinknetworks.com (pm552-00.dialip.mich.net [198.110.22.154]) by aaa.interlinknetworks.com (Postfix) with ESMTP id D158079; Wed, 23 May 2001 19:50:43 -0400 (EDT) Message-ID: <3B0C395A.B5F11253@Interlinknetworks.com> Date: Wed, 23 May 2001 17:27:38 -0500 From: David Spence <DSpence@Interlinknetworks.com> Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Guttman <Erik.Guttman@Sun.COM> Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: List data type discussion References: <Roam.SIMC.2.0.6.989484385.6620.erikg@ehdb03-home.germany> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think that our new broader definition of the Group type would accommodate lists as well. If I want to define a Foo-List AVP that would contain a list of Foo AVPs, I simply state that the Foo-List AVP contains * {Foo}. So we can now define lists if we ever want to. :-) Erik Guttman wrote: > > Under discussion, still not finally resolved is whether we should have > a base 'List' data type, which would essentially allow 'N' identical > items to follow. We have no concrete examples of where this would be > useful. > > There are issues with the List data type: > > (1) Length ambiguity > > In this case of a List of 'N' Integer32 values, an AVP length would > be the following # of bytes: > > 8 [+ 4 (if 'V'endor ID included) ] + 4 * N > > By observing the AVP length (and whether the 'V' bit is set), the > receiver can calculate how many Integer32 values follow. This would > allow the efficient encoding of the data > > [Header] [Int32-0]...[Int32-(N-1)] > > In the case of data types OctetString, Address, Group and List > it will not be possible to determine how many data items follow > simply by observing the AVP length field. To make it possible to > parse individual items in the list, we need to separate them into > individual units of {Length,Data} or perhaps better yet > {AVP header,Data}. > > (2) Why use a List AVP at all? > > But if we are going to do that, what is the use of the List data > type? Where do we gain by having, say, > > <Some-Command> ::= <Diameter Header: ???> > { Origin-Host-List } > > Origin-Host-List AVP = 1* Origin-Host AVP > Origin-Host AVP has type Address > > which leads to the encoding of: > > [Origin-Host-List AVP header] > [Origin-Host AVP Header 0] > Address 0 > ... > [Origin-Host AVP Header N-1] > Address N-1 > > instead of just having 0 or more Origin-Host AVPs in the message: > > <Some-Command> ::= <Diameter Header: ???> > 1* { Origin-Host } > > > Using the same definition of Origin host as above, > > Origin-Host AVP has type Address > > This leads to the encoding: > > [Origin-Host AVP Header 0] > Address 0 > ... > [Origin-Host AVP Header N-1] > Address N-1 > > Which is exactly what we had before, but there is no 'wrapping' > List AVP. > > What we gain here is that there is a definite group - one will > be able to transmit a 'column' of data, like a SMIv2 'SEQUENCE OF', > a facility our grammar currently lacks. > > The question remains - do we need List? Let's try to reach final > working group concensus on this now. If in favor of the proposal, > please send concrete examples of why it is needed. > > Thanks, > > Erik -- 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 Thu May 24 13:46:42 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18016 for <aaa-archive@odin.ietf.org>; Thu, 24 May 2001 13:46:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 872C45DF40; Thu, 24 May 2001 13:38:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0942A5DF65; Thu, 24 May 2001 13:31:37 -0400 (EDT) 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 A17BF5E0AE for <aaa-wg@merit.edu>; Thu, 24 May 2001 13:23:20 -0400 (EDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f4OHNJO16630 for <aaa-wg@merit.edu>; Thu, 24 May 2001 19:23:19 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu May 24 19:23:17 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <LNXPML59>; Thu, 24 May 2001 19:23:19 +0200 Message-ID: <577066326047D41180AC00508B955DDAA63549@eestqnt104.es.eu.ericsson.se> From: "Irene Martin Cabello (ECE)" <Irene.Martin-Cabello@ece.ericsson.se> To: "'pcalhoun@diameter.org'" <pcalhoun@diameter.org>, "'aaa-wg@merit.edu'" <aaa-wg@merit.edu> Subject: [AAA-WG]: Question about NASREQ extension Date: Thu, 24 May 2001 19:23:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, I have a question about NASREQ extension. It is regarding what is written in chapter 3.1.1 AA-Request Command: "It is possible for a single session to be authorized only first, then followed by an authentication request. However the inverse SHOULD NOT be permitted". Is this correct? from my point of view authentication should be performed before authorization. Maybe the above paragraph is only applicable for tunneling, is it? In case the paragraph is right, could you clarify to me why this should be done in this way? Thanks in advance for your answer, Irene From owner-aaa-bof@merit.edu Thu May 24 14:28:27 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18644 for <aaa-archive@odin.ietf.org>; Thu, 24 May 2001 14:28:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1B4DC5DE52; Thu, 24 May 2001 14:26:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1D9C35DF23; Thu, 24 May 2001 14:14:11 -0400 (EDT) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id AE5AF5DEDF for <aaa-wg@merit.edu>; Thu, 24 May 2001 14:01:30 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA13605; Thu, 24 May 2001 14:00:42 -0400 (EDT) Date: Thu, 24 May 2001 14:01:44 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Cc: Bernard Aboba <aboba@internaut.com>, Dave Mitton <david@mitton.com> Subject: [AAA-WG]: [issue] What to do if STR is sent to unavailable server. Message-ID: <Pine.GSO.4.21.0105241357470.28114-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, This issue was brought up during the meeting and it was decided that this needed discussion on the list. So, discuss.. Submitter name: Mark Eklund Submitter email address: meklund@cisco.com Date first submitted: 24-May-2001 Reference: Document: Base Comment type: T Priority: 1 Section: Rationale/Explanation of issue: * The Session-Terminate-Request requires a Destination-FQDN * There was going to be text added to state that the Destination-FQDN should be that of the last place you authenticated. * What happens if that Destination-FQDN is down? If this is a cluster of servers, there may still be a need for the STR to be sent to the realm. Requested change: One or more of the following changes: 1. Do nothing. If the authenticating server goes down, either all the state data is lost, or session timeouts will cleanup any STRs missed. A statement as such should be added to the RFC reflecting this. 2. Make the Destination-FQDN optional. If the client receives a DIAMETER_UNABLE_TO_DELIVER, the client may send the request without a Destination-FQDN. 3. #2 above, but allow a proxy to also do this. 4. Make the Destination-FQDN optional. Add an STR-Destination AVP that is of type integer that is sent as a part of the authentication process. This would contain the Destination-Realm and optionally the Destination-FQDN to which this should be sent. ==================================================================== From owner-aaa-bof@merit.edu Thu May 24 17:12:10 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21020 for <aaa-archive@odin.ietf.org>; Thu, 24 May 2001 17:12:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0DAD95E093; Thu, 24 May 2001 16:48:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DB4135E1F0; Thu, 24 May 2001 16:35:04 -0400 (EDT) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 661185E120 for <aaa-wg@merit.edu>; Thu, 24 May 2001 15:28:38 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA14239; Thu, 24 May 2001 15:27:50 -0400 (EDT) Date: Thu, 24 May 2001 15:28:51 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Cc: Pat Calhoun <pcalhoun@diameter.org> Subject: [AAA-WG]: [issue] Failed-AVP should be Grouped Message-ID: <Pine.GSO.4.21.0105241526320.28136-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Submitter name: Mark Eklund Submitter email address: meklund@cisco.com Date first submitted: 24-May-2001 Reference: Document: Base Comment type: T Priority: 2 Section: Rationale/Explanation of issue: With the change of the grouped type AVP to allow ABNF in the form of 1* {AVP}, the information held by the Failed-Vendor-Id and Offending-AVP may sent by simply putting the failed AVP in the Failed-AVP group. Requested change: Eliminate Offending-AVP and Failed-Vendor-Id, change Failed-AVP to be of type grouped. Resolution: Section 9.3 will be changed to: 9.3 Failed-AVP AVP The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides debugging information in cases where a request is rejected or not fully processed due to erroneous information in a specific AVP. The value of the Result-Code AVP will provide information on the reason for the Failed-AVP AVP. The possible reasons for this AVP are the presence of an improperly constructed AVP, an unsupported or unrecognized AVP, an invalid AVP value, the omission of a required AVP, the presence of an explicitly excluded AVP (see table 13.0), or the presence of two or more occurrences of an AVP which table 15.1 restricts to 0, 1, or 0-1 occurrences. A Diameter message MAY contain one Failed-AVP AVP, containing the entire AVP that could not be processed successfully. If the failure reason is omission of a required AVP, an AVP with the missing command code, the missing vendor id, and a zero filled payload will be added. AVP format: <Failed-AVP> ::= (AVP Code = 279) 1* {AVP} ==================================================================== From owner-aaa-bof@merit.edu Thu May 24 17:22:39 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21131 for <aaa-archive@odin.ietf.org>; Thu, 24 May 2001 17:22:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A094C5DDF6; Thu, 24 May 2001 16:54:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4529A5E061; Thu, 24 May 2001 16:36:48 -0400 (EDT) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 353C95DEE6 for <aaa-wg@merit.edu>; Thu, 24 May 2001 15:55:36 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA14447; Thu, 24 May 2001 15:54:16 -0400 (EDT) Date: Thu, 24 May 2001 15:55:17 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: Pat Calhoun <pcalhoun@diameter.org> Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Re: [issue] Failed-AVP should be Grouped In-Reply-To: <20010524122028.D30735@charizard.diameter.org> Message-ID: <Pine.GSO.4.21.0105241535090.28136-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Hmm, it is quite possible that one thing was said and I heard another. I thought we had decided to put the entire AVP into the Failed-AVP as type grouped. I also thought we discussed placing a dummy zero fill as the value if it were a missing AVP. How would you implement an octetstring? Would you convert it from your internal AVP representation to what is sent over the wire and then add it to the data portion of the octetstring? Here is a sample AA-Answer with type grouped for the Failed-AVP. You could make the Failed-AVP octetstring, but its data would then be printed like I have shown the Proxy-State AVP. AA-Answer = Session-Id = "a unique identifier", Auth-Extension-Id = NASREQ, Result-Code = DIAMETER_INVALID_AVP_VALUE, Origin-FQDN = "server.my.org", Origin-Realm = "cash-cow", Service-Type = 5000, Destination-FQDN = "nas1.your.com", Failed-AVP = { Service-Type = 5000 } Route-Record = { Proxy-Address = "1.2.3.4", Proxy-State = AA AB 08 09 77 44 DE AD } -mark On Thu, 24 May 2001, Pat Calhoun wrote: > On Thu, May 24, 2001 at 03:28:51PM -0400, Mark Eklund wrote: > > Mark, > > I am confused. I *thought* we agreed that it could remain an OctetString, > since it contains the whole AVP header (and data), and therefore includes > the vendor id. No grouping is required. > > Is my recollection incorrect? > > PatC > > > Submitter name: Mark Eklund > > Submitter email address: meklund@cisco.com > > Date first submitted: 24-May-2001 > > Reference: > > Document: Base > > Comment type: T > > Priority: 2 > > Section: > > Rationale/Explanation of issue: > > With the change of the grouped type AVP to allow ABNF in > > the form of 1* {AVP}, the information held by the Failed-Vendor-Id > > and Offending-AVP may sent by simply putting the failed AVP in the > > Failed-AVP group. > > > > Requested change: > > Eliminate Offending-AVP and Failed-Vendor-Id, change > > Failed-AVP to be of type grouped. > > > > Resolution: > > > > Section 9.3 will be changed to: > > > > 9.3 Failed-AVP AVP > > > > The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides > > debugging information in cases where a request is rejected or not > > fully processed due to erroneous information in a specific AVP. The > > value of the Result-Code AVP will provide information on the reason > > for the Failed-AVP AVP. > > > > The possible reasons for this AVP are the presence of an improperly > > constructed AVP, an unsupported or unrecognized AVP, an invalid AVP > > value, the omission of a required AVP, the presence of an explicitly > > excluded AVP (see table 13.0), or the presence of two or more > > occurrences of an AVP which table 15.1 restricts to 0, 1, or 0-1 > > occurrences. > > > > A Diameter message MAY contain one Failed-AVP AVP, containing > > the entire AVP that could not be processed successfully. If the > > failure reason is omission of a required AVP, an AVP with the > > missing command code, the missing vendor id, and a zero filled > > payload will be added. > > > > AVP format: > > <Failed-AVP> ::= (AVP Code = 279) > > 1* {AVP} > > > > ==================================================================== > > > > > > > > > > > From owner-aaa-bof@merit.edu Thu May 24 17:25:44 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21168 for <aaa-archive@odin.ietf.org>; Thu, 24 May 2001 17:25:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A02265DE58; Thu, 24 May 2001 16:54:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0F8B75E33E; Thu, 24 May 2001 16:37:11 -0400 (EDT) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 288615DE0D for <aaa-wg@merit.edu>; Thu, 24 May 2001 16:01:05 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA14533; Thu, 24 May 2001 16:00:17 -0400 (EDT) Date: Thu, 24 May 2001 16:01:17 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Cc: Pat Calhoun <pcalhoun@diameter.org> Subject: [AAA-WG]: [issue] Some AVPs in tables do not have 'V' bit as MUST NOT Message-ID: <Pine.GSO.4.21.0105241600140.28136-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Submitter name: Mark Eklund Submitter email address: meklund@cisco.com Date first submitted: 24-May-2001 Reference: Document: Base Comment type: E Priority: 1 Section: 4.5 Rationale/Explanation of issue: All AVPs defined will either be IETF or vendor specific. In the current Drafts, everything is IETF. Hence the AVP Flag 'V' should be in the MUST NOT column for all attributes. Requested change: Add the 'V' flag to the MUST NOT column. Resolution: This will be done. ==================================================================== From owner-aaa-bof@merit.edu Thu May 24 17:28:49 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21191 for <aaa-archive@odin.ietf.org>; Thu, 24 May 2001 17:28:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E2EEA5E0BB; Thu, 24 May 2001 16:55:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1B0935E31C; Thu, 24 May 2001 16:37:23 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D80415E347 for <aaa-wg@merit.edu>; Thu, 24 May 2001 16:05:12 -0400 (EDT) Received: (qmail 684 invoked by uid 500); 24 May 2001 19:53:52 -0000 Date: Thu, 24 May 2001 12:53:52 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: Mark Eklund <meklund@cisco.com> Cc: Pat Calhoun <pcalhoun@diameter.org>, aaa-wg@merit.edu Subject: [AAA-WG]: Re: [issue] Failed-AVP should be Grouped Message-ID: <20010524125351.G30735@charizard.diameter.org> Mail-Followup-To: Mark Eklund <meklund@cisco.com>, Pat Calhoun <pcalhoun@diameter.org>, aaa-wg@merit.edu References: <20010524122028.D30735@charizard.diameter.org> <Pine.GSO.4.21.0105241535090.28136-100000@knox6039> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <Pine.GSO.4.21.0105241535090.28136-100000@knox6039>; from meklund@cisco.com on Thu, May 24, 2001 at 03:55:17PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, May 24, 2001 at 03:55:17PM -0400, Mark Eklund wrote: > Hmm, it is quite possible that one thing was said and I heard > another. ditto. > I thought we had decided to put the entire AVP into > the Failed-AVP as type grouped. But why do you need a group, if you can fit the whole AVP into the Failed-AVP The Group was to hold the Vendor-Id, but this is already part of the AVP header that would comprise the Failed-AVP's data. > I also thought we discussed > placing a dummy zero fill as the value if it were a missing > AVP. The agreement was that one would create an AVP header, with the fields set to the missing AVP (meaning the AVP Code and Vendor ID would be set to the values of the missing AVP). > > How would you implement an octetstring? Would you convert it > from your internal AVP representation to what is sent over the > wire and then add it to the data portion of the octetstring? That's what I thought we had agreed upon. Of course, we could include the actual AVP (as the AVP itself, and not an octetstring) as an element of the Grouped-AVP, which we can now do now that Grouped-AVPs aren't constrained anymore. > > Here is a sample AA-Answer with type grouped for the Failed-AVP. > You could make the Failed-AVP octetstring, but its data would > then be printed like I have shown the Proxy-State AVP. > > AA-Answer = > Session-Id = "a unique identifier", > Auth-Extension-Id = NASREQ, > Result-Code = DIAMETER_INVALID_AVP_VALUE, > Origin-FQDN = "server.my.org", > Origin-Realm = "cash-cow", > Service-Type = 5000, > Destination-FQDN = "nas1.your.com", > Failed-AVP = { > Service-Type = 5000 > } > Route-Record = { > Proxy-Address = "1.2.3.4", > Proxy-State = AA AB 08 09 77 44 DE AD > } ok, perhaps this is a better approach. I agree that parsers would most likely like this better than my proposed. Keep in mind, though, that AVPs cannot have zero (or NULL) data, so *some* data will have to be added when creating the dummy AVP if it was missing from a message. PatC > > -mark > > On Thu, 24 May 2001, Pat Calhoun wrote: > > > On Thu, May 24, 2001 at 03:28:51PM -0400, Mark Eklund wrote: > > > > Mark, > > > > I am confused. I *thought* we agreed that it could remain an OctetString, > > since it contains the whole AVP header (and data), and therefore includes > > the vendor id. No grouping is required. > > > > Is my recollection incorrect? > > > > PatC > > > > > Submitter name: Mark Eklund > > > Submitter email address: meklund@cisco.com > > > Date first submitted: 24-May-2001 > > > Reference: > > > Document: Base > > > Comment type: T > > > Priority: 2 > > > Section: > > > Rationale/Explanation of issue: > > > With the change of the grouped type AVP to allow ABNF in > > > the form of 1* {AVP}, the information held by the Failed-Vendor-Id > > > and Offending-AVP may sent by simply putting the failed AVP in the > > > Failed-AVP group. > > > > > > Requested change: > > > Eliminate Offending-AVP and Failed-Vendor-Id, change > > > Failed-AVP to be of type grouped. > > > > > > Resolution: > > > > > > Section 9.3 will be changed to: > > > > > > 9.3 Failed-AVP AVP > > > > > > The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides > > > debugging information in cases where a request is rejected or not > > > fully processed due to erroneous information in a specific AVP. The > > > value of the Result-Code AVP will provide information on the reason > > > for the Failed-AVP AVP. > > > > > > The possible reasons for this AVP are the presence of an improperly > > > constructed AVP, an unsupported or unrecognized AVP, an invalid AVP > > > value, the omission of a required AVP, the presence of an explicitly > > > excluded AVP (see table 13.0), or the presence of two or more > > > occurrences of an AVP which table 15.1 restricts to 0, 1, or 0-1 > > > occurrences. > > > > > > A Diameter message MAY contain one Failed-AVP AVP, containing > > > the entire AVP that could not be processed successfully. If the > > > failure reason is omission of a required AVP, an AVP with the > > > missing command code, the missing vendor id, and a zero filled > > > payload will be added. > > > > > > AVP format: > > > <Failed-AVP> ::= (AVP Code = 279) > > > 1* {AVP} > > > > > > ==================================================================== > > > > > > > > > > > > > > > > > > From owner-aaa-bof@merit.edu Thu May 24 17:36:57 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21312 for <aaa-archive@odin.ietf.org>; Thu, 24 May 2001 17:36:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0575D5E014; Thu, 24 May 2001 16:50:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 48AA75E1E6; Thu, 24 May 2001 16:35:19 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 32B435E1E6 for <aaa-wg@merit.edu>; Thu, 24 May 2001 15:31:50 -0400 (EDT) Received: (qmail 31507 invoked by uid 500); 24 May 2001 19:20:29 -0000 Date: Thu, 24 May 2001 12:20:28 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: Mark Eklund <meklund@cisco.com> Cc: aaa-wg@merit.edu, Pat Calhoun <pcalhoun@diameter.org> Subject: [AAA-WG]: Re: [issue] Failed-AVP should be Grouped Message-ID: <20010524122028.D30735@charizard.diameter.org> Mail-Followup-To: Mark Eklund <meklund@cisco.com>, aaa-wg@merit.edu, Pat Calhoun <pcalhoun@diameter.org> References: <Pine.GSO.4.21.0105241526320.28136-100000@knox6039> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <Pine.GSO.4.21.0105241526320.28136-100000@knox6039>; from meklund@cisco.com on Thu, May 24, 2001 at 03:28:51PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, May 24, 2001 at 03:28:51PM -0400, Mark Eklund wrote: Mark, I am confused. I *thought* we agreed that it could remain an OctetString, since it contains the whole AVP header (and data), and therefore includes the vendor id. No grouping is required. Is my recollection incorrect? PatC > Submitter name: Mark Eklund > Submitter email address: meklund@cisco.com > Date first submitted: 24-May-2001 > Reference: > Document: Base > Comment type: T > Priority: 2 > Section: > Rationale/Explanation of issue: > With the change of the grouped type AVP to allow ABNF in > the form of 1* {AVP}, the information held by the Failed-Vendor-Id > and Offending-AVP may sent by simply putting the failed AVP in the > Failed-AVP group. > > Requested change: > Eliminate Offending-AVP and Failed-Vendor-Id, change > Failed-AVP to be of type grouped. > > Resolution: > > Section 9.3 will be changed to: > > 9.3 Failed-AVP AVP > > The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides > debugging information in cases where a request is rejected or not > fully processed due to erroneous information in a specific AVP. The > value of the Result-Code AVP will provide information on the reason > for the Failed-AVP AVP. > > The possible reasons for this AVP are the presence of an improperly > constructed AVP, an unsupported or unrecognized AVP, an invalid AVP > value, the omission of a required AVP, the presence of an explicitly > excluded AVP (see table 13.0), or the presence of two or more > occurrences of an AVP which table 15.1 restricts to 0, 1, or 0-1 > occurrences. > > A Diameter message MAY contain one Failed-AVP AVP, containing > the entire AVP that could not be processed successfully. If the > failure reason is omission of a required AVP, an AVP with the > missing command code, the missing vendor id, and a zero filled > payload will be added. > > AVP format: > <Failed-AVP> ::= (AVP Code = 279) > 1* {AVP} > > ==================================================================== > > > > > From owner-aaa-bof@merit.edu Thu May 24 20:25:20 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23148 for <aaa-archive@odin.ietf.org>; Thu, 24 May 2001 20:25:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CC54B5E8B3; Thu, 24 May 2001 19:45:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1E7DE5E5D4; Thu, 24 May 2001 18:39:45 -0400 (EDT) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id C4E325EDD7 for <aaa-wg@merit.edu>; Thu, 24 May 2001 17:20:17 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA15059; Thu, 24 May 2001 17:18:57 -0400 (EDT) Date: Thu, 24 May 2001 17:19:59 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: Pat Calhoun <pcalhoun@diameter.org> Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Re: [issue] Failed-AVP should be Grouped In-Reply-To: <20010524125351.G30735@charizard.diameter.org> Message-ID: <Pine.GSO.4.21.0105241611260.28136-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, On Thu, 24 May 2001, Pat Calhoun wrote: > On Thu, May 24, 2001 at 03:55:17PM -0400, Mark Eklund wrote: > > Hmm, it is quite possible that one thing was said and I heard > > another. > ditto. > > > I thought we had decided to put the entire AVP into > > the Failed-AVP as type grouped. > > But why do you need a group, if you can fit the whole AVP into the Failed-AVP > The Group was to hold the Vendor-Id, but this is already part of the > AVP header that would comprise the Failed-AVP's data. > > > I also thought we discussed > > placing a dummy zero fill as the value if it were a missing > > AVP. > > The agreement was that one would create an AVP header, with the fields > set to the missing AVP (meaning the AVP Code and Vendor ID would be set > to the values of the missing AVP). > > > > > How would you implement an octetstring? Would you convert it > > from your internal AVP representation to what is sent over the > > wire and then add it to the data portion of the octetstring? > > That's what I thought we had agreed upon. Of course, we could include > the actual AVP (as the AVP itself, and not an octetstring) as an > element of the Grouped-AVP, which we can now do now that Grouped-AVPs > aren't constrained anymore. Are we saying the same thing differently? Using the version 4 AVP header, let us assume the offending AVP is Vendor University of Tennessee (13) AVP 53 which is of type integer and only allows values from 0-99. The value sent was 255. Having a grouped AVP, the reply would be: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code = 53 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length = 24 | Reserved = 0 |.|.|.|.|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code = 53 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length = 16 | Reserved = 0 |.|.|V|.|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID = 13 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ How would the implementation of octetstring be different? > > > > > Here is a sample AA-Answer with type grouped for the Failed-AVP. > > You could make the Failed-AVP octetstring, but its data would > > then be printed like I have shown the Proxy-State AVP. > > > > AA-Answer = > > Session-Id = "a unique identifier", > > Auth-Extension-Id = NASREQ, > > Result-Code = DIAMETER_INVALID_AVP_VALUE, > > Origin-FQDN = "server.my.org", > > Origin-Realm = "cash-cow", > > Service-Type = 5000, > > Destination-FQDN = "nas1.your.com", > > Failed-AVP = { > > Service-Type = 5000 > > } > > Route-Record = { > > Proxy-Address = "1.2.3.4", > > Proxy-State = AA AB 08 09 77 44 DE AD > > } > > ok, perhaps this is a better approach. I agree that parsers would most > likely like this better than my proposed. Keep in mind, though, that AVPs > cannot have zero (or NULL) data, so *some* data will have to be added when > creating the dummy AVP if it was missing from a message. Thanks :) Also, if you use my explanation in the issue resolution, you probably should change If the failure reason is omission of a required AVP, an AVP with the missing command code, the missing vendor id, and a zero filled payload will be added. to If the failure reason is omission of a required AVP, an AVP with the missing AVP code, the missing vendor id, and a zero filled payload of the minimum required length for the ommitted AVP will be added. -mark > > PatC > > > > -mark > > > > On Thu, 24 May 2001, Pat Calhoun wrote: > > > > > On Thu, May 24, 2001 at 03:28:51PM -0400, Mark Eklund wrote: > > > > > > Mark, > > > > > > I am confused. I *thought* we agreed that it could remain an OctetString, > > > since it contains the whole AVP header (and data), and therefore includes > > > the vendor id. No grouping is required. > > > > > > Is my recollection incorrect? > > > > > > PatC > > > > > > > Submitter name: Mark Eklund > > > > Submitter email address: meklund@cisco.com > > > > Date first submitted: 24-May-2001 > > > > Reference: > > > > Document: Base > > > > Comment type: T > > > > Priority: 2 > > > > Section: > > > > Rationale/Explanation of issue: > > > > With the change of the grouped type AVP to allow ABNF in > > > > the form of 1* {AVP}, the information held by the Failed-Vendor-Id > > > > and Offending-AVP may sent by simply putting the failed AVP in the > > > > Failed-AVP group. > > > > > > > > Requested change: > > > > Eliminate Offending-AVP and Failed-Vendor-Id, change > > > > Failed-AVP to be of type grouped. > > > > > > > > Resolution: > > > > > > > > Section 9.3 will be changed to: > > > > > > > > 9.3 Failed-AVP AVP > > > > > > > > The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides > > > > debugging information in cases where a request is rejected or not > > > > fully processed due to erroneous information in a specific AVP. The > > > > value of the Result-Code AVP will provide information on the reason > > > > for the Failed-AVP AVP. > > > > > > > > The possible reasons for this AVP are the presence of an improperly > > > > constructed AVP, an unsupported or unrecognized AVP, an invalid AVP > > > > value, the omission of a required AVP, the presence of an explicitly > > > > excluded AVP (see table 13.0), or the presence of two or more > > > > occurrences of an AVP which table 15.1 restricts to 0, 1, or 0-1 > > > > occurrences. > > > > > > > > A Diameter message MAY contain one Failed-AVP AVP, containing > > > > the entire AVP that could not be processed successfully. If the > > > > failure reason is omission of a required AVP, an AVP with the > > > > missing command code, the missing vendor id, and a zero filled > > > > payload will be added. > > > > > > > > AVP format: > > > > <Failed-AVP> ::= (AVP Code = 279) > > > > 1* {AVP} > > > > > > > > ==================================================================== > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-aaa-bof@merit.edu Thu May 24 22:00:44 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24749 for <aaa-archive@odin.ietf.org>; Thu, 24 May 2001 22:00:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4D0255E252; Thu, 24 May 2001 21:38:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B38445E262; Thu, 24 May 2001 20:39:49 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id 854275DFB8 for <aaa-wg@merit.edu>; Thu, 24 May 2001 19:58:29 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id QAA22605 for <aaa-wg@merit.edu>; Thu, 24 May 2001 16:58:28 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id QAA01690 for <aaa-wg@merit.edu>; Thu, 24 May 2001 16:52:16 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id <LN56R0KX>; Thu, 24 May 2001 18:58:28 -0500 Message-ID: <A5B4C9A2AD89D411AB3E009027B0DA1E234E17@IL27EXM09.cig.mot.com> From: Thomas Panagiotis-PTHOMAS1 <panos.thomas@motorola.com> To: "'Pat Calhoun'" <pcalhoun@diameter.org> Cc: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu> Subject: [AAA-WG]: [issue #19] Extensions that Diameter servers must support Date: Thu, 24 May 2001 18:58:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, > " Diameter home servers MUST support the Base protocol, which includes > Accounting, and both the NASREQ and Mobile IP extensions. Diameter > proxies and redirect servers MUST support the Base protocol, and > MAY support other extensions. Diameter Clients MUST support the > Base protocol, including Accounting, and MAY support any other > extension that would be required to provide service." Why is Accounting mentioned above? All Diameter entities MUST support the base, therefore they MUST support all accounting messages/AVPs defined in the base, right? In any case, there is no way for an entity to advertise Base-minus-Accounting_within_base support. -Panos From owner-aaa-bof@merit.edu Thu May 24 22:05:36 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24808 for <aaa-archive@odin.ietf.org>; Thu, 24 May 2001 22:05:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F0FFB5E228; Thu, 24 May 2001 21:39:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7B1B75EA61; Thu, 24 May 2001 20:40:22 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B58DE5E03E for <aaa-wg@merit.edu>; Thu, 24 May 2001 20:05:34 -0400 (EDT) Received: (qmail 8151 invoked by uid 500); 24 May 2001 23:54:13 -0000 Date: Thu, 24 May 2001 16:54:13 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: Thomas Panagiotis-PTHOMAS1 <panos.thomas@motorola.com> Cc: "'Pat Calhoun'" <pcalhoun@diameter.org>, "'aaa-wg@merit.edu'" <aaa-wg@merit.edu> Subject: [AAA-WG]: Re: [issue #19] Extensions that Diameter servers must support Message-ID: <20010524165412.L30735@charizard.diameter.org> Mail-Followup-To: Thomas Panagiotis-PTHOMAS1 <panos.thomas@motorola.com>, 'Pat Calhoun' <pcalhoun@diameter.org>, "'aaa-wg@merit.edu'" <aaa-wg@merit.edu> References: <A5B4C9A2AD89D411AB3E009027B0DA1E234E17@IL27EXM09.cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <A5B4C9A2AD89D411AB3E009027B0DA1E234E17@IL27EXM09.cig.mot.com>; from panos.thomas@motorola.com on Thu, May 24, 2001 at 06:58:27PM -0500 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, May 24, 2001 at 06:58:27PM -0500, Thomas Panagiotis-PTHOMAS1 wrote: > Pat, > > > " Diameter home servers MUST support the Base protocol, which includes > > Accounting, and both the NASREQ and Mobile IP extensions. Diameter > > proxies and redirect servers MUST support the Base protocol, and > > MAY support other extensions. Diameter Clients MUST support the > > Base protocol, including Accounting, and MAY support any other > > extension that would be required to provide service." > > Why is Accounting mentioned above? All Diameter entities MUST support > the base, therefore they MUST support all accounting messages/AVPs defined > in the base, right? In any case, there is no way for an entity to advertise > Base-minus-Accounting_within_base support. Not quite certain. I received this text from someone, and although it sounded odd to me, I believe that the folks that crafted this language really wanted that there. I do agree, though, and it really doesn't belong there. PatC > > -Panos From owner-aaa-bof@merit.edu Fri May 25 08:35:15 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16227 for <aaa-archive@odin.ietf.org>; Fri, 25 May 2001 08:35:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B63E05DF0C; Fri, 25 May 2001 08:35:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A2BF05DF10; Fri, 25 May 2001 08:35:12 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id EE30A5DF0C for <aaa-wg@merit.edu>; Fri, 25 May 2001 08:35:09 -0400 (EDT) Received: (qmail 10721 invoked by uid 500); 25 May 2001 12:23:46 -0000 Date: Fri, 25 May 2001 05:23:46 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: aaa-wg@merit.edu Subject: [AAA-WG]: Proposed fixes for Issues 13, 18 and 30 Message-ID: <20010525052346.P30735@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, Below is the new text for section 9, which attempts to address the issues mentioned above. I would appreciate some feedback from folks on whether the text is consistent with their understanding of the outcome of the Interim meeting. Actual fixes: Issue 13: DSI is removed, and a new answer only message is used to report protocol errors. Protocol errors MAY be treated at each hop. The DSI-Events are moved to a new class within the Result-Code AVP. Issue 18: Error-Reporting-FQDN was a dup of Origin-FQDN, and therefore MUST only be included if a host is changing the result-code AVP, and is not the one whose identity is in the Origin-FQDN. Issue 30: Failed-AVP should be a grouped AVP, and include the offending AVP in it's group. Thanks, PatC ---- 9.0 Error Handling There are two different types of errors in Diameter; protocol and extensions. A protocol error is one that occurs at the base protocol level, and MAY require attention at each hop in a proxy environment (e.g. message routing error). Extension errors, on the other hand, are generally occur due to a problem with a function specified in a Diameter extension(e.g. user authentication, Missing AVP). Result-Code AVP values that are used to report protocol errors MUST be used in the Message-Reject-Answer command. Unlike most Diameter commands, the Message-Reject-Answer does not have a corresponding request. When a request message is received that causes a protocol error, the command code is changed to Message-Reject-Answer, and the Result-Code AVP is set to the appropriate protocol error value. As the answer is sent back towards the originator of the request, each proxy MAY take action on the message. Calhoun et al. expires October 2001 [Page 41] Internet-Draft May 2001 1. Request +---------+ Link Broken +-------------------------->|Diameter |----///----+ | +---------------------| | v +------+--+ | 2. MRA | Proxy 2 | +--------+ |Diameter |<-+ (Unable to Forward) +---------+ |Diameter| | | | Home | | Proxy 1 |--+ +---------+ | Server | +---------+ | 3. Request |Diameter | +--------+ +-------------------->| | ^ | Proxy 3 |-----------+ +---------+ Figure 1 - Example of Protocol Error causing MRA message Figure 1 provides an example of a message sent by a Diameter proxy towards a home server. When the message is received by Proxy 2, and it detects that it cannot forward the request to the home server, an MRA message is returned with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. Given that this error falls within the protocol error category, Proxy 1 would take special action, and given the error, attempt to route the message through its alternate proxy 3. +---------+ 1. Request +---------+ 2. Request +---------+ | Access |------------>|Diameter |------------>|Diameter | | | | | | Home | | Device |<------------| Proxy |<------------| Server | +---------+ 4. Answer +---------+ 3. Answer +---------+ (Missing AVP) (Missing AVP) Figure 2 - Example of Extension Error Answer message Figure 2 provides an example of a Diameter message that caused an extension error. When extension errors occur, the Diameter entity reporting the error clears the 'R' bit in the Command Flags, and adds the Result-Code AVP with the proper value. Extension errors do not require any proxy involvement, and therefore the message would be forwarded back to the originator of the request. There are certain Result-Code AVP extensions errors that require additional AVPs to be present in the answer, such as: - An unrecognized AVP is received with the 'M' bit (Mandatory bit) set, causes an answer to be sent with the Result-Code AVP set to DIAMETER_AVP_UNSUPPORTED, and the Failed-AVP AVP containing the offending AVP. - An AVP that is received with an unrecognized value causes an answer to be returned with the Result-Code AVP set to DIAMETER_INVALID_AVP_VALUE, with the Failed-AVP AVP containing the AVP causing the error. Calhoun et al. expires October 2001 [Page 42] Internet-Draft May 2001 - A command is received with an AVP that is ommitted, yet is mandatory according to the command's ABNF. The receiver issues an answer with the Result-Code set to DIAMETER_MISSING_AVP, and creates an AVP with the AVP Code and other fields set to the missing AVP's. The created AVP is then added to the Failed-AVP AVP. The Result-Code AVP contains additional errors conditions, and defines the expected behavior of each. 9.1 Result-Code AVP The Result-Code AVP (AVP Code 268) is of type Unsigned32 and indicates whether a particular request was completed successfully or whether an error occurred. All Diameter answer messages MUST include one Result-Code AVP. A non-successful Result-Code AVP (one containing a non 2xxx value) MUST include the Error-Reporting-Host AVP if the host setting the Result-Code AVP is different from the identity encoded in the Origin-Host AVP. The Result-Code data field contains an IANA-managed 32-bit address space representing errors (see section 16.4). Diameter provides the following classes of errors, all identified by the thousands digit: - 1xxx (Informational) - 2xxx (Success) - 3xxx (Protocol Errors) - 4xxx (Transient Failures) - 5xxx (Permanent Failure) A non-recognize class (one whose first digit is not defined in this section) MUST be handled as a permanent failure. 9.1.1 Informational Errors that fall within the Informational category are used to inform a requester that the request cannot be immediately satisfied and a further response will be issued in the near future. There are currently no errors that fall within this class. 9.1.2 Success Errors that fall within the Success category are used to inform a peer that a request has been successfully completed. DIAMETER_SUCCESS 2001 Calhoun et al. expires October 2001 [Page 43] Internet-Draft May 2001 The Request was successfully completed. 9.1.3 Protocol Errors Errors that fall within the Protocol Error category SHOULD be treated on a per-hop basis, and Diameter proxies MAY attempt to correct the error, if it is possible. Note that these errors MUST only be used in the Message-Rejected-Answer message, therefore a Diameter entity that wishes to return an error in this category MUST change the command code to Message-Rejected-Answer message. DIAMETER_INVALID_ROUTE_RECORD 3001 The last Route-Record AVP in the message is not set to the identity of the sender of the message. See Section 11.0 for more information. DIAMETER_COMMAND_UNSUPPORTED 3002 The Request contained a Command-Code that the receiver did not recognize or support. DIAMETER_UNABLE_TO_DELIVER 3003 The request could not be delivered to a host that handles the realm, and extension, requested at this time. DIAMETER_REALM_NOT_SERVED 3004 The intended realm of the offending message is unknown. DIAMETER_TOO_BUSY 3005 When returned, a Diameter node SHOULD attempt to sent the message to an alternate peer. DIAMETER_INVALID_CMS_DATA 3006 The Request did not contain a valid CMS-Data [11] AVP. DIAMETER_LOOP_DETECTED 3007 A Proxy or Redirect server detected a loop while trying to get the message to the Home Diameter server. The message MAY be sent to an alternate peer, if one is available, but the peer reporting the error has identified a configuration problem. DIAMETER_END_2_END_SECURITY 3008 A proxy has detected that end-to-end security has been applied to portions of the Diameter message, and the proxy does not allow this security mode since it needs to alter the message by applying some local policies. Calhoun et al. expires October 2001 [Page 44] Internet-Draft May 2001 9.1.4 Transient Failures Errors that fall within the transient failures category are used to inform a peer that the request could not be satisfied at the time it was received, but MAY be able to satisfy the request in the future. DIAMETER_AUTHENTICATION_REJECTED 4001 The authentication process for the user failed, most likely due to an invalid password used by the user. Further attempts MUST only be tried after prompting the user for a new password. DIAMETER_OUT_OF_SPACE 4002 A Diameter node received the accounting request but was unable to commit it to stable storage due to a temporary lack of space. 9.1.5 Permanent Failures Errors that fall within the permanent failures category are used to inform the peer that the request failed, and should not be attempted again. DIAMETER_USER_UNKNOWN 5001 A request was received for a user that is unknown, therefore authentication and/or authorization failed. DIAMETER_AVP_UNSUPPORTED 5002 The peer received a message that contained an AVP that is not recognized or supported and was marked with the Mandatory bit. A Diameter message with this error MUST contain one or more Failed-AVP AVP containing the AVPs that caused the failure. DIAMETER_UNKNOWN_SESSION_ID 5003 The request contained an unknown Session-Id. DIAMETER_AUTHORIZATION_REJECTED 5004 A request was received for which the user could not be authorized. This error could occur if the service requested is not permitted to the user. DIAMETER_INVALID_AVP_VALUE 5005 The request contained an AVP with an invalid value in its data portion. A Diameter message indicating this error MUST include the offending AVPs within a Failed-AVP AVP. DIAMETER_MISSING_AVP 5006 The request did not contain an AVP that is required by the Calhoun et al. expires October 2001 [Page 45] Internet-Draft May 2001 Command Code definition. If this value is sent in the Result- Code AVP, a Failed-AVP AVP SHOULD be included in the message. The data portion of the Failed-AVP MUST contain an AVP header containing the AVP Code and vendor-Id. DIAMETER_AUTHORIZATION_FAILED 5007 A request was received for which the user could not be authorized at this time. This error could occur when the user has already expended allowed resources, or is only permitted to access services within a time period. DIAMETER_CONTRADICTING_AVPS 5008 The Home Diameter server has detected AVPs in the request that contradicted each other, and is not willing to provide service to the user. One or more Failed-AVP AVPs MUST be present, containing the AVPs that contradicted each other. DIAMETER_AVP_NOT_ALLOWED 5009 A message was received with an AVP that MUST NOT be present. The Failed-AVP AVP MUST be included and contain the AVP Code of the offending AVP. DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5010 A message was received that included an AVP that appeared more often than permitted in the message definition. The Failed-AVP AVP MUST be included and contain the AVP Code of the offending AVP. DIAMETER_VENDOR_ID_UNSUPPORTED 5011 The Home Diameter server has detected vendor-specific AVPs in the message, and the vendor dictionary is not supported. One or more Failed-AVP MUST be present, containing the offending AVPs. DIAMETER_UNSUPPORTED_TRANSFORM 5012 A message was received that included an CMS-Data AVP [11] that made use of an unsupported transform. DIAMETER_NO_COMMON_EXTENSION 5013 This event is returned when a DRA message is received, and there are no common extensions supported between the peer. DIAMETER_UNSUPPORTED_VERSION 5014 This event is returned when a DRA message is received, and the Diameter message is unsupported. 9.2 Message-Reject-Answer Calhoun et al. expires October 2001 [Page 46] Internet-Draft May 2001 The Message-Reject-Answer (MRA), indicated by the Command-Code set to 282, and the Command Flags' 'R' bit cleared, is sent in response to a request that has caused a protocol error. Although the command code is different from the one found in the request, the same procedures used in issuing an answer message is followed. The Result-Code AVP MUST be present, and include a value in the "Protocol Error" category. Proxies receiving an MRA message MAY attempt to rectify the error reported, if possible. In the event that no proxy is able to correct the problem, the MRA will be returned to the originator of the request message. Message Format <Message-Reject-Answer> ::= < Diameter Header: 282, I > < Session-Id > { Origin-Host } { Origin-Realm } { Result-Code } { Destination-Host } * [ AVP ] 9.3 Error-Message AVP The Error-Message AVP (AVP Code 281) is of type OctetString. It is a human readable UTF-8 character encoded string. It MAY accompany a Result-Code AVP as a human readable error message. The Error-Message AVP is not intended to be useful in real-time, and SHOULD NOT be expected to be parsed by network entities. 9.4 Error-Reporting-Host AVP The Error-Reporting-Host AVP (AVP Code 294) is of type OctetString, encoded in the UTF-8 [24] format, according to the Diameter identity rules defined in section 2.6. This AVP contains the identity of the Diameter host that set the Result-Code AVP to a value other than 2001 (Success), only if the host setting the Result-Code is different from the one encoded in the Origin-Host AVP. This AVP is intended to be used for troubleshooting purposes, and MUST be set when the Result- Code AVP indicates a failure. 9.5 Failed-AVP AVP Calhoun et al. expires October 2001 [Page 47] Internet-Draft May 2001 The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides debugging information in cases where a request is rejected or not fully processed due to erroneous information in a specific AVP. The value of the Result-Code AVP will provide information on the reason for the Failed-AVP AVP. The possible reasons for this AVP are the presence of an improperly constructed AVP, an unsupported or unrecognized AVP, an invalid AVP value, the omission of a required AVP, the presence of an explicitly excluded AVP (see table 13.0), or the presence of two or more occurrences of an AVP which table 15.1 restricts to 0, 1, or 0-1 occurrences. A Diameter message MAY contain one Failed-AVP AVP, containing the entire AVP that could not be processed successfully. If the failure reason is omission of a required AVP, an AVP with the missing AVP code, the missing vendor id, and a zero filled payload of the minimum required length for the ommitted AVP will be added. AVP Format <Failed-AVP> ::= < AVP Header: 279 > 1* {AVP} From owner-aaa-bof@merit.edu Fri May 25 09:42:02 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17895 for <aaa-archive@odin.ietf.org>; Fri, 25 May 2001 09:42:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 93CD25DEF6; Fri, 25 May 2001 09:40:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 69A2F5E138; Fri, 25 May 2001 09:39:44 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 35B125E131 for <aaa-wg@merit.edu>; Fri, 25 May 2001 09:37:07 -0400 (EDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4PDbIm29944 for <aaa-wg@merit.edu>; Fri, 25 May 2001 16:37:18 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <T53bd349743ac158f22034@esvir02nok.nokia.com> for <aaa-wg@merit.edu>; Fri, 25 May 2001 16:37:06 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id <J4KQRGPB>; Fri, 25 May 2001 16:37:05 +0300 Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E62686@treis03nok> From: henry.haverinen@nokia.com To: aaa-wg@merit.edu Subject: [AAA-WG]: Proposed additions to diameter Mobile IP draft Date: Fri, 25 May 2001 16:37:02 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi all, I'd like to propose the following two additions to draft-ietf-aaa-diameter-mobileip. Regards, Henry Issue 1: Some authentication mechanisms may take more than one roundtrip to authenticate and authorize the user. An example of such a mechanism is draft-haverinen-mobileip-gsmsim-02.txt. Solution proposal: These mechanisms can easily be supported in the Diameter Mobile IP draft if an unsuccessful AMA message can be used to convey authentication data to the MN in a key distribution extension. So please include the following text in Section 2.2: An unsuccessful AMA message MAY include mobile node registration key AVPs (Section 7.1) such as the MIP-MN-to-FA-Key AVP and the MIP-MN-to-HA-Key AVP. If such an AVP is present in the AMA message, then the foreign agent MUST include the corresponding Mobile IP key distribution extension in the Registration Reply it sends to the mobile node. This is to support multi-roundtrip authentication mechanisms. In addition, please include MIP-MN-to-FA-Key AVP in the AA-Mobile-Node-Answer message format definition. ---------------------------- Issue 2: The AAAL may not be able to reach the home agent the mobile node is using even if it was able to reach the AAAH. This may occur for example if the home agent was allocated from a previously visited network, or if the mobile node is authenticated and authorized using a local gateway to a back end AAA server (see draft-haverinen- mobileip-gsmsim-02.txt for an example). In these cases, the foreign agent needs to forward the Registration Request to the home agent itself. Solution proposal: Section 2.2 currently says: "A successful AMA message MUST include the MIP-Home-Agent-Address, MIP-Home-Mobile-Node-Address AVP and MIP-Reg-Reply AVPs." Please remove the MIP-Reg-Reply AVP from the list. In addition, please include the following text in Section 2.2: The AAAL may not always be able to reach the home agent even if was able to authenticate and authorize the mobile node. Therefore, if a successful AMA message does not include the MIP-Reg-Reply AVP, then then the foreign agent MUST relay the Registration Request in question to the home agent itself. An AMA message can only be successful and not include the MIP-Reg-Reply AVP if the Registration Request includes a Home Agent address and a Mobile-Home Authentication Extension. As required in [MIPv4 base document], the foreign agent must remove any Extensions following the Mobile-Home Authentication Extension before relaying the Request to the home agent. From owner-aaa-bof@merit.edu Fri May 25 09:54:54 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18145 for <aaa-archive@odin.ietf.org>; Fri, 25 May 2001 09:54:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3C3F35DE09; Fri, 25 May 2001 09:54:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C8E795DDE8; Fri, 25 May 2001 09:54:03 -0400 (EDT) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id D70CD5E523 for <aaa-wg@merit.edu>; Fri, 25 May 2001 09:48:46 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA20266; Fri, 25 May 2001 09:47:26 -0400 (EDT) Date: Fri, 25 May 2001 09:48:28 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: Pat Calhoun <pcalhoun@diameter.org> Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Proposed fixes for Issues 13, 18 and 30 In-Reply-To: <20010525052346.P30735@charizard.diameter.org> Message-ID: <Pine.GSO.4.21.0105250939550.28424-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, Looks good. One small documentation issue and one minor issue. See MWE> On Fri, 25 May 2001, Pat Calhoun wrote: > All, > > Below is the new text for section 9, which attempts to address the issues > mentioned above. I would appreciate some feedback from folks on whether the > text is consistent with their understanding of the outcome of the Interim > meeting. > > Actual fixes: > > Issue 13: DSI is removed, and a new answer only message is used to report > protocol errors. Protocol errors MAY be treated at each hop. The DSI-Events > are moved to a new class within the Result-Code AVP. > > Issue 18: Error-Reporting-FQDN was a dup of Origin-FQDN, and therefore MUST > only be included if a host is changing the result-code AVP, and is not the > one whose identity is in the Origin-FQDN. > > Issue 30: Failed-AVP should be a grouped AVP, and include the offending AVP > in it's group. > > Thanks, > > PatC > ---- > 9.0 Error Handling > > There are two different types of errors in Diameter; protocol and > extensions. A protocol error is one that occurs at the base protocol > level, and MAY require attention at each hop in a proxy environment > (e.g. message routing error). Extension errors, on the other hand, > are generally occur due to a problem with a function specified in a > Diameter extension(e.g. user authentication, Missing AVP). > > Result-Code AVP values that are used to report protocol errors MUST > be used in the Message-Reject-Answer command. Unlike most Diameter > commands, the Message-Reject-Answer does not have a corresponding > request. > > When a request message is received that causes a protocol error, the > command code is changed to Message-Reject-Answer, and the Result-Code > AVP is set to the appropriate protocol error value. As the answer is > sent back towards the originator of the request, each proxy MAY take > action on the message. > > > > > > > > > > > > > > > Calhoun et al. expires October 2001 [Page 41] > > > > > > Internet-Draft May 2001 > > > 1. Request +---------+ Link Broken > +-------------------------->|Diameter |----///----+ > | +---------------------| | v > +------+--+ | 2. MRA | Proxy 2 | +--------+ > |Diameter |<-+ (Unable to Forward) +---------+ |Diameter| > | | | Home | > | Proxy 1 |--+ +---------+ | Server | > +---------+ | 3. Request |Diameter | +--------+ > +-------------------->| | ^ > | Proxy 3 |-----------+ > +---------+ > Figure 1 - Example of Protocol Error causing MRA message > > Figure 1 provides an example of a message sent by a Diameter proxy > towards a home server. When the message is received by Proxy 2, and > it detects that it cannot forward the request to the home server, an > MRA message is returned with the Result-Code AVP set to > DIAMETER_UNABLE_TO_DELIVER. Given that this error falls within the > protocol error category, Proxy 1 would take special action, and given > the error, attempt to route the message through its alternate proxy > 3. > > +---------+ 1. Request +---------+ 2. Request +---------+ > | Access |------------>|Diameter |------------>|Diameter | > | | | | | Home | > | Device |<------------| Proxy |<------------| Server | > +---------+ 4. Answer +---------+ 3. Answer +---------+ > (Missing AVP) (Missing AVP) > Figure 2 - Example of Extension Error Answer message > > Figure 2 provides an example of a Diameter message that caused an > extension error. When extension errors occur, the Diameter entity > reporting the error clears the 'R' bit in the Command Flags, and adds > the Result-Code AVP with the proper value. Extension errors do not > require any proxy involvement, and therefore the message would be > forwarded back to the originator of the request. > > There are certain Result-Code AVP extensions errors that require > additional AVPs to be present in the answer, such as: > > - An unrecognized AVP is received with the 'M' bit (Mandatory bit) > set, causes an answer to be sent with the Result-Code AVP set to > DIAMETER_AVP_UNSUPPORTED, and the Failed-AVP AVP containing the > offending AVP. > - An AVP that is received with an unrecognized value causes an > answer to be returned with the Result-Code AVP set to > DIAMETER_INVALID_AVP_VALUE, with the Failed-AVP AVP containing > the AVP causing the error. > > > > Calhoun et al. expires October 2001 [Page 42] > > > > > > Internet-Draft May 2001 > > > - A command is received with an AVP that is ommitted, yet is > mandatory according to the command's ABNF. The receiver issues > an answer with the Result-Code set to DIAMETER_MISSING_AVP, and > creates an AVP with the AVP Code and other fields set to the > missing AVP's. The created AVP is then added to the Failed-AVP > AVP. > > The Result-Code AVP contains additional errors conditions, and > defines the expected behavior of each. > > > 9.1 Result-Code AVP > > The Result-Code AVP (AVP Code 268) is of type Unsigned32 and > indicates whether a particular request was completed successfully or > whether an error occurred. All Diameter answer messages MUST include > one Result-Code AVP. A non-successful Result-Code AVP (one containing > a non 2xxx value) MUST include the Error-Reporting-Host AVP if the > host setting the Result-Code AVP is different from the identity > encoded in the Origin-Host AVP. > > The Result-Code data field contains an IANA-managed 32-bit address > space representing errors (see section 16.4). Diameter provides the > following classes of errors, all identified by the thousands digit: > - 1xxx (Informational) > - 2xxx (Success) > - 3xxx (Protocol Errors) > - 4xxx (Transient Failures) > - 5xxx (Permanent Failure) > > A non-recognize class (one whose first digit is not defined in this > section) MUST be handled as a permanent failure. > > > 9.1.1 Informational > > Errors that fall within the Informational category are used to inform > a requester that the request cannot be immediately satisfied and a > further response will be issued in the near future. There are > currently no errors that fall within this class. > > > 9.1.2 Success > > Errors that fall within the Success category are used to inform a > peer that a request has been successfully completed. > > DIAMETER_SUCCESS 2001 > > > > Calhoun et al. expires October 2001 [Page 43] > > > > > > Internet-Draft May 2001 > > > The Request was successfully completed. > > > 9.1.3 Protocol Errors > > Errors that fall within the Protocol Error category SHOULD be treated > on a per-hop basis, and Diameter proxies MAY attempt to correct the > error, if it is possible. Note that these errors MUST only be used in > the Message-Rejected-Answer message, therefore a Diameter entity that > wishes to return an error in this category MUST change the command > code to Message-Rejected-Answer message. > > DIAMETER_INVALID_ROUTE_RECORD 3001 > The last Route-Record AVP in the message is not set to the > identity of the sender of the message. See Section 11.0 for > more information. > > DIAMETER_COMMAND_UNSUPPORTED 3002 > The Request contained a Command-Code that the receiver did not > recognize or support. > > DIAMETER_UNABLE_TO_DELIVER 3003 > The request could not be delivered to a host that handles the > realm, and extension, requested at this time. > > DIAMETER_REALM_NOT_SERVED 3004 > The intended realm of the offending message is unknown. > > DIAMETER_TOO_BUSY 3005 > When returned, a Diameter node SHOULD attempt to sent the > message to an alternate peer. > > DIAMETER_INVALID_CMS_DATA 3006 > The Request did not contain a valid CMS-Data [11] AVP. > > DIAMETER_LOOP_DETECTED 3007 > A Proxy or Redirect server detected a loop while trying to get > the message to the Home Diameter server. The message MAY be > sent to an alternate peer, if one is available, but the peer > reporting the error has identified a configuration problem. > > DIAMETER_END_2_END_SECURITY 3008 > A proxy has detected that end-to-end security has been applied > to portions of the Diameter message, and the proxy does not > allow this security mode since it needs to alter the message by > applying some local policies. > > > > > > Calhoun et al. expires October 2001 [Page 44] > > > > > > Internet-Draft May 2001 > > > 9.1.4 Transient Failures > > Errors that fall within the transient failures category are used to > inform a peer that the request could not be satisfied at the time it > was received, but MAY be able to satisfy the request in the future. > > DIAMETER_AUTHENTICATION_REJECTED 4001 > The authentication process for the user failed, most likely due > to an invalid password used by the user. Further attempts MUST > only be tried after prompting the user for a new password. > > DIAMETER_OUT_OF_SPACE 4002 > A Diameter node received the accounting request but was unable > to commit it to stable storage due to a temporary lack of > space. > > > 9.1.5 Permanent Failures > > Errors that fall within the permanent failures category are used to > inform the peer that the request failed, and should not be attempted > again. > > DIAMETER_USER_UNKNOWN 5001 > A request was received for a user that is unknown, therefore > authentication and/or authorization failed. > > DIAMETER_AVP_UNSUPPORTED 5002 > The peer received a message that contained an AVP that is not > recognized or supported and was marked with the Mandatory bit. > A Diameter message with this error MUST contain one or more > Failed-AVP AVP containing the AVPs that caused the failure. > > DIAMETER_UNKNOWN_SESSION_ID 5003 > The request contained an unknown Session-Id. > > DIAMETER_AUTHORIZATION_REJECTED 5004 > A request was received for which the user could not be > authorized. This error could occur if the service requested is > not permitted to the user. > > DIAMETER_INVALID_AVP_VALUE 5005 > The request contained an AVP with an invalid value in its data > portion. A Diameter message indicating this error MUST include > the offending AVPs within a Failed-AVP AVP. > > DIAMETER_MISSING_AVP 5006 > The request did not contain an AVP that is required by the > > > > Calhoun et al. expires October 2001 [Page 45] > > > > > > Internet-Draft May 2001 > > > Command Code definition. If this value is sent in the Result- > Code AVP, a Failed-AVP AVP SHOULD be included in the message. > The data portion of the Failed-AVP MUST contain an AVP header > containing the AVP Code and vendor-Id. > > DIAMETER_AUTHORIZATION_FAILED 5007 > A request was received for which the user could not be > authorized at this time. This error could occur when the user > has already expended allowed resources, or is only permitted to > access services within a time period. > > DIAMETER_CONTRADICTING_AVPS 5008 > The Home Diameter server has detected AVPs in the request that > contradicted each other, and is not willing to provide service > to the user. One or more Failed-AVP AVPs MUST be present, > containing the AVPs that contradicted each other. > > DIAMETER_AVP_NOT_ALLOWED 5009 > A message was received with an AVP that MUST NOT be present. > The Failed-AVP AVP MUST be included and contain the AVP Code of > the offending AVP. > > DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5010 > A message was received that included an AVP that appeared more > often than permitted in the message definition. The Failed-AVP > AVP MUST be included and contain the AVP Code of the offending > AVP. > > DIAMETER_VENDOR_ID_UNSUPPORTED 5011 > The Home Diameter server has detected vendor-specific AVPs in > the message, and the vendor dictionary is not supported. One or > more Failed-AVP MUST be present, containing the offending AVPs. > > DIAMETER_UNSUPPORTED_TRANSFORM 5012 > A message was received that included an CMS-Data AVP [11] that > made use of an unsupported transform. > > DIAMETER_NO_COMMON_EXTENSION 5013 > This event is returned when a DRA message is received, and > there are no common extensions supported between the peer. > > DIAMETER_UNSUPPORTED_VERSION 5014 > This event is returned when a DRA message is received, and the > Diameter message is unsupported. > > > 9.2 Message-Reject-Answer > > > > > Calhoun et al. expires October 2001 [Page 46] > > > > > > Internet-Draft May 2001 > > > The Message-Reject-Answer (MRA), indicated by the Command-Code set to > 282, and the Command Flags' 'R' bit cleared, is sent in response to a > request that has caused a protocol error. > > Although the command code is different from the one found in the > request, the same procedures used in issuing an answer message is > followed. The Result-Code AVP MUST be present, and include a value in > the "Protocol Error" category. > > Proxies receiving an MRA message MAY attempt to rectify the error > reported, if possible. In the event that no proxy is able to correct > the problem, the MRA will be returned to the originator of the > request message. > > Message Format > > <Message-Reject-Answer> ::= < Diameter Header: 282, I > > < Session-Id > > { Origin-Host } > { Origin-Realm } > { Result-Code } > { Destination-Host } MWE> Should you also have: [ Error-Message ] [ Error-Reporting-Host ] [ Failed-AVP ] > * [ AVP ] > > > 9.3 Error-Message AVP > > The Error-Message AVP (AVP Code 281) is of type OctetString. It is a > human readable UTF-8 character encoded string. It MAY accompany a > Result-Code AVP as a human readable error message. The Error-Message > AVP is not intended to be useful in real-time, and SHOULD NOT be > expected to be parsed by network entities. > > > 9.4 Error-Reporting-Host AVP > > The Error-Reporting-Host AVP (AVP Code 294) is of type OctetString, > encoded in the UTF-8 [24] format, according to the Diameter identity > rules defined in section 2.6. This AVP contains the identity of the > Diameter host that set the Result-Code AVP to a value other than 2001 > (Success), only if the host setting the Result-Code is different from > the one encoded in the Origin-Host AVP. This AVP is intended to be > used for troubleshooting purposes, and MUST be set when the Result- > Code AVP indicates a failure. > > > 9.5 Failed-AVP AVP > > > > > Calhoun et al. expires October 2001 [Page 47] > > > > > > Internet-Draft May 2001 > > > The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides > debugging information in cases where a request is rejected or not > fully processed due to erroneous information in a specific AVP. The > value of the Result-Code AVP will provide information on the reason > for the Failed-AVP AVP. > > The possible reasons for this AVP are the presence of an improperly > constructed AVP, an unsupported or unrecognized AVP, an invalid AVP > value, the omission of a required AVP, the presence of an explicitly > excluded AVP (see table 13.0), or the presence of two or more > occurrences of an AVP which table 15.1 restricts to 0, 1, or 0-1 > occurrences. > > A Diameter message MAY contain one Failed-AVP AVP, containing the > entire AVP that could not be processed successfully. If the failure > reason is omission of a required AVP, an AVP with the missing AVP > code, the missing vendor id, and a zero filled payload of the minimum > required length for the ommitted AVP will be added. > > AVP Format > > <Failed-AVP> ::= < AVP Header: 279 > > 1* {AVP} > MWE> When I sent you this text, I assummed that if you had more than one problematic AVP for the same reason, you could add multiple AVPs to the Failed-AVP (hence the 1* {AVP} above). I just wanted to make sure that is how everyone else saw it. -mark From owner-aaa-bof@merit.edu Fri May 25 10:23:04 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18751 for <aaa-archive@odin.ietf.org>; Fri, 25 May 2001 10:23:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 74A5A5DE43; Fri, 25 May 2001 10:22:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 72D5E5DD91; Fri, 25 May 2001 10:22:30 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 184E45DDCA for <aaa-wg@merit.edu>; Fri, 25 May 2001 10:20:29 -0400 (EDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4PEKem19056 for <aaa-wg@merit.edu>; Fri, 25 May 2001 17:20:40 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <T53bd5c4b82ac158f22034@esvir02nok.nokia.com> for <aaa-wg@merit.edu>; Fri, 25 May 2001 17:20:28 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <J4JGD1P2>; Fri, 25 May 2001 17:19:38 +0300 Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E62687@treis03nok> From: henry.haverinen@nokia.com To: aaa-wg@merit.edu Subject: [AAA-WG]: Another proposed change to Diameter NASREQ (EAP roundtrips) Date: Fri, 25 May 2001 17:19:36 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi all, In some EAP types, the last EAP-Response from the authenticating peer to the Diameter server is just an aknowledgement that doesn't contain any actual data. In these cases, one NAS-AAA-NAS roundtrip can be saved if the AAA server is able to indicate successful authentication in the Diameter command that contains the last EAP-Request. So I'd like to propose the following changes in the Diameter NASREQ draft: Section 4.0 on page 20 reads: If the Result-Code AVP indicates success, the EAP-Payload AVP MUST encapsulate an EAP-Success [25] payload, and the NAS SHOULD successfully terminate the PPP authentication phase. Please replace that with: If the Result-Code AVP indicates success, the EAP-Payload AVP MUST encapsulate an EAP-Success or an EAP-Request [25] payload, and the NAS SHOULD successfully terminate the PPP authentication phase. Even if the payload encapsulates an EAP-Request, the authentication has been successful. In these cases, the NAS successfully terminates the PPP authentication phase by first sending the encapsulated EAP-Request to the authenticating peer. Then on receipt of the corresponding EAP-Response, the NAS SHOULD send an EAP-Success to the authenticating peer. The NAS MUST NOT send the last EAP-Response to the Diameter server but it MUST discard the EAP-Response. Please add a new item in the list of Section 4.2.1: 5) A Diameter-EAP-Answer containing an EAP-Request encapsulated within an EAP-Payload and a Result-Code indicating success. Please include EAP-Request in the explanations of the first paragraph of Section 4.2.2. Like this: The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code field set to 268 and the 'A' bit set in the message flags field, is sent by the Diameter server to the client to indicate either a successful or failed authentication. The Diameter-EAP-Answer message SHOULD include an EAP payload of type EAP-Success, EAP-Request or EAP-Failure encapsulated within an EAP-Payload AVP. The Result-Code AVP MUST indicate a failure if the EAP-Failure payload is present, while the AVP MUST indicate success if the EAP-Success or the EAP-Request payload is present. From owner-aaa-bof@merit.edu Fri May 25 10:26:22 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18795 for <aaa-archive@odin.ietf.org>; Fri, 25 May 2001 10:26:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 40A765DDD6; Fri, 25 May 2001 10:25:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CE0305DDDD; Fri, 25 May 2001 10:25:47 -0400 (EDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 9F9855DDD6 for <aaa-wg@merit.edu>; Fri, 25 May 2001 10:25:43 -0400 (EDT) Received: (qmail 11817 invoked by uid 500); 25 May 2001 14:07:24 -0000 Date: Fri, 25 May 2001 07:07:24 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: Mark Eklund <meklund@cisco.com> Cc: Pat Calhoun <pcalhoun@diameter.org>, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Proposed fixes for Issues 13, 18 and 30 Message-ID: <20010525070724.Q30735@charizard.diameter.org> Mail-Followup-To: Mark Eklund <meklund@cisco.com>, Pat Calhoun <pcalhoun@diameter.org>, aaa-wg@merit.edu References: <20010525052346.P30735@charizard.diameter.org> <Pine.GSO.4.21.0105250939550.28424-100000@knox6039> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <Pine.GSO.4.21.0105250939550.28424-100000@knox6039>; from meklund@cisco.com on Fri, May 25, 2001 at 09:48:28AM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, May 25, 2001 at 09:48:28AM -0400, Mark Eklund wrote: > > MWE> Should you also have: > [ Error-Message ] > [ Error-Reporting-Host ] > [ Failed-AVP ] right, I should probably propagate these to all answer messages. > > AVP Format > > > > <Failed-AVP> ::= < AVP Header: 279 > > > 1* {AVP} > > > > MWE> When I sent you this text, I assummed that if you had more > than one problematic AVP for the same reason, you could add > multiple AVPs to the Failed-AVP (hence the 1* {AVP} above). I > just wanted to make sure that is how everyone else saw it. yup, that's what the proposed ABNF says, and I agree that there isn't a reason for multiple Failed-AVP AVPs. PatC From owner-aaa-bof@merit.edu Fri May 25 11:10:52 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19311 for <aaa-archive@odin.ietf.org>; Fri, 25 May 2001 11:10:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3A3A75DE59; Fri, 25 May 2001 11:08:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EC0155E010; Fri, 25 May 2001 11:08:41 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 42F455DE59 for <aaa-wg@merit.edu>; Fri, 25 May 2001 11:07:46 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA04458; Fri, 25 May 2001 08:07:41 -0700 (PDT) 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 IAA21481; Fri, 25 May 2001 08:07:40 -0700 (PDT) Received: from darius (darius [152.70.40.121]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA29868; Fri, 25 May 2001 08:07:38 -0700 (PDT) Date: Fri, 25 May 2001 08:07:39 -0700 (PDT) From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM> Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM> Subject: [AAA-WG]: Diameter Proposed Changes To: henry.haverinen@nokia.com Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <6D1A8E7871B9D211B3B00008C7490AA504E62687@treis03nok> Message-ID: <Roam.SIMC.2.0.6.990803259.12169.pcalhoun@nasnfs> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk May I kindly request that all proposed changes include an issue request, as we have been doing to track all issues. Furthermore, I would like to remind everyone that we agreed at the Minn IETF that we wouldn't accept new features. Please keep this in mind when requesting new features, and provide the necessary justification for all new issues. Thanks, PatC From owner-aaa-bof@merit.edu Fri May 25 12:24:51 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20621 for <aaa-archive@odin.ietf.org>; Fri, 25 May 2001 12:24:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 87A275DEBF; Fri, 25 May 2001 12:03:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 91ED35E50C; Fri, 25 May 2001 11:50:50 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id EF8DF5E286 for <aaa-wg@merit.edu>; Fri, 25 May 2001 11:45:57 -0400 (EDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4PFk9m16855 for <aaa-wg@merit.edu>; Fri, 25 May 2001 18:46:09 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <T53bdaa6e10ac158f22034@esvir02nok.nokia.com>; Fri, 25 May 2001 18:45:48 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <J4JGDFNL>; Fri, 25 May 2001 18:45:48 +0300 Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E62689@treis03nok> From: henry.haverinen@nokia.com To: pcalhoun@nasnfs.Eng.Sun.COM Cc: aaa-wg@merit.edu Subject: [AAA-WG]: RE: Diameter Proposed Changes Date: Fri, 25 May 2001 18:45:48 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > May I kindly request that all proposed changes include an > issue request, as we > have been doing to track all issues. Pat, I apologize for my ignorance. Here are my issues re-formatted: ========================================================================= Subject: [issue] EAP Roundtrips Submitter name: Henry Haverinen Submitter email address: henry.haverinen@nokia.com Date first submitted: 2001-05-25 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00974.html Document: <NASREQ> Comment type: T Priority: 2 Section: 4.0, 4.2.1, 4.2.2 Rationale/Explanation of issue: This issue is an optimization. In some EAP types, the last EAP-Response from the authenticating peer to the Diameter server is just an aknowledgement that doesn't contain any actual data. In these cases, one NAS-AAA-NAS roundtrip can be saved if the AAA server is able to indicate successful authentication in the Diameter command that contains the last EAP-Request. Requested change: Section 4.0 on page 20 reads: If the Result-Code AVP indicates success, the EAP-Payload AVP MUST encapsulate an EAP-Success [25] payload, and the NAS SHOULD successfully terminate the PPP authentication phase. Please replace that with: If the Result-Code AVP indicates success, the EAP-Payload AVP MUST encapsulate an EAP-Success or an EAP-Request [25] payload, and the NAS SHOULD successfully terminate the PPP authentication phase. Even if the payload encapsulates an EAP-Request, the authentication has been successful. In these cases, the NAS successfully terminates the PPP authentication phase by first sending the encapsulated EAP-Request to the authenticating peer. Then on receipt of the corresponding EAP-Response, the NAS SHOULD send an EAP-Success to the authenticating peer. The NAS MUST NOT send the last EAP-Response to the Diameter server but it MUST discard the EAP-Response. Please add a new item in the list of Section 4.2.1: 5) A Diameter-EAP-Answer containing an EAP-Request encapsulated within an EAP-Payload and a Result-Code indicating success. Please include EAP-Request in the explanations of the first paragraph of Section 4.2.2. Like this: The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code field set to 268 and the 'A' bit set in the message flags field, is sent by the Diameter server to the client to indicate either a successful or failed authentication. The Diameter-EAP-Answer message SHOULD include an EAP payload of type EAP-Success, EAP-Request or EAP-Failure encapsulated within an EAP-Payload AVP. The Result-Code AVP MUST indicate a failure if the EAP-Failure payload is present, while the AVP MUST indicate success if the EAP-Success or the EAP-Request payload is present. ==================================================================== Subject: [issue] Multi-roundtrip Mobile IP authentication Submitter name: Henry Haverinen Submitter email address: henry.haverinen@nokia.com Date first submitted: 2001-05-25 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00972.html Document: <MobileIP> Comment type: T Priority: 1 Section: 2.2 Rationale/Explanation of issue: Some authentication mechanisms may take more than one roundtrip to authenticate and authorize the user. An example of such a mechanism is draft-haverinen-mobileip-gsmsim-02.txt, but there may be others. This is not supported in the current Diameter Mobile IP draft. Requested change: These mechanisms can easily be supported in the Diameter Mobile IP draft if an unsuccessful AMA message can be used to convey authentication data to the MN in a key distribution extension. So please include the following text in Section 2.2: An unsuccessful AMA message MAY include mobile node registration key AVPs (Section 7.1) such as the MIP-MN-to-FA-Key AVP and the MIP-MN-to-HA-Key AVP. If such an AVP is present in the AMA message, then the foreign agent MUST include the corresponding Mobile IP key distribution extension in the Registration Reply it sends to the mobile node. This is to support multi-roundtrip authentication mechanisms. In addition, please include MIP-MN-to-FA-Key AVP in the AA-Mobile-Node-Answer message format definition. ==================================================================== Subject: [issue] What if the AAAL cannot reach the HA? Submitter name: Henry Haverinen Submitter email address: henry.haverinen@nokia.com Date first submitted: 2001-05-25 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00972.html Document: <MobileIP> Comment type: T Priority: 1 Section: 2.2 Rationale/Explanation of issue: The AAAL may not be able to reach the home agent the mobile node is using even if it was able to reach the AAAH. This may occur for example if the home agent was allocated from a previously visited network, or if the mobile node is authenticated and authorized using a local gateway to a back end AAA server (see draft-haverinen- mobileip-gsmsim-02.txt for an example). In these cases, the foreign agent needs to forward the Registration Request to the home agent itself. Requested change: Section 2.2 currently says: "A successful AMA message MUST include the MIP-Home-Agent-Address, MIP-Home-Mobile-Node-Address AVP and MIP-Reg-Reply AVPs." Please remove the MIP-Reg-Reply AVP from the list. In addition, please include the following text in Section 2.2: The AAAL may not always be able to reach the home agent even if was able to authenticate and authorize the mobile node. Therefore, if a successful AMA message does not include the MIP-Reg-Reply AVP, then then the foreign agent MUST relay the Registration Request in question to the home agent itself. An AMA message can only be successful and not include the MIP-Reg-Reply AVP if the Registration Request includes a Home Agent address and a Mobile-Home Authentication Extension. As required in [MIPv4 base document], the foreign agent must remove any Extensions following the Mobile-Home Authentication Extension before relaying the Request to the home agent. ==================================================================== From owner-aaa-bof@merit.edu Fri May 25 13:34:25 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21994 for <aaa-archive@odin.ietf.org>; Fri, 25 May 2001 13:34:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 607545E398; Fri, 25 May 2001 13:01:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C38545EA42; Fri, 25 May 2001 12:32:39 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id EA47A5DF93 for <aaa-wg@merit.edu>; Fri, 25 May 2001 12:07:35 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02293; Fri, 25 May 2001 09:07:04 -0700 (PDT) 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 JAA12274; Fri, 25 May 2001 09:06:16 -0700 (PDT) Received: from darius (darius [152.70.40.121]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA00339; Fri, 25 May 2001 09:06:14 -0700 (PDT) Date: Fri, 25 May 2001 09:06:14 -0700 (PDT) From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM> Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM> Subject: [AAA-WG]: RE: Diameter Proposed Changes To: henry.haverinen@nokia.com Cc: pcalhoun@nasnfs.Eng.Sun.COM, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <6D1A8E7871B9D211B3B00008C7490AA504E62689@treis03nok> Message-ID: <Roam.SIMC.2.0.6.990806774.6220.pcalhoun@nasnfs> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > > > May I kindly request that all proposed changes include an > > issue request, as we > > have been doing to track all issues. > > Pat, > > I apologize for my ignorance. Here are my issues re-formatted: The issues web page has been updated to include the issues you have submitted. Thanks for your cooperation, PatC From owner-aaa-bof@merit.edu Fri May 25 13:58:45 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22379 for <aaa-archive@odin.ietf.org>; Fri, 25 May 2001 13:58:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 778655DDFE; Fri, 25 May 2001 13:28:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9C8B75E06D; Fri, 25 May 2001 12:39:35 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 2272F5E059 for <aaa-wg@merit.edu>; Fri, 25 May 2001 12:18:50 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id JAA41804; Fri, 25 May 2001 09:09:15 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 25 May 2001 09:09:15 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: henry.haverinen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Another proposed change to Diameter NASREQ (EAP roundtrips) In-Reply-To: <6D1A8E7871B9D211B3B00008C7490AA504E62687@treis03nok> Message-ID: <Pine.BSF.4.21.0105250904360.41531-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk RFC 2284 indicates that EAP Success and EAP Failure message are unacknolwedged. Therefore there is no way for an EAP Response to be sent after that. Also note that RFC 2869 does *not* require that any EAP message be included in an Accept or Reject, or that the EAP Success or Failure indication be consistent with the Accept or Reject indication. This seems weird at first, but then you realize that often the EAP entity and AAA server are different pieces of code, and may take actions for different reasons. For example, the authentication may be ok, but policies are violated so that a Reject is sent. Or the authentication failed, but access is being authorized based on called or calling station id instead, so an Accept is sent. My answer to the situations where an EAP message isn't present, or disagrees with the Accept or Reject is for the NAS to *manufacture* an EAP-Success or Failure message rather than passing through what is in the encapsulated EAP message. That way the peer always gets a consistent view of the state of the conversation. On Fri, 25 May 2001 henry.haverinen@nokia.com wrote: > > Hi all, > > In some EAP types, the last EAP-Response from the authenticating > peer to the Diameter server is just an aknowledgement that doesn't contain > any actual data. In these cases, one NAS-AAA-NAS roundtrip can be > saved if the AAA server is able to indicate successful authentication > in the Diameter command that contains the last EAP-Request. > > So I'd like to propose the following changes in the > Diameter NASREQ draft: > > Section 4.0 on page 20 reads: > If the Result-Code AVP indicates success, > the EAP-Payload AVP MUST encapsulate an EAP-Success [25] payload, > and the NAS SHOULD successfully terminate the PPP authentication > phase. > > Please replace that with: > If the Result-Code AVP indicates success, the EAP-Payload AVP MUST > encapsulate an EAP-Success or an EAP-Request [25] payload, and the > NAS SHOULD successfully terminate the PPP authentication phase. > Even if the payload encapsulates an EAP-Request, the authentication > has been successful. In these cases, the NAS successfully terminates > the PPP authentication phase by first sending the encapsulated > EAP-Request > to the authenticating peer. Then on receipt of the corresponding > EAP-Response, > the NAS SHOULD send an EAP-Success to the authenticating peer. > The NAS MUST NOT send the last EAP-Response to the Diameter server > but it MUST discard the EAP-Response. > > Please add a new item in the list of Section 4.2.1: > > 5) A Diameter-EAP-Answer containing an EAP-Request encapsulated > within an EAP-Payload and a Result-Code indicating success. > > Please include EAP-Request in the explanations of the first paragraph > of Section 4.2.2. Like this: > > The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code > field set to 268 and the 'A' bit set in the message flags field, is > sent by the Diameter server to the client to indicate either a > successful or failed authentication. The Diameter-EAP-Answer message > SHOULD include an EAP payload of type EAP-Success, EAP-Request or > EAP-Failure encapsulated within an EAP-Payload AVP. The Result-Code AVP > MUST indicate a failure if the EAP-Failure payload is present, while the > AVP MUST indicate success if the EAP-Success or the EAP-Request payload > is present. > > From owner-aaa-bof@merit.edu Fri May 25 15:33:26 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23891 for <aaa-archive@odin.ietf.org>; Fri, 25 May 2001 15:33:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 20F4E5E477; Fri, 25 May 2001 13:48:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7C4A95E43E; Fri, 25 May 2001 13:17:38 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E28F95E0AC for <aaa-wg@merit.edu>; Fri, 25 May 2001 12:26:13 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id JAA41814; Fri, 25 May 2001 09:16:38 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 25 May 2001 09:16:38 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM> Cc: henry.haverinen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter Proposed Changes In-Reply-To: <Roam.SIMC.2.0.6.990803259.12169.pcalhoun@nasnfs> Message-ID: <Pine.BSF.4.21.0105250914240.41531-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Furthermore, I would like to remind everyone that we agreed at the Minn IETF > that we wouldn't accept new features. Please keep this in mind when requesting > new features, and provide the necessary justification for all new issues. > Actually, we agreed at IETF 50, not to accept *major* new functionality to the protocol. We can still accept changes at this point, but they need to make technical sense and be necessary. If there is WG consensus on both these points, then we will make the change. From owner-aaa-bof@merit.edu Fri May 25 18:19:42 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26322 for <aaa-archive@odin.ietf.org>; Fri, 25 May 2001 18:19:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 25CEA5E0E0; Fri, 25 May 2001 16:56:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DD86E5EC0C; Fri, 25 May 2001 15:56:59 -0400 (EDT) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 2886C5E433 for <aaa-wg@merit.edu>; Fri, 25 May 2001 14:10:26 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA21828; Fri, 25 May 2001 14:09:37 -0400 (EDT) Date: Fri, 25 May 2001 14:10:39 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Cc: Pat Calhoun <pcalhoun@diameter.org> Subject: [AAA-WG]: [issue] Destination-FQDN in re-auth Messages Message-ID: <Pine.GSO.4.21.0105251408010.28519-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk This issue was one of the issues that it was decided should be sent to the list for discussion. So enjoy... Submitter name: Mark Eklund Submitter email address: meklund@cisco.com Date first submitted: 25-May-2001 Reference: Document: Base Comment type: T Priority: 1 Section: Rationale/Explanation of issue: Note: The answer to this issue may be related to the answer for issue 26, "What to do if STR is sent to unavailable server" and issue 38, "Home should state whether the Destination-FQDN is present in follow-on messages" * When a Diameter server re-authorizes, the Destination-FQDN is optional. * There is no guidance as to how to use the Destination-FQDN. * There are two types of authentication realms: Simple: A simple realm where the servers are ignorant of each other. Re-authorization MUST go to the same server. Linked: A linked realm where the servers are knowledgeable of each other. Re-authorization MAY go to any of the servers in that realm. * There are two common causes of re-authorization Timeout: The Authorization-Lifetime may soon end and re-authorization is needed. Forced: A server sends a AA-Challenge-Ind * So the Destination-FQDN will be set according to the following situations: Simple-Timeout: Re-authorization MUST go to the same server that the previous authorization happened. Simple-Forced: If the previous authorization server and the sender of the Re-authorization are the same, send it to that server. If they are different, the re-authorization location has to be specified in the draft. Linked-Timeout: Either always use the Realm, or have a retry mechanism where it uses the previous authorization server and if that is unreachable, send to the Realm (no Destination-FQDN). Linked-Forced: Combine Simple-Forced and Linked-Forced * If you are using Destination-FQDN with re-authorization, and the server is down, do you send to the realm, assume Re-authorization was successful, or disconnect the user. Requested Change: Option 1: * Only allow Re-authorization in Linked realms. * Destination-FQDN if used must be that of the server used for the most recent authentication. Something like this text should be added. If re-authorization is required by the server because of Authorization-Lifetime timeout or an AA-Challenge-Ind, all servers in the authorization realm (not just the one that did the authorization of that session) MUST be capable of re-authorization. If the Destination-FQDN is included, it MUST contain the Origin-FQDN of the last server that authenticated the user. If the request returns with the error DIAMETER_UNABLE_TO_DELIVER, the client MAY re-send the AAR without a Destination-FQDN. Option 2: * Assume realms are not linked. Something like this text should be added. Re-authorization MUST use as the Destination-FQDN the Origin-FQDN of the server that authenticated the session. If the server is unreachable, the client MAY either assume authorization failure or success. If success is assumed, a Diameter client SHOULD NOT expect payment for services rendered past the session expiration time. Option 3: * Expect ignorance, and allow for enlightenment. Something like this text should be added. Re-authorization MUST first use as the Destination-FQDN the Origin-FQDN of the server that previously authorized the session. If the server is unreachable, the client MAY remove the Destination-FQDN and send the re-authorization request again. The servers in the realm MAY handle a re-authorization request of a session that they did not authenticate in any way (for example database lookup, always fail, always succeed, or any other method). Option 4: * A combination of 2 and 3 Something like this text should be added. Re-authorization MUST first use as the Destination-FQDN the Origin-FQDN of the server that previously authorized the session. If the server is unreachable, the client MAY fail the authentication, pass the authentication, or remove the Destination-FQDN and send the re-authorization request again. If success is assumed, a Diameter client SHOULD NOT expect payment for services rendered past the session expiration time. If the request is sent again, servers in the realm MAY handle a re-authorization request of a session that they did not authenticate in any way (for example database lookup, always fail, always succeed, or any other method). ==================================================================== From owner-aaa-bof@merit.edu Fri May 25 22:38:50 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00868 for <aaa-archive@odin.ietf.org>; Fri, 25 May 2001 22:38:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2D6885EE0F; Fri, 25 May 2001 20:05:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AC3AC5EFFC; Fri, 25 May 2001 18:38:03 -0400 (EDT) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 80D685EE67 for <aaa-wg@merit.edu>; Fri, 25 May 2001 17:06:09 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA23271; Fri, 25 May 2001 17:05:19 -0400 (EDT) Date: Fri, 25 May 2001 17:06:23 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Cc: Pat Calhoun <pcalhoun@diameter.org> Subject: [AAA-WG]: [issue] Support for multi-processes Message-ID: <Pine.GSO.4.21.0105251704430.28725-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Submitter name: Mark Eklund Submitter email address: meklund@cisco.com Date first submitted: 25-May-2001 Reference: Document: Base Comment type: T Priority: 1 Section: 8.0 Rationale/Explanation of issue: * Issue #6, "Server Identification" changes the FQDN to be an identifier that allows more than one copy of a Diameter server on a host. * If more than one server can exist on a platform, then you cannot do refuse a connection based on ip address. Requested change: Modify the Peer State Machine to not contain R-Snd-Conn-Nack. ==================================================================== From owner-aaa-bof@merit.edu Fri May 25 22:39:08 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00887 for <aaa-archive@odin.ietf.org>; Fri, 25 May 2001 22:39:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7E2FC5DF39; Fri, 25 May 2001 20:06:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 075985F165; Fri, 25 May 2001 18:38:29 -0400 (EDT) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 50E435DEA0 for <aaa-wg@merit.edu>; Fri, 25 May 2001 17:09:45 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA23318; Fri, 25 May 2001 17:08:56 -0400 (EDT) Date: Fri, 25 May 2001 17:09:59 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Cc: Pat Calhoun <pcalhoun@diameter.org> Subject: [AAA-WG]: [issue] What does "Snd-Conn-Nack" Mean? Message-ID: <Pine.GSO.4.21.0105251709260.28725-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Submitter name: Mark Eklund Submitter email address: meklund@cisco.com Date first submitted: 25-May-2001 Reference: Document: Base Comment type: T Priority: 1 Section: 8.0 Rationale/Explanation of issue: R-Send-Conn-NACK assumes that the application has the ability to refuse a connection before it is made. The UNIX select doesn't give this capability. The application is not informed until after the connection has been made. Modify the Peer State Machine to not contain R-Snd-Conn-Nack. ==================================================================== From owner-aaa-bof@merit.edu Sat May 26 20:09:01 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21644 for <aaa-archive@odin.ietf.org>; Sat, 26 May 2001 20:09:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 789905DD9A; Sat, 26 May 2001 20:08:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6526F5DDA2; Sat, 26 May 2001 20:08:51 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id ADF455DD9A for <aaa-wg@merit.edu>; Sat, 26 May 2001 20:08:49 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id TAA27660; Sat, 26 May 2001 19:59:53 -0400 (EDT) Message-Id: <4.1.20010526194114.01cbe630@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 26 May 2001 19:47:17 -0400 To: Pat Calhoun <pcalhoun@diameter.org>, aaa-wg@merit.edu From: Paul Funk <paul@funk.com> Subject: Re: [AAA-WG]: Proposed fixes for Issues 13, 18 and 30 In-Reply-To: <20010525052346.P30735@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, At 05:23 AM 5/25/01 -0700, Pat Calhoun wrote: > >Issue 18: Error-Reporting-FQDN was a dup of Origin-FQDN, and therefore MUST >only be included if a host is changing the result-code AVP, and is not the >one whose identity is in the Origin-FQDN. I may be misremembering, but I thought we concluded that we could eliminate Error-Reporting-FQDN entirely. If a proxy sets its own failure Result-Code, it is in effect taking responsibility for the response, and would set its own FQDN as Origin-FQDN. Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Sat May 26 21:06:35 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21787 for <aaa-archive@odin.ietf.org>; Sat, 26 May 2001 21:06:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 58EAA5DDAD; Sat, 26 May 2001 21:06:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 47FA05DDAC; Sat, 26 May 2001 21:06:37 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id B82865DDA3 for <aaa-wg@merit.edu>; Sat, 26 May 2001 21:06:35 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id UAA27707 for <aaa-wg@merit.edu>; Sat, 26 May 2001 20:58:11 -0400 (EDT) Message-Id: <4.1.20010526195627.01cc2a40@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 26 May 2001 20:45:35 -0400 To: aaa-wg@merit.edu From: Paul Funk <paul@funk.com> Subject: [AAA-WG]: [issue] Proposal to modify STI Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Submitter name: Paul Funk Submitter email address: paul@funk.com Date first submitted: May, 20001 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00881.html Document: Base Comment Type: Technical Priority: 1 Section: (throughout) Rationale/Explanation of issue: There is a desire to eliminate the STI message. Currently, a server that wishes to terminate a session requires 1.5 round trips (STI, STR, STA). Requested change: The conclusion at the interim meeting was that notification by the access device to the authorizing server that a session has ended (STR/STA) should be treated independently from a session management sort of request by some server (possibly the authorizing one) to the access device to abort the session (STI). In addition, since the interim meeting is proposing that one-way transactions (Indications) should be eliminated, the abort request would be two-way, i.e., Request/Answer, rather than STI. Other situations are also covered in the suggested language below, such as sessions that never start and proxy interceptions. Suggested language: 10.8 Session Termination It is necessary for a Diameter server that authorized a session to be notified when that session is no longer active, both for tracking purposes as well as to allow the Diameter server to release any resources that it may have provided for the user session. When a user session that required Diameter authorization terminates, the access device that provided the service MUST issue a Session-Termination- Request (STR) message to the Diameter server that authorized the service, to notify it that the session is no longer active. An STR MUST be issued when a user session terminates for any reason, including user logoff, expiration of Session-Timeout, administrative action, termination upon receipt of an Abort-Session-Request (see below), orderly shutdown of the access device, etc. The access device also MUST issue an STR for a session that was authorized but never actually started. This could occur, for example, due to a sudden resource shortage in the access device, or because the access device is unwilling to provide the type of service requested in the authorization, or because the access device does not support a mandatory AVP returned in the authorization, etc. It is also possible that a session that was authorized is never actually started due to action of a proxy. For example, a proxy may modify an authorization answer, converting the result from success to failure, prior to forwarding the message to the access device. A proxy that causes an authorized session not to be started MUST issue an STR to the Diameter server that authorized the session, since the access device has no way of knowing that the session had been authorized. A Diameter server that receives an STR message MUST clean up resources (e.g., session state) associated with the Session-Id specified in the STR, and return a Session-Termination-Answer. A Diameter server also MUST clean up resources when the Session- Timeout expires, or when the Authorization-Lifetime expires without re-authorization, regardless of whether an STR for that session is received. The access device is not expected to provide service beyond the expiration of these timers; thus, expiration of either of these timers implies that the access device may have unexpectedly shut down. 10.8.1 Session-Termination-Request The Session-Termination-Request (STR), indicated by the Command- Code set to 275 and the message flags' 'R' bit set, is sent by the access device to inform the Diameter Server that an authenticated and/or authorized session is being terminated. Message Format <Session-Termination-Request> ::= < Diameter Header: 275, R > < Session-Id > { Origin-FQDN } { Origin-Realm } { User-Name } { Destination-Realm } { Destination-FQDN } [ Max-Wait-Time ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] 10.8.2 Session-Termination-Answer The Session-Termination-Answer (STA), indicated by the Command- Code set to 275 and the message flags' 'R' bit clear, is sent by the Diameter Server to acknowledge the notification that the session has been terminated. The Result-Code AVP MUST be present, and MAY contain an indication that an error occurred while servicing the STR. Upon sending or receipt of the STA, the Diameter Server MUST 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. Message Format <Session-Termination-Answer> ::= < Diameter Header: 275 > < Session-Id > { Result-Code } { Origin-FQDN } { Origin-Realm } { Destination-FQDN } { User-Name } * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] 10.9 Aborting a Session A Diameter server may request that the access device stop providing service for a particular session by issuing an Abort-Session-Request (ASR). For example, the Diameter server that originally authorized the session may be required to cause that session to be stopped for credit or other reasons that were not anticipated when the session was first authorized. Or, an operator may maintain a management server for the purpose of issuing ASRs to administratively remove users from the network. An access device that receives an ASR with Session-ID equal to a currently active session MAY stop the session. Whether the access device stops the session or not is implementation- and/or configuration- dependent. For example, an access device may honor ASRs from certain servers only. In any case, the access device MUST respond with an Abort-Session-Answer, including a Result-Code AVP to indicate what action it took. Note that if the access device does stop the session upon receipt of an ASR, it issues an STR to the authorizing server (which may or may not be the server issuing the ASR) just as it would if the session were terminated for any other reason. 10.9.1 Abort-Session-Request The Abort-Session-Request (ASR), indicated by the Command-Code set to [nnn] and the message flags' 'R' bit set, may be sent by any server to the access device that is providing session service, to request that the session identified by the Session-Id be stopped. <Abort-Session-Request> ::= < Diameter Header: nnn, R > < Session-Id > { Origin-FQDN } { Origin-Realm } { Destination-Realm } { Destination-FQDN } * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] 10.9.2 Abort-Session-Answer The Abort-Session-Answer (ASA), indicated by the Command-Code set to [nnn] and the message flags' 'R' bit clear, is sent in response to the ASR. The Result-Code AVP MUST be present, and indicates the disposition of the request. If the session identified by Session-Id in the ASR was successfully terminated, Result-Code is set to DIAMETER_SUCCESS. If the session is not currently active, Result-Code is set to DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the session for any other reason, Result-Code is set to [what? should there be a generic failure result code?]. <Abort-Session-Answer> ::= < Diameter Header: nnn > < Session-Id > { Result-Code } { Origin-FQDN } { Origin-Realm } { Destination-FQDN } * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Sat May 26 21:39:18 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22808 for <aaa-archive@odin.ietf.org>; Sat, 26 May 2001 21:39:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E133A5DDA3; Sat, 26 May 2001 21:39:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CE9F05DDAC; Sat, 26 May 2001 21:39:19 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 582945DDA3 for <aaa-wg@merit.edu>; Sat, 26 May 2001 21:39:18 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id VAA27736 for <aaa-wg@merit.edu>; Sat, 26 May 2001 21:30:52 -0400 (EDT) Message-Id: <4.1.20010526210443.01ca09c0@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 26 May 2001 21:18:10 -0400 To: aaa-wg@merit.edu From: Paul Funk <paul@funk.com> Subject: [AAA-WG]: [issue] Increase randomness of Session-Id to 64 bits Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Submitter name: Paul Funk Submitter email address: paul@funk.com Date first submitted: May, 20001 Reference: Document: Base Comment Type: Technical Priority: ? Section: 10.3 Rationale/Explanation of issue: A 32 bit monotonically increasing value is not sufficient to guarantee uniqueness of Session-Id, especially if a starting value is randomly selected at startup. Also, Session-Id ought to be unique for longer than the lifetime of the session, since it will have to be used to match up historical authorization and accounting information. Requested change: Basically, make the monotonically increasing value 64 bits rather than 32 bits. Note that I went beyond what was discussed at the interim meeting in the language below, specifying that the FQDN part of Session-ID is a MUST, rather than a SHOULD. Session-Ids generated by different devices have to be distinguishable, hence the MUST. I also added semicolon delimiters, to guarantee that ambiguity cannot result from FQDN followed immediately by some numeric value. Suggested language: The Session-Id MUST be globally and eternally unique, as it is meant to uniquely identify a user session without reference to any other information, and may be needed to correlate historical authentication information with accounting information. The Session-Id includes a mandatory portion and an implementation-defined portion; a recommended format for the implementation-defined portion is outlined below. The Session-Id MUST begin with the client FQDN. If the client uses a non-standard authorization port, the FQDN MUST be followed by a colon (:) and the port number. The next character MUST be a semicolon (;). The remainder of the Session-Id MAY be any sequence that the client can guarantee to be eternally unique; however, the following format is recommended, (square brackets [] indicate an optional element): <client FQDN>[:<port>];<high 32 bits>;<low 32 bits>[;<optional value>] <high 32 bits> and <low 32 bits> are decimal representations of the high and low 32 bits of a monotonically increasing 64-bit value. The 64-bit value is rendered in two part to simplify formatting by 32-bit processors. At startup, the high 32 bits of the 64-bit value MAY be initialized to the time, and the low 32 bits MAY be initialized to 0. This will for practical purposes eliminate the possibility of overlapping Session-Ids after a reboot, assuming the reboot process takes longer than a second. Alternatively, an implementation MAY keep track of the increasing value in non-volatile memory. <optional value> is implementation specific but may include a modem's device Id, a layer 2 address, timestamp, etc. Example, in which the standard port is used and there is no optional value: accesspoint7.acme.com;1876543210;523 Example, in which a non-standard port is used and there is an optional value: accesspoint7.acme.com:831;1876543210;523;mobile@200.1.1.88 Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Sun May 27 14:39:29 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11365 for <aaa-archive@odin.ietf.org>; Sun, 27 May 2001 14:39:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9CD505DEAA; Sun, 27 May 2001 14:38:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 81C755DEB6; Sun, 27 May 2001 14:38:56 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 130895DEAA for <aaa-wg@merit.edu>; Sun, 27 May 2001 14:38:50 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id LAA46786; Sun, 27 May 2001 11:28:58 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Sun, 27 May 2001 11:28:58 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: henry.haverinen@nokia.com Cc: pcalhoun@nasnfs.Eng.Sun.COM, aaa-wg@merit.edu Subject: Re: [AAA-WG]: RE: Diameter Proposed Changes In-Reply-To: <6D1A8E7871B9D211B3B00008C7490AA504E62689@treis03nok> Message-ID: <Pine.BSF.4.21.0105271107050.46769-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk I think we are actually getting into some murky areas of RFC 2869 here, and the solution is *not* to specify behavior for Diameter alone, but to figure out what should happen and issue an RFC 2869bis, then have Diameter inherit the correct behavior. 1. If a AAA server an Accept message with an EAP-Message inside not corresponding to a Failure or Success, this implies that the user is to be let on. For PPP, RFC 2284 indicates that the peer is to be able to discern Failure or Success by alternate methods (seeing NCP packets as an indication of Success, receipt of an LCP-Terminate as an alternate indication of Failure). For 802.1X, these alternate mechanisms are not available so that a manufactured EAP-Success or EAP-Failure packet is sent instead. Note that this implies that the last encapsulated packet will actually not be sent to the peer. So in general, it seems to me that AAA servers terminating a AAA exchange this way will not be obtaining a guaranteed result. 2. Sending an EAP-Response after an EAP-Sucess message is illegal under RFC 2284, since Success messages are not ACK'd. This is what leads to the need for "alternate" indication methods in RFC 2284, and the issues described in #1. 3. EAP authentication does *not* terminate on receipt of an encapsulated EAP-Success/Failure message from the AAA server, but rather on receipt of an Accept/Reject indication. So if an EAP-Success/Failiure message is encapsulated in a Challenge rather than an Accept/Reject message, then authentication could continue, enabling more than one EAP method to be used for a given session. However, it is not clear to me how the two auth methods would be bridged within AAA, since there is no EAP-Response to be sent back to the AAA server as described above. The situation would be different if the other side initiated the second EAP conversation, since then the packet sent after an EAP-Success would be an EAP-Request. On Fri, 25 May 2001 henry.haverinen@nokia.com wrote: > > > > May I kindly request that all proposed changes include an > > issue request, as we > > have been doing to track all issues. > > Pat, > > I apologize for my ignorance. Here are my issues re-formatted: > > ========================================================================= > > Subject: [issue] EAP Roundtrips > > Submitter name: Henry Haverinen > Submitter email address: henry.haverinen@nokia.com > Date first submitted: 2001-05-25 > Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00974.html > Document: <NASREQ> > Comment type: T > Priority: 2 > Section: 4.0, 4.2.1, 4.2.2 > Rationale/Explanation of issue: > > This issue is an optimization. In some EAP types, the last EAP-Response > from the authenticating peer to the Diameter server is just an > aknowledgement > that doesn't contain any actual data. In these cases, one NAS-AAA-NAS > roundtrip > can be saved if the AAA server is able to indicate successful authentication > in the Diameter command that contains the last EAP-Request. > > Requested change: > > Section 4.0 on page 20 reads: > If the Result-Code AVP indicates success, > the EAP-Payload AVP MUST encapsulate an EAP-Success [25] payload, > and the NAS SHOULD successfully terminate the PPP authentication > phase. > > Please replace that with: > If the Result-Code AVP indicates success, the EAP-Payload AVP MUST > encapsulate an EAP-Success or an EAP-Request [25] payload, and the > NAS SHOULD successfully terminate the PPP authentication phase. > Even if the payload encapsulates an EAP-Request, the authentication > has been successful. In these cases, the NAS successfully terminates > the PPP authentication phase by first sending the encapsulated > EAP-Request > to the authenticating peer. Then on receipt of the corresponding > EAP-Response, > the NAS SHOULD send an EAP-Success to the authenticating peer. > The NAS MUST NOT send the last EAP-Response to the Diameter server > but it MUST discard the EAP-Response. > > Please add a new item in the list of Section 4.2.1: > > 5) A Diameter-EAP-Answer containing an EAP-Request encapsulated > within an EAP-Payload and a Result-Code indicating success. > > Please include EAP-Request in the explanations of the first paragraph > of Section 4.2.2. Like this: > > The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code > field set to 268 and the 'A' bit set in the message flags field, is > sent by the Diameter server to the client to indicate either a > successful or failed authentication. The Diameter-EAP-Answer message > SHOULD include an EAP payload of type EAP-Success, EAP-Request or > EAP-Failure encapsulated within an EAP-Payload AVP. The Result-Code AVP > MUST indicate a failure if the EAP-Failure payload is present, while the > AVP MUST indicate success if the EAP-Success or the EAP-Request payload > is present. > > ==================================================================== > > Subject: [issue] Multi-roundtrip Mobile IP authentication > > Submitter name: Henry Haverinen > Submitter email address: henry.haverinen@nokia.com > Date first submitted: 2001-05-25 > Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00972.html > Document: <MobileIP> > Comment type: T > Priority: 1 > Section: 2.2 > Rationale/Explanation of issue: > > Some authentication mechanisms may take more than one > roundtrip to authenticate and authorize the user. An example > of such a mechanism is draft-haverinen-mobileip-gsmsim-02.txt, > but there may be others. > This is not supported in the current Diameter Mobile IP draft. > > Requested change: > > > These mechanisms can easily be supported in the Diameter Mobile IP > draft if an unsuccessful AMA message can be used to convey authentication > data to the MN in a key distribution extension. So please > include the following text in Section 2.2: > > An unsuccessful AMA message MAY include mobile node registration > key AVPs (Section 7.1) such as the MIP-MN-to-FA-Key AVP and > the MIP-MN-to-HA-Key AVP. If such an AVP is present in the AMA message, > then the foreign agent MUST include the corresponding Mobile IP key > distribution extension in the Registration Reply it sends to > the mobile node. This is to support multi-roundtrip authentication > mechanisms. > > In addition, please include MIP-MN-to-FA-Key AVP in the > AA-Mobile-Node-Answer message format definition. > > > ==================================================================== > > Subject: [issue] What if the AAAL cannot reach the HA? > > Submitter name: Henry Haverinen > Submitter email address: henry.haverinen@nokia.com > Date first submitted: 2001-05-25 > Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00972.html > Document: <MobileIP> > Comment type: T > Priority: 1 > Section: 2.2 > Rationale/Explanation of issue: > > The AAAL may not be able to reach the home agent the mobile > node is using even if it was able to reach the AAAH. This may occur > for example if the home agent was allocated from a previously visited > network, or if the mobile node is authenticated and authorized using > a local gateway to a back end AAA server (see draft-haverinen- > mobileip-gsmsim-02.txt for an example). In these cases, the foreign > agent needs to forward the Registration Request to the home agent > itself. > > Requested change: > > > Section 2.2 currently says: "A successful AMA message MUST include > the MIP-Home-Agent-Address, MIP-Home-Mobile-Node-Address AVP and > MIP-Reg-Reply AVPs." Please remove the MIP-Reg-Reply AVP from the list. > In addition, please include the following text in Section 2.2: > > The AAAL may not always be able to reach the home agent even if was able > to authenticate and authorize the mobile node. Therefore, if a successful > > AMA message does not include the MIP-Reg-Reply AVP, then then the foreign > > agent MUST relay the Registration Request in question to the home agent > itself. An AMA message can only be successful and not include > the MIP-Reg-Reply AVP if the Registration Request includes a Home Agent > address and a Mobile-Home Authentication Extension. As required in > [MIPv4 base document], the foreign agent must remove any Extensions > following the Mobile-Home Authentication Extension before relaying > the Request to the home agent. > > ==================================================================== > > From owner-aaa-bof@merit.edu Sun May 27 22:03:18 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13884 for <aaa-archive@odin.ietf.org>; Sun, 27 May 2001 22:03:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 520D65DFF4; Sun, 27 May 2001 22:01:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 04A165E010; Sun, 27 May 2001 22:01:15 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 6105A5DFC5 for <aaa-wg@merit.edu>; Sun, 27 May 2001 22:00:29 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id VAA28639 for <aaa-wg@merit.edu>; Sun, 27 May 2001 21:52:03 -0400 (EDT) Message-Id: <4.1.20010527212341.01cc9560@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 27 May 2001 21:39:27 -0400 To: aaa-wg@merit.edu From: Paul Funk <paul@funk.com> Subject: [AAA-WG]: [issue] Boot-Id Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Submitter name: Paul Funk Submitter email address: paul@funk.com Date first submitted: May, 20001 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00135.html Document: Base Comment Type: Technical Priority: 1 or 2 (?) Section: Somewhere in section 6 Rationale/Explanation of issue: Servers need to know if a NAS has rebooted, to be able to clean up state. A new connection is not necessarily and indication of reboot, since it could be a reconnect after a connection was broken. Requested change: The interim group felt that, of the three proposals in the foot-fetish thread, Paul's and Pat's should be adopted. Briefly, a Boot-Id is passed in DRI to allow a server to determine when a peer has rebooted, and Boot-Id is also passed in other messages, to allow downstream servers more than one hop away to glean this information. Randy suggested that the name of the AVP be changed from Boot-Id to State-Id, since a server may retain state across reboots. Therefore, a new id is really indicative of fresh state. I suggest we in fact call it Origin-State-Id, to emphasize its relationship to Origin-FQDN. Origin-State-Id will have to be added to the ABNF for DRI as well as all other messages, as an optional AVP. Suggested language: [add the following somewhere in the DRI section:] Origin-State-Id AVP The Origin-State-Id AVP (AVP Code ?), of type Unsigned32, is a monotonically increasing value that is advanced whenever a Diameter entity restarts with loss of previous state, for example upon reboot. Origin-State-Id MAY be included in any Diameter message, including DRI. A Diameter entity issuing this AVP MUST create a higher value for this AVP each time its state is reset. A Diameter entity MAY set Origin-State-Id to the time of startup, or it MAY use an incrementing counter retained in non-volatile memory across restarts. The Origin-State-Id, if present, MUST reflect the state of the entity indicated by Origin-FQDN. If a proxy modifies Origin-FQDN, it MUST either remove Origin-State-Id or modify it appropriately as well. Typically, Origin-State-Id is used by an access device that always starts up with no active sessions; that is, any session active prior to restart will have been been lost. By including Origin-State-Id in a message, it allows other Diameter entities to infer that sessions associated with a lower Origin-State-Id are no longer active. If an access device does not intend for such inferences to be made, it MUST either not include Origin-FQDN in any message, or set its value to 0. [add the following to the Session Termination section:] 10.10 Inferring Session Termination from Origin-State-Id Origin-State-Id is used to allow rapid detection of terminated sessions for which no STR would have been issued, due to unanticipated shutdown of an access device. By including Origin-State-Id in DRI messages, an access device allows a next-hop server to determine immediately upon connection whether the device has lost its sessions since the last connection. By including Origin-State-Id in request messages, an access device also allows a server with which it communicates via proxy to make such a determination. However, a server that is not directly connected with the access device will not discover that the access device has been restarted unless and until it receives a new request from the access device. Thus, use of this mechanism across proxies is opportunistic rather than reliable, but useful nonetheless. When a Diameter server receives a Origin-State-Id that is greater than the Origin-State-Id previously received from the same issuer, it may assume that the issuer has lost state since the previous message and that all sessions that were active under the lower Origin-State-Id have been terminated. The Diameter server MAY clean up all session state associated with such lost sessions, and MAY also issues STRs for all such lost sessions that were authorized on downstream servers, to allow session state to be cleaned up globally. Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Sun May 27 22:17:18 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13938 for <aaa-archive@odin.ietf.org>; Sun, 27 May 2001 22:17:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CE0FB5DEC6; Sun, 27 May 2001 22:16:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BC75B5DEC5; Sun, 27 May 2001 22:16:56 -0400 (EDT) Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 363655DE16 for <aaa-wg@merit.edu>; Sun, 27 May 2001 22:16:55 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id WAA28656 for <aaa-wg@merit.edu>; Sun, 27 May 2001 22:08:32 -0400 (EDT) Message-Id: <4.1.20010527215226.01ccc2a0@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 27 May 2001 21:55:51 -0400 To: aaa-wg@merit.edu From: Paul Funk <paul@funk.com> Subject: [AAA-WG]: [issue] Make AVP Header consistent with Message Header Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_721322857==_.ALT" Sender: owner-aaa-bof@merit.edu Precedence: bulk --=====================_721322857==_.ALT Content-Type: text/plain; charset="us-ascii" Submitter name: Paul Funk Submitter email address: paul@funk.com Date first submitted: May, 20001 Reference: Document: Base Comment Type: Technical Priority: 2 Section: 4.1 Rationale/Explanation of issue: As long as we have 24 bit message length, how about 24 bit AVP length, with similar positioning of length in low order bits? Requested change: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V|M|P| Reserved| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com --=====================_721322857==_.ALT Content-Type: text/html; charset="us-ascii" <html> Submitter name: Paul Funk <br> Submitter email address: paul@funk.com <br> Date first submitted: May, 20001 <br> Reference:<br> Document: Base <br> Comment Type: Technical <br> Priority: 2 <br> Section: 4.1<br> Rationale/Explanation of issue: <br> As long as we have 24 bit message length, how about 24 bit AVP length, <br> with similar positioning of length in low order bits?<br> <br> Requested change:<br>  <br> <tt>       0                   1                   2                   3<br>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<br>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>       |                           AVP Code                            |<br>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>       |V|M|P| Reserved|                 AVP Length                    |<br>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>       |                        Vendor-ID (opt)                        |<br>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>       |    Data ...<br>       +-+-+-+-+-+-+-+-+<br> <br> </tt>Paul<br> <br> <div>Paul Funk</div> <div>Funk Software, Inc.</div> <div>617 497-6339</div> <div>paul@funk.com</div> </html> --=====================_721322857==_.ALT-- From owner-aaa-bof@merit.edu Mon May 28 00:03:18 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16000 for <aaa-archive@odin.ietf.org>; Mon, 28 May 2001 00:03:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D12795DDE9; Mon, 28 May 2001 00:03:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AB53E5DE16; Mon, 28 May 2001 00:03:10 -0400 (EDT) Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by segue.merit.edu (Postfix) with ESMTP id E65885DDE9 for <aaa-wg@merit.edu>; Mon, 28 May 2001 00:03:07 -0400 (EDT) Received: (from barney@localhost) by tp.databus.com (8.11.3/8.11.3) id f4S432936314; Mon, 28 May 2001 00:03:02 -0400 (EDT) (envelope-from barney) Date: Mon, 28 May 2001 00:02:57 -0400 From: Barney Wolff <barney@databus.com> To: Paul Funk <paul@funk.com> Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Boot-Id Message-ID: <20010528000257.A36174@tp.databus.com> References: <4.1.20010527212341.01cc9560@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010527212341.01cc9560@cairo.funk.com>; from paul@funk.com on Sun, May 27, 2001 at 09:39:27PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk The idea of a state-id has some merit, but (as I always seem to) I protest against over-determination. There is no actual need for a monotonic value. All that's required is a value that does not duplicate any value used within the "recent" past. A 32-bit pseudo-random number would do perfectly well. My problem with using the boot time as the state-id is that it is not well defined until an interaction with some timeserver has completed. A boot counter kept in nvram is problematic when hardware is replaced. The requirement that if Origin-FQDN is changed that state-id be changed does not seem to make any sense: state-id is not required to be unique across different origin devices. Barney Wolff From owner-aaa-bof@merit.edu Mon May 28 02:21:53 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28715 for <aaa-archive@odin.ietf.org>; Mon, 28 May 2001 02:21:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DE0925DE57; Mon, 28 May 2001 02:21:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CA0BB5DE5A; Mon, 28 May 2001 02:21:55 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E62165DE57 for <aaa-wg@merit.edu>; Mon, 28 May 2001 02:21:53 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id XAA47313; Sun, 27 May 2001 23:11:59 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Sun, 27 May 2001 23:11:59 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: Paul Funk <paul@funk.com> Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Make AVP Header consistent with Message Header In-Reply-To: <4.1.20010527215226.01ccc2a0@cairo.funk.com> Message-ID: <Pine.BSF.4.21.0105272309200.47301-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk The 32-bit length field always did seem somewhat excessive. Thanks for raising this issue. BTW, did you see Christian Huitemas suggestions somewhat along the same lines? On Sun, 27 May 2001, Paul Funk wrote: > Submitter name: Paul Funk > Submitter email address: paul@funk.com > Date first submitted: May, 20001 > Reference: > Document: Base > Comment Type: Technical > Priority: 2 > Section: 4.1 > Rationale/Explanation of issue: > As long as we have 24 bit message length, how about 24 bit AVP length, > with similar positioning of length in low order bits? > > Requested change: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AVP Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |V|M|P| Reserved| AVP Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor-ID (opt) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data ... > +-+-+-+-+-+-+-+-+ > > Paul > > Paul Funk > Funk Software, Inc. > 617 497-6339 > paul@funk.com > From owner-aaa-bof@merit.edu Mon May 28 03:43:24 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01872 for <aaa-archive@odin.ietf.org>; Mon, 28 May 2001 03:43:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 95B7A5DE37; Mon, 28 May 2001 03:40:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6D7215DE2C; Mon, 28 May 2001 03:40:39 -0400 (EDT) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by segue.merit.edu (Postfix) with ESMTP id A2E805DE5F for <aaa-wg@merit.edu>; Mon, 28 May 2001 03:40:28 -0400 (EDT) Received: from kolumbus.fi (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 392C76A901; Mon, 28 May 2001 10:39:44 +0300 (EEST) Message-ID: <3B120184.5050203@kolumbus.fi> Date: Mon, 28 May 2001 10:43:00 +0300 From: Jari Arkko <jari.arkko@kolumbus.fi> User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-ipsec i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: "Yolanda Garcia-Serrano (ECE)" <yolanda.garcia-serrano@ece.ericsson.se> Cc: "'pcalhoun@diameter.org'" <pcalhoun@diameter.org>, "'aaa-wg@merit.edu'" <aaa-wg@merit.edu> Subject: Re: [AAA-WG]: Accounting clarifications References: <577066326047D41180AC00508B955DDA02C009F9@eestqnt104.es.eu.ericsson.se> 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 Replying to an old e-mail on accounting issues, hope this helps: Yolanda Garcia-Serrano (ECE) wrote: > 12.5. Accounting-Records > What can be exactly an accounted service? Is it an extension (Mobile IP, NASREQ), or is it indicated > by Service-Type AVP in NASREQ, but in Mobile IP which is the service/s? Could be the text more specific, > giving some examples? This was already discussed earlier on the list. In general the service could be anything, and the included AVPs must specify what service was provided. What AVPs are used for this specification is service-specific. > 14.1 Accounting-Record-Type > Are EVENT_RECORDs (one-time events) and START-STOP records mutually exclusive for the same > Session-Id, i.e. if received an event record for sessionId=x.abc.com:8888:1234567890 is/is not possible > to receive a Start/interim/stop one for same sessionId=x.abc.com:8888:1234567890 ? I think we should have just one submitted event or start-stop for one session-id. There is definately sometimes a need to correlate several records related to the same true user session. However, at a diameter level this is often not possible. Rather, such coordination should be left up to the postprocessing systems. For instance, one box could be delivering NASREQ data, including the user's IP address while another box might be providing some additional service. Both records would contain IP addresses which would help the postprocessing systems in correlating the records even if they came from two different boxes. And as you indicate below, there is a need to clarify this text in the draft. I propose that we add a statement to the explanation of the session id AVP that prohibits the submission of several sessions with the same session id, and says that the type of the session must be one of event or start-interim-stop for a particular session id. > > Is the type or record (EVENT vs START/INTERIM/STOP) tight to the particular kind of service, so that > when some services are used, it is reported accounted info of kind EVENT, and when some other services > are used, it is reported accounted info in the style Start/Interim/Stop ? This should be dictated by the text appearing in a particular extension document. > > Is it possible to send (Diameter client)/receive (Accounting server) several EVENT_RECORD for the same > Session-Id? > > Same question but for measurable length services: is it possible to send/receive several START-STOP > sequences for the same Session-Id? For both, see above. > > For the answer of all these questions, could be added the corresponding clarifying text on the I-D? > It would be quite helpful. I agree. Jari From owner-aaa-bof@merit.edu Mon May 28 05:00:28 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02376 for <aaa-archive@odin.ietf.org>; Mon, 28 May 2001 05:00:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7B4545DF9F; Mon, 28 May 2001 04:42:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4E1EA5DF9E; Mon, 28 May 2001 04:42:21 -0400 (EDT) Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id F3E645DF88 for <aaa-wg@merit.edu>; Mon, 28 May 2001 04:42:13 -0400 (EDT) Received: from fredrikj (c42.local.ipunplugged.com [192.168.4.241]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA09684; Mon, 28 May 2001 10:42:35 +0200 From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com> To: "Pat Calhoun" <pcalhoun@diameter.org>, <aaa-wg@merit.edu> Subject: RE: [AAA-WG]: Proposed fixes for Issues 13, 18 and 30 Date: Mon, 28 May 2001 10:43:50 +0200 Message-ID: <MJEMJBGGCLLDLFFAHLJKEELJCPAA.fredrik.johansson@ipunplugged.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20010525052346.P30735@charizard.diameter.org> Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Looks good to me, just two small questions/clarifications (see below). /Fredrik >-----Original Message----- >From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf >Of Pat Calhoun >Sent: den 25 maj 2001 14:24 >To: aaa-wg@merit.edu >Subject: [AAA-WG]: Proposed fixes for Issues 13, 18 and 30 > > >All, > >Below is the new text for section 9, which attempts to address the issues >mentioned above. I would appreciate some feedback from folks on whether the >text is consistent with their understanding of the outcome of the Interim >meeting. > >Actual fixes: > >Issue 13: DSI is removed, and a new answer only message is used to report >protocol errors. Protocol errors MAY be treated at each hop. The DSI-Events >are moved to a new class within the Result-Code AVP. > >Issue 18: Error-Reporting-FQDN was a dup of Origin-FQDN, and therefore MUST >only be included if a host is changing the result-code AVP, and is not the >one whose identity is in the Origin-FQDN. > >Issue 30: Failed-AVP should be a grouped AVP, and include the offending AVP >in it's group. > >Thanks, > >PatC >---- >9.0 Error Handling > > There are two different types of errors in Diameter; protocol and > extensions. A protocol error is one that occurs at the base protocol > level, and MAY require attention at each hop in a proxy environment > (e.g. message routing error). Extension errors, on the other hand, > are generally occur due to a problem with a function specified in a > Diameter extension(e.g. user authentication, Missing AVP). > > Result-Code AVP values that are used to report protocol errors MUST > be used in the Message-Reject-Answer command. Unlike most Diameter > commands, the Message-Reject-Answer does not have a corresponding > request. > > When a request message is received that causes a protocol error, the > command code is changed to Message-Reject-Answer, and the Result-Code > AVP is set to the appropriate protocol error value. As the answer is > sent back towards the originator of the request, each proxy MAY take > action on the message. > > > > > > > > > > > > > > >Calhoun et al. expires October 2001 [Page 41] > > > > > >Internet-Draft May 2001 > > > 1. Request +---------+ Link Broken > +-------------------------->|Diameter |----///----+ > | +---------------------| | v > +------+--+ | 2. MRA | Proxy 2 | +--------+ > |Diameter |<-+ (Unable to Forward) +---------+ |Diameter| > | | | Home | > | Proxy 1 |--+ +---------+ | Server | > +---------+ | 3. Request |Diameter | +--------+ > +-------------------->| | ^ > | Proxy 3 |-----------+ > +---------+ > Figure 1 - Example of Protocol Error causing MRA message > > Figure 1 provides an example of a message sent by a Diameter proxy > towards a home server. When the message is received by Proxy 2, and > it detects that it cannot forward the request to the home server, an > MRA message is returned with the Result-Code AVP set to > DIAMETER_UNABLE_TO_DELIVER. Given that this error falls within the > protocol error category, Proxy 1 would take special action, and given > the error, attempt to route the message through its alternate proxy > 3. > > +---------+ 1. Request +---------+ 2. Request +---------+ > | Access |------------>|Diameter |------------>|Diameter | > | | | | | Home | > | Device |<------------| Proxy |<------------| Server | > +---------+ 4. Answer +---------+ 3. Answer +---------+ > (Missing AVP) (Missing AVP) > Figure 2 - Example of Extension Error Answer message > > Figure 2 provides an example of a Diameter message that caused an > extension error. When extension errors occur, the Diameter entity > reporting the error clears the 'R' bit in the Command Flags, and adds Is there realy a 'R'-bit in the cmd flags? See Mark's mail titled "Make FAIR flags a part of Command-Code" > the Result-Code AVP with the proper value. Extension errors do not > require any proxy involvement, and therefore the message would be > forwarded back to the originator of the request. > > There are certain Result-Code AVP extensions errors that require > additional AVPs to be present in the answer, such as: > > - An unrecognized AVP is received with the 'M' bit (Mandatory bit) > set, causes an answer to be sent with the Result-Code AVP set to > DIAMETER_AVP_UNSUPPORTED, and the Failed-AVP AVP containing the > offending AVP. > - An AVP that is received with an unrecognized value causes an > answer to be returned with the Result-Code AVP set to > DIAMETER_INVALID_AVP_VALUE, with the Failed-AVP AVP containing > the AVP causing the error. > > > >Calhoun et al. expires October 2001 [Page 42] > > > > > >Internet-Draft May 2001 > > > - A command is received with an AVP that is ommitted, yet is > mandatory according to the command's ABNF. The receiver issues > an answer with the Result-Code set to DIAMETER_MISSING_AVP, and > creates an AVP with the AVP Code and other fields set to the > missing AVP's. The created AVP is then added to the Failed-AVP > AVP. > > The Result-Code AVP contains additional errors conditions, and > defines the expected behavior of each. > > >9.1 Result-Code AVP > > The Result-Code AVP (AVP Code 268) is of type Unsigned32 and > indicates whether a particular request was completed successfully or > whether an error occurred. All Diameter answer messages MUST include > one Result-Code AVP. A non-successful Result-Code AVP (one containing > a non 2xxx value) MUST include the Error-Reporting-Host AVP if the > host setting the Result-Code AVP is different from the identity > encoded in the Origin-Host AVP. > > The Result-Code data field contains an IANA-managed 32-bit address > space representing errors (see section 16.4). Diameter provides the > following classes of errors, all identified by the thousands digit: > - 1xxx (Informational) > - 2xxx (Success) > - 3xxx (Protocol Errors) > - 4xxx (Transient Failures) > - 5xxx (Permanent Failure) > > A non-recognize class (one whose first digit is not defined in this > section) MUST be handled as a permanent failure. > > >9.1.1 Informational > > Errors that fall within the Informational category are used to inform > a requester that the request cannot be immediately satisfied and a > further response will be issued in the near future. There are > currently no errors that fall within this class. > > >9.1.2 Success > > Errors that fall within the Success category are used to inform a > peer that a request has been successfully completed. > > DIAMETER_SUCCESS 2001 > > > >Calhoun et al. expires October 2001 [Page 43] > > > > > >Internet-Draft May 2001 > > > The Request was successfully completed. > > >9.1.3 Protocol Errors > > Errors that fall within the Protocol Error category SHOULD be treated > on a per-hop basis, and Diameter proxies MAY attempt to correct the > error, if it is possible. Note that these errors MUST only be used in > the Message-Rejected-Answer message, therefore a Diameter entity that > wishes to return an error in this category MUST change the command > code to Message-Rejected-Answer message. > > DIAMETER_INVALID_ROUTE_RECORD 3001 > The last Route-Record AVP in the message is not set to the > identity of the sender of the message. See Section 11.0 for > more information. > > DIAMETER_COMMAND_UNSUPPORTED 3002 > The Request contained a Command-Code that the receiver did not > recognize or support. > > DIAMETER_UNABLE_TO_DELIVER 3003 > The request could not be delivered to a host that handles the > realm, and extension, requested at this time. > > DIAMETER_REALM_NOT_SERVED 3004 > The intended realm of the offending message is unknown. > > DIAMETER_TOO_BUSY 3005 > When returned, a Diameter node SHOULD attempt to sent the > message to an alternate peer. > > DIAMETER_INVALID_CMS_DATA 3006 > The Request did not contain a valid CMS-Data [11] AVP. > > DIAMETER_LOOP_DETECTED 3007 > A Proxy or Redirect server detected a loop while trying to get > the message to the Home Diameter server. The message MAY be > sent to an alternate peer, if one is available, but the peer > reporting the error has identified a configuration problem. > > DIAMETER_END_2_END_SECURITY 3008 > A proxy has detected that end-to-end security has been applied > to portions of the Diameter message, and the proxy does not > allow this security mode since it needs to alter the message by > applying some local policies. > > > > > >Calhoun et al. expires October 2001 [Page 44] > > > > > >Internet-Draft May 2001 > > >9.1.4 Transient Failures > > Errors that fall within the transient failures category are used to > inform a peer that the request could not be satisfied at the time it > was received, but MAY be able to satisfy the request in the future. > > DIAMETER_AUTHENTICATION_REJECTED 4001 > The authentication process for the user failed, most likely due > to an invalid password used by the user. Further attempts MUST > only be tried after prompting the user for a new password. > > DIAMETER_OUT_OF_SPACE 4002 > A Diameter node received the accounting request but was unable > to commit it to stable storage due to a temporary lack of > space. > > >9.1.5 Permanent Failures > > Errors that fall within the permanent failures category are used to > inform the peer that the request failed, and should not be attempted > again. > > DIAMETER_USER_UNKNOWN 5001 > A request was received for a user that is unknown, therefore > authentication and/or authorization failed. > > DIAMETER_AVP_UNSUPPORTED 5002 > The peer received a message that contained an AVP that is not > recognized or supported and was marked with the Mandatory bit. > A Diameter message with this error MUST contain one or more > Failed-AVP AVP containing the AVPs that caused the failure. > > DIAMETER_UNKNOWN_SESSION_ID 5003 > The request contained an unknown Session-Id. > > DIAMETER_AUTHORIZATION_REJECTED 5004 > A request was received for which the user could not be > authorized. This error could occur if the service requested is > not permitted to the user. > > DIAMETER_INVALID_AVP_VALUE 5005 > The request contained an AVP with an invalid value in its data > portion. A Diameter message indicating this error MUST include > the offending AVPs within a Failed-AVP AVP. > > DIAMETER_MISSING_AVP 5006 > The request did not contain an AVP that is required by the > > > >Calhoun et al. expires October 2001 [Page 45] > > > > > >Internet-Draft May 2001 > > > Command Code definition. If this value is sent in the Result- > Code AVP, a Failed-AVP AVP SHOULD be included in the message. > The data portion of the Failed-AVP MUST contain an AVP header > containing the AVP Code and vendor-Id. > > DIAMETER_AUTHORIZATION_FAILED 5007 > A request was received for which the user could not be > authorized at this time. This error could occur when the user > has already expended allowed resources, or is only permitted to > access services within a time period. > > DIAMETER_CONTRADICTING_AVPS 5008 > The Home Diameter server has detected AVPs in the request that > contradicted each other, and is not willing to provide service > to the user. One or more Failed-AVP AVPs MUST be present, > containing the AVPs that contradicted each other. > > DIAMETER_AVP_NOT_ALLOWED 5009 > A message was received with an AVP that MUST NOT be present. > The Failed-AVP AVP MUST be included and contain the AVP Code of > the offending AVP. > > DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5010 > A message was received that included an AVP that appeared more > often than permitted in the message definition. The Failed-AVP > AVP MUST be included and contain the AVP Code of the offending > AVP. > > DIAMETER_VENDOR_ID_UNSUPPORTED 5011 > The Home Diameter server has detected vendor-specific AVPs in > the message, and the vendor dictionary is not supported. One or > more Failed-AVP MUST be present, containing the offending AVPs. > > DIAMETER_UNSUPPORTED_TRANSFORM 5012 > A message was received that included an CMS-Data AVP [11] that > made use of an unsupported transform. > > DIAMETER_NO_COMMON_EXTENSION 5013 > This event is returned when a DRA message is received, and > there are no common extensions supported between the peer. > > DIAMETER_UNSUPPORTED_VERSION 5014 > This event is returned when a DRA message is received, and the > Diameter message is unsupported. > > >9.2 Message-Reject-Answer > > > > >Calhoun et al. expires October 2001 [Page 46] > > > > > >Internet-Draft May 2001 > > > The Message-Reject-Answer (MRA), indicated by the Command-Code set to > 282, and the Command Flags' 'R' bit cleared, is sent in response to a > request that has caused a protocol error. > > Although the command code is different from the one found in the > request, the same procedures used in issuing an answer message is > followed. The Result-Code AVP MUST be present, and include a value in > the "Protocol Error" category. > > Proxies receiving an MRA message MAY attempt to rectify the error > reported, if possible. In the event that no proxy is able to correct > the problem, the MRA will be returned to the originator of the > request message. > > Message Format > > <Message-Reject-Answer> ::= < Diameter Header: 282, I > > < Session-Id > > { Origin-Host } > { Origin-Realm } > { Result-Code } > { Destination-Host } > * [ AVP ] > > >9.3 Error-Message AVP > > The Error-Message AVP (AVP Code 281) is of type OctetString. It is a > human readable UTF-8 character encoded string. It MAY accompany a > Result-Code AVP as a human readable error message. The Error-Message > AVP is not intended to be useful in real-time, and SHOULD NOT be > expected to be parsed by network entities. > > >9.4 Error-Reporting-Host AVP > > The Error-Reporting-Host AVP (AVP Code 294) is of type OctetString, > encoded in the UTF-8 [24] format, according to the Diameter identity > rules defined in section 2.6. This AVP contains the identity of the > Diameter host that set the Result-Code AVP to a value other than 2001 > (Success), only if the host setting the Result-Code is different from > the one encoded in the Origin-Host AVP. This AVP is intended to be > used for troubleshooting purposes, and MUST be set when the Result- > Code AVP indicates a failure. > > >9.5 Failed-AVP AVP > > > > >Calhoun et al. expires October 2001 [Page 47] > > > > > >Internet-Draft May 2001 > > > The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides > debugging information in cases where a request is rejected or not > fully processed due to erroneous information in a specific AVP. The > value of the Result-Code AVP will provide information on the reason > for the Failed-AVP AVP. > > The possible reasons for this AVP are the presence of an improperly > constructed AVP, an unsupported or unrecognized AVP, an invalid AVP > value, the omission of a required AVP, the presence of an explicitly > excluded AVP (see table 13.0), or the presence of two or more > occurrences of an AVP which table 15.1 restricts to 0, 1, or 0-1 > occurrences. > > A Diameter message MAY contain one Failed-AVP AVP, containing the > entire AVP that could not be processed successfully. If the failure > reason is omission of a required AVP, an AVP with the missing AVP > code, the missing vendor id, and a zero filled payload of the minimum > required length for the ommitted AVP will be added. > Does a zero filled payload of the minimum length mean that a octetstring has a payload of 1 byte. The AVP is then padded to be 32bit aligned. > AVP Format > > <Failed-AVP> ::= < AVP Header: 279 > > 1* {AVP} From owner-aaa-bof@merit.edu Mon May 28 05:37:03 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02575 for <aaa-archive@odin.ietf.org>; Mon, 28 May 2001 05:37:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6967E5DDE1; Mon, 28 May 2001 05:37:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4B1645DE21; Mon, 28 May 2001 05:37:06 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 34A215DDE1 for <aaa-wg@merit.edu>; Mon, 28 May 2001 05:37:04 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4S9cmh02460 for <aaa-wg@merit.edu>; Mon, 28 May 2001 12:38:48 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <T53cbcbd0d7ac158f24077@esvir04nok.ntc.nokia.com>; Mon, 28 May 2001 12:36:57 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <J4JGDWFD>; Mon, 28 May 2001 12:36:57 +0300 Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E6268A@treis03nok> From: henry.haverinen@nokia.com To: aboba@internaut.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Another proposed change to Diameter NASREQ (EAP rou ndtrips) Date: Mon, 28 May 2001 12:36:52 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hello Bernard, > RFC 2284 indicates that EAP Success and EAP Failure message are > unacknolwedged. Therefore there is no way for an EAP Response > to be sent > after that. I didn't mean that. My intention was to fix the fact that an EAP-Success packet cannot contain any data by sending that data in an EAP-Request. There could be better ways to fix this, such as issuing RFC2284bis which would support acknowledged EAP Success with encapsulated data. Consider the following snippet of an EAP authentication: Peer NAS AAA Server ... EAP-Response/X ---------------> DER: EAP-Response/X ---------------> The response is OK, and the peer has been authenticated. Now the AAA needs to transmit session key data or other "auxiliary" data to the peer within an EAP-Request: DEI: EAP-Request/X EAP-Request/X <--------------- <--------------- EAP-Response/X (empty) ---------------> DER: EAP-Response/X (empty) ---------------> DEA: EAP-Success EAP-Success <--------------- <--------------- Here the last EAP-response is empty (it is just an acknowledgement) and the last NAS-AAA-NAS roundtrip is unnecessary and it could be avoided if the session key or other auxiliary data could be included in the EAP-Success. If we don't want to change EAP, then we could fix this by encapsulating an EAP-Request in a DEA message: Peer NAS AAA Server ... EAP-Response/X ---------------> DER: EAP-Response/X ---------------> The response is OK, and the peer has been authenticated. Now the AAA needs to transmit session key data or other "auxiliary" data to the peer within an EAP-Request: DEA: EAP-Request/X EAP-Request/X <--------------- <--------------- EAP-Response/X (empty) ---------------> EAP-Success <--------------- > My answer to the situations where an EAP message isn't present, or > disagrees with the Accept or Reject is for the NAS to *manufacture* an > EAP-Success or Failure message rather than passing through > what is in the > encapsulated EAP message. In this case, the NAS should first pass through the encapsulated EAP message and then manufacture an EAP-Success after receiving the last (empty) EAP-Response. The NAS knows it must do this because the Diameter message (DEA) indicates success but encapsulates an EAP-Request. If the working group feels that this is something we want to do, then I agree with you that we should try to fix this for Radius too and issue an RFC 2869bis. The fix I proposed for Diameter isn't "backward compatible" but the NAS needs to know this feature in order for things to work at all. I assume this wouldn't be a problem in Diameter as it isn't an existing (deployed) protocol, but such a requirement would cause problems with Radius. So we may be able to do this smarter in Diameter. I think the three items listed in your e-mail below are very relevant to the evolution of EAP. This optimization I'm proposing is related to the first item -- how to pass both indication of success and some data to the peer in a single AAA message. This EAP packet should be ack'ed so that the data is always delivered to the peer. Regards, Henry > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 27. May 2001 21:29 > To: henry.haverinen@nokia.com > Cc: pcalhoun@nasnfs.Eng.Sun.COM; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: RE: Diameter Proposed Changes > > > I think we are actually getting into some murky areas of RFC > 2869 here, > and the solution is *not* to specify behavior for Diameter > alone, but to > figure out what should happen and issue an RFC 2869bis, then > have Diameter > inherit the correct behavior. > > 1. If a AAA server an Accept message with an EAP-Message inside not > corresponding to a Failure or Success, this implies that the > user is to be > let on. For PPP, RFC 2284 indicates that the peer is to be > able to discern > Failure or Success by alternate methods (seeing NCP packets as an > indication of Success, receipt of an LCP-Terminate as an alternate > indication of Failure). For 802.1X, these alternate mechanisms are not > available so that a manufactured EAP-Success or EAP-Failure > packet is sent > instead. Note that this implies that the last encapsulated packet will > actually not be sent to the peer. So in general, it seems to me that > AAA servers terminating a AAA exchange this way will not be > obtaining a > guaranteed result. > > 2. Sending an EAP-Response after an EAP-Sucess message is > illegal under > RFC 2284, since Success messages are not ACK'd. This is what > leads to the > need for "alternate" indication methods in RFC 2284, and the issues > described in #1. > > 3. EAP authentication does *not* terminate on receipt of an > encapsulated EAP-Success/Failure message from the AAA server, > but rather > on receipt of an Accept/Reject indication. So if an > EAP-Success/Failiure > message is encapsulated in a Challenge rather than an Accept/Reject > message, then authentication could continue, enabling more > than one EAP > method to be used for a given session. However, it is not clear to > me how the two auth methods would be bridged within AAA, > since there is no > EAP-Response to be sent back to the AAA server as described above. The > situation would be different if the other side initiated the > second EAP > conversation, since then the packet sent after an EAP-Success > would be an > EAP-Request. > > > > > From owner-aaa-bof@merit.edu Mon May 28 14:00:34 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06228 for <aaa-archive@odin.ietf.org>; Mon, 28 May 2001 14:00:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7A0B991207; Mon, 28 May 2001 13:48:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3466691208; Mon, 28 May 2001 13:48:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DB63391207 for <aaa-wg@trapdoor.merit.edu>; Mon, 28 May 2001 13:48:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D8BB75DE12; Mon, 28 May 2001 13:48:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 63D925DDF4 for <aaa-wg@merit.edu>; Mon, 28 May 2001 13:48:21 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id NAA29167; Mon, 28 May 2001 13:39:48 -0400 (EDT) Message-Id: <4.1.20010528125837.01ca3520@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 28 May 2001 13:27:13 -0400 To: Barney Wolff <barney@databus.com> From: Paul Funk <paul@funk.com> Subject: Re: [AAA-WG]: [issue] Boot-Id Cc: aaa-wg@merit.edu In-Reply-To: <20010528000257.A36174@tp.databus.com> References: <4.1.20010527212341.01cc9560@cairo.funk.com> <4.1.20010527212341.01cc9560@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 12:02 AM 5/28/01 -0400, Barney Wolff wrote: >The idea of a state-id has some merit, but (as I always seem to) >I protest against over-determination. There is no actual need for >a monotonic value. All that's required is a value that does not >duplicate any value used within the "recent" past. A 32-bit >pseudo-random number would do perfectly well. My problem with >using the boot time as the state-id is that it is not well defined >until an interaction with some timeserver has completed. A boot >counter kept in nvram is problematic when hardware is replaced. If the only use of a state-id were between directly connecting peers, say in DRI, then yes, you would be correct, and only a different, rather than an increasing, state-id would be required. However, once state-id passes across proxies, there would be a problem if a server were to receive messages out of order. Suppose an access device issues message A, reboots, then issues message B. If these messages take different proxy paths and a server receives message B first, upon subsequent receipt of message A it would incorrectly release authorization resources it created for message B. Hence the monotonically increasing value. A server is only supposed to release resources for sessions with lower state-id than the one it just received. Use of boot time for state-id doesn't imply any synchronization with other devices. Whether the access device gets time from a time server or from its own clock, there's no requirement that the time be accurate, only that it never goes backwards. If the access device used a time server, it would have to complete the time determination prior to starting connections. If you replace hardware and the nvram counter is reinitialized to 0, yes, sessions from the previous piece of hardware may persist until their authorization-lifetimes expire. But the error is on the conservative side -- no current users will lose resources. > >The requirement that if Origin-FQDN is changed that state-id be >changed does not seem to make any sense: state-id is not >required to be unique across different origin devices. That state-id is associated with Origin-FQDN is exactly the point. A server would be expected to associate state-id and Origin-FQDN with a session state. When a higher state-id arrived from a particular Origin-FQDN, it could release each session state entry with the same Origin-FQDN and lower state-id. The purpose of the requirement is this: Suppose a broker "takes responsibility" for a request and modifies Origin-FQDN to its own. Well, it better modify state-id also, otherwise the home server will incorrectly assume the unmodified state-id from the access device is actually the state-id of the broker, and will clear sessions incorrectly. Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Mon May 28 16:01:51 2001 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06721 for <aaa-archive@odin.ietf.org>; Mon, 28 May 2001 16:01:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0BE3C9120A; Mon, 28 May 2001 16:01:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CDFA09120C; Mon, 28 May 2001 16:01:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AB4CA9120A for <aaa-wg@trapdoor.merit.edu>; Mon, 28 May 2001 16:01:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 250855DDBB; Mon, 28 May 2001 16:00:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id B23B95DD95 for <aaa-wg@merit.edu>; Mon, 28 May 2001 16:00:47 -0400 (EDT) Received: (qmail 24335 invoked by uid 500); 28 May 2001 20:00:42 -0000 Date: Mon, 28 May 2001 15:00:41 -0500 From: David Frascone <dave@frascone.com> To: Paul Funk <paul@funk.com> Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Make AVP Header consistent with Message Header Message-ID: <20010528150041.Q19487@newman.frascone.com> Mail-Followup-To: Paul Funk <paul@funk.com>, aaa-wg@merit.edu References: <4.1.20010527215226.01ccc2a0@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010527215226.01ccc2a0@cairo.funk.com>; from paul@funk.com on Sun, May 27, 2001 at 09:55:51PM -0400 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk Works for me. On Sun, May 27, 2001 at 09:55:51PM -0400, Paul Funk wrote: > Submitter name: Paul Funk > Submitter email address: paul@funk.com > Date first submitted: May, 20001 > Reference: > Document: Base > Comment Type: Technical > Priority: 2 > Section: 4.1 > Rationale/Explanation of issue: > As long as we have 24 bit message length, how about 24 bit AVP length, > with similar positioning of length in low order bits? > > Requested change: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AVP Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |V|M|P| Reserved| AVP Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor-ID (opt) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data ... > +-+-+-+-+-+-+-+-+ > > Paul > > Paul Funk > Funk Software, Inc. > 617 497-6339 > paul@funk.com From owner-aaa-bof@merit.edu Tue May 29 09:17:27 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00804 for <aaa-archive@odin.ietf.org>; Tue, 29 May 2001 09:17:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B71F89121B; Tue, 29 May 2001 08:44:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D3539121C; Tue, 29 May 2001 08:44:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6A86D9121B for <aaa-wg@trapdoor.merit.edu>; Tue, 29 May 2001 08:44:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AED1C5DDED; Tue, 29 May 2001 08:44:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 627815DDE2 for <aaa-wg@merit.edu>; Tue, 29 May 2001 08:44:23 -0400 (EDT) Received: (qmail 14536 invoked by uid 500); 29 May 2001 12:32:41 -0000 Date: Tue, 29 May 2001 05:32:41 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] Replace the term extension to application Message-ID: <20010529053241.T30735@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk Replace the term extension to application Submitter name: Pat Calhoun (via Randy Bush) Submitter email address: pcalhoun@diameter.org Date first submitted: 2001-05-29 Reference: Document: All Comment type: C Priority: 1 Section: Rationale/Explanation of issue: The IESG has stated that they are concerned with the term extension, and would prefer that the term application be used instead. Requested change: Make the necessary terminology changes throughout the specs. From owner-aaa-bof@merit.edu Tue May 29 10:52:00 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02867 for <aaa-archive@odin.ietf.org>; Tue, 29 May 2001 10:51:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 73AC791227; Tue, 29 May 2001 10:51:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3764E91228; Tue, 29 May 2001 10:51:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2708591227 for <aaa-wg@trapdoor.merit.edu>; Tue, 29 May 2001 10:51:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DE8F95DDBD; Tue, 29 May 2001 10:52:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 1996A5DDA9 for <aaa-wg@merit.edu>; Tue, 29 May 2001 10:52:05 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA11759; Tue, 29 May 2001 10:51:07 -0400 (EDT) Date: Tue, 29 May 2001 10:52:12 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: aaa-wg@merit.edu, erik.guttman@germany.sun.com, schoenw@ibr.cs.tu-bs.de Cc: Pat Calhoun <pcalhoun@diameter.org> Subject: [AAA-WG]: Re: [issue] Bring back UTF8 datatype. In-Reply-To: <Pine.GSO.4.21.0105181859060.28262-100000@knox6039> Message-ID: <Pine.GSO.4.21.0105291044520.29369-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk erik.guttman and schoenw, I have made the request to make UTF8 an official defined type in the Diameter Base draft. I was told that it was removed because it was not a primitive type as defined in SMI. It would be convenient to have an officially defined type of UTF8 so that other Diameter extensions could refer to it explicitly instead of doing what is now done by defining it as OctetString and then describing it as UTF8 format in the text. I was given the impression that one of you could give me guidance on how to add this. I read RFC1155, "Structure and Identification of Management Information for TCP/IP-based Internets". In section 3.2.1, it defines the Primitive Types of INTEGER, OCTET STRING, OBJECT IDENTIFIER, and NULL. In section 3.2.3 it defines Defined Types of Counter, Gauge, TimeTicks, IpAddress, and Opaque which are derived from the Primitive Types. I would like to do something similar with UTF8 derived from OctetString. The wording is OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 9 (13 if the 'V' bit is enabled). AVP Values of this type that do not align on a 32-bit boundary MUST have the necessary padding. UTF8 This application-wide type is represented as an OctetString. It is used to transmit (human readable) character string data uses the UTF-8 [24] character set and is NOT NULL-terminated. The minimum Length field MUST be 9, but can be set to any value up to 65504 bytes. Currently I would indent it after the definition of OctetString, in section 4.3, "AVP Data Formats" but it could be placed in a separate section like 4.3.1, "Defined Data Types". Do you have any suggestions/comments? Thanks, -mark From owner-aaa-bof@merit.edu Tue May 29 11:38:52 2001 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03801 for <aaa-archive@odin.ietf.org>; Tue, 29 May 2001 11:38:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 98BF19147F; Tue, 29 May 2001 11:36:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4959291472; Tue, 29 May 2001 11:36:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0AA5691449 for <aaa-wg@trapdoor.merit.edu>; Tue, 29 May 2001 11:33:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C53B55DDBD; Tue, 29 May 2001 11:33:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 128B35DDA9 for <aaa-wg@merit.edu>; Tue, 29 May 2001 11:33:19 -0400 (EDT) Received: (qmail 17339 invoked by uid 500); 29 May 2001 15:21:22 -0000 Date: Tue, 29 May 2001 08:21:21 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: aaa-wg@merit.edu Cc: aboba@internaut.com Subject: [AAA-WG]: Re: [Issue] Proxy Behavior Message-ID: <20010529082121.Z30735@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu, aboba@internaut.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk > The current base draft defines "Proxy Server" as a routing proxy, and > re-direct is also defined, but other proxy types aren't. The proxy draft, > http://www.ietf.org/internet-drafts/draft-ietf-aaa-proxies-01.txt also > takes a shot at this, but the terminology is not consistent with the base > draft or the transport draft. So at a minimum we need to clean up the > terminology and definitions so that all drafts are consistent. ok, this is occuring. > > However, I think we should probably aim higher. The operation of proxies > is so basic that it is hard to understand the base spec without a mental > model of how they work. So I think that the proxy draft material needs to > be consolidated with the base Proxy material on pp. 59-61, and this should > probably be moved closer to the front of the base draft. I agree, but I wonder if you thought that some of the text in section 2 of the proxy draft was sufficient. Section 3 describes the problems introduced by proxies, and I am not really sure that this is really required in the base protocol spec. Thoughts? PatC From owner-aaa-bof@merit.edu Tue May 29 12:19:11 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05250 for <aaa-archive@odin.ietf.org>; Tue, 29 May 2001 12:19:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B2D749122D; Tue, 29 May 2001 12:19:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 842189122F; Tue, 29 May 2001 12:19:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5604E9122D for <aaa-wg@trapdoor.merit.edu>; Tue, 29 May 2001 12:19:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 58A0F5DFF2; Tue, 29 May 2001 12:18:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 4F9705E020 for <aaa-wg@merit.edu>; Tue, 29 May 2001 12:18:30 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id MAA00272 for <aaa-wg@merit.edu>; Tue, 29 May 2001 12:09:57 -0400 (EDT) Message-Id: <4.1.20010529115503.01cbf930@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 29 May 2001 11:57:13 -0400 To: aaa-wg@merit.edu From: Paul Funk <paul@funk.com> Subject: [AAA-WG]: [issue] Grouped AVP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Grouped AVP Submitter name: Paul Funk, Dave Frascone Submitter email address: paul@funk.com, dave@frascone.com Date first submitted: May, 20001 Reference: many but look at http://www.merit.edu/mail.archives/aaa-wg/msg00883.html Document: Base Comment Type: Technical Priority: 1 or 2 (?) Section: Somewhere in section 4 Proprietary Tag: C Rationale/Explanation of issue: Grouped AVPs MUST NOT be fixed. The same flexibility that Diameter provides is required for Grouped AVPs. See the above URL for a problem that was discussed on the list. Not solving this problem will require that many GRouped AVPs be defined for all possible combinations. Requested change: Make Grouped AVP definitions use ABNF, same as command codes. Suggested language: 4.4 Grouped AVP Values The Diameter protocol allows AVP values of type 'Grouped.' This implies that the Data field comprises one or more AVPs. Every AVP defined to be of data type Grouped MUST include a corresponding ABNF specification, which is used to define the permitted arrangements of AVPs within the Group. The format to be used follows the format for Command Code ABNF specifications (3.2), with the following additional definition: group-def = AVP-name "::=" [*fixed] [*required] [*optional] [*fixed] It is possible to include an AVP with a Grouped type within a Grouped type, that is, to nest them. AVPs within an AVP of type Grouped have the same padding requirements as non-Grouped AVPs, as defined in section 4.0. Example: group-def ::= example-avp {Origin-FQDN} {Host-IP-Address} *[AVP] Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Tue May 29 12:23:35 2001 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05343 for <aaa-archive@odin.ietf.org>; Tue, 29 May 2001 12:23:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8EAF791239; Tue, 29 May 2001 12:20:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 439609123F; Tue, 29 May 2001 12:20:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 829F091239 for <aaa-wg@trapdoor.merit.edu>; Tue, 29 May 2001 12:20:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 56FB65DDA9; Tue, 29 May 2001 12:20:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 5573E5DD9F for <aaa-wg@merit.edu>; Tue, 29 May 2001 12:20:43 -0400 (EDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f4TGKaO07519 for <aaa-wg@merit.edu>; Tue, 29 May 2001 18:20:36 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue May 29 18:20:36 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <LNXPPN4M>; Tue, 29 May 2001 18:23:00 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1A96E@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se> To: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu> Subject: [AAA-WG]: Questions on mobileip-04 draft Date: Tue, 29 May 2001 18:20:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, Here are some questions on the mobileip-04 draft: 1- Where is the Acct-Session-Id AVP defined? I could not find it anywhere. 2- When a MN moves to a new FA, is it now forced to also request a new set of keys?, or can the existing keys be returned by the AAA? The thing is that there seem to be no way of making sure you go through the same AAAF as the last registration, and even no assurance of getting to the same AAAH neither, right? Then I guess that the MN should request a new set of keys each time it sends a Registration request to a new FA that request the AAAH. That would mean that there is no point of keeping any generated keys in the AAAF nor in the AAAH, right? Regards, Martin From owner-aaa-bof@merit.edu Tue May 29 14:40:35 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08801 for <aaa-archive@odin.ietf.org>; Tue, 29 May 2001 14:40:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E01229123D; Tue, 29 May 2001 14:40:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE0019123E; Tue, 29 May 2001 14:40:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6CEAB9123D for <aaa-wg@trapdoor.merit.edu>; Tue, 29 May 2001 14:40:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 597625DE11; Tue, 29 May 2001 14:40:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id BC0B45DDB1 for <aaa-wg@merit.edu>; Tue, 29 May 2001 14:40:35 -0400 (EDT) Received: (qmail 20399 invoked by uid 500); 29 May 2001 18:28:53 -0000 Date: Tue, 29 May 2001 11:28:52 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: Paul Funk <paul@funk.com> Cc: Pat Calhoun <pcalhoun@diameter.org>, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Proposed fixes for Issues 13, 18 and 30 Message-ID: <20010529112852.F30735@charizard.diameter.org> Mail-Followup-To: Paul Funk <paul@funk.com>, Pat Calhoun <pcalhoun@diameter.org>, aaa-wg@merit.edu References: <20010525052346.P30735@charizard.diameter.org> <4.1.20010526194114.01cbe630@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010526194114.01cbe630@cairo.funk.com>; from paul@funk.com on Sat, May 26, 2001 at 07:47:17PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Sat, May 26, 2001 at 07:47:17PM -0400, Paul Funk wrote: > Pat, > > At 05:23 AM 5/25/01 -0700, Pat Calhoun wrote: > > > >Issue 18: Error-Reporting-FQDN was a dup of Origin-FQDN, and therefore MUST > >only be included if a host is changing the result-code AVP, and is not the > >one whose identity is in the Origin-FQDN. > > I may be misremembering, but I thought we concluded that we could eliminate > Error-Reporting-FQDN entirely. If a proxy sets its own failure Result-Code, > it is > in effect taking responsibility for the response, and would set its own FQDN > as Origin-FQDN. That's not what I remember, but I could be wrong. Others? PatC From owner-aaa-bof@merit.edu Tue May 29 14:45:46 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08898 for <aaa-archive@odin.ietf.org>; Tue, 29 May 2001 14:45:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B60209123A; Tue, 29 May 2001 14:39:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85FFF9123D; Tue, 29 May 2001 14:39:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F8B89123A for <aaa-wg@trapdoor.merit.edu>; Tue, 29 May 2001 14:39:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7F9995DE00; Tue, 29 May 2001 14:39:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id F1A3A5DDB1 for <aaa-wg@merit.edu>; Tue, 29 May 2001 14:39:48 -0400 (EDT) Received: (qmail 20383 invoked by uid 500); 29 May 2001 18:28:06 -0000 Date: Tue, 29 May 2001 11:28:06 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: Fredrik Johansson <fredrik.johansson@ipunplugged.com> Cc: Pat Calhoun <pcalhoun@diameter.org>, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Proposed fixes for Issues 13, 18 and 30 Message-ID: <20010529112805.E30735@charizard.diameter.org> Mail-Followup-To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>, Pat Calhoun <pcalhoun@diameter.org>, aaa-wg@merit.edu References: <20010525052346.P30735@charizard.diameter.org> <MJEMJBGGCLLDLFFAHLJKEELJCPAA.fredrik.johansson@ipunplugged.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <MJEMJBGGCLLDLFFAHLJKEELJCPAA.fredrik.johansson@ipunplugged.com>; from fredrik.johansson@ipunplugged.com on Mon, May 28, 2001 at 10:43:50AM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, May 28, 2001 at 10:43:50AM +0200, Fredrik Johansson wrote: > > Is there realy a 'R'-bit in the cmd flags? See Mark's mail titled "Make FAIR > flags a part of Command-Code" Well, Mark's e-mail didn't quite reflect the figure that I had put on the board, but the concept is identical. There is an 'R' bit only, where Mark's e-mail introduced the 'A' bit. Same difference, though. > > Does a zero filled payload of the minimum length mean that a octetstring has > a payload of 1 byte. The AVP is then padded to be 32bit aligned. correct. From owner-aaa-bof@merit.edu Tue May 29 14:59:54 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09195 for <aaa-archive@odin.ietf.org>; Tue, 29 May 2001 14:59:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 06D429123E; Tue, 29 May 2001 14:59:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4D799123F; Tue, 29 May 2001 14:59:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 91F029123E for <aaa-wg@trapdoor.merit.edu>; Tue, 29 May 2001 14:59:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9B0005DE01; Tue, 29 May 2001 14:59:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 1EE075DE00 for <aaa-wg@merit.edu>; Tue, 29 May 2001 14:59:58 -0400 (EDT) Received: (qmail 20779 invoked by uid 500); 29 May 2001 18:48:13 -0000 Date: Tue, 29 May 2001 11:48:08 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] Base protocol doesn't specify how to get Vendor Identifier Message-ID: <20010529114808.I30735@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, One issue that was opened at the Interim Meeting was that the base protocol didn't specify how a vendor-id should be allocated. However, the current base protocol includes the following text: Vendor-ID In the event that the Command-Code field contains a vendor specific command, the four octet Vendor-ID field contains the IANA assigned "SMI Network Management Private Enterprise Codes" [2] value. If the Command-Code field contains an IETF standard Command, the Vendor-ID field MUST be set to zero (0). The above states that enterprise numbers are assigned by IANA (see http://www.iana.org/cgi-bin/enterprise.pl for more info). Is this sufficient, or is the URL to the IANA site required? PatC From owner-aaa-bof@merit.edu Tue May 29 15:18:19 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09531 for <aaa-archive@odin.ietf.org>; Tue, 29 May 2001 15:18:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2F9E5913EC; Tue, 29 May 2001 14:03:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 884A591413; Tue, 29 May 2001 14:03:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 904AD91406 for <aaa-wg@trapdoor.merit.edu>; Tue, 29 May 2001 14:02:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A699C5DE66; Tue, 29 May 2001 14:02:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D7B7B5DE1C for <aaa-wg@merit.edu>; Tue, 29 May 2001 14:02:28 -0400 (EDT) Received: (qmail 20077 invoked by uid 500); 29 May 2001 17:50:46 -0000 Date: Tue, 29 May 2001 10:50:45 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: aaa-wg@merit.edu Cc: randy@psg.com, aboba@internaut.com, david@mitton.com Subject: [AAA-WG]: Partial Proposed Fix for Issue 50 Message-ID: <20010529105045.C30735@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu, randy@psg.com, aboba@internaut.com, david@mitton.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, Issue 50, submitted by Bernard, states that the Diameter document should attempt to incorporate some portions of the proxy draft, and some of the proxy discussions should be moved towards the beginning of the document. Here is my attempted fix, which I'd like to get some feedback on. Thanks, PatC ---- 2.5 Role of Diameter Agents In addition to client and servers, the Diameter protocol introduces relays, redirectors, proxies and translation agents, each of which is defined in Section 1.3. These Diameter agents are useful for several reasons: - They can distribute administration of systems to a configurable grouping, including the maintenance of security associations. - They can be used for concentration of requests from an number of co-located or distributed NAS equipment sets to a set of like user groups. - They can do value-added processing to the requests or responses. - They can used for load balancing. - A complex network will have multiple authentication sources, they can sort requests and forward towards the correct target. The Diameter protocol requires that agents maintain transaction state, which is used for failover purposes. Transaction state implies that upon forwarding a request, it's Hop-by-Hop identifier is saved, the field is replaced with a locally unique identifier, which is restored to its original value when the corresponding answer is received. The request's state is released upon receipt of the answer. A stateless agent is one that only maintains transaction state. The Proxy-Info AVP allows stateless agent to add local state to a Diameter request, with the guarantee that the same state will be present in the answer. However, the protocol's failover procedures requires that agents maintain a copy of pending requests. A stateful agent is one that maintains session state information, by keeping track of all authorized active sessions. Each authorized session is bound to a particular service, and its state is considered active either until it is notified otherwise, or by expiration. Each authorized session has a expiration, which is communicated by Diameter servers via the Authorized-Lifetime AVP. Maintaining session state MAY be useful in certain applications, such as: Calhoun et al. expires October 2001 [Page 16] Internet-Draft May 2001 - Protocol translation (e.g. RADIUS <-> Diameter) - Limiting resources authorized to a particular user - Per user or transaction auditing A Diameter agent MAY act in a stateful manner for some requests, while be stateless for others. A Diameter implementation MAY act as one type of agent for some requests, and as another type of agent for others. 2.5.1 Relay Agents Relay Agents are Diameter agents that accept requests and routes the message to another Diameter agent based on information found in the message (e.g. Destination-Realm). This routing decision is performed using a list of supported domains, and known peers. This is known as the Diameter Routing Table, as is defined further in section x.x. Relays MAY be used to aggregate requests from multiple Network Access Servers (NASes) within a common geographical area (POP). The use of Relays is advantageous since it eliminates the need for NASes to be configured with the necessary security information it would otherwise require to communicate with Diameter servers in other realms. Likewise, this reduces the configuration load on Diameter servers that would otherwise be necessary when NASes are added, changed or deleted. Relays modify Diameter messages by inserting, and removing, routing information, but do not modify any other portion of a message. Further, Relays inherent simplicity implies that they are stateless, and therefore SHOULD NOT maintain session state, but MUST maintain transaction state. +------+ ---------> +------+ ---------> +------+ | | 1. Request | | 2. Request | | | NAS | | DRL | | HMS | | | 4. Answer | | 3. Answer | | +------+ <--------- +------+ <--------- +------+ mno.net mno.net abc.com Figure 1: Relaying of Diameter messages The example provided in Figure 1 depicts a request issued from NAS, which is an access device, for the user bob@abc.com. Prior to issuing the request, NAS performs a Diameter route lookup, using "abc.com" as the key, and determines that the message is to be relayed to DRL, which is a Diameter Relay. DRL performs the same route lookup as NAS, and relays the message to HMS, which is abc.com's Home Diameter Server. HMS identifies that the request can be locally supported (via Calhoun et al. expires October 2001 [Page 17] Internet-Draft May 2001 the realm), processes the authentication and/or authorization request, and replies with an answer, which is routed back to NAS using Diameter routing AVPs. Since Relays do not perform any application level processing, they provide relaying services for all Diameter applications. 2.5.2 Proxy Agents Similarly to Relays, Proxy agents route Diameter messages using the Diameter Routing Table. However, they differ since they modify messages to implement policy enforcement. This requires that proxies maintain the state of their downstream peers (e.g. access devices) to enforce resource usage, provide admission control, and provisioning. It is important to note that although proxies MAY provide a value-add function for NASes, they do not allow access devices to use the Diameter End-to-End Security application, since modifying messages breaks end-to-end authentication. Proxies MAY be used in call control centers or access ISPs that provide outsourced connections, they can monitor the number and types of ports in use, and make allocation and admission decisions according to their configuration. Proxies that wish to limit resources MUST be stateful, and all Proxies MUST maintain transaction state. Since enforcing policies requires an understanding of the service being provided, Proxies MUST only advertise the Diameter applications they support. 2.5.3 Redirector Agents Redirector agents provide Realm to Server address resolution, and use the Diameter routing table to determine where a given request should be forwarded to. When a request is received by a Diameter redirector, a special answer is created, which includes the identity of the Diameter server(s) the originator of the request should contact directly. Redirectors are useful in scenarios where the Diameter routing configuration needs to be centralized. An example is a redirector that provides services to all members of a consortium, but does not wish to be burdened with relaying all messages between domains. This scenario is advantageous since it does not require that the Calhoun et al. expires October 2001 [Page 18] Internet-Draft May 2001 consortium provide routing updates to its members when changes are made to a member's infrastructure. Since redirectors do not relay messages, and only return an answer with the information necessary for Diameter agents to communicate directly, they do not modify messages, and therefore MUST NOT maintain session state. Further, since redirectors never relay requests, they are not required to maintain transaction state. +------+ | | | DRD | | | +------+ ^ | 2. Request | | 3. Redirection | | Notification | v +------+ ---------> +------+ ---------> +------+ | | 1. Request | | 4. Request | | | NAS | | DRL | | HMS | | | 6. Answer | | 5. Answer | | +------+ <--------- +------+ <--------- +------+ mno.net mno.net abc.com Figure 2: Redirecting a Diameter Message The example provided in Figure 2 depicts a request issued from the access device, NAS, for the user bob@abc.com. The message is forwarded by the NAS to its relay, DRL, which does not have a routing entry in its Diameter Routing Table for abc.com. DRL has a default route configured to DRD, which is a redirector that returns a redirect notification to DLR, as well as HMS' contact information. Upon receipt of the redirect notification, DRL establishes a transport connection with HMS, if one doesn't already exist, and forwards the request to it. Since Redirectors do not perform any application level processing, they provide relaying services for all Diameter applications. 2.5.4 Translation Agents A Translation Agent is a device that provides translation between two protocols (e.g. RADIUS<->Diameter, TACACS+<->Diameter). Translation agents are likely to be used as aggregation servers to communicate with a Diameter infrastructure, while allowing for the embedded systems to be migrated at a slower pace. Calhoun et al. expires October 2001 [Page 19] Internet-Draft May 2001 Given that the Diameter protocol introduces the concept of long-lived authorized sessions, translation agents MUST be stateful and MUST maintain transaction state. Translation of messages can only occur if the agent recognizes the application of a particular request, and therefore MUST only advertise their locally supported extensions. +------+ ---------> +------+ ---------> +------+ | | RADIUS Request | | Diameter Request | | | NAS | | TLA | | HMS | | | RADIUS Answer | | Diameter Answer | | +------+ <--------- +------+ <--------- +------+ mno.net mno.net abc.com Figure 3: Translation of RADIUS to Diameter From owner-aaa-bof@merit.edu Tue May 29 15:39:51 2001 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09912 for <aaa-archive@odin.ietf.org>; Tue, 29 May 2001 15:39:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9EEA591244; Tue, 29 May 2001 15:38:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6EBDB91258; Tue, 29 May 2001 15:38:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0C53391244 for <aaa-wg@trapdoor.merit.edu>; Tue, 29 May 2001 15:38:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 120805DE15; Tue, 29 May 2001 15:38:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 7C3E15DE00 for <aaa-wg@merit.edu>; Tue, 29 May 2001 15:38:17 -0400 (EDT) Received: (qmail 11369 invoked by uid 500); 29 May 2001 19:37:58 -0000 Date: Tue, 29 May 2001 14:37:57 -0500 From: David Frascone <dave@frascone.com> To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Proposed fix for Grouped AVP (Issue 11) Message-ID: <20010529143757.A6403@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu References: <20010529121405.O30735@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010529121405.O30735@charizard.diameter.org>; from pcalhoun@diameter.org on Tue, May 29, 2001 at 12:14:05PM -0700 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk On Tue, May 29, 2001 at 12:14:05PM -0700, Pat Calhoun wrote: > 4.4 Grouped AVP Values > > The Diameter protocol allows AVP values of type 'Grouped.' This > implies that the Data field is actually a sequence of AVPs. It is > possible to include an AVP with a Grouped type within a Grouped type, > that is, to nest them. AVPs within an AVP of type Grouped have the > same padding requirements as non-Grouped AVPs, as defined in section > 4.0. Small nit: Since the avps within a group must be padded, and since the avp header itself is padded by design, then isn't the last sentance here redundant? From owner-aaa-bof@merit.edu Tue May 29 16:26:25 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10631 for <aaa-archive@odin.ietf.org>; Tue, 29 May 2001 16:26:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DA0DC91251; Tue, 29 May 2001 16:23:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ADE569124E; Tue, 29 May 2001 16:23:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 38C7491251 for <aaa-wg@trapdoor.merit.edu>; Tue, 29 May 2001 16:23:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 647505DE15; Tue, 29 May 2001 16:23:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D56EC5DDB1 for <aaa-wg@merit.edu>; Tue, 29 May 2001 16:23:28 -0400 (EDT) Received: (qmail 21808 invoked by uid 500); 29 May 2001 20:11:45 -0000 Date: Tue, 29 May 2001 13:11:45 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: Jari Arkko <jari.arkko@kolumbus.fi> Cc: "Yolanda Garcia-Serrano (ECE)" <yolanda.garcia-serrano@ece.ericsson.se>, "'pcalhoun@diameter.org'" <pcalhoun@diameter.org>, "'aaa-wg@merit.edu'" <aaa-wg@merit.edu> Subject: Re: [AAA-WG]: Accounting clarifications Message-ID: <20010529131145.S30735@charizard.diameter.org> Mail-Followup-To: Jari Arkko <jari.arkko@kolumbus.fi>, "Yolanda Garcia-Serrano (ECE)" <yolanda.garcia-serrano@ece.ericsson.se>, "'pcalhoun@diameter.org'" <pcalhoun@diameter.org>, "'aaa-wg@merit.edu'" <aaa-wg@merit.edu> References: <577066326047D41180AC00508B955DDA02C009F9@eestqnt104.es.eu.ericsson.se> <3B120184.5050203@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B120184.5050203@kolumbus.fi>; from jari.arkko@kolumbus.fi on Mon, May 28, 2001 at 10:43:00AM +0300 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, May 28, 2001 at 10:43:00AM +0300, Jari Arkko wrote: > And as you indicate below, there is a need to clarify this text in the > draft. I propose > that we add a statement to the explanation of the session id AVP that > prohibits > the submission of several sessions with the same session id, and says > that the type of > the session must be one of event or start-interim-stop for a particular > session id. Then please submit an official Issue to the list. Thanks, PatC From owner-aaa-bof@merit.edu Tue May 29 17:18:09 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11329 for <aaa-archive@odin.ietf.org>; Tue, 29 May 2001 17:18:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C969F91254; Tue, 29 May 2001 17:17:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 993FF91253; Tue, 29 May 2001 17:17:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 082AA91254 for <aaa-wg@trapdoor.merit.edu>; Tue, 29 May 2001 17:17:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 933A55DE10; Tue, 29 May 2001 17:17:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 150005DD8F for <aaa-wg@merit.edu>; Tue, 29 May 2001 17:17:23 -0400 (EDT) Received: (qmail 22586 invoked by uid 500); 29 May 2001 21:05:39 -0000 Date: Tue, 29 May 2001 14:05:39 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: aaa-wg@merit.edu Subject: [AAA-WG]: What to do about open issues? Message-ID: <20010529140539.T30735@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, Does anyone object if I remove section 17? Since we are using standardized AVP definitions, where Unsigned32 can be used as time, and this is already done in SMI, is the following really needed? PatC ---- "17.0 Open Issues The following are the open issues that SHOULD be addressed in future versions of the Diameter protocol: - AVPs with time values are represented by Unsigned32 type data. This value is a timestamp consistent with NTP [18]. This field is expected to expire sometime in 2038. Future investigation SHOULD be done to determine if a 64 bit time format could be used." From owner-aaa-bof@merit.edu Tue May 29 18:29:50 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12201 for <aaa-archive@odin.ietf.org>; Tue, 29 May 2001 18:29:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 494BC9127B; Tue, 29 May 2001 15:29:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 18837912A2; Tue, 29 May 2001 15:29:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E7B191252 for <aaa-wg@trapdoor.merit.edu>; Tue, 29 May 2001 15:25:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AD3935DE00; Tue, 29 May 2001 15:25:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 4D2885DDB1 for <aaa-wg@merit.edu>; Tue, 29 May 2001 15:25:51 -0400 (EDT) Received: (qmail 21239 invoked by uid 500); 29 May 2001 19:14:05 -0000 Date: Tue, 29 May 2001 12:14:05 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] Proposed fix for Grouped AVP (Issue 11) Message-ID: <20010529121405.O30735@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, Although Paul proposed a fix for the base protocol spec, I believe that the ABNF needs to be well defined. Below is my proposed fix for this issue. Comments welcomed, PatC ---- 4.3 AVP Data Formats [...] Grouped The Data field is specified as a sequence of AVPs. Each of these AVPs follows including their headers and padding. The Calhoun et al. expires October 2001 [Page 29] Internet-Draft May 2001 AVP Length field is set to 8 (12 if the 'V' bit is enabled) plus the total length of all included AVPs, including their headers and padding. 4.4 Grouped AVP Values The Diameter protocol allows AVP values of type 'Grouped.' This implies that the Data field is actually a sequence of AVPs. It is possible to include an AVP with a Grouped type within a Grouped type, that is, to nest them. AVPs within an AVP of type Grouped have the same padding requirements as non-Grouped AVPs, as defined in section 4.0. Every Grouped AVP defined MUST include a corresponding ABNF [31] specification, which is used to define the AVPs that MUST, MAY and MUST NOT be present. The following format is used in the definition: avp-def = name "::=" avp name-fmt = ALPHA *(ALPHA / DIGIT / "-") name = name-fmt ; The name has to be the name of an AVP, ; defined in the base or extended Diameter ; specifications. avp = header [ *fixed] [ *required] [ *optional] [ *fixed] header = "<AVP-Header:" avpcode ">" avpcode = 1*DIGIT ; The AVP Code assigned to the Grouped AVP fixed = [qual] "<" avp-spec ">" required = [qual] "{" avp-spec "}" optional = [qual] "[" avp-name "]" ; The avp-name in the 'optional' rule cannot ; evaluate to any AVP Name which is included ; in a fixed or required rule. qual = [min] "*" [max] ; See ABNF conventions, RFC 2234 section 6.6. ; The absence of any qualifiers implies that ; one and only one such AVP MUST be present. Calhoun et al. expires October 2001 [Page 30] Internet-Draft May 2001 ; ; NOTE: "[" and "]" have a different meaning ; than in ABNF (see the optional rule, above). ; These braces cannot be used to express ; optional fixed rules (such as an optional ; ICV at the end.) To do this, the convention ; is '0*1fixed'. min = 1*DIGIT ; The minimum number of times the element may ; be present. max = 1*DIGIT ; The maximum number of times the element may ; be present. avp-spec = name-fmt ; The avp-spec has to be an AVP Name, defined ; in the base or extended Diameter ; specifications. avp-name = avp-spec | "AVP" ; The string "AVP" stands for *any* arbitrary ; AVP Name, which does not conflict with the ; required or fixed position AVPs defined in ; the command code definition. 4.4.1 Example AVP with a Grouped Data type The Example AVP (AVP Code 999999) is of type Grouped and is used to clarify how Grouped AVP values work. The Grouped Data field has the following ABNF grammar: Example-AVP ::= < AVP Header: 999999 > { Origin-Host } { Host-IP-Address } An Example AVP with the Grouped Data Origin-Host = "example.com", Host-IP-Address = "10.10.10.10" would be encoded as follows: Calhoun et al. expires October 2001 [Page 31] Internet-Draft May 2001 0 1 2 3 4 5 6 7 +-------+-------+-------+-------+-------+-------+-------+-------+ 0 | Example AVP Header (AVP Code = 999999), Length = 40 | +-------+-------+-------+-------+-------+-------+-------+-------+ 8 | Origin-Host AVP Header (AVP Code = 264), Length = 19 | +-------+-------+-------+-------+-------+-------+-------+-------+ 16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' | +-------+-------+-------+-------+-------+-------+-------+-------+ 24 | 'c' | 'o' | 'm' |Padding| Host-IP-Addr AVP Header | +-------+-------+-------+-------+-------+-------+-------+-------+ 32 | (AVP Code = 257), Length = 12 | 0x0a | 0x0a | 0x0a | 0x0a | +-------+-------+-------+-------+-------+-------+-------+-------+ From owner-aaa-bof@merit.edu Tue May 29 18:29:53 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12212 for <aaa-archive@odin.ietf.org>; Tue, 29 May 2001 18:29:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9C0429124B; Tue, 29 May 2001 16:12:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5725791280; Tue, 29 May 2001 16:12:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 03DD99124B for <aaa-wg@trapdoor.merit.edu>; Tue, 29 May 2001 16:11:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 360D95DE1D; Tue, 29 May 2001 16:12:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E59145DDF2 for <aaa-wg@merit.edu>; Tue, 29 May 2001 16:12:04 -0400 (EDT) Received: (qmail 21716 invoked by uid 500); 29 May 2001 20:00:21 -0000 Date: Tue, 29 May 2001 13:00:21 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se> Cc: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu> Subject: Re: [AAA-WG]: Questions on mobileip-04 draft Message-ID: <20010529130021.R30735@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>, "'aaa-wg@merit.edu'" <aaa-wg@merit.edu> References: <577066326047D41180AC00508B955DDA04D1A96E@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA04D1A96E@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Tue, May 29, 2001 at 06:20:32PM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Tue, May 29, 2001 at 06:20:32PM +0200, Martin Julien (ECE) wrote: > Hi, > > Here are some questions on the mobileip-04 draft: > > 1- Where is the Acct-Session-Id AVP defined? I could not find it anywhere. base protocol (well, it should have been) > > 2- When a MN moves to a new FA, is it now forced to also request a new set > of keys?, or can the existing keys be returned by the AAA? The thing is that there seem > to be no way of making sure you go through the same AAAF as the last > registration, and even no assurance of getting to the same AAAH neither, right? That has always been the case, so the default is that the new foreign agent knows nothing about the previous registration. The optimized approach, where some context is traferred between the foreign agents, would eliminate that problem. > Then I guess that the MN should request a new set of keys each time it sends > a Registration request to a new FA that request the AAAH. That would mean > that there is no point of keeping any generated keys in the AAAF nor > in the AAAH, right? Unless the optimized approach (above) is done, you are correct. PatC From owner-aaa-bof@merit.edu Tue May 29 21:29:31 2001 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13634 for <aaa-archive@odin.ietf.org>; Tue, 29 May 2001 21:29:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F30BA91270; Tue, 29 May 2001 21:29:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A477C91273; Tue, 29 May 2001 21:29:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3EFAB91270 for <aaa-wg@trapdoor.merit.edu>; Tue, 29 May 2001 21:29:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 864C15DE17; Tue, 29 May 2001 21:29:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 103AF5DD9D for <aaa-wg@merit.edu>; Tue, 29 May 2001 21:29:11 -0400 (EDT) Received: (qmail 25962 invoked by uid 500); 30 May 2001 01:17:26 -0000 Date: Tue, 29 May 2001 18:17:26 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: aaa-wg@merit.edu Subject: [AAA-WG]: Re: [Issue] Proxy Behavior Message-ID: <20010529181726.A30735@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk First, thanks for the comments. I will send another e-mail with my proposed remaining fixes for this fix (I sent another one earlier which I also sent an e-mail to). > One interesting point made in the SIP spec is that types of proxy behavior > are situational, so that a proxy may act as a routing proxy for one type > of message, a re-direct for another, etc. I'm curious if this logical > applies to Diameter or not. This complicates the capabilities exchange > considerably, because it implies that a proxy's capabilities might vary > depending on the message type, destination realm, etc. Correct, and I believe that the rules for advertising are quite clear in the text that I sent out today. > > At various points in the base spec, it is hard for me to understand what > type of proxy is being referred to, or whether the text applies to *all* > proxy types as defined in the various drafts. Some examples: Right, and I believe that the text that I sent earlier today handles this. All types of Agents are now well defined. The term proxy was being abused, so I now use agent as the umbrella term. An agent is either a relay, proxy, redirector or server. > > 1. pp. 21, base. "If such an AVP is received by a Proxy or Redirect > Server, the message MUST be forwarded to its logical destination and MUST > NOT be rejected." Do all proxy types defined in the proxy doc behave this > way, or just routing proxies? Might a policy proxy NOT forward such a > message? This is now fixed to state that relay and redirectors DO NOT return an error when this occurs. > > 2. pp. 27, base. "Proxies receiving messages that contain the > Destination-FQDN 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." Again, do *all* proxy types behave this > way, or just routing proxies? Might a policy proxy not do this? Check, I believe this is now described much better in the text. This is *always* done by proxy and relay agents. > > 3. pp. 28, base. "A receiver of a DRI message which does not have any > extensions in common with the sender MUST return a DSI message to the > peer..." Would suggest we explicitly state how proxy types are expected to > behave with respect to a DRI message. It makes sense that a routing proxy > MUST advertise *, as would a re-direct. A policy proxy might not advertise > wildcard though, right? Is there ever a situation where a proxy might > implement different capabilities based on mesage type or the realm of the > request? So for mitton.com, proxy might handle MIP requests, but for > internaut.com I wouldn't ('cause he only paid for dialup)? Or is this > something I handle by not authorizing those types of access? Clarification > on the role of capabilities exchange versus authorization would be > helpful. The text I sent earlier now describes how advertises what (actually, I made a couple of adjustments, so I will re-send my whole Issue 50 fix later). > > 4. pp. 39. "An e2e error occurs when a Diameter entity sends a message and > either an intermediate proxy or the home server wishes to return a > failure." Term "intermediate proxy" is not defined in the glossary. Also, > I thought that e2e errors were removed based on discussion at IETF50. I do not recall such a conversation, and we agreed that it was necessary at the last interim meeting. > > 5. pp. 44 "The Device-Status-Ind message MUST NOT be proxied, but MAY be > forwarded". If "proxy" means "routing proxy" as indicated in the glossary > you'd think these two actions would be equivalent. Obviously there is > some distinction here but it's not defined well, so it's hard to make out > what the difference is. Check, and the problem, which was raised once, is that the forwarding and routing text are in two seaprate places in the draft. I have now consolidated, and cleaned up, the text into section 5. > > 6. pp. 56. Section 11.1.1 talks about the realm-based routing table. Table > entries include Domain Name, Extension Identifier, Action. Making > forwarding decisions based on extension seems complicated to me, and I'd > prefer to do away with it if possible. I would assume that > re-directs and routing proxies always have wildcard in the extension > identifier, but they still need to track the extensions of their > downstream neighbors, right? This is one of the reasons why having a > server support all extensions would simplify things. Wildcard is an extension, and is a wildcard, so ANY packets MAY be sent to an agent that advertises this. I believe that the text is much clearer on this now. > > 7. On pp. 57 it says "the local server MAY apply its local > policies to the message by including new AVPs prior to forwarding". This > doesn't seem like routing proxy behavior, more like a policy proxy, right? check, and fixed. > > 8. pp. 57 "a message that does not contain any of the above AVPs MUST NOT > be routed". Not clear about the distinction been forwarding and routing > used here. Is this distinct from forwarding and proxying, and if so what > operations does routing include? check, and fixed. > > 9. pp. 59. This section talks about behavior of stateless and stateful > proxies. I think that more detail on behavior of these types is needed > up front. Given that a stateful proxy maintains session > state, I think that more explicit guidance is needed on how this is done > in the face of reboot indications, network partitions, etc. It's not an > easy problem. check, and I (hope) it is fixed. Sending fixes right now, PatC From owner-aaa-bof@merit.edu Tue May 29 21:32:25 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13709 for <aaa-archive@odin.ietf.org>; Tue, 29 May 2001 21:32:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3E9F39126D; Tue, 29 May 2001 21:32:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1691E91273; Tue, 29 May 2001 21:32:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 990479126D for <aaa-wg@trapdoor.merit.edu>; Tue, 29 May 2001 21:32:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2ECDD5DDF1; Tue, 29 May 2001 21:32:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 12C735DD9D for <aaa-wg@merit.edu>; Tue, 29 May 2001 21:32:22 -0400 (EDT) Received: (qmail 25980 invoked by uid 500); 30 May 2001 01:20:37 -0000 Date: Tue, 29 May 2001 18:20:37 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] Fixes for Issue 50 Message-ID: <20010529182037.B30735@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, Today I posted my partial fix for Issue 50, and this is the complete text. What I've done, in addition to the text I sent today, is pulled all of the routing section into section 5, and cleaned it up considerably. I am sending the fix I sent today since I changed the last sentences of in sections 2.5.1 and 2.5.3. I would really appreciate some feedback, but I am quite certain that this new text will really clear up many issues that were raised in #50. [...] 2.5 Role of Diameter Agents In addition to client and servers, the Diameter protocol introduces relays, redirectors, proxies and translation gateways, each of which is defined in Section 1.3. These Diameter agents are useful for several reasons: - They can distribute administration of systems to a configurable grouping, including the maintenance of security associations. - They can be used for concentration of requests from an number of co-located or distributed NAS equipment sets to a set of like user groups. - They can do value-added processing to the requests or responses. - They can used for load balancing. - A complex network will have multiple authentication sources, they can sort requests and forward towards the correct target. The Diameter protocol requires that agents maintain transaction state, which is used for failover purposes. Transaction state implies that upon forwarding a request, it's Hop-by-Hop identifier is saved, the field is replaced with a locally unique identifier, which is restored to its original value when the corresponding answer is received. The request's state is released upon receipt of the answer. A stateless agent is one that only maintains transaction state. The Proxy-Info AVP allows stateless agent to add local state to a Diameter request, with the guarantee that the same state will be present in the answer. However, the protocol's failover procedures requires that agents maintain a copy of pending requests. A stateful agent is one that maintains session state information, by keeping track of all authorized active sessions. Each authorized session is bound to a particular service, and its state is considered active either until it is notified otherwise, or by expiration. Each authorized session has a expiration, which is communicated by Diameter servers via the Authorized-Lifetime AVP. Calhoun et al. expires October 2001 [Page 16] Internet-Draft May 2001 Maintaining session state MAY be useful in certain applications, such as: - Protocol translation (e.g. RADIUS <-> Diameter) - Limiting resources authorized to a particular user - Per user or transaction auditing A Diameter agent MAY act in a stateful manner for some requests, while be stateless for others. A Diameter implementation MAY act as one type of agent for some requests, and as another type of agent for others. 2.5.1 Relay Agents Relay Agents are Diameter agents that accept requests and routes the message to another Diameter agent based on information found in the message (e.g. Destination-Realm). This routing decision is performed using a list of supported domains, and known peers. This is known as the Diameter Routing Table, as is defined further in section x.x. Relays MAY be used to aggregate requests from multiple Network Access Servers (NASes) within a common geographical area (POP). The use of Relays is advantageous since it eliminates the need for NASes to be configured with the necessary security information it would otherwise require to communicate with Diameter servers in other realms. Likewise, this reduces the configuration load on Diameter servers that would otherwise be necessary when NASes are added, changed or deleted. Relays modify Diameter messages by inserting, and removing, routing information, but do not modify any other portion of a message. Further, Relays inherent simplicity implies that they are stateless, and therefore SHOULD NOT maintain session state, but MUST maintain transaction state. +------+ ---------> +------+ ---------> +------+ | | 1. Request | | 2. Request | | | NAS | | DRL | | HMS | | | 4. Answer | | 3. Answer | | +------+ <--------- +------+ <--------- +------+ mno.net mno.net abc.com Figure 1: Relaying of Diameter messages The example provided in Figure 1 depicts a request issued from NAS, which is an access device, for the user bob@abc.com. Prior to issuing the request, NAS performs a Diameter route lookup, using "abc.com" as the key, and determines that the message is to be relayed to DRL, which is a Diameter Relay. DRL performs the same route lookup as NAS, Calhoun et al. expires October 2001 [Page 17] Internet-Draft May 2001 and relays the message to HMS, which is abc.com's Home Diameter Server. HMS identifies that the request can be locally supported (via the realm), processes the authentication and/or authorization request, and replies with an answer, which is routed back to NAS using Diameter routing AVPs. Since Relays do not perform any application level processing, they provide relaying services for all Diameter applications, and therefore MUST advertise the Relay Application Identifier. 2.5.2 Proxy Agents Similarly to Relays, Proxy agents route Diameter messages using the Diameter Routing Table. However, they differ since they modify messages to implement policy enforcement. This requires that proxies maintain the state of their downstream peers (e.g. access devices) to enforce resource usage, provide admission control, and provisioning. It is important to note that although proxies MAY provide a value-add function for NASes, they do not allow access devices to use the Diameter End-to-End Security application, since modifying messages breaks end-to-end authentication. Proxies MAY be used in call control centers or access ISPs that provide outsourced connections, they can monitor the number and types of ports in use, and make allocation and admission decisions according to their configuration. Proxies that wish to limit resources MUST be stateful, and all Proxies MUST maintain transaction state. Proxy agents MUST NOT allow end-to-end security to be established between two peers if it expects to modify ANY non-routing AVP in messages exchanged between the peers. See [11] for more information. Since enforcing policies requires an understanding of the service being provided, Proxies MUST only advertise the Diameter applications they support. 2.5.3 Redirector Agents Redirector agents provide Realm to Server address resolution, and use the Diameter routing table to determine where a given request should be forwarded to. When a request is received by a Diameter redirector, a special answer is created, which includes the identity of the Diameter server(s) the originator of the request should contact Calhoun et al. expires October 2001 [Page 18] Internet-Draft May 2001 directly. Redirectors are useful in scenarios where the Diameter routing configuration needs to be centralized. An example is a redirector that provides services to all members of a consortium, but does not wish to be burdened with relaying all messages between domains. This scenario is advantageous since it does not require that the consortium provide routing updates to its members when changes are made to a member's infrastructure. Since redirectors do not relay messages, and only return an answer with the information necessary for Diameter agents to communicate directly, they do not modify messages, and therefore MUST NOT maintain session state. Further, since redirectors never relay requests, they are not required to maintain transaction state. +------+ | | | DRD | | | +------+ ^ | 2. Request | | 3. Redirection | | Notification | v +------+ ---------> +------+ ---------> +------+ | | 1. Request | | 4. Request | | | NAS | | DRL | | HMS | | | 6. Answer | | 5. Answer | | +------+ <--------- +------+ <--------- +------+ mno.net mno.net abc.com Figure 2: Redirecting a Diameter Message The example provided in Figure 2 depicts a request issued from the access device, NAS, for the user bob@abc.com. The message is forwarded by the NAS to its relay, DRL, which does not have a routing entry in its Diameter Routing Table for abc.com. DRL has a default route configured to DRD, which is a redirector that returns a redirect notification to DLR, as well as HMS' contact information. Upon receipt of the redirect notification, DRL establishes a transport connection with HMS, if one doesn't already exist, and forwards the request to it. Since Redirectors do not perform any application level processing, they provide relaying services for all Diameter applications, and therefore MUST advertise the Relay Application Identifier. Calhoun et al. expires October 2001 [Page 19] Internet-Draft May 2001 2.5.4 Translation Agents A Translation Agent is a device that provides translation between two protocols (e.g. RADIUS<->Diameter, TACACS+<->Diameter). Translation agents are likely to be used as aggregation servers to communicate with a Diameter infrastructure, while allowing for the embedded systems to be migrated at a slower pace. Given that the Diameter protocol introduces the concept of long-lived authorized sessions, translation agents MUST be stateful and MUST maintain transaction state. Translation of messages can only occur if the agent recognizes the application of a particular request, and therefore MUST only advertise their locally supported extensions. +------+ ---------> +------+ ---------> +------+ | | RADIUS Request | | Diameter Request | | | NAS | | TLA | | HMS | | | RADIUS Answer | | Diameter Answer | | +------+ <--------- +------+ <--------- +------+ mno.net mno.net abc.com Figure 3: Translation of RADIUS to Diameter [...] 5.0 Diameter message processing All Diameter messages MUST include the Origin-Host and Origin-Realm AVPs, which are used to identify the source of the message. The Destination-Host AVP MAY be present in requests, and MUST be present in answers. The Destination-Host AVP is used when the destination of the message is fixed, which includes: - 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. access device), such as the Abort- Session-Request message, which is used to request that a Calhoun et al. expires October 2001 [Page 33] Internet-Draft May 2001 particular user's session be terminated. The Destination-Realm AVP MUST be present if the message is routable. A message that MUST NOT be relayed, proxied or redirected MUST NOT include the Destination-Realm in its ABNF. The value of the Destination-Realm AVP MAY be extracted from the User-Name AVP, or other application-specific methods. When a message is received, the message is processed in the following order: 1. If the message is destined for the local host, the procedures listed in section 5.1 are followed. 2. If the message is intended for a Diameter peer with whom the local host is able to directly communicate with, the procedures listed in section 5.2 are followed. This is known as Message Forwarding. 3. The procedures listed in section 5.3 are followed, which is known as Message Routing. 4. If none of the above are successful, an answer is returned with the Result-Code set to DIAMETER_UNABLE_TO_DELIVER. 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. 5.1 Processing Local Messages A request is known to be for local comsumption when one of the following conditions occur: - The Destination-Host AVP contains the local host's identity, - The Destination-Host AVP is not present, the Destination-Realm AVP contains a realm the server is configured to process locally, and the Diameter application is locally supported, or - The Destination-Realm AVP is not present. When a request is locally processed, the following procedures MUST be applied, in addition to any additional procedures that MAY be discussed in the Diameter application defining the command: - The same Hop-by-Hop identifier in the request is used in the answer. - The local host's identity is encoded in the Origin-Host and Origin-FQDN AVPs. - The value of the Origin-Host AVP in the request is included in the answer's Destination-Host AVP. - The Result-Code AVP is added with its value indicating success Calhoun et al. expires October 2001 [Page 34] Internet-Draft May 2001 or failure. - If the Session-Id is present in the request, it MUST be included in the answer. - Any Route-Record or Proxy-Info AVPs in the request MUST be added to the answer message, in the same order they were present in the request. When the local message is an answer, no additional procedures beyond those listed in the specific Diameter application are to be followed. 5.2 Message Forwarding Message forwarding is done using the Diameter Peer Table. The Diameter peer table contains all of the peers that the local node is able to directly communicate with. When a request is received, and the host encoded in the Destination- Host AVP is one that is present in the peer table, the message SHOULD be forwarded to the peer. If the message received is an answer, the host in the Destination- Host AVP is in the peer table, and there are no Route-Record AVPs in the message, the message MUST be forwarded to the peer. 5.2.1 Peer Table The Diameter Peer Table is used in message forwarding, and referenced by the Domain Routing Table. A Peer Table entry contains the following fields: - Peer name. The Fully Qualified Domain Name of the peer. This MAY be resolved locally, or known via the DRR or DRA message. - Port Number. The port number the peer may be contacted on. - Protocol. Specifies whether TCP or SCTP is the protocol to use to communicate with the peer. - TLS Enabled. Specifies whether TLS is to be used when communicating with the peer. 5.3 Message Routing Diameter request message routing is done via realms. A Diameter message that is proxyable MUST include the target realm in the Destination-Realm AVP. The realm MAY be retrieved from the User-Name AVP, which is in the form of a Network Access Identifier (NAI). The realm portion of the NAI is inserted in the Destination-Realm AVP. Calhoun et al. expires October 2001 [Page 35] Internet-Draft May 2001 Diameter agents have a list of locally supported realms, and MAY have a list of externally supported realms. When a request is received that includes a realm that is not locally supported, the message is routed to the peer configured in the Domain Routing Table table (see section 5.3.1). 5.3.1 Realm-Based Routing Table All Realm-Based routing lookups are performed against what is commonly known as the Domain Routing Table (see section 18.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. - Application Identifier. It is possible for a routing entry to have a different destination based on the Acct-Application-Id (for accounting messages) or Auth-Application-Id (for non- accounting messages) 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 routed to another server. 2. RELAY - All Diameter messages that fall within this category MUST be routed to a next hop server, without modifying any non-routing AVPs. See sections 5.3.3 and 5.3.4 for relaying guidelines 3. PROXY - All Diameter messages that fall within this category MUST be routed 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 routing. See sections 5.3.3 and 5.3.4 for relaying guidelines. 4. 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 message. See section 5.3.2 for redirect guidelines. - Server Identifier - One or more servers the message is to be routed to. These servers MUST also be present in the Peer table. When the Local Action is set to RELAY or PROXY, this field contains the identity of the server(s) the message must be routed to. When the Local Action field is set to REDIRECT, this field contains the identity of one or more servers the message should be redirected to. Calhoun et al. expires October 2001 [Page 36] Internet-Draft May 2001 It is important to note that Diameter agents MUST support at least one of the LOCAL, RELAY, PROXY or REDIRECT modes of operation. Agents do not need to support all modes of operation in order to conform with the protocol specification, but MUST follow the protocol compliance guidelines in section 2.0. Relay agents MUST NOT reorder AVPs, and proxies SHOULD NOT reorder AVPs. When a request is routed, the target server MUST have advertised the Application Identifier (see section 6.1) for the given message, or have advertised itself as a relay or proxy agent. 5.3.2 Redirecting requests When a redirector agent receives a request whose routing entry is set to REDIRECT, it MUST answer the request with Message-Reject-Answer, while maintaining the Hop-by-Hop Identifier in the header, and include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION. Each of the servers associated with the routing entry are added in separate Redirect-Host AVP. +------------------+ | Diameter | | Redirector Agent | +------------------+ ^ | 1. Request | | 2. MRA + joe@xyz.com | | Result-Code = DIAMETER_REDIRECT_INDICATION + | | Redirect-Host AVP(s) | v +---------+ 3. Request +----------+ | abc.net |------------->| xyz.net | | Relay | | Diameter | | Agent |<-------------| Server | +---------+ 4. Answer +----------+ Figure 7: Diameter Redirect Server Redirector agents MAY also include the certificate of the servers in the Redirect-Host AVP(s). These certificates are encapsulated in a CMS-Cert AVP [11]. The receiver of the MRA message with the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION uses the hop-by-hop field in the Diameter header to identify the request in the pending message queue (see Section 7.3) that is to be redirected. If no transport connection exists with the new agent, one is created, and the request is sent directly to it. Calhoun et al. expires October 2001 [Page 37] Internet-Draft May 2001 5.3.3 Relaying and Proxying Requests A relay or proxy agent MUST check for forwarding loops before forwarding requests. A loop is detected if the server finds its own address in a Route-Record AVP. When such an event occurs, the agent MUST answer with the Result-Code AVP set to DIAMETER_LOOP_DETECTED. A relay or proxy agent MUST append a Route-Record AVP that includes its identity to all requests forwarded. The last Route-Record AVP in all requests received MUST be validated, by ensuring that the host encoded in the AVP is the same as the peer the message was received from. The Hop-by-Hop identifier in the request is saved, and replaced with a locally unique value. Relay and Proxy agents MAY include the Proxy-Info AVP in requests if it requires access any local state information when the corresponding response is received. Alternatively, it MAY simply use local storage to store state information. The message is then forwarded to the next hop, as identified in the Domain Routing Table. Figure 6 provides an example of message routing using the procedures listed in these sections. (Origin-Host=nas.mno.net) (Origin-Host=nas.mno.net) (Origin-Realm=mno.net) (Origin-Realm=mno.net) (Destination-Realm=abc.com) (Destination-Realm=abc.com) (Route-Record=drl.mno.net) +------+ ------> +------+ ------> +------+ | | (Request) | | (Request) | | | NAS +-------------------+ DRL +-------------------+ HMS | | | | | | | +------+ <------ +------+ <------ +------+ mno.net (Answer) mno.net (Answer) abc.com (Origin-Host=hms.abc.com) (Origin-Host=hms.abc.com) (Origin-Realm=abc.com) (Origin-Realm=abc.com) (Destination-Host=nas.mno.net) (Destination-Host=nas.mno.net) (Route-Record=drl.mno.net) Figure 6: Routing of Diameter messages 5.3.4 Relaying and Proxying Answers A relay or proxy agent MUST only process Answers whose last Route- Record AVP matches one of its identities. Any answers that do not Calhoun et al. expires October 2001 [Page 38] Internet-Draft May 2001 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-Info AVP in the message is targeted to the local Diameter server, the AVP MUST be removed. If a relay or proxy agent receives an answer 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. If the agent receives an answer message with a Result-Code AVP indicating success, and it wishes to modify the AVP to indicate an error, it MUST issue an STR on behalf of the access device. Prior to forwarding the answer, the agent MUST restore the original value of the Diameter header's Hop-by-Hop Identifier field. 5.4.6 Hiding Network Topology A Relay or Proxy agent routing messages outside of their administrative domain MAY need to hide the internal Diameter topology. This is done by removing all Route-Record AVPs in a request, and later adding them back into the corresponding answer, in the same order. Such agents MUST take care to not assume that the absence of any Route-Record AVPs implies the message is for local comsumption. 5.5 Origin-Host AVP The Origin-Host AVP (AVP Code 264) is of type OctetString, encoded in the UTF-8 [24] format, according to the Diameter identity rules defined in section 2.7, and MUST be present in all Diameter messages. This AVP identifies the endpoint which originated the Diameter message, i.e. the access device, home server, or broker. Relay agents MUST NOT modify this AVP. Note that the Origin-Host AVP may resolve to more than one address as the Diameter peer may support more than one address. This AVP SHOULD be placed as close to the Diameter header as possible. 5.6 Origin-Realm AVP Calhoun et al. expires October 2001 [Page 39] Internet-Draft May 2001 The Origin-Realm AVP (AVP Code 296) is of type OctetString, encoded in the UTF-8 [24] format. This AVP contains the Realm of the originator of any Diameter message and MUST be present in all messages This AVP SHOULD be placed as close to the Diameter header as possible. 5.7 Destination-Host AVP The Destination-Host AVP (AVP Code 293) is of type OctetString, encoded in the UTF-8 [24] format, according to the Diameter identity rules defined in section 2.7. This AVP MUST be present in all unsolicited agent initiated messages, MAY be present in request messages, and MUST be present in Answer messages. The value of the Destination-Host AVP is set to the value of the Origin-Host AVP found in a message from the intended target host. This AVP SHOULD be placed as close to the Diameter header as possible. 5.8 Destination-Realm AVP The Destination-Realm AVP (AVP Code 283) is of type OctetString, encoded in the UTF-8 [24] format, and contains the realm the message is to be routed to. The Destination-Realm AVP MUST NOT be present in Answer messages. Diameter Clients insert the realm portion of the User-Name AVP. Diameter servers initiating a request message use the value of the Origin-Realm AVP from a previous message received from the intended target host (unless it is known a priori). When present, the Destination-Realm AVP is used to perform message routing decisions. Request messages whose ABNF does not list the Destination-Realm AVP as a mandatory AVP are inherently non-routable messages. This AVP SHOULD be placed as close to the Diameter header as possible. 5.9 Route-Record AVP The Route-Record AVP (AVP Code 282) is of type OctetString, encoded in the UTF-8 [24] format, according to the Diameter identity rules defined in section 2.7. The identity added in this AVP MUST be the same as the identity sent in the Origin-Host of the Device-Reboot- Calhoun et al. expires October 2001 [Page 40] Internet-Draft May 2001 Request message. 5.10 Proxy-Info AVP The Proxy-Info AVP (AVP Code = 284) is of type Grouped. The Grouped Data field has the following ABNF grammar: Proxy-Info ::= < AVP Header: 284 > { Proxy-Host } { Proxy-State } * [ AVP ] 5.11 Proxy-Host AVP The Proxy-Host AVP (AVP Code = 280) is of type OctetString, encoded in the UTF-8 [24] format, according to the Diameter identity rules defined in section 2.7. This AVP contains the identity of the host that added the Proxy-Info AVP. 5.12 Proxy-State AVP The Proxy-State AVP (AVP Code = 33) is of type OctetString, and contains state local information, and MUST be treated as opaque data. 5.13 Redirect-Host AVP The Redirect-Host AVP (AVP Code 292) is of type OctetString, encoded in the UTF-8 [24] format, according to the Diameter identity rules defined in section 2.7. This AVP MUST be present in Message-Reject- Answer messages that include the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION. Upon receiving the above, the receiving Diameter node SHOULD forward the request directly to the host identified in this AVP. From owner-aaa-bof@merit.edu Wed May 30 01:48:25 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20172 for <aaa-archive@odin.ietf.org>; Wed, 30 May 2001 01:48:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CEC7291280; Wed, 30 May 2001 01:48:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E66791281; Wed, 30 May 2001 01:48:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8226391280 for <aaa-wg@trapdoor.merit.edu>; Wed, 30 May 2001 01:48:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 676135DE2D; Wed, 30 May 2001 01:48:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id BCB975DDE5 for <aaa-wg@merit.edu>; Wed, 30 May 2001 01:48:36 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id WAA49932; Tue, 29 May 2001 22:38:29 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 29 May 2001 22:38:29 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: Pat Calhoun <pcalhoun@diameter.org> Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Re: [Issue] Proxy Behavior In-Reply-To: <20010529082121.Z30735@charizard.diameter.org> Message-ID: <Pine.BSF.4.21.0105292224390.49908-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > I agree, but I wonder if you thought that some of the text in section 2 of > the proxy draft was sufficient. Section 3 describes the problems introduced > by proxies, and I am not really sure that this is really required in the > base protocol spec. > > Thoughts? I re-read the proxy draft, as well as the text in Diameter base, and on reflection, I'm not sure that pulling the proxy draft stuff into base is the right thing. For one thing, I think that the base draft is more comprehensive in some aspects (e.g. routing behavior) for what it covers. And the proxy and base drafts are not always consistent in their approach. So perhaps a better way to go after the definitions have been clarified, is to complete any missing sections describing the behavior of the various AAA intermediaries (re-direct, relay, proxy). Here is what I think needs to be covered: 1. Introduction to AAA intermediaries a. Re-direct b. Relays c. Proxies d. Stateless versus stateful 2. The routing process a. NAS as "stub" resolver b. Intermediaries as "full" resolver c. Organization of the Routing Information Base (RIB) d. Sources of routing information (SLP, DNS SRV, manual entries) 3. Re-directs a. Basic behavior b. Operations on routing AVPs c. Stateless behavior d. Extension advertisement behavior 4. Relay behavior a. Operations on routing AVPs b. Behavior with respect to encrypted AVPs c. Stateless behavior d. Extension advertisement behavior 5. Proxy behavior a. Operations on routing AVPs (if different from above types) b. Proxy-related AVPs (Proxy State, etc.) c. Behavior with respect to encrypted AVPs d. Stateless versus stateful proxies e. Permissible policy operations f. Error messages/AVPs/messages (e.g. RFC 2607-style proxy stop) g. Interactions with e2e security h. Extension advertisement behavior From owner-aaa-bof@merit.edu Wed May 30 04:34:53 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03650 for <aaa-archive@odin.ietf.org>; Wed, 30 May 2001 04:34:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 807A691283; Wed, 30 May 2001 04:34:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5428C91284; Wed, 30 May 2001 04:34:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 504D291283 for <aaa-wg@trapdoor.merit.edu>; Wed, 30 May 2001 04:34:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 790725DE41; Wed, 30 May 2001 04:35:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 992BD5DDC2 for <aaa-wg@merit.edu>; Wed, 30 May 2001 04:34:59 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA06340; Wed, 30 May 2001 01:34:50 -0700 (PDT) Received: from vayne (muc-isdn-12 [129.157.164.112]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id KAA28371; Wed, 30 May 2001 10:34:48 +0200 (MET DST) Date: Wed, 30 May 2001 10:46:32 +0200 (MET DST) From: Erik Guttman <Erik.Guttman@Sun.COM> Reply-To: Erik Guttman <Erik.Guttman@Sun.COM> Subject: Re: [AAA-WG]: [Issue] Proposed fix for Grouped AVP (Issue 11) To: David Frascone <dave@frascone.com> Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <20010529143757.A6403@newman.frascone.com> Message-ID: <Roam.SIMC.2.0.6.991212392.18494.erikg@ehdb03-home.germany> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > On Tue, May 29, 2001 at 12:14:05PM -0700, Pat Calhoun wrote: > > 4.4 Grouped AVP Values > > > > The Diameter protocol allows AVP values of type 'Grouped.' This > > implies that the Data field is actually a sequence of AVPs. It is > > possible to include an AVP with a Grouped type within a Grouped type, > > that is, to nest them. AVPs within an AVP of type Grouped have the > > same padding requirements as non-Grouped AVPs, as defined in section > > 4.0. > > Small nit: Since the avps within a group must be padded, and since the > avp header itself is padded by design, then isn't the last sentance here > redundant? This clarifying text came out of implementor confusion. We went back and forth on this a few times on the diameter list, if I recall. Sometimes redundancy is needed to help people along toward interoperable implementations. Erik From owner-aaa-bof@merit.edu Wed May 30 04:37:03 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03668 for <aaa-archive@odin.ietf.org>; Wed, 30 May 2001 04:37:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 330A291284; Wed, 30 May 2001 04:36:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EAA7391285; Wed, 30 May 2001 04:36:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 08F3B91284 for <aaa-wg@trapdoor.merit.edu>; Wed, 30 May 2001 04:36:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 449925DE41; Wed, 30 May 2001 04:37:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id C27615DDC2 for <aaa-wg@merit.edu>; Wed, 30 May 2001 04:37:03 -0400 (EDT) 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 CAA17554; Wed, 30 May 2001 02:36:49 -0600 (MDT) Received: from vayne (muc-isdn-12 [129.157.164.112]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id KAA28412; Wed, 30 May 2001 10:36:49 +0200 (MET DST) Date: Wed, 30 May 2001 10:48:33 +0200 (MET DST) From: Erik Guttman <Erik.Guttman@Sun.COM> Reply-To: Erik Guttman <Erik.Guttman@Sun.COM> Subject: Re: [AAA-WG]: What to do about open issues? To: Pat Calhoun <pcalhoun@diameter.org> Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <20010529140539.T30735@charizard.diameter.org> Message-ID: <Roam.SIMC.2.0.6.991212513.17821.erikg@ehdb03-home.germany> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk >>17.0 Open Issues > Does anyone object if I remove section 17? Since we are using standardized > AVP definitions, where Unsigned32 can be used as time, and this is already > done in SMI, is the following really needed? No. If it hasn't been an issue for anyone over the past 23 drafts of Diameter, it isn't one now. Remove it. Erik From owner-aaa-bof@merit.edu Wed May 30 05:48:20 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04299 for <aaa-archive@odin.ietf.org>; Wed, 30 May 2001 05:48:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0BE9F91285; Wed, 30 May 2001 05:48:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C5BC891287; Wed, 30 May 2001 05:48:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A6DA291285 for <aaa-wg@trapdoor.merit.edu>; Wed, 30 May 2001 05:48:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D5A315DE30; Wed, 30 May 2001 05:48:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 73D7D5DE19 for <aaa-wg@merit.edu>; Wed, 30 May 2001 05:48:19 -0400 (EDT) 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 DAA05215; Wed, 30 May 2001 03:48:09 -0600 (MDT) Received: from vayne (muc-isdn-12 [129.157.164.112]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id LAA29204; Wed, 30 May 2001 11:48:08 +0200 (MET DST) Date: Wed, 30 May 2001 11:59:52 +0200 (MET DST) From: Erik Guttman <Erik.Guttman@Sun.COM> Reply-To: Erik Guttman <Erik.Guttman@Sun.COM> Subject: Re: [AAA-WG]: [Issue] Proposed fix for Grouped AVP (Issue 11) To: Pat Calhoun <pcalhoun@diameter.org> Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <20010529121405.O30735@charizard.diameter.org> Message-ID: <Roam.SIMC.2.0.6.991216792.32570.erikg@ehdb03-home.germany> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, A couple comments on resolution to Issue #11: > Every Grouped AVP defined MUST include a corresponding ABNF [31] > specification, which is used to define the AVPs that MUST, MAY and > MUST NOT be present. This is no longer true. The Diameter modified ABNF has special rules for optional terms which are not in ABNF. For instance, a term in the optional AVP section cannot evaluate to a term in a fixed or required section. Suggested fix: Every Grouped AVP defined MUST include a corresponding grammar, using ABNF [31] with Diameter extensions, as defined below. > 4.4.1 Example AVP with a Grouped Data type > > The Example AVP (AVP Code 999999) is of type Grouped and is used to > clarify how Grouped AVP values work. The Grouped Data field has the > following ABNF grammar: > > Example-AVP ::= < AVP Header: 999999 > > { Origin-Host } > { Host-IP-Address } A better example, to show how flexible things are now, is to give the following example: Example-AVP ::= < AVP Header: 999999 > { Origin-Host } 1*{ Session-Id } *[ AVP ] An Example AVP with Grouped Data follows. The Origin-Host AVP is required. In this case: Origin-Host = "example.com". One or more Session-Ids must follow. Here there are two: Session-Id = "grump.example.com:33041;23432;893;0AF3B81" Session-Id = "grump.example.com:33054;23561;2358;0AF3B82" optional AVPs included are Recovery-Policy = <binary> 2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35 2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5 c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119 26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c 1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92 Futuristic-Acct-Record = <binary> fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0 57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8 17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c 41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067 d3427475e49968f841 The data for the optional AVPs is represented in hex since the format of these AVPs is neither known at the time of definition of the Example-AVP group, nor (likely) at the time when the example instance of this AVP is interpreted - except by Diameter implementations which support the same set of AVPs. The encoding example illustrates how padding is used, how length fields are calculated and how AVPs do not have to begin on 8 byte boundaries. Also note that AVPs may be present in the Grouped AVP value which the receiver cannot interpret (here, the Recover-Policy and Futuristic-Acct-Record AVPs). This AVP would be encoded as follows: 0 1 2 3 4 5 6 7 +-------+-------+-------+-------+-------+-------+-------+-------+ 0 | Example AVP Header (AVP Code = 999999), Length = 468 | +-------+-------+-------+-------+-------+-------+-------+-------+ 8 | Origin-Host AVP Header (AVP Code = 264), Length = 19 | +-------+-------+-------+-------+-------+-------+-------+-------+ 16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' | +-------+-------+-------+-------+-------+-------+-------+-------+ 24 | 'c' | 'o' | 'm' |Padding| Session-Id AVP Header | +-------+-------+-------+-------+-------+-------+-------+-------+ 32 | (AVP Code = 263), Length = 50 | 'g' | 'r' | 'u' | 'm' | +-------+-------+-------+-------+-------+-------+-------+-------+ . . . +-------+-------+-------+-------+-------+-------+-------+-------+ 64 | 'A' | 'F' | '3' | 'B' | '8' | '1' |Padding|Padding| +-------+-------+-------+-------+-------+-------+-------+-------+ 68 | Session-Id AVP Header (AVP Code = 263), Length = 51 | +-------+-------+-------+-------+-------+-------+-------+-------+ 72 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x' | +-------+-------+-------+-------+-------+-------+-------+-------+ . . . +-------+-------+-------+-------+-------+-------+-------+-------+ 104 | '0' | 'A' | 'F' | '3' | 'B' | '8' | '2' |Padding| +-------+-------+-------+-------+-------+-------+-------+-------+ 112 | Recovery-Policy Header (AVP Code = 8341), Length = 223 | +-------+-------+-------+-------+-------+-------+-------+-------+ 120 | 0x21 | 0x63 | 0xbc | 0x1d | 0x0a | 0xd8 | 0x23 | 0x71 | +-------+-------+-------+-------+-------+-------+-------+-------+ . . . +-------+-------+-------+-------+-------+-------+-------+-------+ 320 | 0x2f | 0xd7 | 0x96 | 0x6b | 0x8c | 0x7f | 0x92 |Padding| +-------+-------+-------+-------+-------+-------+-------+-------+ 328 | Futuristic-Acct-Record Header (AVP Code = 15930), Length = 137| +-------+-------+-------+-------+-------+-------+-------+-------+ 336 | 0xfe | 0x19 | 0xda | 0x58 | 0x02 | 0xac | 0xd9 | 0x8b | +-------+-------+-------+-------+-------+-------+-------+-------+ . . . +-------+-------+-------+-------+-------+-------+-------+-------+ 464 | 0x41 |Padding|Padding|Padding| +-------+-------+-------+-------+ --- Erik From owner-aaa-bof@merit.edu Wed May 30 09:42:08 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10661 for <aaa-archive@odin.ietf.org>; Wed, 30 May 2001 09:42:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3D1EC91292; Wed, 30 May 2001 09:42:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0AC6C91293; Wed, 30 May 2001 09:42:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B807E91292 for <aaa-wg@trapdoor.merit.edu>; Wed, 30 May 2001 09:41:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4B4E05DDBF; Wed, 30 May 2001 09:42:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id B52145DD9E for <aaa-wg@merit.edu>; Wed, 30 May 2001 09:42:08 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id JAA09226 for <aaa-wg@merit.edu>; Wed, 30 May 2001 09:36:19 -0400 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id JAA05905 for <aaa-wg@merit.edu>; Wed, 30 May 2001 09:42:59 -0400 (EDT) From: "Mark Jones" <mjones@bridgewatersystems.com> To: "IETF AAA WG" <aaa-wg@merit.edu> Subject: [AAA-WG]: [issue] Issue #22: Enums Date: Wed, 30 May 2001 09:42:56 -0400 MIME-Version: 1.0 Message-ID: <020601c0e90e$6ee836e0$2096a8c0@mjones.bridgewatersys.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_01FB_01C0E8EC.E6BA5170" Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01FB_01C0E8EC.E6BA5170 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Submitter name: Mark Jones Submitter email address: mjones@bridgewatersystems.com Date first submitted: May, 2001 Reference: Issue #22 on http://www.diameter.org/issues.html Document: Base Comment type: T Priority: 1 or 2 (?) Section: 4.3 Rationale/Explanation of issue: At the interim meeting, a proposal for the introduction of a new data type (or subtype) of Enumerated met with a favorable response so I am posting it to the list for comments. As with Mark Eklund's suggestion for UTF8, guidance is sought from SMI gurus on the most appropriate way to introduce Enums into the base protocol. Enumerated types are defined in the NASREQ extension already and are different from the currently defined types in how they are validated, encoded and allocated. An enumerated type defines an explicit list of unsigned 32-bit integer values that an AVP may take. This allows a Diameter peer to validate and reject commands containing an enumerated AVP with an invalid value (Result-Code = DIAMETER_INVALID_AVP_VALUE). When encoding enumerated types there is a translation step from a name to a corresponding integer value (either in the server itself or the provisioning application). Service provisioning applications make use of the enumerated type definition to validate data entry or offer a drop-down list of possible names/values. Enumerated types are also treated differently when it comes to allocating the values in order to avoid overlapping values being used by different implementations, e.g. NASREQ/RADIUS enumerated types are controlled by IANA (see http://www.iana.org/assignments/radius-types). A similar approach is required for the values of enumerated types defined in the Diameter extensions. The values of vendor-specific Enumerated AVPs would be controlled by the vendor themselves and not by IANA. Requested change: Add a new subtype of Unsigned32 as follows: Unsigned32 32 bit unsigned value, in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled). Enumerated 32 bit unsigned value, in network byte order, where the list of valid values and their interpretation is described in the Diameter extension introducing the AVP. As with Unsigned32, the AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled). Regards, Mark ------=_NextPart_000_01FB_01C0E8EC.E6BA5170 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw ggH9oAMCAQICAwS4ODANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDUwMTE4MTgwOFoXDTAyMDUwMTE4MTgwOFowTzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdbWpvbmVzQGJyaWRnZXdhdGVyc3lzdGVt cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMemr5diJO/8+r2Hj3Opr9LbaVAXFgo2 Fhu0tfSSdvlMy52Y67GMoJbv0I282FWO9z4bsnuSIU7y3arEmyA78mwjTSdt2GK5QJHT6jKOqF6M 81Q5j2fU3dQwCPiCQZlOqUJEA3PySRjUQNOgnRUhoSuzGd7IMJ3Y6oeMtE8a02nTAgMBAAGjOjA4 MCgGA1UdEQQhMB+BHW1qb25lc0BicmlkZ2V3YXRlcnN5c3RlbXMuY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEANyubKv2ajV9VxVe4xUDaqZbQ2DEXgGKSFWwsdC06zUucuCmeHHqT vLcoUnI8/dCbSnSwRrELpemSoqTv/99uW+jS6cN5320w1ZEBsC2RSVrSJd8LqxKALmMexgbywYvF /hMe120ctocvwnfbeZmzBIKSF7BDs8YPGzSWgsa5gKUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2 17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP 6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9 edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O +PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R hGvk+NHOd6KBMYICmzCCApcCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDBLg4MAkGBSsOAwIaBQCgggFWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDUzMDEzNDI1NFowIwYJKoZIhvcNAQkEMRYEFOqQw0CMIQj35BulV1ZuiHW/tGrv MEkGCSqGSIb3DQEJDzE8MDowCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMAIDBLg4MA0GCSqGSIb3DQEBAQUABIGATw2dgrrNqTNkFIEVVaYkpQFe DpENNjoW7sWS/fxQAzKDXPcKewPVFrGX+oVuEF5vG93yz5Eej2F4RJI26aNK4U1p+T7GlQTld5Gb E9dlFYUiz+fZY9HMNVsshog7Ztj7jU/vwi1uJV1UabhY0buIxXRVEkVBfHInOVDq1G1F0UQAAAAA AAA= ------=_NextPart_000_01FB_01C0E8EC.E6BA5170-- From owner-aaa-bof@merit.edu Wed May 30 13:52:58 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19717 for <aaa-archive@odin.ietf.org>; Wed, 30 May 2001 13:52:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1651891299; Wed, 30 May 2001 13:52:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D5FD19129B; Wed, 30 May 2001 13:52:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CC12491299 for <aaa-wg@trapdoor.merit.edu>; Wed, 30 May 2001 13:52:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C0C505DDB2; Wed, 30 May 2001 13:53:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 1648C5DD9E for <aaa-wg@merit.edu>; Wed, 30 May 2001 13:53:06 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id KAA50865; Wed, 30 May 2001 10:43:01 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 30 May 2001 10:43:01 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: aaa-wg@merit.edu Cc: aboba@internaut.com Subject: [AAA-WG]: [issue] flag bit for start of conversation Message-ID: <Pine.BSF.4.21.0105301042200.50852-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 30-May-2001 Reference: Document: Base Comment type: T Priority: 1 Section: Rationale/Explanation of issue: For use in load balancing, it can be important to easily discern whether a request constitutes the beginning of a conversation or not. For example, if EAP is in use, there could be many requests within a given conversation, and if the request were to be sent to another server in the middle, ongoing conversations could fail. It does not appear to me that any of the existing flag bits can be used to determine this. Requested change: Addition of Flag bit to denote "start of conversation". From owner-aaa-bof@merit.edu Wed May 30 14:31:25 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20863 for <aaa-archive@odin.ietf.org>; Wed, 30 May 2001 14:31:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E6F4E9129B; Wed, 30 May 2001 14:31:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BAAAF9129C; Wed, 30 May 2001 14:31:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A06FE9129B for <aaa-wg@trapdoor.merit.edu>; Wed, 30 May 2001 14:31:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1961B5DDCF; Wed, 30 May 2001 14:31:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 060005DDBF for <aaa-wg@merit.edu>; Wed, 30 May 2001 14:31:16 -0400 (EDT) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 5B0FA7A; Wed, 30 May 2001 14:31:15 -0400 (EDT) Message-ID: <3B153C1F.ABB9AC45@Interlinknetworks.com> Date: Wed, 30 May 2001 14:29:51 -0400 From: David Spence <DSpence@Interlinknetworks.com> Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba <Aboba@Internaut.com>, David Mitton <David@Mitton.com>, AAA Working Group <aaa-wg@merit.edu>, David Mitton <DMitton@Nortelnetworks.com> Subject: Re: [AAA-WG]: [issue] Server Identification References: <3B058795.D1B019A0@Interlinknetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Resolution of: > > Subject: [issue] Server Identification > > Submitter name: David Spence > Submitter email address: DSpence@Interlinknetworks.com > Date first submitted: May 18, 2001 > Reference: > Document: Base > Comment type: T > Priority: 1 > Section: 5.1, 5.3, 8.4, 11.4.3, 11.7 and others > Rationale/Explanation of issue: > > There are various places in the base protocol specification that > assume that only one copy of a Diameter server can run on a host and > therefore that a Diameter server can be uniquely identified by an > FQDN or an IP address. It would be helpful to allow for multiple > server processes to run on a host. Some of the places where this > assumption is made are as follows: > > 1. DRI election process > > There is a problem in the DRI election process, where a server is > identified solely by FQDN. The DRI election process resolves by > comparing FQDNs and assumes that they won't be the same. > > 2. Origin-FQDN AVP and Destination-FQDN AVP > > The Origin-FQDN and Destination-FQDN AVPs are used for final hop > routing. > > 3. Route-Record AVP > > The Route-Record AVP is also FQDN based and is used both for > routing and for loop detection. > > This issue was actually raised in February on the mailing list. > (See Pat Calhoun email of Friday, February 23, 2001 8:30 AM.) The > thread died without resolution, but Pat's final question was > "whether multiple aaad processes on a single box is a > requirement?" > > 4. Error-Reporting-FQDN AVP > > The Error-Reporting-FQDN AVP is also FQDN based and is used for > identifying a Diameter server. > > There is one place where Diameter does accommodate multiple servers > per host. A redirect host is identified by a Redirect-Host grouped > AVP which contains an FQDN and a port. > > Requested change: > > Invent a general way to identify an instance of a Diameter server. A > combination of FQDN and TCP/SCTP port number is suggested. Use this > combination in each of the above AVPs. > Resolution: At the May interim meeting, we decided to use a Diameter URL instead of host and port number AVPs. The Diameter server URL would look something like: diameter://host.domain:port;transport=sctp SIP does a similar thing, and we copied their way of indicating transport. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Wed May 30 15:44:52 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22620 for <aaa-archive@odin.ietf.org>; Wed, 30 May 2001 15:44:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9C6D1912A3; Wed, 30 May 2001 15:44:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63E26912A4; Wed, 30 May 2001 15:44:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4FC86912A3 for <aaa-wg@trapdoor.merit.edu>; Wed, 30 May 2001 15:44:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5C4805DDCC; Wed, 30 May 2001 15:45:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 48B595DDBF for <aaa-wg@merit.edu>; Wed, 30 May 2001 15:45:00 -0400 (EDT) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 9429B7A; Wed, 30 May 2001 15:44:59 -0400 (EDT) Message-ID: <3B154D65.C578BA12@Interlinknetworks.com> Date: Wed, 30 May 2001 15:43:33 -0400 From: David Spence <DSpence@Interlinknetworks.com> Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba <Aboba@Internaut.com>, David@Mitton.com, AAA Working Group <aaa-wg@merit.edu>, David Mitton <DMitton@Nortelnetworks.com> Subject: Re: [AAA-WG]: [issue] 3GPP2 Accounting Requirements References: <3B059F74.C481A12@Interlinknetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The following summarizes the discussion of this issue at the May interim meeting and raises further discussion. As discussed at the May interim meeting, the important part of this issue is how to handle multiple accounting records per authentication session. At the meeting, we decided to see if we could use the Acct-Multi-Session-Id AVP for this purpose. We did not discuss the details, so the following is how I imagine this might work. The idea is that the Acct-Multi-Session-ID AVP would replace the Correlation-ID attribute defined by 3GPP2. It would be included both in the authentication/authorization request (AMR and HAR) messages and in the Accounting Request (ACR) message. The Session-ID AVP would take on a different value at each handoff. We would not use the Session-Continue attribute, because Diameter does not use accounting messages to control session state. At the interim meeting, we decided not to define IETF standard accounting AVPs to track the 3GPP2 accounting attributes, but to continue to allow 3GPP2 to define accounting attributes out of their vendor-specific numbering space. If we adopt this proposal then the Acct-Multi-Session-ID AVP should be specified in the base protocol. In thinking about this proposal since the interim meeting, I do have one reservation. In the primary use of the Acct-Multi-Session-ID AVP to support PPP Multilink connections, there is an authentication/ authorization request for each single link as it comes up. Thus, each Accounting-Request message can be matched to an authentication/ authorization message by using the Session-ID AVP. With the 3GPP2 standard, this will not be the case. Successive accounting sessions do not have corresponding auth/auth sessions. Instead, one long auth/auth session will match a series of shorter accounting sessions. For this reason, I think it might be better to use the auth/auth Session-ID for all of the Accounting-Request messages in the series, but to use some new AVP to indicate that this is one of a series of Accounting-Requests, and that all requests in the series are significant and need to be kept (that is, later messages are not updates to earlier messages which can then be thrown away). David Spence wrote: > > Subject: [issue] 3GPP2 Accounting Requirements > > Submitter name: David Spence > Submitter email address: DSpence@Interlinknetworks.com > Date first submitted: May 18, 2001 > Reference: http://www.3gpp2.org/Public_html/specs/P.S0001-A-1.pdf > Document: Accounting, MobileIP > Comment type: T > Priority: ? > Section: > Rationale/Explanation of issue: > > Is it an AAA WG requirement that we meet 3GPP2 requirements? If so, > then the following may be an issue. > > 3GPP2 document P.S0001-A-1, "Wireless IP Network Standard" specifies > use of a variety of public standards to realize wireless IP service. > Included in the document is a specification for how RADIUS should be > used. A number of RADIUS vendor-specific attributes are defined > including many accounting attributes. > > The standard realizes version 1 of an architecture defined in 3GPP2 > document P.R0001, "Wireless IP Architecture Based on IETF Protocols". > Version 2 of the architecture specified in this document goes on to > define a number of AAA requirements essentially all met by Diameter > with the exceptions described below. > > The "Wireless IP Network Standard" defines quite a number of > vendor-specific accounting attributes, many of which report Radio > Network counters. When a wireless handoff takes place, the counts > collected at the old Radio Network need to be transmitted to the > accounting server. Thus, at the end of the Packet Data Session, > there may be multiple accounting sub-records. The standard specifies > two ways to handle this in RADIUS. The first is to bundle the > attributes of a subsession into an Accounting-Container attribute > (similar to a Grouped type AVP). This requires these attributes to > be held in the Packet Data Serving Node (PDSN -- the node that > contains the FA) until the end of the session and then they are all > sent to the AAA server in a single Accounting Stop message. To allow > subsession accounting data to be forwarded to the AAA servers as > generated, the standard specifies a second method. A vendor specific > Correlation-ID attribute is defined to supplement the RADIUS > Account-Session ID attribute. They also define a Session-Continue > attribute. Each time during the session that a PDSN has accounting > data to send, it generates an Accounting Stop message which includes > a Session-Contine attribute with a value of True. This is > immediately followed by an Accounting Start message with a new > Account-Session ID which begins the next sub-session. All accounting > messages sent for the Packet Data Session contain the same value of > the Correlation-ID attribute which then becomes the session > identifier that can be used to correlate accounting messages with > authentication messages. This is messy in RADIUS and would be worse > in Diameter. > > Requested change: > > 1. Define all the 3GPP2 vendor specific accounting attributes as > Diameter AVPs in the MIP extension. > > 2. Invent a clean way to carry subsession accounting data in > Diameter, perhaps by inventing a Subsession-Identifier AVP and a > Subsession accounting message in the base protocol. > > -- > 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 Wed May 30 16:28:27 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23685 for <aaa-archive@odin.ietf.org>; Wed, 30 May 2001 16:28:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5A5829129F; Wed, 30 May 2001 16:28:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2BFE9912A5; Wed, 30 May 2001 16:28:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 13CD99129F for <aaa-wg@trapdoor.merit.edu>; Wed, 30 May 2001 16:28:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3B2945DDBF; Wed, 30 May 2001 16:28:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id C157C5DDCC for <aaa-wg@merit.edu>; Wed, 30 May 2001 16:28:28 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA22676; Wed, 30 May 2001 16:23:29 -0400 (EDT) Date: Wed, 30 May 2001 16:24:35 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: Bernard Aboba <aboba@internaut.com> Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] flag bit for start of conversation In-Reply-To: <Pine.BSF.4.21.0105301042200.50852-100000@internaut.com> Message-ID: <Pine.GSO.4.21.0105301619380.29780-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Bernard, You can use the Origin-FQDN from the reply of the initial request as the Destination-FQDN for the requests following that. Does this accomplish what you are requesting? -mark On Wed, 30 May 2001, Bernard Aboba wrote: > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: 30-May-2001 > Reference: > Document: Base > Comment type: T > Priority: 1 > Section: > Rationale/Explanation of issue: > > For use in load balancing, it can be important to easily discern > whether a request constitutes the beginning of a conversation or not. > For example, if EAP is in use, there could be many requests within a given > conversation, and if the request were to be sent to another server in > the middle, ongoing conversations could fail. It does not appear to me > that any of the existing flag bits can be used to determine this. > > Requested change: > Addition of Flag bit to denote "start of conversation". > From owner-aaa-bof@merit.edu Wed May 30 16:29:40 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23709 for <aaa-archive@odin.ietf.org>; Wed, 30 May 2001 16:29:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 72FA0912A5; Wed, 30 May 2001 16:29:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44A8A912A6; Wed, 30 May 2001 16:29:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 245CE912A5 for <aaa-wg@trapdoor.merit.edu>; Wed, 30 May 2001 16:29:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 58CB65DDD2; Wed, 30 May 2001 16:29:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 45D905DDCC for <aaa-wg@merit.edu>; Wed, 30 May 2001 16:29:55 -0400 (EDT) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 9522C7A; Wed, 30 May 2001 16:29:54 -0400 (EDT) Message-ID: <3B1557EB.D71E8898@Interlinknetworks.com> Date: Wed, 30 May 2001 16:28:27 -0400 From: David Spence <DSpence@Interlinknetworks.com> Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba <Aboba@Internaut.com>, David@Mitton.com, AAA Working Group <aaa-wg@merit.edu>, David Mitton <DMitton@Nortelnetworks.com> Subject: Re: [AAA-WG]: [issue] Required Transports References: <3B086709.96B74A62@Interlinknetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Resolution to: > > Subject: [issue] Required Transports > > Submitter name: David Spence > Submitter email address: DSpence@Interlinknetworks.com > Date first submitted: May 20, 2001 > Reference: > > From: DSpence@Interlinknetworks.com > Date: May 20, 2001 > Subject: Re: [AAA-WG]: transport MUSTs > > Document: Base > Comment type: T > Priority: S > Section: 2.1 > Rationale/Explanation of issue: > > The following sentence from section 2.1 is unclear: > > "Diameter clients SHOULD support SCTP, but MUST support TCP if SCTP > is not available." > > It appears to allow Diameter clients not to support TCP. This would be > contrary to past WG decision. > > Requested change: > > The sentence should read: > > "Diameter clients MUST support TCP and MAY support SCTP." > Resolution: The consensus reached at the May interim meeting on this issue is to change the approach agreed to last February. The new position is that clients MUST support either SCTP or TCP. This allows for SCTP-only clients, TCP-only clients, or clients that support both. Servers MUST support both SCTP and TCP. Transport negotiation is simplified. Servers always connect to servers using SCTP unless explicitly configured to do otherwise. For client-server connections, the client initiates the connection using whichever transport it supports or prefers. The change in reasoning is as follows. We no longer care about the firewall issue. Firewalls can be made to pass SCTP. If finer grained control is needed, it will soon be offered by the firewall vendors. Similarly, we are no longer concerned about operating system support. The requirement is for servers to support SCTP. We do not specify whether the support is provided in the application or in the operating system. If the Diameter server application expects operating system support, then that server can only fully support the standard by running on an operating system that supports SCTP. With regard to the security issue, we recognize that there are issues running SCTP over IPsec and running TLS over SCTP. But we feel that these issues must be urgently addressed. IPsec would have problems with the multiple IP addresses supported by SCTP. However, Diameter does not need multiple addresses, so it appears that IPsec can still be used with Diameter/SCTP. TLS would have difficulty running over multiple SCTP streams. Multiple streams are required to prevent head of line blocking. We need to resolve this problem, but running Diameter over TLS over a single SCTP stream would be no worse than running Diameter over TLS over TCP, so there is no need to require use of TCP with TLS. The interoperability of SCTP with IPsec and TLS requires further study, however, before Diameter goes to last call. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Wed May 30 16:39:30 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23985 for <aaa-archive@odin.ietf.org>; Wed, 30 May 2001 16:39:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 31851912A6; Wed, 30 May 2001 16:39:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E92A3912A8; Wed, 30 May 2001 16:39:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D90AB912A6 for <aaa-wg@trapdoor.merit.edu>; Wed, 30 May 2001 16:39:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1701B5DDD2; Wed, 30 May 2001 16:39:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 7D3835DDCC for <aaa-wg@merit.edu>; Wed, 30 May 2001 16:39:27 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id QAA02315; Wed, 30 May 2001 16:25:23 -0400 (EDT) Message-Id: <4.1.20010530154419.01cbf400@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 30 May 2001 16:12:49 -0400 To: Pat Calhoun <pcalhoun@diameter.org>, David Spence <DSpence@Interlinknetworks.com> From: Paul Funk <paul@funk.com> Subject: Re: [AAA-WG]: [issue] Server Identification Cc: Bernard Aboba <Aboba@Internaut.com>, David Mitton <David@Mitton.com>, AAA Working Group <aaa-wg@merit.edu>, David Mitton <DMitton@Nortelnetworks.com> In-Reply-To: <20010530112413.F2279@charizard.diameter.org> References: <3B153C1F.ABB9AC45@Interlinknetworks.com> <3B058795.D1B019A0@Interlinknetworks.com> <3B153C1F.ABB9AC45@Interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk I believe the scheme can also be optional, allowing reduction of the text size. In URI terms (RFC 2396), we can use a relative URI, with an application- defined base URI of "diameter://". Thus, the examples can be reduced to: host.abc.com host.abc.com:6666 host.abc.com;transport=tcp host.abc.com:6666;transport=tcp In effect, the diameter scheme becomes a formality for adhering to URI rules. We should probably make reference to URIs and RFC 2396 in the text. Paul At 11:24 AM 5/30/01 -0700, Pat Calhoun wrote: >On Wed, May 30, 2001 at 02:29:51PM -0400, David Spence wrote: >> Resolution of: >> > >> > Subject: [issue] Server Identification >> > >> > Submitter name: David Spence >> > Submitter email address: DSpence@Interlinknetworks.com >> > Date first submitted: May 18, 2001 >> > Reference: >> > Document: Base >> > Comment type: T >> > Priority: 1 >> > Section: 5.1, 5.3, 8.4, 11.4.3, 11.7 and others >> > Rationale/Explanation of issue: >> > >> > There are various places in the base protocol specification that >> > assume that only one copy of a Diameter server can run on a host and >> > therefore that a Diameter server can be uniquely identified by an >> > FQDN or an IP address. It would be helpful to allow for multiple >> > server processes to run on a host. Some of the places where this >> > assumption is made are as follows: >> > >> > 1. DRI election process >> > >> > There is a problem in the DRI election process, where a server is >> > identified solely by FQDN. The DRI election process resolves by >> > comparing FQDNs and assumes that they won't be the same. >> > >> > 2. Origin-FQDN AVP and Destination-FQDN AVP >> > >> > The Origin-FQDN and Destination-FQDN AVPs are used for final hop >> > routing. >> > >> > 3. Route-Record AVP >> > >> > The Route-Record AVP is also FQDN based and is used both for >> > routing and for loop detection. >> > >> > This issue was actually raised in February on the mailing list. >> > (See Pat Calhoun email of Friday, February 23, 2001 8:30 AM.) The >> > thread died without resolution, but Pat's final question was >> > "whether multiple aaad processes on a single box is a >> > requirement?" >> > >> > 4. Error-Reporting-FQDN AVP >> > >> > The Error-Reporting-FQDN AVP is also FQDN based and is used for >> > identifying a Diameter server. >> > >> > There is one place where Diameter does accommodate multiple servers >> > per host. A redirect host is identified by a Redirect-Host grouped >> > AVP which contains an FQDN and a port. >> > >> > Requested change: >> > >> > Invent a general way to identify an instance of a Diameter server. A >> > combination of FQDN and TCP/SCTP port number is suggested. Use this >> > combination in each of the above AVPs. >> > >> >> Resolution: >> >> At the May interim meeting, we decided to use a Diameter URL instead of >> host and port number AVPs. The Diameter server URL would look something >> like: >> >> diameter://host.domain:port;transport=sctp >> >> SIP does a similar thing, and we copied their way of indicating >> transport. >> >The actual text that I propose is as follows: > >2.7 Diameter Identity Encoding > > Several Diameter AVPs are used to include a node's identity, such as > the Destination-Host, Origin-Host, Route-Record, etc. The contents of > such AVPs MUST follow the encoding rules defined in this section. > > Diameter-Identity = "diameter://" fqdn [ port ] > [ transport ] > > fqdn = Fully Qualified Host Name > > port = ":" port > ; If absent, the default Diameter port (TBD) is assumed. > > transport = ";transport=" ( "tcp" | "sctp" ) > ; If absent, the default SCPT [26] protocol is assumed. > > The following are examples of valid Diameter host identities: > > diameter://host.abc.com > diameter://host.abc.com:6666 > diameter://host.abc.com;transport=tcp > diameter://host.abc.com:6666;transport=tcp Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Wed May 30 16:59:48 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24585 for <aaa-archive@odin.ietf.org>; Wed, 30 May 2001 16:59:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7D2929129C; Wed, 30 May 2001 14:35:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48B8E9129E; Wed, 30 May 2001 14:35:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 101379129C for <aaa-wg@trapdoor.merit.edu>; Wed, 30 May 2001 14:35:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E7B775DDB8; Wed, 30 May 2001 14:36:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 1EE215DD9E for <aaa-wg@merit.edu>; Wed, 30 May 2001 14:36:04 -0400 (EDT) Received: (qmail 3965 invoked by uid 500); 30 May 2001 18:24:15 -0000 Date: Wed, 30 May 2001 11:24:13 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: David Spence <DSpence@Interlinknetworks.com> Cc: Bernard Aboba <Aboba@Internaut.com>, David Mitton <David@Mitton.com>, AAA Working Group <aaa-wg@merit.edu>, David Mitton <DMitton@Nortelnetworks.com> Subject: Re: [AAA-WG]: [issue] Server Identification Message-ID: <20010530112413.F2279@charizard.diameter.org> Mail-Followup-To: David Spence <DSpence@Interlinknetworks.com>, Bernard Aboba <Aboba@Internaut.com>, David Mitton <David@Mitton.com>, AAA Working Group <aaa-wg@merit.edu>, David Mitton <DMitton@Nortelnetworks.com> References: <3B058795.D1B019A0@Interlinknetworks.com> <3B153C1F.ABB9AC45@Interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B153C1F.ABB9AC45@Interlinknetworks.com>; from DSpence@Interlinknetworks.com on Wed, May 30, 2001 at 02:29:51PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, May 30, 2001 at 02:29:51PM -0400, David Spence wrote: > Resolution of: > > > > Subject: [issue] Server Identification > > > > Submitter name: David Spence > > Submitter email address: DSpence@Interlinknetworks.com > > Date first submitted: May 18, 2001 > > Reference: > > Document: Base > > Comment type: T > > Priority: 1 > > Section: 5.1, 5.3, 8.4, 11.4.3, 11.7 and others > > Rationale/Explanation of issue: > > > > There are various places in the base protocol specification that > > assume that only one copy of a Diameter server can run on a host and > > therefore that a Diameter server can be uniquely identified by an > > FQDN or an IP address. It would be helpful to allow for multiple > > server processes to run on a host. Some of the places where this > > assumption is made are as follows: > > > > 1. DRI election process > > > > There is a problem in the DRI election process, where a server is > > identified solely by FQDN. The DRI election process resolves by > > comparing FQDNs and assumes that they won't be the same. > > > > 2. Origin-FQDN AVP and Destination-FQDN AVP > > > > The Origin-FQDN and Destination-FQDN AVPs are used for final hop > > routing. > > > > 3. Route-Record AVP > > > > The Route-Record AVP is also FQDN based and is used both for > > routing and for loop detection. > > > > This issue was actually raised in February on the mailing list. > > (See Pat Calhoun email of Friday, February 23, 2001 8:30 AM.) The > > thread died without resolution, but Pat's final question was > > "whether multiple aaad processes on a single box is a > > requirement?" > > > > 4. Error-Reporting-FQDN AVP > > > > The Error-Reporting-FQDN AVP is also FQDN based and is used for > > identifying a Diameter server. > > > > There is one place where Diameter does accommodate multiple servers > > per host. A redirect host is identified by a Redirect-Host grouped > > AVP which contains an FQDN and a port. > > > > Requested change: > > > > Invent a general way to identify an instance of a Diameter server. A > > combination of FQDN and TCP/SCTP port number is suggested. Use this > > combination in each of the above AVPs. > > > > Resolution: > > At the May interim meeting, we decided to use a Diameter URL instead of > host and port number AVPs. The Diameter server URL would look something > like: > > diameter://host.domain:port;transport=sctp > > SIP does a similar thing, and we copied their way of indicating > transport. > The actual text that I propose is as follows: 2.7 Diameter Identity Encoding Several Diameter AVPs are used to include a node's identity, such as the Destination-Host, Origin-Host, Route-Record, etc. The contents of such AVPs MUST follow the encoding rules defined in this section. Diameter-Identity = "diameter://" fqdn [ port ] [ transport ] fqdn = Fully Qualified Host Name port = ":" port ; If absent, the default Diameter port (TBD) is assumed. transport = ";transport=" ( "tcp" | "sctp" ) ; If absent, the default SCPT [26] protocol is assumed. The following are examples of valid Diameter host identities: diameter://host.abc.com diameter://host.abc.com:6666 diameter://host.abc.com;transport=tcp diameter://host.abc.com:6666;transport=tcp From owner-aaa-bof@merit.edu Wed May 30 17:45:05 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25395 for <aaa-archive@odin.ietf.org>; Wed, 30 May 2001 17:45:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 21D44912A8; Wed, 30 May 2001 16:42:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5972912A9; Wed, 30 May 2001 16:42:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B2FE3912A8 for <aaa-wg@trapdoor.merit.edu>; Wed, 30 May 2001 16:42:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E31EE5DDCC; Wed, 30 May 2001 16:43:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id E2ABA5DDBF for <aaa-wg@merit.edu>; Wed, 30 May 2001 16:42:55 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA22838; Wed, 30 May 2001 16:37:04 -0400 (EDT) Date: Wed, 30 May 2001 16:38:10 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: Pat Calhoun <pcalhoun@diameter.org> Cc: David Spence <DSpence@Interlinknetworks.com>, Bernard Aboba <Aboba@Internaut.com>, David Mitton <David@Mitton.com>, AAA Working Group <aaa-wg@merit.edu>, David Mitton <DMitton@Nortelnetworks.com> Subject: Re: [AAA-WG]: [issue] Server Identification In-Reply-To: <20010530112413.F2279@charizard.diameter.org> Message-ID: <Pine.GSO.4.21.0105301631260.29780-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, If you had If you have a proxy that speaks both radius and diameter and is connected to a radius NAS and a Diameter server, could it set the NAS identifier as below before proxying to the Diameter server? radius://nas.legacy.xyz:1813;transport=udp -mark On Wed, 30 May 2001, Pat Calhoun wrote: > On Wed, May 30, 2001 at 02:29:51PM -0400, David Spence wrote: > > Resolution of: > > > > > > Subject: [issue] Server Identification > > > > > > Submitter name: David Spence > > > Submitter email address: DSpence@Interlinknetworks.com > > > Date first submitted: May 18, 2001 > > > Reference: > > > Document: Base > > > Comment type: T > > > Priority: 1 > > > Section: 5.1, 5.3, 8.4, 11.4.3, 11.7 and others > > > Rationale/Explanation of issue: > > > > > > There are various places in the base protocol specification that > > > assume that only one copy of a Diameter server can run on a host and > > > therefore that a Diameter server can be uniquely identified by an > > > FQDN or an IP address. It would be helpful to allow for multiple > > > server processes to run on a host. Some of the places where this > > > assumption is made are as follows: > > > > > > 1. DRI election process > > > > > > There is a problem in the DRI election process, where a server is > > > identified solely by FQDN. The DRI election process resolves by > > > comparing FQDNs and assumes that they won't be the same. > > > > > > 2. Origin-FQDN AVP and Destination-FQDN AVP > > > > > > The Origin-FQDN and Destination-FQDN AVPs are used for final hop > > > routing. > > > > > > 3. Route-Record AVP > > > > > > The Route-Record AVP is also FQDN based and is used both for > > > routing and for loop detection. > > > > > > This issue was actually raised in February on the mailing list. > > > (See Pat Calhoun email of Friday, February 23, 2001 8:30 AM.) The > > > thread died without resolution, but Pat's final question was > > > "whether multiple aaad processes on a single box is a > > > requirement?" > > > > > > 4. Error-Reporting-FQDN AVP > > > > > > The Error-Reporting-FQDN AVP is also FQDN based and is used for > > > identifying a Diameter server. > > > > > > There is one place where Diameter does accommodate multiple servers > > > per host. A redirect host is identified by a Redirect-Host grouped > > > AVP which contains an FQDN and a port. > > > > > > Requested change: > > > > > > Invent a general way to identify an instance of a Diameter server. A > > > combination of FQDN and TCP/SCTP port number is suggested. Use this > > > combination in each of the above AVPs. > > > > > > > Resolution: > > > > At the May interim meeting, we decided to use a Diameter URL instead of > > host and port number AVPs. The Diameter server URL would look something > > like: > > > > diameter://host.domain:port;transport=sctp > > > > SIP does a similar thing, and we copied their way of indicating > > transport. > > > The actual text that I propose is as follows: > > 2.7 Diameter Identity Encoding > > Several Diameter AVPs are used to include a node's identity, such as > the Destination-Host, Origin-Host, Route-Record, etc. The contents of > such AVPs MUST follow the encoding rules defined in this section. > > Diameter-Identity = "diameter://" fqdn [ port ] > [ transport ] > > fqdn = Fully Qualified Host Name > > port = ":" port > ; If absent, the default Diameter port (TBD) is assumed. > > transport = ";transport=" ( "tcp" | "sctp" ) > ; If absent, the default SCPT [26] protocol is assumed. > > The following are examples of valid Diameter host identities: > > diameter://host.abc.com > diameter://host.abc.com:6666 > diameter://host.abc.com;transport=tcp > diameter://host.abc.com:6666;transport=tcp > From owner-aaa-bof@merit.edu Wed May 30 17:45:14 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25409 for <aaa-archive@odin.ietf.org>; Wed, 30 May 2001 17:45:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 873D6912AB; Wed, 30 May 2001 17:17:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB0B3912AD; Wed, 30 May 2001 17:17:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 98539912AB for <aaa-wg@trapdoor.merit.edu>; Wed, 30 May 2001 17:17:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3BCA45DE1E; Wed, 30 May 2001 17:17:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7A75D5DE12 for <aaa-wg@merit.edu>; Wed, 30 May 2001 17:17:04 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id OAA51141; Wed, 30 May 2001 14:06:55 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 30 May 2001 14:06:55 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: Mark Eklund <meklund@cisco.com> Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] flag bit for start of conversation In-Reply-To: <Pine.GSO.4.21.0105301619380.29780-100000@knox6039> Message-ID: <Pine.BSF.4.21.0105301404570.51130-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk I am thinking mostly of an intermediary. Is use of the Destination-FQDN for multi-round-trip conversations required? If so, then one can conclude that any Request with a Destination-FQDN is a continuing conversation and all other requests are new conversations. If it's not required, then some other mechanism is required to figure this out. On Wed, 30 May 2001, Mark Eklund wrote: > Bernard, > > You can use the Origin-FQDN from the reply of the initial > request as the Destination-FQDN for the requests following that. > Does this accomplish what you are requesting? > > -mark > > On Wed, 30 May 2001, Bernard Aboba wrote: > > > Submitter name: Bernard Aboba > > Submitter email address: aboba@internaut.com > > Date first submitted: 30-May-2001 > > Reference: > > Document: Base > > Comment type: T > > Priority: 1 > > Section: > > Rationale/Explanation of issue: > > > > For use in load balancing, it can be important to easily discern > > whether a request constitutes the beginning of a conversation or not. > > For example, if EAP is in use, there could be many requests within a given > > conversation, and if the request were to be sent to another server in > > the middle, ongoing conversations could fail. It does not appear to me > > that any of the existing flag bits can be used to determine this. > > > > Requested change: > > Addition of Flag bit to denote "start of conversation". > > > > > From owner-aaa-bof@merit.edu Wed May 30 18:10:57 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26119 for <aaa-archive@odin.ietf.org>; Wed, 30 May 2001 18:10:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6E842912B1; Wed, 30 May 2001 18:10:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3EB8F912B2; Wed, 30 May 2001 18:10:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3093B912B1 for <aaa-wg@trapdoor.merit.edu>; Wed, 30 May 2001 18:10:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8AE6A5DDCF; Wed, 30 May 2001 18:11:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id BD0EF5DDB7 for <aaa-wg@merit.edu>; Wed, 30 May 2001 18:11:07 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA23692; Wed, 30 May 2001 18:06:13 -0400 (EDT) Date: Wed, 30 May 2001 18:07:20 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: Bernard Aboba <aboba@internaut.com> Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] flag bit for start of conversation In-Reply-To: <Pine.BSF.4.21.0105301404570.51130-100000@internaut.com> Message-ID: <Pine.GSO.4.21.0105301744550.29900-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Bernard, I don't think you can use Destination-FQDN as the sentinal. For example issue #48, "Destination-FQDN in re-auth Messages" suggests as an option that if the server is unreachable, you MAY resend the re-auth without a Destination-FQDN. Could you give an example of how an intermediary would use the information that this is continued conversation? Your one listed in the issue was more of a routing issue. I can think of one way where your requested bit would be useful. If you get a AAR without a flag bit for start of conversation, you will know that is a re-auth. Of course, you could also look in the session state table to see if the session already exists. -mark On Wed, 30 May 2001, Bernard Aboba wrote: > I am thinking mostly of an intermediary. Is use of the Destination-FQDN > for multi-round-trip conversations required? If so, then one can conclude > that any Request with a Destination-FQDN is a continuing conversation and > all other requests are new conversations. If it's not required, then some > other mechanism is required to figure this out. > > On Wed, 30 May 2001, Mark Eklund wrote: > > > Bernard, > > > > You can use the Origin-FQDN from the reply of the initial > > request as the Destination-FQDN for the requests following that. > > Does this accomplish what you are requesting? > > > > -mark > > > > On Wed, 30 May 2001, Bernard Aboba wrote: > > > > > Submitter name: Bernard Aboba > > > Submitter email address: aboba@internaut.com > > > Date first submitted: 30-May-2001 > > > Reference: > > > Document: Base > > > Comment type: T > > > Priority: 1 > > > Section: > > > Rationale/Explanation of issue: > > > > > > For use in load balancing, it can be important to easily discern > > > whether a request constitutes the beginning of a conversation or not. > > > For example, if EAP is in use, there could be many requests within a given > > > conversation, and if the request were to be sent to another server in > > > the middle, ongoing conversations could fail. It does not appear to me > > > that any of the existing flag bits can be used to determine this. > > > > > > Requested change: > > > Addition of Flag bit to denote "start of conversation". > > > > > > > > > > From owner-aaa-bof@merit.edu Wed May 30 19:47:04 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27541 for <aaa-archive@odin.ietf.org>; Wed, 30 May 2001 19:47:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 866C9912B4; Wed, 30 May 2001 19:46:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 57D9D912B5; Wed, 30 May 2001 19:46:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 27938912B4 for <aaa-wg@trapdoor.merit.edu>; Wed, 30 May 2001 19:46:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8F16B5DE56; Wed, 30 May 2001 19:45:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id CBF5E5DE3A for <aaa-wg@merit.edu>; Wed, 30 May 2001 19:45:46 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id QAA51318; Wed, 30 May 2001 16:35:38 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 30 May 2001 16:35:38 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: Mark Eklund <meklund@cisco.com> Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] flag bit for start of conversation In-Reply-To: <Pine.GSO.4.21.0105301744550.29900-100000@knox6039> Message-ID: <Pine.BSF.4.21.0105301627240.51271-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Could you give an example of how an intermediary would use the > information that this is continued conversation? Your one > listed in the issue was more of a routing issue. > Assume we've got a stateless proxy load balancing between connections to N servers. As described in http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-03.txt we might wish to hash on the NAI to decide which connection to use for a given transaction. Say that one of the servers goes down. We now need to re-partition the workload between N-1 connections. However, we do not want to move existing connections to a new server, just new connections. Since this is a stateless proxy, we don't have a table of conversations to use in order to accomplish this. We would like to have a way to know if the transactions represents a new connection so we can execute the following logic: a. If it is a new connection, utilize the re-computed partition table to assign it to a server. b. If it is an existing connection, utilize the previously computed partition table to assign it to a server. From owner-aaa-bof@merit.edu Wed May 30 22:28:08 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00041 for <aaa-archive@odin.ietf.org>; Wed, 30 May 2001 22:28:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 98FB1912BA; Wed, 30 May 2001 22:27:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6492A912BB; Wed, 30 May 2001 22:27:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4C68E912BA for <aaa-wg@trapdoor.merit.edu>; Wed, 30 May 2001 22:27:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D11A75DE09; Wed, 30 May 2001 22:28:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 7DF2B5DE08 for <aaa-wg@merit.edu>; Wed, 30 May 2001 22:28:05 -0400 (EDT) Received: (qmail 8894 invoked by uid 500); 31 May 2001 02:16:15 -0000 Date: Wed, 30 May 2001 19:16:15 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: Bernard Aboba <aboba@internaut.com> Cc: Mark Eklund <meklund@cisco.com>, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] flag bit for start of conversation Message-ID: <20010530191615.A8869@charizard.diameter.org> Mail-Followup-To: Bernard Aboba <aboba@internaut.com>, Mark Eklund <meklund@cisco.com>, aaa-wg@merit.edu References: <Pine.GSO.4.21.0105301744550.29900-100000@knox6039> <Pine.BSF.4.21.0105301627240.51271-100000@internaut.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <Pine.BSF.4.21.0105301627240.51271-100000@internaut.com>; from aboba@internaut.com on Wed, May 30, 2001 at 04:35:38PM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, May 30, 2001 at 04:35:38PM -0700, Bernard Aboba wrote: > > Could you give an example of how an intermediary would use the > > information that this is continued conversation? Your one > > listed in the issue was more of a routing issue. > > > > Assume we've got a stateless proxy load balancing between > connections to N servers. As described in > http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-03.txt we > might wish to hash on the NAI to decide which connection to use for a > given transaction. > > Say that one of the servers goes down. We now need to re-partition the > workload between N-1 connections. However, we do not want to move existing > connections to a new server, just new connections. Since this is a > stateless proxy, we don't have a table of conversations to use in order to > accomplish this. If this is required, then I agree that some way to signal an auth or re-auth is desired. In fact, I believe that it MAY also be useful to have such a bit to inform the server that a message will create a session, and it should expect a session terminationm message in the future. Of course, for re-auth messages, the bit wouldn't be set. Keep in mind, though, that the Destination-FQDN is *always* present when the mesage is destined for a particular server, and if this is the intent of your proposal, then I still believe that the Destination-FQDN is sufficient. If the message can be sent to any server within a realm, then the AVP wouldn't be present, and stateless proxies could perform the necessary load balancing. PatC From owner-aaa-bof@merit.edu Thu May 31 01:49:57 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05629 for <aaa-archive@odin.ietf.org>; Thu, 31 May 2001 01:49:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 72502912BE; Thu, 31 May 2001 01:49:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 461DB912BF; Thu, 31 May 2001 01:49:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C906912BE for <aaa-wg@trapdoor.merit.edu>; Thu, 31 May 2001 01:48:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 309A65DE10; Thu, 31 May 2001 01:48:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id A6E185DDAE for <aaa-wg@merit.edu>; Thu, 31 May 2001 01:48:15 -0400 (EDT) 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 XAA24032; Wed, 30 May 2001 23:46:15 -0600 (MDT) Received: from vayne (muc-isdn-11 [129.157.164.111]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id HAA15059; Thu, 31 May 2001 07:46:13 +0200 (MET DST) Date: Thu, 31 May 2001 07:57:57 +0200 (MET DST) From: Erik Guttman <Erik.Guttman@Sun.COM> Reply-To: Erik Guttman <Erik.Guttman@Sun.COM> Subject: Re: [AAA-WG]: [issue] Server Identification To: David Spence <DSpence@Interlinknetworks.com> Cc: Bernard Aboba <Aboba@Internaut.com>, David Mitton <David@Mitton.com>, AAA Working Group <aaa-wg@merit.edu>, David Mitton <DMitton@Nortelnetworks.com> In-Reply-To: "Your message with ID" <3B153C1F.ABB9AC45@Interlinknetworks.com> Message-ID: <Roam.SIMC.2.0.6.991288677.29983.erikg@ehdb03-home.germany> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk An additional implication of this isssue is a modification of the service template in Appendix A. Two lines have to change: template-url-syntax= url-path= ; The standard service URL syntax is used. ; For example: 'service:diameter://aaa.example.com:1812 Should become: template-url-syntax= url-path= ; The diameter URL format is described in section XXX. ; Example: 'diameter://aaa.example.com:1812;transport=tcp Erik > Resolution of: > > > > Subject: [issue] Server Identification > > > > Submitter name: David Spence > > Submitter email address: DSpence@Interlinknetworks.com > > Date first submitted: May 18, 2001 > > Reference: > > Document: Base > > Comment type: T > > Priority: 1 > > Section: 5.1, 5.3, 8.4, 11.4.3, 11.7 and others > > Rationale/Explanation of issue: > > > > There are various places in the base protocol specification that > > assume that only one copy of a Diameter server can run on a host and > > therefore that a Diameter server can be uniquely identified by an > > FQDN or an IP address. It would be helpful to allow for multiple > > server processes to run on a host. Some of the places where this > > assumption is made are as follows: > > > > 1. DRI election process > > > > There is a problem in the DRI election process, where a server is > > identified solely by FQDN. The DRI election process resolves by > > comparing FQDNs and assumes that they won't be the same. > > > > 2. Origin-FQDN AVP and Destination-FQDN AVP > > > > The Origin-FQDN and Destination-FQDN AVPs are used for final hop > > routing. > > > > 3. Route-Record AVP > > > > The Route-Record AVP is also FQDN based and is used both for > > routing and for loop detection. > > > > This issue was actually raised in February on the mailing list. > > (See Pat Calhoun email of Friday, February 23, 2001 8:30 AM.) The > > thread died without resolution, but Pat's final question was > > "whether multiple aaad processes on a single box is a > > requirement?" > > > > 4. Error-Reporting-FQDN AVP > > > > The Error-Reporting-FQDN AVP is also FQDN based and is used for > > identifying a Diameter server. > > > > There is one place where Diameter does accommodate multiple servers > > per host. A redirect host is identified by a Redirect-Host grouped > > AVP which contains an FQDN and a port. > > > > Requested change: > > > > Invent a general way to identify an instance of a Diameter server. A > > combination of FQDN and TCP/SCTP port number is suggested. Use this > > combination in each of the above AVPs. > > > > Resolution: > > At the May interim meeting, we decided to use a Diameter URL instead of > host and port number AVPs. The Diameter server URL would look something > like: > > diameter://host.domain:port;transport=sctp > > SIP does a similar thing, and we copied their way of indicating > transport. > > -- > 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 Thu May 31 09:07:06 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23384 for <aaa-archive@odin.ietf.org>; Thu, 31 May 2001 09:07:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 034179126F; Thu, 31 May 2001 09:07:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C32AB912C2; Thu, 31 May 2001 09:07:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9A8C89126F for <aaa-wg@trapdoor.merit.edu>; Thu, 31 May 2001 09:07:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1C9565DE1F; Thu, 31 May 2001 09:07:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 373AD5DE1E for <aaa-wg@merit.edu>; Thu, 31 May 2001 09:07:12 -0400 (EDT) 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 f4VD72N25555 for <aaa-wg@merit.edu>; Thu, 31 May 2001 15:07:02 +0200 (MEST) Received: from lmf.ericsson.se (turqws113.lmf.ericsson.se [131.160.120.113]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f4VD70426817 for <aaa-wg@merit.edu>; Thu, 31 May 2001 16:07:00 +0300 (EET DST) Message-ID: <3B1641E9.790B9AD7@lmf.ericsson.se> Date: Thu, 31 May 2001 16:06:49 +0300 From: Taneli Haverinen <Taneli.Haverinen@lmf.ericsson.se> Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Error signaling ('A' msg.) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Chapter 9.1. (End-To-End Error Signaling) of the base protocol does not seem to define what to do when an error occurs while processing an Answer message. Earlier the situation was handled by sending an MRI, but this command was eliminated recently. I noticed that this problem was discussed in Pat's message "A proposal for the elimination of MRI" (http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00110.html). In that message it was proposed that a STR with a Termination-Cause should be issued. I also noticed, that Issue #10 "Sessions that do not start" deals with my question, but only in the case of authorization messages. I wonder what is the procedure in a general case? BR, Taneli Haverinen --- --- --- --- --- --- Taneli Haverinen, MSc SW Designer OY L M Ericsson AB Telecom R&D, Turku Tel: +358 2 265 3728 From owner-aaa-bof@merit.edu Thu May 31 09:41:02 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24595 for <aaa-archive@odin.ietf.org>; Thu, 31 May 2001 09:41:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CE14F912C4; Thu, 31 May 2001 09:41:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95826912C5; Thu, 31 May 2001 09:41:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 79625912C4 for <aaa-wg@trapdoor.merit.edu>; Thu, 31 May 2001 09:41:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 05C335DE1E; Thu, 31 May 2001 09:41:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 7B25A5DD9E for <aaa-wg@merit.edu>; Thu, 31 May 2001 09:41:13 -0400 (EDT) Received: (qmail 11054 invoked by uid 500); 31 May 2001 13:29:21 -0000 Date: Thu, 31 May 2001 06:29:21 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: Taneli Haverinen <Taneli.Haverinen@lmf.ericsson.se> Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Error signaling ('A' msg.) Message-ID: <20010531062921.C10291@charizard.diameter.org> Mail-Followup-To: Taneli Haverinen <Taneli.Haverinen@lmf.ericsson.se>, aaa-wg@merit.edu References: <3B1641E9.790B9AD7@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B1641E9.790B9AD7@lmf.ericsson.se>; from Taneli.Haverinen@lmf.ericsson.se on Thu, May 31, 2001 at 04:06:49PM +0300 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, May 31, 2001 at 04:06:49PM +0300, Taneli Haverinen wrote: > Hi, > Chapter 9.1. (End-To-End Error Signaling) of the base protocol does not > seem to define what to do when an error occurs while processing an > Answer message. Earlier the situation was handled by sending an MRI, but > this command was eliminated recently. I noticed that this problem was > discussed in Pat's message "A proposal for the elimination of MRI" > (http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00110.html). In > that message it was proposed that a STR with a Termination-Cause should > be issued. I also noticed, that Issue #10 "Sessions that do not start" > deals with my question, but only in the case of authorization messages. > I wonder what is the procedure in a general case? So do you mean what one does if an accounting answer is received, with an error, or a bad STA or DWA? I believe that these are the only remanining messages that aren't covered by #10. PatC From owner-aaa-bof@merit.edu Thu May 31 09:44:51 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24796 for <aaa-archive@odin.ietf.org>; Thu, 31 May 2001 09:44:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A0BE0912C3; Thu, 31 May 2001 09:20:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8226C912C2; Thu, 31 May 2001 09:19:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6B462912C3 for <aaa-wg@trapdoor.merit.edu>; Thu, 31 May 2001 09:17:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D19065DE1E; Thu, 31 May 2001 09:17:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu 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 275895DD9E for <aaa-wg@merit.edu>; Thu, 31 May 2001 09:17:33 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id PAA05390; Thu, 31 May 2001 15:17:23 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id PAA01361; Thu, 31 May 2001 15:17:22 +0200 Date: Thu, 31 May 2001 15:17:22 +0200 Message-Id: <200105311317.PAA01361@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de> To: meklund@cisco.com Cc: aaa-wg@merit.edu, erik.guttman@germany.sun.com, pcalhoun@diameter.org In-reply-to: <Pine.GSO.4.21.0105291044520.29369-100000@knox6039> (message from Mark Eklund on Tue, 29 May 2001 10:52:12 -0400 (EDT)) Subject: Re: [AAA-WG]: Re: [issue] Bring back UTF8 datatype. References: <Pine.GSO.4.21.0105291044520.29369-100000@knox6039> Sender: owner-aaa-bof@merit.edu Precedence: bulk >>>>> Mark Eklund writes: Mark> I have made the request to make UTF8 an official defined type in Mark> the Diameter Base draft. I was told that it was removed because Mark> it was not a primitive type as defined in SMI. It would be Mark> convenient to have an officially defined type of UTF8 so that Mark> other Diameter extensions could refer to it explicitly instead Mark> of doing what is now done by defining it as OctetString and then Mark> describing it as UTF8 format in the text. I argued in the AAA DT that Diameter should have a small set of base types and that there should be a mechanism to define new types which add restrictions to the core base types. Experience with SNMP tells us that the number of data types you have needs to be changed over time and that having to touch the base protocol to introduce something new is way too costly. With this in mind, I recommended to stay with an orthogonal set of base types (distinguished by type tags) and I suggested to have a kind of a typedef mechanism (in SMIng terms) or a textual convention mechanism (in SMIv2 terms) that allows to define derived types which have additional semantics. The WG did not want to go with a formal data type definition language and so we ended up where we are now. I still believe that it would be valuable to formally say something like the following (copied from draft-ietf-sming-modules-01.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."; }; You can of course do the same informally in a new section "Derived Data Types" - but you will end up with problems when you get name clashes because vendors introduce their own types and so on. Note that I also suggested to not define the Address AVP with its own type tag. Instead, I suggested to define addresses as special interpretations of OctetStrings. This again gives you flexibility to add new address formats as the need shows up. Note also that you probably need to define a bunch of additional derived types that are frequently used such as a TimeStamp or NetworkAccessIdentifier and so on. /js -- Juergen Schoenwaelder Technical University Braunschweig <schoenw@ibr.cs.tu-bs.de> Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 <URL:http://www.ibr.cs.tu-bs.de/~schoenw/> From owner-aaa-bof@merit.edu Thu May 31 09:50:20 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25016 for <aaa-archive@odin.ietf.org>; Thu, 31 May 2001 09:50:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C101D912C5; Thu, 31 May 2001 09:50:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92951912C6; Thu, 31 May 2001 09:50:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 86A56912C5 for <aaa-wg@trapdoor.merit.edu>; Thu, 31 May 2001 09:50:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 165795DDEB; Thu, 31 May 2001 09:50:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 56BE25DD9E for <aaa-wg@merit.edu>; Thu, 31 May 2001 09:50:31 -0400 (EDT) Received: (qmail 11279 invoked by uid 500); 31 May 2001 13:50:22 -0000 Date: Thu, 31 May 2001 08:50:21 -0500 From: David Frascone <dave@frascone.com> To: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de> Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: [issue] Bring back UTF8 datatype. Message-ID: <20010531085021.A10373@newman.frascone.com> Mail-Followup-To: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>, aaa-wg@merit.edu References: <Pine.GSO.4.21.0105291044520.29369-100000@knox6039> <200105311317.PAA01361@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: <200105311317.PAA01361@henkell.ibr.cs.tu-bs.de>; from schoenw@ibr.cs.tu-bs.de on Thu, May 31, 2001 at 03:17:22PM +0200 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk I brought up a similar point a while ago. I wanted a "printable as" type attribute, so you could tell if an octet string was text, or was binary (unprintable) data. Also, I wanted to be able to tell if an Integer32 was a time. The general consensus of the WG was that the protocol should be left alone, but the dictionaries in the implementation could contain extra informaiton about how to best display the AVP. So, in a dictionary, there would be a flag stating that a FQDN was really a UTF8, and that a Timestamp was really a time_t. But, the protocol would not (and should not) care. I was swayed in their direction, and I think the same applies here. The existing types can contain any possible data we need to model. -Dave On Thu, May 31, 2001 at 03:17:22PM +0200, Juergen Schoenwaelder wrote: > > >>>>> Mark Eklund writes: > > Mark> I have made the request to make UTF8 an official defined type in > Mark> the Diameter Base draft. I was told that it was removed because > Mark> it was not a primitive type as defined in SMI. It would be > Mark> convenient to have an officially defined type of UTF8 so that > Mark> other Diameter extensions could refer to it explicitly instead > Mark> of doing what is now done by defining it as OctetString and then > Mark> describing it as UTF8 format in the text. > > I argued in the AAA DT that Diameter should have a small set of base > types and that there should be a mechanism to define new types which > add restrictions to the core base types. Experience with SNMP tells us > that the number of data types you have needs to be changed over time > and that having to touch the base protocol to introduce something new > is way too costly. > > With this in mind, I recommended to stay with an orthogonal set of > base types (distinguished by type tags) and I suggested to have a kind > of a typedef mechanism (in SMIng terms) or a textual convention > mechanism (in SMIv2 terms) that allows to define derived types which > have additional semantics. The WG did not want to go with a formal > data type definition language and so we ended up where we are now. > > I still believe that it would be valuable to formally say something > like the following (copied from draft-ietf-sming-modules-01.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."; > }; > > You can of course do the same informally in a new section "Derived > Data Types" - but you will end up with problems when you get name > clashes because vendors introduce their own types and so on. > > Note that I also suggested to not define the Address AVP with its > own type tag. Instead, I suggested to define addresses as special > interpretations of OctetStrings. This again gives you flexibility > to add new address formats as the need shows up. > > Note also that you probably need to define a bunch of additional > derived types that are frequently used such as a TimeStamp or > NetworkAccessIdentifier and so on. > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > <schoenw@ibr.cs.tu-bs.de> Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 <URL:http://www.ibr.cs.tu-bs.de/~schoenw/> > > From owner-aaa-bof@merit.edu Thu May 31 10:12:12 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25878 for <aaa-archive@odin.ietf.org>; Thu, 31 May 2001 10:12:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7790C912C6; Thu, 31 May 2001 10:12:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 490D4912C7; Thu, 31 May 2001 10:12:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5DB55912C6 for <aaa-wg@trapdoor.merit.edu>; Thu, 31 May 2001 10:12:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 014A75DDEB; Thu, 31 May 2001 10:12:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 9D4F15DDD9 for <aaa-wg@merit.edu>; Thu, 31 May 2001 10:12:14 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA22643; Thu, 31 May 2001 07:12:01 -0700 (PDT) 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 HAA12160; Thu, 31 May 2001 07:11:59 -0700 (PDT) Received: from darius (darius [152.70.40.121]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with SMTP id f4VEBv214477; Thu, 31 May 2001 07:11:58 -0700 (PDT) Date: Thu, 31 May 2001 07:11:58 -0700 (PDT) From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM> Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM> Subject: Re: [AAA-WG]: [Issue] Proposed fix for Grouped AVP (Issue 11) To: Erik Guttman <Erik.Guttman@Sun.COM> Cc: Pat Calhoun <pcalhoun@diameter.org>, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <Roam.SIMC.2.0.6.991216792.32570.erikg@ehdb03-home.germany> Message-ID: <Roam.SIMC.2.0.6.991318318.2181.pcalhoun@nasnfs> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > This is no longer true. The Diameter modified ABNF has special rules > for optional terms which are not in ABNF. For instance, a term in > the optional AVP section cannot evaluate to a term in a fixed or > required section. Suggested fix: > > Every Grouped AVP defined MUST include a corresponding grammar, > using ABNF [31] with Diameter extensions, as defined below. How about: Every Grouped AVP defined MUST include a corresponding grammar, using ABNF [31], as defined below. (not sure what "with Diameter extensions" meant) PatC From owner-aaa-bof@merit.edu Thu May 31 11:13:09 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28164 for <aaa-archive@odin.ietf.org>; Thu, 31 May 2001 11:13:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2490D912C7; Thu, 31 May 2001 11:13:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E4221912C9; Thu, 31 May 2001 11:12:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E87BF912C7 for <aaa-wg@trapdoor.merit.edu>; Thu, 31 May 2001 11:12:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A497D5DE0C; Thu, 31 May 2001 11:13:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 1DFAF5DD98 for <aaa-wg@merit.edu>; Thu, 31 May 2001 11:13:10 -0400 (EDT) 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 JAA08318; Thu, 31 May 2001 09:12:58 -0600 (MDT) Received: from ehdb03-home.Germany.Sun.COM (euroapp.Holland.Sun.COM [129.159.197.58]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with ESMTP id RAA23746; Thu, 31 May 2001 17:12:43 +0200 (MET DST) From: Erik Guttman <Erik.Guttman@sun.com> Message-Id: <200105311512.RAA23746@ehdb03-home.Germany.Sun.COM> Date: Thu, 31 May 2001 16:52:33 +0-200 To: "Patrice Calhoun" <pcalhoun@nasnfs.eng.sun.com>, "Erik Guttman" <Erik.Guttman@sun.com> Cc: <aaa-wg@merit.edu>, "Pat Calhoun" <pcalhoun@diameter.org> Reply-To: <erik.guttman@germany.sun.com> Subject: Re: [AAA-WG]: [Issue] Proposed fix for Grouped AVP (Issue 11) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> This is no longer true. The Diameter modified ABNF has special rules >> for optional terms which are not in ABNF. For instance, a term in >> the optional AVP section cannot evaluate to a term in a fixed or >> required section. Suggested fix: >> >> Every Grouped AVP defined MUST include a corresponding grammar, >> using ABNF [31] with Diameter extensions, as defined below. > >How about: > Every Grouped AVP defined MUST include a corresponding grammar, > using ABNF [31], as defined below. > >(not sure what "with Diameter extensions" meant) The point is that ABNF as used in the diameter spec is not using ABNF as defined in RFC 2234. It uses ABNF with extensions, specific to Diameter. My text is ambiguous (given that Diameter extensions with a capital E means something else). How about: Every Grouped AVP defined MUST include a corresponding grammar, using ABNF [31] (with modifications), as defined below. ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n SHORT msgs: 01728655497@d2-message.de Sr Staff Engineer, Sun Microsystems Email: erik.guttman@sun.com Eichhoelzelstr. 7, 74915 Waibstadt Germany Phone: +49 172 865 5497 From owner-aaa-bof@merit.edu Thu May 31 14:54:06 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06046 for <aaa-archive@odin.ietf.org>; Thu, 31 May 2001 14:54:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 037E4912D2; Thu, 31 May 2001 14:53:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95FF1912D5; Thu, 31 May 2001 14:53:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 73536912D2 for <aaa-wg@trapdoor.merit.edu>; Thu, 31 May 2001 14:53:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 397335DDA9; Thu, 31 May 2001 14:53:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id AAEB75DD8F for <aaa-wg@merit.edu>; Thu, 31 May 2001 14:53:47 -0400 (EDT) Received: (qmail 15412 invoked by uid 500); 31 May 2001 18:41:55 -0000 Date: Thu, 31 May 2001 11:41:54 -0700 From: Pat Calhoun <pcalhoun@diameter.org> To: Mark Eklund <meklund@cisco.com> Cc: Pat Calhoun <pcalhoun@diameter.org>, David Spence <DSpence@Interlinknetworks.com>, Bernard Aboba <Aboba@Internaut.com>, David Mitton <David@Mitton.com>, AAA Working Group <aaa-wg@merit.edu>, David Mitton <DMitton@Nortelnetworks.com> Subject: Re: [AAA-WG]: [issue] Server Identification Message-ID: <20010531114154.P10291@charizard.diameter.org> Mail-Followup-To: Mark Eklund <meklund@cisco.com>, Pat Calhoun <pcalhoun@diameter.org>, David Spence <DSpence@Interlinknetworks.com>, Bernard Aboba <Aboba@Internaut.com>, David Mitton <David@Mitton.com>, AAA Working Group <aaa-wg@merit.edu>, David Mitton <DMitton@Nortelnetworks.com> References: <20010530112413.F2279@charizard.diameter.org> <Pine.GSO.4.21.0105301631260.29780-100000@knox6039> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <Pine.GSO.4.21.0105301631260.29780-100000@knox6039>; from meklund@cisco.com on Wed, May 30, 2001 at 04:38:10PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, May 30, 2001 at 04:38:10PM -0400, Mark Eklund wrote: > Pat, > > If you had > > If you have a proxy that speaks both radius and diameter and is > connected to a radius NAS and a Diameter server, could it set > the NAS identifier as below before proxying to the Diameter > server? > > radius://nas.legacy.xyz:1813;transport=udp Seems like a good idea for a protocol gateway to do. I guess that would belong somewhere in the NASREQ spec. I suppose I should open a separate issue on that one. PatC From owner-aaa-bof@merit.edu Thu May 31 17:01:36 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08077 for <aaa-archive@odin.ietf.org>; Thu, 31 May 2001 17:01:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BF7C7912D3; Thu, 31 May 2001 16:07:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B0EA912D4; Thu, 31 May 2001 16:07:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8119C912D3 for <aaa-wg@trapdoor.merit.edu>; Thu, 31 May 2001 16:07:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AED8E5DDAE; Thu, 31 May 2001 16:07:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id DF9375DD8F for <aaa-wg@merit.edu>; Thu, 31 May 2001 16:07:48 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA02078; Thu, 31 May 2001 16:02:19 -0400 (EDT) Date: Thu, 31 May 2001 16:03:26 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: Pat Calhoun <pcalhoun@diameter.org> Cc: David Spence <DSpence@Interlinknetworks.com>, Bernard Aboba <Aboba@Internaut.com>, David Mitton <David@Mitton.com>, AAA Working Group <aaa-wg@merit.edu>, David Mitton <DMitton@Nortelnetworks.com> Subject: Re: [AAA-WG]: [issue] Server Identification In-Reply-To: <20010531114154.P10291@charizard.diameter.org> Message-ID: <Pine.GSO.4.21.0105311540220.373-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, On Thu, 31 May 2001, Pat Calhoun wrote: > On Wed, May 30, 2001 at 04:38:10PM -0400, Mark Eklund wrote: > > Pat, > > > > If you had > > > > If you have a proxy that speaks both radius and diameter and is > > connected to a radius NAS and a Diameter server, could it set > > the NAS identifier as below before proxying to the Diameter > > server? > > > > radius://nas.legacy.xyz:1813;transport=udp > > Seems like a good idea for a protocol gateway to do. I guess > that would belong somewhere in the NASREQ spec. I suppose I should > open a separate issue on that one. Sounds good. It would also involve the base. A change something like this would be needed. Diameter-Identity = [protocol] fqdn [port] protocol = protocol-type "//" ; If absent, the default is "diameter://" protocol-type = The protocol of the originator. ; This is typically "diameter", but may be other ; values like "radius" if a radius gateway is involved. fqdn = Fully Qualified Host Name port = ":" port ; If absent, the default Diameter port (TBD) is assumed. transport = ";transport=" ( "tcp" | "sctp" ) ; If absent, the default SCPT [26] protocol is assumed. -mark > > PatC > From owner-aaa-bof@merit.edu Thu May 31 18:44:56 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09660 for <aaa-archive@odin.ietf.org>; Thu, 31 May 2001 18:44:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A51BD912DF; Thu, 31 May 2001 18:36:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 72ACE912DE; Thu, 31 May 2001 18:36:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D8F43912DF for <aaa-wg@trapdoor.merit.edu>; Thu, 31 May 2001 18:34:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3D8FC5DD91; Thu, 31 May 2001 18:34:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 438365DD90 for <aaa-wg@merit.edu>; Thu, 31 May 2001 18:34:56 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA03655; Thu, 31 May 2001 18:33:20 -0400 (EDT) Date: Thu, 31 May 2001 18:34:28 -0400 (EDT) From: Mark Eklund <meklund@cisco.com> X-Sender: meklund@knox6039 To: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de> Cc: aaa-wg@merit.edu, erik.guttman@germany.sun.com, pcalhoun@diameter.org Subject: Re: [AAA-WG]: Re: [issue] Bring back UTF8 datatype. In-Reply-To: <200105311317.PAA01361@henkell.ibr.cs.tu-bs.de> Message-ID: <Pine.GSO.4.21.0105311758410.616-100000@knox6039> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Juergen, Is the following acceptable. 1. I renamed "AVP Data Formats" to "AVP Base Data Formats". 2. I created a new section, "AVP Derived Data Formats". 3. I stated that an AVP Derived Data Format MUST only be defined in one RFC. 4. I stated that a new AVP Derived Data Format MUST be registered with IANA. (This may be a little extreme.) 5. I moved Address to the AVP Derived Data Formats. 6. I added a time format to the AVP Derived Data Formats. 7. I added UTF8String and used most of the explanation from your example to describe it. 8. Additionally, I specified that UTF8String MUST not contain an octet with a value of zero. 9. I added a DiameterIdentity format (formerly FQDN) to the AVP Derived Data Formats. 10. I added an Enumerated format to the AVP Derived Data Formats. Below is the new text. Is the basic idea getting closer to respectable? If so, any comments on the details? 4.3 AVP Base Data Format The Data field is zero or more octets and contains information specific to the Attribute. The format and length of the Data field is determined by the AVP Code and AVP Length fields. The format of the Data field MUST be one of the following base data types or a data type derived from the base data types. In the event that a new AVP Base Data Format is needed, a new version of this RFC must be created. OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 9 (13 if the 'V' bit is enabled). AVP Values of this type that do not align on a 32-bit boundary MUST have the necessary padding. Integer32 32 bit signed value, in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled). Integer64 64 bit signed value, in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled). Unsigned32 32 bit unsigned value, in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled). Unsigned32 values used to transmit time data contains the four most significant octets returned from NTP [18], in network byte order. Unsigned64 64 bit unsigned value, in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled). Float32 This represents floating point values of single precision as described by [30]. The 32 bit value is transmitted in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled). Float64 This represents floating point values of double precision as described by [30]. The 64 bit value is transmitted in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled). Float128 This represents floating point values of quadruple precision as described by [30]. The 128 bit value is transmitted in network byte order. The AVP Length field MUST be set to 24 (28 if the 'V' bit is enabled). Grouped The Data field is specified as a sequence of AVPs. Each of these AVPs follows - in the order in which they are specified - including their headers and padding. The AVP Length field is set to 8 (12 if the 'V' bit is enabled) plus the total length of all included AVPs, including their headers and padding. 4.4 AVP Derived Data Formats In addition to the AVP Base Data Formats, applications may define data formats derived from the AVP Base Data Formats. New AVP Derived Data Formats MUST be registered with IANA. A derived Data Format can only be defined in one active (non-obsolete) RFC. An application that uses AVP Derived Data Formats other than those defined in the base protocol MUST have a section "AVP Derived Data Formats" that includes each of these formats. In that section, each format is either defined or listed with a reference to the RFC that defines this format. If the AVP Derived Data Format is defined, it SHOULD use a format similar to the format definitions below. The below AVP Derived DATA Formats are commonly used by applications. Address The Address format is derived from the OctetString AVP Base Format. It represents 32 bit (IPv4) [17] or 128 bit (IPv6) [16] address, most significant octet first. The format of the address (IPv4 or IPv6) is determined by the length. If the attribute value is an IPv4 address, the AVP Length field MUST be 12 (16 if 'V' bit is enabled), otherwise the AVP Length field MUST be set to 24 (28 if the 'V' bit is enabled) for IPv6 addresses. Time The Time format is derived from the Unsigned32 AVP Base Format. This is 32 bit unsigned value containing the four most significant octets returned from NTP [18], in network byte order. This represent the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC). On 6h 28m 16s UTC, 7 February 2036 the time value will overflow. NTP [18] describes a procedure to extend the time to 2104. UTF8String The UTF8String format is derived from the OctetString AVP Base Format. This is a human readable string represented using the ISO/IEC IS 10646-1 character set, encoded as an OctetString using the UTF-8 [29] 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 0x00000001 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. Note that the size of an UTF8String is measured in octets, not characters." The UTF8String MUST not contain any octets with a value of zero. DiameterIdentity The DiameterIdentity format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String. In addition, it must follow the following encoding rules. Diameter-Identity = "diameter://" fqdn [ port ] [ transport ] fqdn = Fully Qualified Host Name port = ":" port ; If absent, the default Diameter port (TBD) is assumed. transport = ";transport=" ( "tcp" | "sctp" ) ; If absent, the default SCPT [26] protocol is assumed. The following are examples of valid DiameterIdentities: diameter://host.abc.com diameter://host.abc.com:6666 diameter://host.abc.com;transport=tcp diameter://host.abc.com:6666;transport=tcp Enumerated Enumerated is Derived from the Unsigned32 AVP Base Format. This contains a list of valid values and their interpretation and is described in the Diameter application introducing the AVP. -mark On Thu, 31 May 2001, Juergen Schoenwaelder wrote: > > >>>>> Mark Eklund writes: > > Mark> I have made the request to make UTF8 an official defined type in > Mark> the Diameter Base draft. I was told that it was removed because > Mark> it was not a primitive type as defined in SMI. It would be > Mark> convenient to have an officially defined type of UTF8 so that > Mark> other Diameter extensions could refer to it explicitly instead > Mark> of doing what is now done by defining it as OctetString and then > Mark> describing it as UTF8 format in the text. > > I argued in the AAA DT that Diameter should have a small set of base > types and that there should be a mechanism to define new types which > add restrictions to the core base types. Experience with SNMP tells us > that the number of data types you have needs to be changed over time > and that having to touch the base protocol to introduce something new > is way too costly. > > With this in mind, I recommended to stay with an orthogonal set of > base types (distinguished by type tags) and I suggested to have a kind > of a typedef mechanism (in SMIng terms) or a textual convention > mechanism (in SMIv2 terms) that allows to define derived types which > have additional semantics. The WG did not want to go with a formal > data type definition language and so we ended up where we are now. > > I still believe that it would be valuable to formally say something > like the following (copied from draft-ietf-sming-modules-01.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."; > }; > > You can of course do the same informally in a new section "Derived > Data Types" - but you will end up with problems when you get name > clashes because vendors introduce their own types and so on. > > Note that I also suggested to not define the Address AVP with its > own type tag. Instead, I suggested to define addresses as special > interpretations of OctetStrings. This again gives you flexibility > to add new address formats as the need shows up. > > Note also that you probably need to define a bunch of additional > derived types that are frequently used such as a TimeStamp or > NetworkAccessIdentifier and so on. > > /js > >