From owner-aaa-wg@merit.edu Fri Nov 1 21:41:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13881 for ; Fri, 1 Nov 2002 21:41:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1DD239121C; Fri, 1 Nov 2002 21:43:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DDC7C9122F; Fri, 1 Nov 2002 21:43:18 -0500 (EST) 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 F40919121C for ; Fri, 1 Nov 2002 21:43:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id D34175DEE5; Fri, 1 Nov 2002 21:43:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 461D45DEE2 for ; Fri, 1 Nov 2002 21:43:17 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gA21eCF27797 for ; Fri, 1 Nov 2002 17:40:12 -0800 Date: Fri, 1 Nov 2002 17:40:12 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Strawman agenda for IETF 55, Take Two Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Here is a strawman agenda for the AAA WG meeting at IETF 55. Additions/deletions/comments welcome. Authentication, Authorization and Accounting WG (AAA) IETF 55, Atlanta, GA Wednesday, November 20 1300 - 1500 CHAIRS: Bernard Aboba David Mitton AGENDA Preliminaries (5 minutes) Bluesheets and Minutes Document Status Interoperability/bakeoff report (David Frascone, Tony Johansson) IETF last call Diameter Base, John Loughney (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-14.txt Diameter transport, Bernard Aboba (1 minute) http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-08.txt Diameter MIP, Tony Johansson (4 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-13.txt AAA WG last call Diameter NASREQ, David Mitton (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-10.txt Diameter APIs Diameter API, J. Kempf (5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-api-02.txt Diameter C++ API, Y. Ohba (5 minutes) http://www.ietf.org/internet-drafts/draft-ohba-aaa-diameter-cxxapi-00.txt 3GPP Liason Requests Diameter Credit Control Application, Harri Hakala (5 minutes) http://www.ietf.org/internet-drafts/draft-hakala-diameter-credit-control-04.txt Diameter Multimedia Application, Tony Johansson (5 minutes) http://www.ietf.org/internet-drafts/draft-johansson-aaa-diameter-mm-app-03.txt Work in progress Diameter CMS Security, Stephen Farrell (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-04.txt Diameter EAP, Tom Hiller & Glen Zorn (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-00.txt AAA key distribution, Jesse Walker (10 minutes) http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt Predictive authentication support in AAA, S. Pac, Y. Choi (15 minutes) http://mmlab.snu.ac.kr/research/publication/docs/pwc2002_shpack.pdf http://mmlab.snu.ac.kr/research/publication/docs/Networks2002_shpack.pdf MIPv6/AAA Diameter Mobile IPv6 Application, Franck Le (5 minutes) http://www.ietf.org/internet-drafts/draft-le-aaa-diameter-mobileipv6-02.txt Localized Key Management for AAA in MIPv6, M. Kim (5 minutes) http://www.ietf.org/internet-drafts/draft-mun-aaa-localkm-mobileipv6-00.txt From owner-aaa-wg@merit.edu Sun Nov 3 09:35:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06790 for ; Sun, 3 Nov 2002 09:35:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 178C691210; Sun, 3 Nov 2002 09:37:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D37E591228; Sun, 3 Nov 2002 09:37:37 -0500 (EST) 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 CD4CE91210 for ; Sun, 3 Nov 2002 09:37:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id BBA795DE8C; Sun, 3 Nov 2002 09:37:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 1E3715DE8B for ; Sun, 3 Nov 2002 09:37:36 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gA3DYNb20120 for ; Sun, 3 Nov 2002 05:34:23 -0800 Date: Sun, 3 Nov 2002 05:34:23 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 378: Yet More Base-15 Nits Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 378: Yet More Base-15 Nits Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: November 3, 2002 Reference: Document: Base-15 Comment type: E Priority: S Section: Several Rationale/Explanation of issue: Since we agreed to adopt a base protocol standard accounting application Id, the value needs to be included somewhere and statements about support being implicit within CER/CEA need to be removed. Section 1.2.4, Page 14: Change: "Since every Diameter implementation MUST support accounting, there is no need to advertise support for the Base accounting application within the CER/CEA, since this is implicit. This basic accounting support is sufficient to handle any application that uses the ACR/ACA commands defined in this document, as long as no new mandatory AVPs are added. A mandatory AVP is defined as one which has the "M" bit set when sent within an accounting command, regardless of whether it is required or optional within the ABNF for the accounting application." To: "Every Diameter implementation MUST support accounting. Basic accounting support is sufficient to handle any application that uses the ACR/ACA commands defined in this document, as long as no new mandatory AVPs are added. A mandatory AVP is defined as one which has the "M" bit set when sent within an accounting command, regardless of whether it is required or optional within the ABNF for the accounting application." Section 1.2.4, last paragraph: "If the base accounting is used without any mandatory AVPs, new commands or additional mechanisms (e.g. application defined state machine), then the base protocol defined standard accounting application Id (section 2.4) MUST be used in ACR/ACA commands." The base protocol defined standard accounting application id is not defined in section 2.4, 11.3 or anywhere else for that matter. Suggest the value 0x00000000 be allocated in Section 11.3: "IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for standards-track applications; and 0xff00000000 - 0xfffffffe for vendor specific applications, on a first-come, first-served basis. The value 0x00000000 is allocated for use within the Diameter Base standard accounting application. Assignment of standards-track application IDs are by Designated Expert with Specification Required [IANA]." Section 3, Application-ID "See Section 11.3 for the possible values that the application-id may use." Section 11.3 doesn't contain any such values. Should this section include values for NASREQ or MIP? Section 6.8 (Auth-Application-Id AVP) and 6.9 (Acct-Application-ID AVP) "This AVP SHOULD be placed as close to the Diameter header as possible." The ABNFs show this AVP 6th in commands as as RAR. Is this "as close as possible"? Or was this a typo, made unnecessary by including the application-Id in the header? Section 3: " Command-Code values in the range 0xfffffe through 0xffffff are reserved for experimental use (see Section 11.3). Commands in this range MUST also include a Vendor-Specific Application ID AVP (see section 6.11)." There are only two experimental AVPs now, and this space is to be used for experimental, not vendor-specific purposes. Please change to: "Command-Code values 16,777,214 and 16,777,215 (hexidecimal values FFFFFE - FFFFFF) are reserved for experimental use (See Section 11.3). " 6.11 Vendor-Specific-Application-Id AVP "Exactly one of the Auth-Application-Id and Acct-Application-Id AVPs MAY be present." Shouldn't this statement have occurred earlier, such as in section 6.9? From owner-aaa-wg@merit.edu Sun Nov 3 11:32:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09925 for ; Sun, 3 Nov 2002 11:32:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 13C829122A; Sun, 3 Nov 2002 11:34:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB9C39122D; Sun, 3 Nov 2002 11:34:31 -0500 (EST) 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 CD9D49122A for ; Sun, 3 Nov 2002 11:34:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id B37985DE7E; Sun, 3 Nov 2002 11:34:30 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 482405DE49 for ; Sun, 3 Nov 2002 11:34:30 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gA3FVHD26553 for ; Sun, 3 Nov 2002 07:31:17 -0800 Date: Sun, 3 Nov 2002 07:31:17 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter Nasreq Draft 10, preview copy (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk ---------- Forwarded message ---------- Date: Sun, 03 Nov 2002 00:23:01 -0500 From: David Mitton To: aaa-editors@internaut.com Subject: [aaa-editors] Diameter Nasreq Draft 10, preview copy I've put a copy of the pre-submission version the Nasreq 10 draft on my site. If you can find any problems before EOD Monday, I'll try to get them fixed. Dave. http://home.attbi.com/~dmitton/draft-ietf-aaa-diameter-nasreq-10.txt From owner-aaa-wg@merit.edu Sun Nov 3 11:55:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10402 for ; Sun, 3 Nov 2002 11:55:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BAB3F9122D; Sun, 3 Nov 2002 11:57:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8888991233; Sun, 3 Nov 2002 11:57:13 -0500 (EST) 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 3DEF19122D for ; Sun, 3 Nov 2002 11:57:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2244A5DE87; Sun, 3 Nov 2002 11:57:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 3C9455DE7F for ; Sun, 3 Nov 2002 11:57:10 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gA3FrvD27748 for ; Sun, 3 Nov 2002 07:53:57 -0800 Date: Sun, 3 Nov 2002 07:53:57 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 379: NASREQ-10 NITs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 379: NASREQ-10 NITs Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: November 3, 2002 Reference: Document: NASREQ-10 Comment type: T Priority: S Section: Several Rationale/Explanation of issue: Page 1: The draft lists 7 authors. This exceeds the guideline of 5 established by the RFC Editor. Suggest that two authors be dropped. Page 2: "This application, combined with the Diameter base protocol [BASE], satisfies the requirements defined in the NAS Requirements AAA Criteria specification [NASCrit] and the Roaming Operations AAA Criteria specification [ROAMCrit]." Suggest change to: "The Diameter NAS application, when combined with the Diameter base protocol, Transport Profile, EAP and CMS Security specifications, satisfies NAS-related requirements defined in [AAACRIT]." Section 1, Page 6: "This is achieved by re-using the RADIUS attribute space, and eliminating the need to perform most attribute translations." Actually, it appears that translations are required in a considerable number of cases. Suggest that this sentence be deleted. Page 6: "This document describes Diameter applications that are used for AAA in the Network Access Server (NAS) environment. This application, combined with the Diameter base protocol [BASE] and related Diameter Transport [DiamTrans] and Security [DiamEAP,DiamCMS] specifications, satisfies the requirements defined in the NAS Requirements AAA Criteria specification [NASCrit] and the Roaming Operations AAA Criteria specification [ROAMCrit]." Suggest change to: "This document describes the Diameter NAS application that is used for AAA in the Network Access Server (NAS) environment. This application, combined with the Diameter base protocol [BASE], Transport Profile [DiamTrans], EAP [DiamEAP], and CMS Security [DiamCMS] specifications, satisfies NAS-related requirements defined in [AAACRIT]." Section 1.2 The Auth-Application-Id OR Acct-Application-Id are included in the CER/CEA, but never both. Suggest changing: " Diameter nodes conforming to this specification MAY advertise support by including the value of one (1) in the Auth-Application-Id and/or the Acct-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands [BASE]." To: "Diameter nodes conforming to this specification MAY advertise support by including the value of one (1) in the Auth-Application-Id or the Acct-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands [BASE]." Section 2: "If the value of Result- Code is DIAMETER_MULTI_ROUND_AUTH, an additional authentication exchange is indicated, and several AAR and AAA messages may be exchanged until the transaction completes." Can you give a usage example (e.g. Challenge/Response token cards)? Section 2.2: "the NAS is using RADIUS which does not support re-authentication or re-authorization." Actually, RADIUS *does* support re-authentication, just not driven by the server (except for dynamic authorization). Change to: "the NAS is using RADIUS which does not support server-initiated re-authentication or re-authorization. For an exception, see [RADDYNAUTH]." Section 3.1 and 3.2 EAP-Payload is included in the AAR/AAA messages. Isn't this reserved for the EAP application only? If not, can you provide guidelines as to which application ID (NASREQ or EAP) is used with EAP? Section 4.1 AVPs NAS-Port-Id, Called-Station-Id, Calling-Station-ID are listed as type UTF8String. Is this correct? These AVPs typically only contain numbers and a few other characters. If so, they should contain ASCII characters only. Section 4.1.6 An example of the Connect-Info AVP would be helpful. Section 4.1.9 " Note: The Termination-Action AVP is typically used for the login service (Service-Type = 1 or "Login") or by 802.1X supplicants [802.1X] (e.g., NAS-Port-Type = 19 or "Wireless - IEEE 802.11"). When used for the login service, the service typically terminates when the login host clears the connection. The NAS may prompt the user for a new connection and issue a new AA-Request. When used by 802.1X supplicants, the service typically terminates due to the expiry of the Session-Timeout AVP. The access device may then reauthenticate the user with a new AA-Request. The RECOMMENDED way to do this in Diameter is to use the Authorization-Lifetime AVP rather than the Termination-Action AVP. However, the Termination- Action AVP MAY be used when copied from a RADIUS Access-Accept to a Diameter AA-Answer by a Translation Agent." If the Termination-Action AVP contains a value other than DEFAULT, shouldn't a Translation Agent use Authorization-Lifetime AVP instead of copying the Termination-Action AVP into the Diameter AA-Answer? Section 4.2 EAP-Payload included here again. Is this for use in NASREQ or EAP applications (or both)? Section 4.2.1 " The User-Password AVP MUST be encrypted using the methods described in [DiamSEC], or where [DiamSEC] isn't applied, the whole DIAMETER message flow MUST be encrypted using IPsec and/or TLS as described in [BASE]. Unless this AVP is used for one-time passwords, the User- Password AVP SHOULD NOT be used in untrusted proxy environments." DiamSEC isn't an alternative to use of IPsec or TLS. Change to: " The User-Password AVP contains a user password or one-time password and therefore represents sensitive information. As required in [BASE], Diameter messages are encrypted using IPsec or TLS. Unless this AVP is used for one-time passwords, the User- Password AVP SHOULD NOT be used in untrusted proxy environments without encrypting it using end-to-end security techniques, such as CMS Security [DiamSEC], a work in progress." Section 4.2.9 I thought that EAP-Payload was supposed to be defined within the EAP Application. If it is defined in both NASREQ and EAP applications, which application-id is used when EAP authentication is desired? Section 4.3.10.3 and 4.3.10.7 Framed-IPv6-Route and Framed-Route AVP should be ASCII not UTF8String. Section 4.4.5 " This AVP MUST only be present in authorization responses in an encrypted form, using one of the methods described in [BASE] and [DiamSEC]." Change to: " The Tunnel-Password AVP contains sensitive information. As required in [BASE], Diameter messages are encrypted using IPsec or TLS. The Tunnel-Password AVP SHOULD NOT be used in untrusted proxy environments without encrypting it using end-to-end security techniques, such as CMS Security [DiamSEC], a work in progress." Section 6.2.5 " >From RFC 2866, the termination causes are as follows:" Change to: " From RFC 2866, the termination causes are as follows:" Section 8.3: "8.3. Application Identifier This specification assigns the value one (1) to the Application Identifier namespace defined in [IANAConsid]. See section 1.2 for more information." Is a separate application-Id needed for NASREQ authentication and accounting? Section 9: " This specification also defines a method by which the home Diameter server can create and distribute registration keys to be used to authenticate link layer messages (e.g. PPP ECP). The keys SHOULD be be protected using the methods defined in [DiamSEC]." Since keying AVPs are no longer in the specification, this paragraph should be deleted. Section 10.1 References need to be updated: [BASE] - Draft 15 is the latest. [AAATrans] - Draft 8 is the latest. [DiamMIP] - Draft 13 is the latest. From owner-aaa-wg@merit.edu Mon Nov 4 11:27:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20589 for ; Mon, 4 Nov 2002 11:27:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A9D879124D; Mon, 4 Nov 2002 11:29:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B87E9124E; Mon, 4 Nov 2002 11:29:52 -0500 (EST) 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 4D08F9124D for ; Mon, 4 Nov 2002 11:29:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2E9195DEFC; Mon, 4 Nov 2002 11:29:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by segue.merit.edu (Postfix) with ESMTP id 731765DEDF for ; Mon, 4 Nov 2002 11:29:50 -0500 (EST) Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gA4GM9h07158 for ; Mon, 4 Nov 2002 17:22:09 +0100 Received: from alcatel.be ([138.203.67.40]) by bemail04.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002110417293680:6167 ; Mon, 4 Nov 2002 17:29:36 +0100 Message-ID: <3DC6A06C.3684F048@alcatel.be> Date: Mon, 04 Nov 2002 17:29:32 +0100 From: suresh.leroy@alcatel.be Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Where can I find [RoamRev] X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/04/2002 17:29:36, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/04/2002 17:29:38, Serialize complete at 11/04/2002 17:29:38 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello,

Does anyone know where I can find the [ROAMREV] document mentioned in the introduction of base-15 document.
It is not in the reference list.
"The ROAMOPS WG provided a survey of roaming implementations [ROAMREV], detailed ..."
 

Regards,
    Suresh From owner-aaa-wg@merit.edu Mon Nov 4 11:32:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21312 for ; Mon, 4 Nov 2002 11:32:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CD8379124F; Mon, 4 Nov 2002 11:34:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F4AE91250; Mon, 4 Nov 2002 11:34:46 -0500 (EST) 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 994619124F for ; Mon, 4 Nov 2002 11:34:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 842665E10C; Mon, 4 Nov 2002 11:34:45 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from bsn-mail-01.bstormnetworks.com (unknown [209.11.156.50]) by segue.merit.edu (Postfix) with ESMTP id 42DC65DEFC for ; Mon, 4 Nov 2002 11:34:45 -0500 (EST) Subject: Re: [AAA-WG]: Where can I find [RoamRev] From: Pat Calhoun To: suresh.leroy@alcatel.be Cc: aaa-wg@merit.edu In-Reply-To: <3DC6A06C.3684F048@alcatel.be> References: <3DC6A06C.3684F048@alcatel.be> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 04 Nov 2002 08:34:45 +0000 Message-Id: <1036398885.17826.60.camel@x1-6-00-b0-d0-bf-86-b5> Mime-Version: 1.0 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Information can be found on the old roamops web page at http://www.ietf.org/html.charters/OLD/roamops-charter.html PatC On Mon, 2002-11-04 at 16:29, suresh.leroy@alcatel.be wrote:Hello, Does anyone know where I can find the [ROAMREV] document mentioned in the introduction of base-15 document. It is not in the reference list. "The ROAMOPS WG provided a survey of roaming implementations [ROAMREV], detailed ..." Regards, Suresh From owner-aaa-wg@merit.edu Mon Nov 4 11:34:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21397 for ; Mon, 4 Nov 2002 11:34:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 919BA91250; Mon, 4 Nov 2002 11:36:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE71391251; Mon, 4 Nov 2002 11:36:31 -0500 (EST) 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 0AAC791250 for ; Mon, 4 Nov 2002 11:36:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id EC90B5DEFC; Mon, 4 Nov 2002 11:36:30 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7E6FB5DEE1 for ; Mon, 4 Nov 2002 11:36:30 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gA4FWlG08617; Mon, 4 Nov 2002 07:32:47 -0800 Date: Mon, 4 Nov 2002 07:32:47 -0800 (PST) From: Bernard Aboba To: suresh.leroy@alcatel.be Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Where can I find [RoamRev] In-Reply-To: <3DC6A06C.3684F048@alcatel.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is RFC 2194. Isn't this listed in the reference section? On Mon, 4 Nov 2002 suresh.leroy@alcatel.be wrote: > Hello, > > Does anyone know where I can find the [ROAMREV] document mentioned in the > introduction of base-15 document. > It is not in the reference list. > "The ROAMOPS WG provided a survey of roaming implementations [ROAMREV], detailed > ..." > > > Regards, > Suresh > From owner-aaa-wg@merit.edu Mon Nov 4 12:01:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22414 for ; Mon, 4 Nov 2002 12:01:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3B23D91259; Mon, 4 Nov 2002 12:03:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04C469125A; Mon, 4 Nov 2002 12:03:54 -0500 (EST) 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 D270591259 for ; Mon, 4 Nov 2002 12:03:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id C13105DEFC; Mon, 4 Nov 2002 12:03:53 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 06B0D5DEDC for ; Mon, 4 Nov 2002 12:03:53 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA4H3QO14200 for ; Mon, 4 Nov 2002 19:03:26 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Nov 2002 19:03:52 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 4 Nov 2002 19:03:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Where can I find [RoamRev] Date: Mon, 4 Nov 2002 19:03:51 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E43C6@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Where can I find [RoamRev] Thread-Index: AcKEIF5domgBF54lR8mdfXCcjvEHVwAA0y3Q From: To: , Cc: X-OriginalArrivalTime: 04 Nov 2002 17:03:52.0015 (UTC) FILETIME=[268B55F0:01C28424] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA22414 > This is RFC 2194. Isn't this listed in the reference section? No it's not listed, perhaps we need to add it. Br Marco > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 04. November 2002 17:33 > To: suresh.leroy@alcatel.be > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Where can I find [RoamRev] > > > This is RFC 2194. Isn't this listed in the reference section? > > On Mon, 4 Nov 2002 suresh.leroy@alcatel.be wrote: > > > Hello, > > > > Does anyone know where I can find the [ROAMREV] document > mentioned in the > > introduction of base-15 document. > > It is not in the reference list. > > "The ROAMOPS WG provided a survey of roaming > implementations [ROAMREV], detailed > > ..." > > > > > > Regards, > > Suresh > > > > From owner-aaa-wg@merit.edu Mon Nov 4 23:47:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23103 for ; Mon, 4 Nov 2002 23:47:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 46CB79127F; Mon, 4 Nov 2002 23:50:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1479B91280; Mon, 4 Nov 2002 23:50:06 -0500 (EST) 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 0A71C9127F for ; Mon, 4 Nov 2002 23:50:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id E80005DDFE; Mon, 4 Nov 2002 23:50:04 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 1D97F5DDFC for ; Mon, 4 Nov 2002 23:50:03 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA54oTB11513 for ; Tue, 5 Nov 2002 06:50:29 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Nov 2002 06:49:49 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 06:49:49 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 06:49:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Where can I find [RoamRev] Date: Tue, 5 Nov 2002 06:49:48 +0200 Message-ID: Thread-Topic: [AAA-WG]: Where can I find [RoamRev] Thread-Index: AcKEIF5T/0Ss3VWyTSWyfwrGbJZOxAAZl64g From: To: , Cc: X-OriginalArrivalTime: 05 Nov 2002 04:49:48.0878 (UTC) FILETIME=[C533B6E0:01C28486] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA23103 I'll check & fix if needed. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 04 November, 2002 17:33 > To: suresh.leroy@alcatel.be > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Where can I find [RoamRev] > > > This is RFC 2194. Isn't this listed in the reference section? > > On Mon, 4 Nov 2002 suresh.leroy@alcatel.be wrote: > > > Hello, > > > > Does anyone know where I can find the [ROAMREV] document > mentioned in the > > introduction of base-15 document. > > It is not in the reference list. > > "The ROAMOPS WG provided a survey of roaming > implementations [ROAMREV], detailed > > ..." > > > > > > Regards, > > Suresh > > > > From owner-aaa-wg@merit.edu Tue Nov 5 05:41:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09518 for ; Tue, 5 Nov 2002 05:41:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 842B691221; Tue, 5 Nov 2002 05:43:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 500F391222; Tue, 5 Nov 2002 05:43:24 -0500 (EST) 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 4BE0691221 for ; Tue, 5 Nov 2002 05:43:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 360EF5DF55; Tue, 5 Nov 2002 05:43:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 8ADD05DE80 for ; Tue, 5 Nov 2002 05:43:22 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA5Ah4KV009622; Tue, 5 Nov 2002 11:43:04 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 5 Nov 2002 11:43:04 +0100 Message-ID: From: "Harri Hakala (LMF)" To: "'Bernard Aboba'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Strawman agenda for IETF 55, Take Two Date: Tue, 5 Nov 2002 11:43:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, We have submitted the new version of Diameter credit control draft to the IETF archive. Until it shows up the archive, it can be found: http://standards.ericsson.net/harri/draft-hakala-diameter-credit-control-05.txt Regards..........Harri > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: 2. marraskuuta 2002 3:40 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Strawman agenda for IETF 55, Take Two > > > Here is a strawman agenda for the AAA WG meeting at IETF 55. > Additions/deletions/comments welcome. > > Authentication, Authorization and Accounting WG (AAA) > IETF 55, Atlanta, GA > Wednesday, November 20 1300 - 1500 > > CHAIRS: > Bernard Aboba > David Mitton > > AGENDA > > Preliminaries (5 minutes) > Bluesheets and Minutes > Document Status > Interoperability/bakeoff report (David Frascone, Tony Johansson) > > IETF last call > > Diameter Base, John Loughney (10 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-14.txt > > Diameter transport, Bernard Aboba (1 minute) > http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-08.txt > > Diameter MIP, Tony Johansson (4 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mo > bileip-13.txt > > AAA WG last call > > Diameter NASREQ, David Mitton (10 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-na sreq-10.txt Diameter APIs Diameter API, J. Kempf (5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-api-02.txt Diameter C++ API, Y. Ohba (5 minutes) http://www.ietf.org/internet-drafts/draft-ohba-aaa-diameter-cxxapi-00.txt 3GPP Liason Requests Diameter Credit Control Application, Harri Hakala (5 minutes) http://www.ietf.org/internet-drafts/draft-hakala-diameter-credit-control-04.txt Diameter Multimedia Application, Tony Johansson (5 minutes) http://www.ietf.org/internet-drafts/draft-johansson-aaa-diameter-mm-app-03.txt Work in progress Diameter CMS Security, Stephen Farrell (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-04.txt Diameter EAP, Tom Hiller & Glen Zorn (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-00.txt AAA key distribution, Jesse Walker (10 minutes) http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt Predictive authentication support in AAA, S. Pac, Y. Choi (15 minutes) http://mmlab.snu.ac.kr/research/publication/docs/pwc2002_shpack.pdf http://mmlab.snu.ac.kr/research/publication/docs/Networks2002_shpack.pdf MIPv6/AAA Diameter Mobile IPv6 Application, Franck Le (5 minutes) http://www.ietf.org/internet-drafts/draft-le-aaa-diameter-mobileipv6-02.txt Localized Key Management for AAA in MIPv6, M. Kim (5 minutes) http://www.ietf.org/internet-drafts/draft-mun-aaa-localkm-mobileipv6-00.txt From owner-aaa-wg@merit.edu Tue Nov 5 10:55:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25593 for ; Tue, 5 Nov 2002 10:55:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4308191216; Tue, 5 Nov 2002 10:57:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1912F91217; Tue, 5 Nov 2002 10:57:43 -0500 (EST) 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 2D86E91216 for ; Tue, 5 Nov 2002 10:57:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1084A5DF2D; Tue, 5 Nov 2002 10:57:42 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 53EA25DE79 for ; Tue, 5 Nov 2002 10:57:32 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gA5Es8Q21311 for ; Tue, 5 Nov 2002 06:54:08 -0800 Date: Tue, 5 Nov 2002 06:54:08 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Strawman agenda for IETF 55, Take Three Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Here is a strawman agenda for the AAA WG meeting at IETF 55. Additions/deletions/comments welcome. Authentication, Authorization and Accounting WG (AAA) IETF 55, Atlanta, GA Wednesday, November 20 1300 - 1500 CHAIRS: Bernard Aboba David Mitton AGENDA Preliminaries (5 minutes) Bluesheets and Minutes Document Status Interoperability/bakeoff report (David Frascone, Tony Johansson) IETF last call Diameter Base, John Loughney (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-14.txt Diameter transport, Bernard Aboba (1 minute) http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-08.txt Diameter MIP, Tony Johansson (4 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-13.txt Diameter NASREQ, David Mitton (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-09.txt Diameter APIs Diameter API, J. Kempf (5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-api-02.txt Diameter C++ API, Y. Ohba (5 minutes) http://www.ietf.org/internet-drafts/draft-ohba-aaa-diameter-cxxapi-00.txt 3GPP Liason Requests Diameter Credit Control Application, Harri Hakala (5 minutes) http://www.ietf.org/internet-drafts/draft-hakala-diameter-credit-control-05.txt Diameter Multimedia Application, Maria-Carmen Belinchon (5 minutes) http://www.ietf.org/internet-drafts/draft-johansson-aaa-diameter-mm-app-04.txt Work in progress Diameter CMS Security, Stephen Farrell (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-04.txt AAA key distribution, Jesse Walker (10 minutes) http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt Predictive authentication support in AAA, S. Pac, Y. Choi (15 minutes) http://mmlab.snu.ac.kr/research/publication/docs/pwc2002_shpack.pdf http://mmlab.snu.ac.kr/research/publication/docs/Networks2002_shpack.pdf Diameter EAP, Tom Hiller & Glen Zorn (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-00.txt MIPv6/AAA Diameter Mobile IPv6 Application, Franck Le (5 minutes) http://www.ietf.org/internet-drafts/draft-le-aaa-diameter-mobileipv6-02.txt Localized Key Management for AAA in MIPv6, M. Kim (5 minutes) http://www.ietf.org/internet-drafts/draft-mun-aaa-localkm-mobileipv6-00.txt From owner-aaa-wg@merit.edu Wed Nov 6 02:01:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15448 for ; Wed, 6 Nov 2002 02:01:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 73D0C91285; Wed, 6 Nov 2002 02:01:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 498B091290; Wed, 6 Nov 2002 02:01:44 -0500 (EST) 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 1D11F91285 for ; Wed, 6 Nov 2002 02:01:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id EDC055DE59; Wed, 6 Nov 2002 02:01:42 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 0A53E5DE30 for ; Wed, 6 Nov 2002 02:01:42 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA671FO02415 for ; Wed, 6 Nov 2002 09:01:15 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Nov 2002 09:01:39 +0200 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 09:01:39 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 09:01:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Strawman agenda for IETF 55, Take Three Date: Wed, 6 Nov 2002 09:01:37 +0200 Message-ID: Thread-Topic: [AAA-WG]: Strawman agenda for IETF 55, Take Three Thread-Index: AcKE5CDglUxpslY/S6S4YoKxE+Y6vgAfiwBg From: To: , X-OriginalArrivalTime: 06 Nov 2002 07:01:38.0740 (UTC) FILETIME=[5A429F40:01C28562] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA15448 Hi Bernard, One note, the Diameter Base spec to be presented should be:_ http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-15.txt thanks, John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 05 November, 2002 16:54 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Strawman agenda for IETF 55, Take Three > > > Here is a strawman agenda for the AAA WG meeting at IETF 55. > Additions/deletions/comments welcome. > > Authentication, Authorization and Accounting WG (AAA) > IETF 55, Atlanta, GA > Wednesday, November 20 1300 - 1500 > > CHAIRS: > Bernard Aboba > David Mitton > > AGENDA > > Preliminaries (5 minutes) > Bluesheets and Minutes > Document Status > Interoperability/bakeoff report (David Frascone, Tony Johansson) > > IETF last call > > Diameter Base, John Loughney (10 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-14.txt > > Diameter transport, Bernard Aboba (1 minute) > http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-08.txt > > Diameter MIP, Tony Johansson (4 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mo bileip-13.txt Diameter NASREQ, David Mitton (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-09.txt Diameter APIs Diameter API, J. Kempf (5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-api-02.txt Diameter C++ API, Y. Ohba (5 minutes) http://www.ietf.org/internet-drafts/draft-ohba-aaa-diameter-cxxapi-00.txt 3GPP Liason Requests Diameter Credit Control Application, Harri Hakala (5 minutes) http://www.ietf.org/internet-drafts/draft-hakala-diameter-credit-control-05.txt Diameter Multimedia Application, Maria-Carmen Belinchon (5 minutes) http://www.ietf.org/internet-drafts/draft-johansson-aaa-diameter-mm-app-04.txt Work in progress Diameter CMS Security, Stephen Farrell (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-04.txt AAA key distribution, Jesse Walker (10 minutes) http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt Predictive authentication support in AAA, S. Pac, Y. Choi (15 minutes) http://mmlab.snu.ac.kr/research/publication/docs/pwc2002_shpack.pdf http://mmlab.snu.ac.kr/research/publication/docs/Networks2002_shpack.pdf Diameter EAP, Tom Hiller & Glen Zorn (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-00.txt MIPv6/AAA Diameter Mobile IPv6 Application, Franck Le (5 minutes) http://www.ietf.org/internet-drafts/draft-le-aaa-diameter-mobileipv6-02.txt Localized Key Management for AAA in MIPv6, M. Kim (5 minutes) http://www.ietf.org/internet-drafts/draft-mun-aaa-localkm-mobileipv6-00.txt From owner-aaa-wg@merit.edu Wed Nov 6 10:25:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26217 for ; Wed, 6 Nov 2002 10:25:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F31CA91294; Wed, 6 Nov 2002 10:27:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8C8191295; Wed, 6 Nov 2002 10:27:27 -0500 (EST) 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 A47CE91294 for ; Wed, 6 Nov 2002 10:27:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 947AB5DE30; Wed, 6 Nov 2002 10:27:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from cms1.etri.re.kr (cms1.etri.re.kr [129.254.16.11]) by segue.merit.edu (Postfix) with ESMTP id A26955DE17 for ; Wed, 6 Nov 2002 10:27:25 -0500 (EST) Received: from JUNNY (junny.etri.re.kr [129.254.241.18]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VZPSL695; Thu, 7 Nov 2002 00:20:06 +0900 Message-ID: <002801c285a9$02b133d0$12f1fe81@JUNNY> From: "S. Lee" To: Subject: [AAA-WG]: Questions about nasreq-10 preview Date: Thu, 7 Nov 2002 00:27:25 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C285F4.7279E220" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C285F4.7279E220 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SSBoYXZlIHNvbWUgcXVlc3Rpb25zIGFib3V0IG5hc3JlcS0xMCBwcmV2aWV3Li4uDQoNCjEuIElu IFNlY3Rpb24gNi4xLCANCg0KIi0gSWYgc3RhdGUgaW5mb3JtYXRpb24gcmVnYXJkaW5nIHRoZSBS QURJVVMgcmVxdWVzdCB3YXMgc2F2ZWQgaW4gYQ0KICAgIFByb3h5LUluZm8gQVZQLCB0aGUgUkFE SVVTIElkZW50aWZpZXIgYW5kIFVEUCBJUCBBZGRyZXNzIGFuZA0KICAgIHBvcnQgbnVtYmVyIGFy ZSBleHRyYWN0ZWQgYW5kIHVzZWQgaW4gaXNzdWluZyB0aGUgUkFESVVTIHJlcGx5LiINCg0KSSB0 aGluayB0aGlzIHNlbnRlbmNlIG11c3QgYmUgY2hhbmdlZCB0byA6DQoNCiJJZiBzdGF0ZSBpbmZv cm1hdGlvbiByZWdhcmRpbmcgdGhlIFJBRElVUyByZXF1ZXN0IHdhcyBzYXZlZCBpbiBhDQogICAg UHJveHktSW5mbyBBVlAgb3IgbG9jYWwgc3RhdGUgdGFibGUsIHRoZSBSQURJVVMgSWRlbnRpZmll ciBhbmQgVURQIElQIEFkZHJlc3MgYW5kDQogICAgcG9ydCBudW1iZXIgYXJlIGV4dHJhY3RlZCBh bmQgdXNlZCBpbiBpc3N1aW5nIHRoZSBSQURJVVMgcmVwbHkuIg0KDQoyLiBNdWx0aS1Sb3VuZC1U aW1lLU91dCBBVlAgaXMgcmVmZXJlZCBpbiBzZWN0aW9uIDYuMSAmIDYuMS4xLCANCmJ1dCBpbiA3 LjEgd2UgY2FuJ3QgZmluZCB0aGlzIEFWUCBmcm9tIEFBUi9BIEFWUCB0YWJsZS4gDQoNCjMuIElu IFNlY3Rpb24gNi4xLjENCiItIFRoZSBSb3V0ZS1SZWNvcmQgQVZQcyBNVVNUIGJlIGFkZGVkIHRv IHRoZSBEaWFtZXRlciBtZXNzYWdlLCBpbg0KICAgICAgICB0aGUgc2FtZSBvcmRlciB0aGV5IHdl cmUgcHJlc2VudCBpbiB0aGUgcmVxdWVzdC4iDQpXaHkgdGhlIFJvdXRlLVJlY29yZCBBVlAgTVVT VCBiZSBhZGRlZCBpbiBEaWFtZXRlciBhbnN3ZXI/DQoNCjQuIFdoeSBpcyB0aGUgTkFTLVNlc3Np b24tS2V5IEFWUCBvbWl0dGVkIGluIHRoaXMgZHJhZnQ/DQpJdCB3aWxsIGJlIG9ubHkgaW4gYWFh LWRpYW1ldGVyLWVhcCBkcmFmdD8NCg0KNS4gSW4gU2VjdGlvbiA2LjEuMSwgd2hhdCBpcyBBY2N0 LVNlc3Npb24tSWQgQVZQPw0Kd2hlcmUgaXMgaXQgZGVmaW5lZD8NCg0KKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCisgIExlZSwg U29ram9vbiAoSUNRIE5vIDogNjkzNDcwMDUpDQorICBPZmZpY2UgOiArODItNDItODYwLTU0NTUg ICAgRmF4IDogKzgyLTQyLTg2MC01NjExDQorICBDZWxsIDogKzgyLTE3LTM0NC0xMjk1ICAgICAg RS1NYWlsIDoganVubnlAZXRyaS5yZS5rcg0KIA0KKyAgV2lyZWxlc3MgSW50ZXJuZXQgU2VjdXJp dHkgUmVzZWFyY2ggVGVhbQ0KKyAgRWxlY3Ryb25pY3MgYW5kIFRlbGVjb21tdW5pY2F0aW9ucyBS ZXNlYXJjaCBJbnN0aXR1dGUNCisgIDE2MSBHYWplb25nZG9uZywgWXVzZW9uZ2d1LCBEYWVqZW9u LCAzMDUtMzUwLCBLb3JlYQ0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSs= ------=_NextPart_000_0025_01C285F4.7279E220 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTEwNiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgaGF2ZSBz b21lIHF1ZXN0aW9ucyBhYm91dCBuYXNyZXEtMTAgcHJldmlldy4uLjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjEu IEluJm5ic3A7U2VjdGlvbiA2LjEsIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPiItIElmIHN0YXRlIGluZm9ybWF0 aW9uIHJlZ2FyZGluZyB0aGUgUkFESVVTIHJlcXVlc3Qgd2FzIHNhdmVkIA0KaW4gYTxCUj4mbmJz cDsmbmJzcDsmbmJzcDsgUHJveHktSW5mbyBBVlAsIHRoZSBSQURJVVMgSWRlbnRpZmllciBhbmQg VURQIElQIA0KQWRkcmVzcyBhbmQ8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBvcnQgbnVtYmVyIGFy ZSBleHRyYWN0ZWQgYW5kIHVzZWQgaW4gaXNzdWluZyANCnRoZSBSQURJVVMgcmVwbHkuIjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPkkgdGhpbmsgdGhpcyBzZW50ZW5jZSBtdXN0IGJlIGNoYW5nZWQgdG8gOjwvRk9O VD48L0RJVj48Rk9OVCANCnNpemU9Mj4NCjxESVY+PEJSPiJJZiBzdGF0ZSBpbmZvcm1hdGlvbiBy ZWdhcmRpbmcgdGhlIFJBRElVUyByZXF1ZXN0IHdhcyBzYXZlZCBpbiANCmE8QlI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IFByb3h5LUluZm8gQVZQIG9yIGxvY2FsIHN0YXRlIHRhYmxlLCB0aGUgUkFESVVT IA0KSWRlbnRpZmllciBhbmQgVURQIElQIEFkZHJlc3MgYW5kPEJSPiZuYnNwOyZuYnNwOyZuYnNw OyBwb3J0IG51bWJlciBhcmUgDQpleHRyYWN0ZWQgYW5kIHVzZWQgaW4gaXNzdWluZyB0aGUgUkFE SVVTIHJlcGx5LiI8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjIuIE11bHRpLVJvdW5k LVRpbWUtT3V0IEFWUCBpcyByZWZlcmVkIGluIHNlY3Rpb24mbmJzcDs2LjEgJmFtcDsgNi4xLjEs IA0KPC9ESVY+DQo8RElWPmJ1dCBpbiA3LjEgd2UgY2FuJ3QgZmluZCB0aGlzIEFWUCZuYnNwO2Zy b20gQUFSL0EgQVZQIHRhYmxlLiA8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjMuIElu IFNlY3Rpb24gNi4xLjE8L0RJVj4NCjxESVY+Ii0gVGhlIFJvdXRlLVJlY29yZCBBVlBzIE1VU1Qg YmUgYWRkZWQgdG8gdGhlIERpYW1ldGVyIG1lc3NhZ2UsIA0KaW48QlI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBzYW1lIG9yZGVyIHRoZXkgd2VyZSANCnBy ZXNlbnQgaW4gdGhlIHJlcXVlc3QuIjwvRElWPg0KPERJVj5XaHkmbmJzcDt0aGUgUm91dGUtUmVj b3JkIEFWUCBNVVNUIGJlIGFkZGVkIGluJm5ic3A7RGlhbWV0ZXIgYW5zd2VyPzwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+NC4mbmJzcDtXaHkgaXMgdGhlJm5ic3A7TkFTLVNlc3Npb24t S2V5IEFWUCBvbWl0dGVkIGluIHRoaXMgZHJhZnQ/PC9ESVY+DQo8RElWPkl0IHdpbGwgYmUgb25s eSBpbiBhYWEtZGlhbWV0ZXItZWFwIGRyYWZ0PzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+NS4gSW4gU2VjdGlvbiA2LjEuMSwgd2hhdCBpcyBBY2N0LVNlc3Npb24tSWQgQVZQPzwvRElW Pg0KPERJVj53aGVyZSBpcyBpdCBkZWZpbmVkPzwvRElWPg0KPERJVj48L0ZPTlQ+PEZPTlQgc2l6 ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgDQpzaXplPTI+Ky0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSs8QlI+KyZu YnNwOyANCkxlZSwgU29ram9vbiAoSUNRIE5vIDogNjkzNDcwMDUpPEJSPismbmJzcDsgT2ZmaWNl IDogDQorODItNDItODYwLTU0NTUmbmJzcDsmbmJzcDsmbmJzcDsgRmF4IDogKzgyLTQyLTg2MC01 NjExPEJSPismbmJzcDsgQ2VsbCA6IA0KKzgyLTE3LTM0NC0xMjk1Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEUtTWFpbCA6IDxBIA0KaHJlZj0ibWFpbHRvOmp1bm55QGV0cmkucmUua3Ii Pmp1bm55QGV0cmkucmUua3I8L0E+PEJSPiZuYnNwOzxCUj4rJm5ic3A7IA0KV2lyZWxlc3MgSW50 ZXJuZXQgU2VjdXJpdHkgUmVzZWFyY2ggVGVhbTxCUj4rJm5ic3A7IEVsZWN0cm9uaWNzIGFuZCAN ClRlbGVjb21tdW5pY2F0aW9ucyBSZXNlYXJjaCBJbnN0aXR1dGU8QlI+KyZuYnNwOyAxNjEgR2Fq ZW9uZ2RvbmcsIFl1c2VvbmdndSwgDQpEYWVqZW9uLCAzMDUtMzUwLCANCktvcmVhPEJSPistLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0025_01C285F4.7279E220-- From owner-aaa-wg@merit.edu Wed Nov 6 10:44:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27471 for ; Wed, 6 Nov 2002 10:44:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 59F0991296; Wed, 6 Nov 2002 10:46:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2984391298; Wed, 6 Nov 2002 10:46:26 -0500 (EST) 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 31CB191296 for ; Wed, 6 Nov 2002 10:46:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 15CAC5DDA5; Wed, 6 Nov 2002 10:45:49 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 31B2D5DDF9 for ; Wed, 6 Nov 2002 10:45:47 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gA6EgAH14499; Wed, 6 Nov 2002 06:42:10 -0800 Date: Wed, 6 Nov 2002 06:42:10 -0800 (PST) From: Bernard Aboba To: "S. Lee" Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Questions about nasreq-10 preview In-Reply-To: <002801c285a9$02b133d0$12f1fe81@JUNNY> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Filed as Issue 380. On Thu, 7 Nov 2002, S. Lee wrote: > I have some questions about nasreq-10 preview... > > 1. In Section 6.1, > > "- If state information regarding the RADIUS request was saved in a > Proxy-Info AVP, the RADIUS Identifier and UDP IP Address and > port number are extracted and used in issuing the RADIUS reply." > > I think this sentence must be changed to : > > "If state information regarding the RADIUS request was saved in a > Proxy-Info AVP or local state table, the RADIUS Identifier and UDP IP Address and > port number are extracted and used in issuing the RADIUS reply." > > 2. Multi-Round-Time-Out AVP is refered in section 6.1 & 6.1.1, > but in 7.1 we can't find this AVP from AAR/A AVP table. > > 3. In Section 6.1.1 > "- The Route-Record AVPs MUST be added to the Diameter message, in > the same order they were present in the request." > Why the Route-Record AVP MUST be added in Diameter answer? > > 4. Why is the NAS-Session-Key AVP omitted in this draft? > It will be only in aaa-diameter-eap draft? > > 5. In Section 6.1.1, what is Acct-Session-Id AVP? > where is it defined? > > +------------------------------------------------------------+ > + Lee, Sokjoon (ICQ No : 69347005) > + Office : +82-42-860-5455 Fax : +82-42-860-5611 > + Cell : +82-17-344-1295 E-Mail : junny@etri.re.kr > > + Wireless Internet Security Research Team > + Electronics and Telecommunications Research Institute > + 161 Gajeongdong, Yuseonggu, Daejeon, 305-350, Korea > +------------------------------------------------------------+ From owner-aaa-wg@merit.edu Fri Nov 8 02:31:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09081 for ; Fri, 8 Nov 2002 02:31:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5B95091232; Fri, 8 Nov 2002 02:34:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D918912D5; Fri, 8 Nov 2002 02:34:14 -0500 (EST) 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 1ACAD91232 for ; Fri, 8 Nov 2002 02:32:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id EBBAD5DE3B; Fri, 8 Nov 2002 02:32:25 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 742245DE2D for ; Fri, 8 Nov 2002 02:32:25 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gA86SdW15772 for ; Thu, 7 Nov 2002 22:28:39 -0800 Date: Thu, 7 Nov 2002 22:28:39 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: "Pseudo WG last call" on draft-ietf-aaa-diameter-nasreq-10.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Many thanks to Glen Zorn and David Mitton for their work on the NASREQ-10 draft. The draft was not ready prior to the IETF 55 submission deadline, so it is not up on the IETF archive, but that does not prevent us from reading it and finding issues, so... This is to announce a "pseudo" AAA WG last call on the Diameter NASREQ application: http://home.attbi.com/~dmitton/draft-ietf-aaa-diameter-nasreq-10.txt AAA WG participants are encouraged to read the draft and send issues relating to it to the AAA WG mailing list, using the issue submission format described at: http://www.drizzle.com/~aboba/AAA/issues.html Since we've set aside some time to discuss NASREQ issues at IETF 55, if possible, it would be helpful to get issues submitted prior to the AAA WG meeting at IETF 55. After IETF 55, we will resolve the outstanding issues and get a new version up on the IETF archive, and start the "real" AAA WG last call on NASREQ-10. If everyone reads the draft and posts their issues, hopefully there won't be many left for the "real" AAA WG last call :) From owner-aaa-wg@merit.edu Fri Nov 8 02:34:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09130 for ; Fri, 8 Nov 2002 02:34:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5DA71912D5; Fri, 8 Nov 2002 02:36:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 28FA0912D6; Fri, 8 Nov 2002 02:36:49 -0500 (EST) 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 32061912D5 for ; Fri, 8 Nov 2002 02:36:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id B0B925DE2D; Fri, 8 Nov 2002 02:36:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 25E335DDF3 for ; Fri, 8 Nov 2002 02:36:47 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gA86XAG16098 for ; Thu, 7 Nov 2002 22:33:10 -0800 Date: Thu, 7 Nov 2002 22:33:10 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: NASREQ question (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk ---------- Forwarded message ---------- Date: Fri, 8 Nov 2002 08:50:08 +0100 From: Valery Kholodkov To: aboba@internaut.com Subject: NASREQ question Hello! I examined NASREQ 10 and found some disadventages, which had not been eliminated since the first RADIUS accounting RFC. While the speed of access servers increasing there should arise a problem of traffic limitation. To increase finacial mobility traffic limits should be specified by AAA server in authorization messsages explicitly. As an example 6 AVPs to AA-Answer message: Input-Octets-Limit This attribute specifies maximum number of octets to be received from user before termination of session or prompt. If this attribute is not specified and Input-Gigawords-Limit attribute is not specified the maximum number of octets to be received from user is unlimited. Output-Octets-Limit This attribute specifies maximum number of octets to be sent to user before termination of session or prompt. If this attribute is not specified and Output-Gigawords-Limit attribute is not specified the maximum number of octets to be sent to user is unlimited. Input-Gigawords-Limit This attribute specifies maximum number of gigawords to be received from user before termination of session or prompt. If this attribute is not specified the maximum number of octets to be received from user is defined by Input-Octets-Limit attribute. Output-Gigawords-Limit This attribute specifies maximum number of gigawords to be sent to user before termination of session or prompt. If this attribute is not specified the maximum number of octets to be sent to user is defined by Output-Octets-Limit attribute. Input-Packets-Limit This attribute specifies maximum number of packets to be received from user before termination of session or prompt. Output-Packets-Limit This attribute specifies maximum number of packets to be sent to user before termination of session or prompt. And another question: will be there a dedicated Diameter application for authenticaton, authorization and accounting of E-mail services? -- Valery Kholodkov | Golden Line Communications Company 52 Chkalova, st | Russian Federation, Penza 440052 From owner-aaa-wg@merit.edu Thu Nov 14 15:17:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29368 for ; Thu, 14 Nov 2002 15:17:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 84E4E912AA; Thu, 14 Nov 2002 15:20:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5470C912AB; Thu, 14 Nov 2002 15:20:21 -0500 (EST) 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 52AE7912AA for ; Thu, 14 Nov 2002 15:20:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3FA9C5DF68; Thu, 14 Nov 2002 15:20:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from roam.psg.com (unknown [204.42.73.254]) by segue.merit.edu (Postfix) with ESMTP id 1F7B65DF65 for ; Thu, 14 Nov 2002 15:20:20 -0500 (EST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18CQTL-000O4Y-00; Thu, 14 Nov 2002 12:20:19 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: aaa-wg@merit.edu Cc: Patrik Fältström Subject: [AAA-WG]: charset issue with draft-ietf-aaa-diameter-15.txt Message-Id: Date: Thu, 14 Nov 2002 12:20:19 -0800 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Text from draft below... When you have two strings using the Unicode Character Set, there need to be rules for how you compare the two strings -- if comparison is done. Doing bit by bit comparison is cruel, and not recommended, but even if that is the solution that has to be stated. The easiest way of doing it is to create a profile of stringprep, which tells how comparison is to be done, and then point at that profile in documents like this. Note: UTF8String in diameter possibly have to be split in two different types "normalized UTF8String" and "raw UTF8String". I am happy to explain more if needed. paf > 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 [UFT8] 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 > encoding of a code point into UTF-8 charset 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 charset > is > identical to the US-ASCII charset. > > UTF-8 may require multiple bytes to represent a single > character / code point; thus the length of an UTF8String in > octets may be different from the number of characters encoded. > > Note that the AVP Length field of an UTF8String is measured in > octets, not characters. ------- end of forwarded message ------- From owner-aaa-wg@merit.edu Thu Nov 14 15:26:03 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29600 for ; Thu, 14 Nov 2002 15:26:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 509A0912AB; Thu, 14 Nov 2002 15:28:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A25A912AE; Thu, 14 Nov 2002 15:28:24 -0500 (EST) 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 B7B95912AB for ; Thu, 14 Nov 2002 15:28:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 934615DF7F; Thu, 14 Nov 2002 15:28:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from roam.psg.com (unknown [204.42.73.254]) by segue.merit.edu (Postfix) with ESMTP id 730845DF73 for ; Thu, 14 Nov 2002 15:28:21 -0500 (EST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18CQb6-000O5U-00; Thu, 14 Nov 2002 12:28:20 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: aaa-wg@merit.edu Cc: Patrik Fältström Subject: [AAA-WG]: charset issue with draft-ietf-aaa-diameter-15.txt Message-Id: Date: Thu, 14 Nov 2002 12:28:20 -0800 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit more from paf, the actual suggested text! > The easiest way of doing it is to create a profile of stringprep, > which tells how comparison is to be done, and then point at that > profile in documents like this. I.e. suggested action: 1) Create a profile of stringprep to be used for diameter 2) Add the following text to "UTF8String", after first paragraph The string is to be normalized according to the specification in RFC XXXX [xxxx] 3) Add reference to the profile Reference: [xxxx] RFC XXXX, stringprep profile for use in the Diameter protocol. paf From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Text from draft below... When you have two strings using the Unicode Character Set, there need to be rules for how you compare the two strings -- if comparison is done. Doing bit by bit comparison is cruel, and not recommended, but even if that is the solution that has to be stated. The easiest way of doing it is to create a profile of stringprep, which tells how comparison is to be done, and then point at that profile in documents like this. Note: UTF8String in diameter possibly have to be split in two different types "normalized UTF8String" and "raw UTF8String". I am happy to explain more if needed. paf > 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 [UFT8] 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 > encoding of a code point into UTF-8 charset 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 charset > is > identical to the US-ASCII charset. > > UTF-8 may require multiple bytes to represent a single > character / code point; thus the length of an UTF8String in > octets may be different from the number of characters encoded. > > Note that the AVP Length field of an UTF8String is measured in > octets, not characters. ------- end of forwarded message ------- From owner-aaa-wg@merit.edu Sun Nov 17 10:14:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19492 for ; Sun, 17 Nov 2002 10:14:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CFA3291230; Sun, 17 Nov 2002 10:16:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2FCD491231; Sun, 17 Nov 2002 10:16:47 -0500 (EST) 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 99CA591230 for ; Sun, 17 Nov 2002 10:16:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 73F715E0B9; Sun, 17 Nov 2002 10:16:37 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8531C5E0B8 for ; Sun, 17 Nov 2002 10:16:32 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gAHEC2b15567 for ; Sun, 17 Nov 2002 06:12:02 -0800 Date: Sun, 17 Nov 2002 06:12:02 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: RE: Evaluation: draft-ietf-aaa-diameter-mobileip - Diameter Mobil e IPv4 Application to Proposed Standard (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk From: "Wijnen, Bert (Bert)" Nits: - document diameter-mobileip-13 - needs IPR section - introduction 1st para: "an Application of 4" means ???I think you mean "Application-ID" or such, no? - sect 9.7 referes to sect 1.7, which should be sect 1.8 I think - [KEYWORDS] reference has been decided to be a normative reference From owner-aaa-wg@merit.edu Sun Nov 17 10:17:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19529 for ; Sun, 17 Nov 2002 10:17:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1107891307; Sun, 17 Nov 2002 10:19:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E1D69123A; Sun, 17 Nov 2002 10:17:03 -0500 (EST) 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 E1AA591231 for ; Sun, 17 Nov 2002 10:16:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id CE0255E0B8; Sun, 17 Nov 2002 10:16:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 9AC0F5DF78 for ; Sun, 17 Nov 2002 10:16:54 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gAHECPf15571 for ; Sun, 17 Nov 2002 06:12:25 -0800 Date: Sun, 17 Nov 2002 06:12:25 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Re: Evaluation: draft-ietf-aaa-diameter-mobileip - Diameter Mobile IPv4 Application to Proposed Standard (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk ------- start of forwarded message ------- From: "Steven M. Bellovin" To: IESG Secretary Cc: Internet Engineering Steering Group Subject: Re: Evaluation: draft-ietf-aaa-diameter-mobileip - Diameter Mobile IPv4 Application to Proposed Standard Date: Thu, 14 Nov 2002 01:39:45 -0500 In message <200211041850.NAA28818@ietf.org>, IESG Secretary writes: > >Last Call to expire on: 2002-10-30 > > Please return the full line with your position. > > Yes No-Objection Discuss * Abstain > > >Steve Bellovin [ ] [ ] [ X ] [ ] 1.6: What is a "preconfigured shared security association"? Do you mean a preshared secret? A security association comprises far more than just a key. I have not evaluated the security of the scheme in this section, since it depends on another draft, and possibly on the security of MobileIP itself. Can we really even consider this draft until those are done? 1.10: What firewall rules? Are the agents supposed to tell their local firewalls to open up some holes? 5.2: 64 bits is not sufficient for a key. Why not just mandate 128, instead of strongly recommending it? 5: I confess that it still isn't clear to me how the home and foreign agents know authoritatively who each other are. Then again, that's always been my main complaint about AAA. But here they're handing out keys. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) ------- end of forwarded message ------- From owner-aaa-wg@merit.edu Sun Nov 17 10:17:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19567 for ; Sun, 17 Nov 2002 10:17:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7725E91302; Sun, 17 Nov 2002 10:19:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C3CCC91305; Sun, 17 Nov 2002 10:19:29 -0500 (EST) 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 1CB7B9123C for ; Sun, 17 Nov 2002 10:19:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 058D05E0B8; Sun, 17 Nov 2002 10:19:08 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 6628A5DF79 for ; Sun, 17 Nov 2002 10:19:07 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gAHEEb715698 for ; Sun, 17 Nov 2002 06:14:37 -0800 Date: Sun, 17 Nov 2002 06:14:37 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Re: IPAddress derived datatype in Diameter (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Sent: dinsdag 12 november 2002 11:33 > To: bwijnen@lucent.com > Cc: bkhabs@nc.rr.com; mwdaniele@adelphia.net; > shawn.routhier@windriver.com; randy@psg.com > Subject: Re: Question on IPAddress > > > > >>>>> Wijnen, Bert (Bert) writes: > > Bert> If you look at draft-ietf-aaa-diameter-15.txt, page 40, sect > Bert> 4.4, then you will see that they use IPAddress to represent IPv4 > Bert> and IPv6 addresses. > > Bert> I wondered what your comments would be, given the fact that you > Bert> guys took a real good look at IP (or INET) addresses when you > Bert> worked on the INET-ADDRESS-MIB. > > Bert> For me, this use of IPAddress seems at least confusing, and it > Bert> also does not seem future-proof. > > I brought this issue up, probably two years ago now. The answer was > (if I recall correctly) that they do not really care about boxes at > zone boundaries and future IP address formats. I have not followed the > AAA work lately so I have no clue whether they have a union mechanism > which can be used to introduce a more generic format for addresses. > > /js > -----Original Message----- > From: Brian Haberman [mailto:bkhabs@nc.rr.com] > Sent: dinsdag 12 november 2002 0:04 > To: Wijnen, Bert (Bert) > Cc: Mike Daniele (E-mail); Juergen Schoenwaelder (E-mail); Shawn > Routhier (E-mail); Randy Bush (E-mail) > Subject: Re: Question on IPAddress > > > I agree that it is confusing. It will be broken if a new IP > address family comes along that just happens to have the same > address lengths as either v4 or v6. > > Any ideas why they did not use a Type definition rather than > relying on address lengths? > > Brian > > Wijnen, Bert (Bert) wrote: > > If you look at draft-ietf-aaa-diameter-15.txt, page 40, sect 4.4, > > then you will see that they use IPAddress to represent IPv4 and > > IPv6 addresses. > > > > I wondered what your comments would be, given the fact that you > > guys took a real good look at IP (or INET) addresses when you > > worked on the INET-ADDRESS-MIB. > > > > For me, this use of IPAddress seems at least confusing, and it > > also does not seem future-proof. > > > > Thanks, > > Bert From owner-aaa-wg@merit.edu Sun Nov 17 10:17:45 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19580 for ; Sun, 17 Nov 2002 10:17:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C950D91238; Sun, 17 Nov 2002 10:19:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2B2791304; Sun, 17 Nov 2002 10:19:25 -0500 (EST) 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 4EE3191240 for ; Sun, 17 Nov 2002 10:17:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 357375DF78; Sun, 17 Nov 2002 10:17:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id B073D5DF33 for ; Sun, 17 Nov 2002 10:17:14 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gAHECjW15602 for ; Sun, 17 Nov 2002 06:12:45 -0800 Date: Sun, 17 Nov 2002 06:12:45 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Late comments (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk ------- start of forwarded message ------- From: "IANA" To: "Randy Bush" Cc: "IESG" Subject: Late comments Date: Thu, 14 Nov 2002 07:48:55 -0800 Token: Bush, Randy Hi Randy, I'm getting this comment to you a little late. This document was late night reading for me last night. This stuff is a bit confusing. I was wondering if it would be possible for the authors to include an initial registry in this document? This would help the IANA when it comes time to take care of the IANA actions. If that is not possible can one of the authors assist me in getting this registry set-up? Suggestions? Thanks, Michelle IANA ------- end of forwarded message ------- From owner-aaa-wg@merit.edu Sun Nov 17 11:03:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20484 for ; Sun, 17 Nov 2002 11:03:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 190EC91203; Sun, 17 Nov 2002 11:05:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB08F91235; Sun, 17 Nov 2002 11:05:38 -0500 (EST) 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 F150891203 for ; Sun, 17 Nov 2002 11:05:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id DA9355DDDB; Sun, 17 Nov 2002 11:05:37 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 599BF5DDD4 for ; Sun, 17 Nov 2002 11:05:37 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gAHF17w18343 for ; Sun, 17 Nov 2002 07:01:07 -0800 Date: Sun, 17 Nov 2002 07:01:07 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: RE: Randy won't be around this week (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk ---------- Forwarded message ---------- Date: Sun, 17 Nov 2002 16:43:52 +0100 From: "Wijnen, Bert (Bert)" To: ops-chairs@ietf.org Cc: "Iesg (E-mail)" Subject: RE: Randy won't be around this week As a follow up to Harald's email, here is the list of WGs and ADs that will be in your WG session in the AD role. MBONED - Bill Fenner PSAMP - Bert Wijnen DNSOP - Bert Wijnen, with Rob & Patrik PTOMAINE - Alex Zinin (+ Bill a bit) V6OPS - Thomas Narten, with Erik Nordmark AAA - Steve Bellovin, with Bert Wijnen BMWG - Scott Bradner (half-time, shared with rddp) IPFIX - Bert Wijnen If you have any questions, psl do email me or grab in in the hallways Thanks, Bert > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: zondag 17 november 2002 15:19 > To: ops-chairs@ietf.org > Subject: Randy won't be around this week > > > Randy Bush has been called away due to a family medical emergency. > > He is not expected back for this IETF meeting. > > We will do what we can to make sure your groups are still adequately > provided with IESG contacts. > > Harald Alvestrand > IETF Chair > From owner-aaa-wg@merit.edu Mon Nov 18 04:38:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16477 for ; Mon, 18 Nov 2002 04:38:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B738291214; Mon, 18 Nov 2002 04:40:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D06191218; Mon, 18 Nov 2002 04:40:23 -0500 (EST) 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 3FFD691214 for ; Mon, 18 Nov 2002 04:40:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2D8495DDB2; Mon, 18 Nov 2002 04:40:22 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from rumba.cefriel.it (rumba.cefriel.it [131.175.53.6]) by segue.merit.edu (Postfix) with ESMTP id 898F05DDA0 for ; Mon, 18 Nov 2002 04:40:21 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: [AAA-WG]: Ipsec Usage in DIAMETER MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 18 Nov 2002 10:42:30 +0100 Message-ID: <28C92BFE6EB5C943B15743D0E11E60360467D7@rumba.cefriel.it> Thread-Topic: Ipsec Usage in DIAMETER Thread-Index: AcKO5s/k+KDdL8J2QAiyxzvwL2Wd8Q== From: "Antonio Forzieri" To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA16477 Hi, I have a question on the Ipsec usage under DIAMETER... What I can't really understand is where IPsec should be used. Suppose we have the folllowing scenario: +-----+ | | +--| DIA | +-----+ +-----+ | | | | | PSTN | | | +-----+ | Joe |------------| NAS |---| | | | | | +-----+ +-----+ | +-----+ IP.valid.ip.2 | | | +--|Targ.| | | +-----+ IP.valid.ip.1 In this scenario Joe tries to authenticate himself using the diameter server. Once Joe is authenticated I would like that traffic between Joe and the target will be secured using Ipsec. Can Diameter (NAS) negotiate an Ipsec tunnel between Joe and Target or Ipsec is just used between NAS and the target to establish a secure tunnel for the user? Can Diameter be used as a kind of PIC (Pre-IKE Credential Provisioning Protocol)? Is there any document (draft, rfc, thesis, article...) about this topic? From owner-aaa-wg@merit.edu Mon Nov 18 07:10:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18658 for ; Mon, 18 Nov 2002 07:10:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 38E3191218; Mon, 18 Nov 2002 07:13:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06BFB9123B; Mon, 18 Nov 2002 07:13:10 -0500 (EST) 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 12DD891218 for ; Mon, 18 Nov 2002 07:13:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id E87095DF46; Mon, 18 Nov 2002 07:13:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7A5F85DDFF for ; Mon, 18 Nov 2002 07:13:09 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gAIB8RV20067; Mon, 18 Nov 2002 03:08:27 -0800 Date: Mon, 18 Nov 2002 03:08:27 -0800 (PST) From: Bernard Aboba To: Antonio Forzieri Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Ipsec Usage in DIAMETER In-Reply-To: <28C92BFE6EB5C943B15743D0E11E60360467D7@rumba.cefriel.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Via Tunnel attributes it is possible for the Diameter server to specify a compulsory IPsec tunnel (or other types of tunnels) to be brought up between the NAS and the Target. But if you want a tunnel between Joe and the Target then that is "voluntary tunneling" which is the responsibility of the end systems. On Mon, 18 Nov 2002, Antonio Forzieri wrote: > Hi, > I have a question on the Ipsec usage under DIAMETER... > From owner-aaa-wg@merit.edu Mon Nov 18 08:02:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19828 for ; Mon, 18 Nov 2002 08:02:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F3C329123E; Mon, 18 Nov 2002 08:02:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F3AE9124A; Mon, 18 Nov 2002 08:02:23 -0500 (EST) 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 1D0839123E for ; Mon, 18 Nov 2002 08:02:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 00B795DE51; Mon, 18 Nov 2002 08:02:16 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from rumba.cefriel.it (rumba.cefriel.it [131.175.53.6]) by segue.merit.edu (Postfix) with ESMTP id 37A1E5DDD4 for ; Mon, 18 Nov 2002 08:02:15 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: Ipsec Usage in DIAMETER MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 18 Nov 2002 14:04:23 +0100 Message-ID: <28C92BFE6EB5C943B15743D0E11E60360467D9@rumba.cefriel.it> Thread-Topic: [AAA-WG]: Ipsec Usage in DIAMETER Thread-Index: AcKO/ClFwAECU3zETVu3g0Ob4VmhPgAAP16A From: "Antonio Forzieri" To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA19828 >Via Tunnel attributes it is possible for the Diameter server to specify a >compulsory IPsec tunnel (or other types of tunnels) to be brought up >between the NAS and the Target. But if you want a tunnel between Joe and the Target then >that is "voluntary tunneling" which is the responsibility of the end >systems. Ok that's right. What I had in mind is the following: I want to access to a VPN from a remote "untrusted" system. An idea should be (IPSRA): - Obtain an internet access; - Connect to the edge-gateway of the target VPN - Authenticate the user (DIAMETER ?!?) - If Authentication is OK then return the remote user some credential (certificate+private key ?!?) else brig the connection down. - Give remote user configuration parameters (valid_ip, dns address,...) - Start IKE negotiation using the credential (Joe <--> Target) - Bring up the tunnel (Joe <--> Target) But It seems to me DIAMETER can't authenticate the user and then brig up a tunnel between the remote user and the edge gateway. Am I right? -- Antonio From owner-aaa-wg@merit.edu Tue Nov 19 12:33:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10647 for ; Tue, 19 Nov 2002 12:33:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AFE93912A3; Tue, 19 Nov 2002 12:35:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 973829129D; Tue, 19 Nov 2002 12:35:45 -0500 (EST) 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 C17A0912D1 for ; Tue, 19 Nov 2002 12:35:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id A231D5DEC0; Tue, 19 Nov 2002 12:35:33 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E47CD5DDF8 for ; Tue, 19 Nov 2002 12:35:32 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gAJGUpg20583 for ; Tue, 19 Nov 2002 08:30:51 -0800 Date: Tue, 19 Nov 2002 08:30:50 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 388: Diameter Peer Discovery and Authorization Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: November 11, 2002 Reference: Document: BASE-15 Comment type: T Priority: S Section: 5.2 Rationale/Explanation of issue: While Diameter uses IPsec or TLS for transmission layer security, the ability authenticate with IKE or TLS does not imply authorization. Therefore, with pre-shared key authentication in IKE it is still typically necessary to manually configure the IP address of the NAS or AAA server, along with the corresponding pre-shared key. With certificate authentication, the FQDN is typically manually configued, along with the trusted root. This means that Diameter Peer discovery, even if secured, must be careful to make sure that the discovered Diameter peers are actually authorized for their roles. This is particularly important when DNS is used for discovery, because the use of DNSSEC does not imply authorization. For example, a host could exist that had a TyLS certificate (for web use), and secured DNS RRs, but was *not* authorized to act as a Diameter server. Similarly, with SLPv2, security SHOULD be used, both to validate the integrity of the advertisements as well as to determine authorization to act as a Diameter Peer. Change: "It is recommended that SLPv2 security be deployed (this requires distributing keys to SLPv2 agents). This is discussed further in Appendix A." To: "SLPv2 security SHOULD be used (requiring distribution of keys to SLPv2 agents) in order to ensure that discovered peers are authorized for their roles. SLPv2 is discussed further in Appendix A." Change: "If the server is using a site certificate, the domain name in the query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS exchange. Similarly, the domain name in the SRV query and the domain name in the target in the SRV record MUST both be valid based on the same site certificate. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate that this was the desired behavior, or the result of an attack." To: "If the server is using a site certificate, the domain name in the query and the domain name in the replacement field MUST both be valid based onthe the site certificate handed out by the server in the TLS or IKE exchange. Similarly, the domain name in the SRV query and the domain name in the target in the SRV record MUST both be valid based on the same site certificate. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate that this was the desired behavior, or the result of an attack. Also, the Diameter Peer MUST check to make sure that the discovered peers are authorized to act in its role. Authentication via IKE or TLS, or validation of DNS RRs via DNSSEC is not sufficient to conclude this. For example, a web server may have obtained a valid TLS certificate, and secured RRs may be included in the DNS, but this does not imply that it is authorized to act as a Diameter Server. Authorization can be achieved for example, by configuration of a Diameter Server CA. Alternatively this can be achieved by definition of OIDs within TLS or IKE certificates so as to signify Diameter Server authorization." From owner-aaa-wg@merit.edu Tue Nov 19 16:35:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17377 for ; Tue, 19 Nov 2002 16:35:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CB0EF912AA; Tue, 19 Nov 2002 16:37:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2A87912AC; Tue, 19 Nov 2002 16:37:13 -0500 (EST) 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 47EC9912AA for ; Tue, 19 Nov 2002 16:37:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2E9225E37E; Tue, 19 Nov 2002 16:37:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h007.c000.snv.cp.net [209.228.32.71]) by segue.merit.edu (Postfix) with SMTP id 85B505E383 for ; Tue, 19 Nov 2002 16:37:08 -0500 (EST) Received: (cpmta 28754 invoked from network); 19 Nov 2002 13:37:07 -0800 Received: from 204.42.69.172 (HELO DMITTON-IBMTP.mitton.com) by smtp.mitton.com (209.228.32.71) with SMTP; 19 Nov 2002 13:37:07 -0800 X-Sent: 19 Nov 2002 21:37:07 GMT Message-Id: <5.1.1.6.2.20021119163242.03637d78@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 19 Nov 2002 16:37:01 -0500 To: aaa-wg@merit.edu From: David Mitton Subject: [AAA-WG]: Issue 381: New Authorization Limit AVPs request Cc: Valery Kholodkov In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk I'd like to see some interest and support for these AVPs from the WG before adding these. Dave. >Date: Fri, 8 Nov 2002 08:50:08 +0100 >From: Valery Kholodkov >Subject: NASREQ question > > Hello! >I examined NASREQ 10 and found some disadventages, which had not been >eliminated since the first RADIUS accounting RFC. While the speed of access >servers increasing there should arise a problem of traffic limitation. To >increase finacial mobility traffic limits should be specified by AAA server >in authorization messsages explicitly. >As an example 6 AVPs to AA-Answer message: > >Input-Octets-Limit >This attribute specifies maximum number of octets to be received from user >before termination of session or prompt. If this attribute is not specified >and Input-Gigawords-Limit attribute is not specified the maximum number of >octets to be received from user is unlimited. > >Output-Octets-Limit >This attribute specifies maximum number of octets to be sent to user before >termination of session or prompt. If this attribute is not specified and >Output-Gigawords-Limit attribute is not specified the maximum number of >octets to be sent to user is unlimited. > >Input-Gigawords-Limit >This attribute specifies maximum number of gigawords to be received from user >before termination of session or prompt. If this attribute is not specified >the maximum number of octets to be received from user is defined by >Input-Octets-Limit attribute. > >Output-Gigawords-Limit >This attribute specifies maximum number of gigawords to be sent to user >before termination of session or prompt. If this attribute is not specified >the maximum number of octets to be sent to user is defined by >Output-Octets-Limit attribute. > >Input-Packets-Limit >This attribute specifies maximum number of packets to be received from user >before termination of session or prompt. > >Output-Packets-Limit >This attribute specifies maximum number of packets to be sent to user before >termination of session or prompt. ----- >And another question: will be there a dedicated Diameter application for >authenticaton, authorization and accounting of E-mail services? No, Not in scope. >-- >Valery Kholodkov | Golden Line Communications Company >52 Chkalova, st | Russian Federation, Penza 440052 From owner-aaa-wg@merit.edu Tue Nov 19 16:35:09 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17402 for ; Tue, 19 Nov 2002 16:35:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3E932912A9; Tue, 19 Nov 2002 16:37:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C76B1912AB; Tue, 19 Nov 2002 16:37:10 -0500 (EST) 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 DC7E7912A9 for ; Tue, 19 Nov 2002 16:37:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id CB3235E41B; Tue, 19 Nov 2002 16:37:08 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h007.c000.snv.cp.net [209.228.32.71]) by segue.merit.edu (Postfix) with SMTP id 7350F5E37E for ; Tue, 19 Nov 2002 16:37:08 -0500 (EST) Received: (cpmta 28733 invoked from network); 19 Nov 2002 13:37:06 -0800 Received: from 204.42.69.172 (HELO DMITTON-IBMTP.mitton.com) by smtp.mitton.com (209.228.32.71) with SMTP; 19 Nov 2002 13:37:06 -0800 X-Sent: 19 Nov 2002 21:37:06 GMT Message-Id: <5.1.1.6.2.20021119161347.03637948@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 19 Nov 2002 16:32:20 -0500 To: "S. Lee" From: David Mitton Subject: [AAA-WG]: Issue 380: Questions about nasreq-10 preview Cc: aaa-wg@merit.edu In-Reply-To: References: <002801c285a9$02b133d0$12f1fe81@JUNNY> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 11/6/2002 06:42 AM -0800, Bernard Aboba wrote: >Filed as Issue 380. > >On Thu, 7 Nov 2002, S. Lee wrote: > > > I have some questions about nasreq-10 preview... > > > > 1. In Section 6.1, > > > > "- If state information regarding the RADIUS request was saved in a > > Proxy-Info AVP, the RADIUS Identifier and UDP IP Address and > > port number are extracted and used in issuing the RADIUS reply." > > > > I think this sentence must be changed to : > > > > "If state information regarding the RADIUS request was saved in a > > Proxy-Info AVP or local state table, the RADIUS Identifier and UDP > IP Address and > > port number are extracted and used in issuing the RADIUS reply." Accepted. > > 2. Multi-Round-Time-Out AVP is refered in section 6.1 & 6.1.1, > > but in 7.1 we can't find this AVP from AAR/A AVP table. Ummm... it's there now. > > > > 3. In Section 6.1.1 > > "- The Route-Record AVPs MUST be added to the Diameter message, in > > the same order they were present in the request." > > Why the Route-Record AVP MUST be added in Diameter answer? Per rules of Base sections 6.1.8, 6.2 et.al. > > > > 4. Why is the NAS-Session-Key AVP omitted in this draft? > > It will be only in aaa-diameter-eap draft? Yes, that is why. > > 5. In Section 6.1.1, what is Acct-Session-Id AVP? > > where is it defined? It is the AVP formerly named Acct-RADIUS-Session-Id in the Base. The inclusion of -RADIUS in the AVP name is a gratuitous change from RADIUS attribute 44 and the Base editor agreed to change it back. > > +------------------------------------------------------------+ > > + Lee, Sokjoon (ICQ No : 69347005) > > + Office : +82-42-860-5455 Fax : +82-42-860-5611 > > + Cell : +82-17-344-1295 E-Mail : junny@etri.re.kr > > > > + Wireless Internet Security Research Team > > + Electronics and Telecommunications Research Institute > > + 161 Gajeongdong, Yuseonggu, Daejeon, 305-350, Korea > > +------------------------------------------------------------+ From owner-aaa-wg@merit.edu Wed Nov 20 15:22:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29852 for ; Wed, 20 Nov 2002 15:22:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 22234912D2; Wed, 20 Nov 2002 15:24:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5BD4912D3; Wed, 20 Nov 2002 15:24:32 -0500 (EST) 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 E20A0912D2 for ; Wed, 20 Nov 2002 15:24:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id BCE7B5DE80; Wed, 20 Nov 2002 15:24:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h000.c000.snv.cp.net [209.228.32.64]) by segue.merit.edu (Postfix) with SMTP id 720985DD99 for ; Wed, 20 Nov 2002 15:24:31 -0500 (EST) Received: (cpmta 5504 invoked from network); 20 Nov 2002 12:24:30 -0800 Received: from 204.42.69.172 (HELO DMITTON-IBMTP.mitton.com) by smtp.mitton.com (209.228.32.64) with SMTP; 20 Nov 2002 12:24:30 -0800 X-Sent: 20 Nov 2002 20:24:30 GMT Message-Id: <5.1.1.6.2.20021120152327.0315b958@131.103.193.97> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 20 Nov 2002 15:24:27 -0500 To: aaa-wg@merit.edu From: David Mitton Subject: [AAA-WG]: Session Presentation slide copies Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Will all speakers please send your presentations files to Bernard and me. Thanks, Dave From owner-aaa-wg@merit.edu Fri Nov 22 17:07:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05393 for ; Fri, 22 Nov 2002 17:07:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0FF3F91237; Fri, 22 Nov 2002 17:09:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CDF5191238; Fri, 22 Nov 2002 17:09:21 -0500 (EST) 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 DA05291237 for ; Fri, 22 Nov 2002 17:09:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id BD3605DDE3; Fri, 22 Nov 2002 17:09:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 4D8F85DDC5 for ; Fri, 22 Nov 2002 17:09:20 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gAML4KV14046 for ; Fri, 22 Nov 2002 13:04:20 -0800 Date: Fri, 22 Nov 2002 13:04:20 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Slides from IETF 55 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Are available at: http://www.drizzle.com/~aboba/AAA/AAA-IETF55.zip From owner-aaa-wg@merit.edu Fri Nov 22 19:22:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07532 for ; Fri, 22 Nov 2002 19:22:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5635A91231; Fri, 22 Nov 2002 19:24:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2007491236; Fri, 22 Nov 2002 19:24:56 -0500 (EST) 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 3442891231 for ; Fri, 22 Nov 2002 19:24:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 194C95E07E; Fri, 22 Nov 2002 19:24:55 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id AA6EF5DEE6 for ; Fri, 22 Nov 2002 19:24:54 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gAMNJsH21506 for ; Fri, 22 Nov 2002 15:19:54 -0800 Date: Fri, 22 Nov 2002 15:19:54 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Minutes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk If those of you who took minutes at IETF 55 can send them to me and David, that would be helpful. From owner-aaa-wg@merit.edu Sun Nov 24 13:46:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00728 for ; Sun, 24 Nov 2002 13:46:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EE88191232; Sun, 24 Nov 2002 13:48:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA64B91233; Sun, 24 Nov 2002 13:48:29 -0500 (EST) 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 B5B9291232 for ; Sun, 24 Nov 2002 13:48:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id AB0EC5E030; Sun, 24 Nov 2002 13:48:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8FF175DEF1 for ; Sun, 24 Nov 2002 13:47:26 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gAOHgDH02237; Sun, 24 Nov 2002 09:42:13 -0800 Date: Sun, 24 Nov 2002 09:42:12 -0800 (PST) From: Bernard Aboba To: marco.stura@nokia.com Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Re: Technical question about Diam. transport In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D9E43EA@esebe016.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I think the answer is that the transport document focusses on the AAA layer heartbeat, since that is available over any reliable transport, and provides inter-box failover support. That said, the SCTP heartbeat could result in failover between interfaces on the same box. On Mon, 18 Nov 2002 marco.stura@nokia.com wrote: > Hi Bernard, > > I'm a bit late with this question but some time ago while discussing the > issue 372 (T-flag) you wrote: > > "While the original connection is "suspect", the > Diameter client may have switched over to the new server, and according to > the transport state machine, the time between going into the "SUSPECT" > state and closing the connection is Tw + TIME_WAIT, assuming that no > heartbeat is detected. If a heartbeat is detected, then the > original connection might remain up for considerably longer than this. So > the time to look into the future is really until TIME_WAIT after the > old connection is closed." > > I did check the aaa-transport (http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-08.txt) > , I know that SCTP reports to the application layer but I didn't find any > interaction with the SCTP heartbeat in the described transport state machine. > Could you help me to understand how exactly interaction with SCTP is supposed > to work and when Diameter should close the connection? > > Thanks by advance > Marco > From owner-aaa-wg@merit.edu Mon Nov 25 11:37:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07493 for ; Mon, 25 Nov 2002 11:37:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E261F91244; Mon, 25 Nov 2002 11:40:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A5DB391246; Mon, 25 Nov 2002 11:40:23 -0500 (EST) 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 596DC91244 for ; Mon, 25 Nov 2002 11:40:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 422155DF3B; Mon, 25 Nov 2002 11:40:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from cms1.etri.re.kr (cms1.etri.re.kr [129.254.16.11]) by segue.merit.edu (Postfix) with ESMTP id 81E2A5DF3A for ; Mon, 25 Nov 2002 11:40:20 -0500 (EST) Received: from JUNNY (junny.etri.re.kr [129.254.241.18]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XS4RYFFK; Tue, 26 Nov 2002 01:32:24 +0900 Message-ID: <001801c294a1$57c02190$12f1fe81@JUNNY> From: "S. Lee" To: "David Mitton" Cc: References: <002801c285a9$02b133d0$12f1fe81@JUNNY> <5.1.1.6.2.20021119161347.03637948@getmail.mitton.com> Subject: [AAA-WG]: Re: Issue 380: Questions about nasreq-10 preview Date: Tue, 26 Nov 2002 01:40:18 +0900 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thank you for your answer. But, Route-Record AVP will be omitted in any Diameter answer message by Base draft. Route-Record AVP is only for loop checking, not for answer message routing. Moreover, by Base section 6.2, the following setence of nasreq section 6.1.1 would be deleted. "- The request's Origin-Host information is added to the Destination-Host AVP." I also found editorial mistake in section 8.1. '268' would be deleted because of the absence of DER/A in this draft. By the way, if NAS-Session-Key AVP will be only in aaa-diameter-eap draft, then does it mean that session key share between peer and authenticator will not be established on nasreq application? In wireless LAN environment supporting 802.11i (which needs session key sharing), nasreq application will be meaningless? Sokjoon Lee ----- Original Message ----- From: "David Mitton" To: "S. Lee" Cc: Sent: Wednesday, November 20, 2002 6:32 AM Subject: Issue 380: Questions about nasreq-10 preview > At 11/6/2002 06:42 AM -0800, Bernard Aboba wrote: > >Filed as Issue 380. > > > >On Thu, 7 Nov 2002, S. Lee wrote: > > > > > I have some questions about nasreq-10 preview... > > > > > > 1. In Section 6.1, > > > > > > "- If state information regarding the RADIUS request was saved in a > > > Proxy-Info AVP, the RADIUS Identifier and UDP IP Address and > > > port number are extracted and used in issuing the RADIUS reply." > > > > > > I think this sentence must be changed to : > > > > > > "If state information regarding the RADIUS request was saved in a > > > Proxy-Info AVP or local state table, the RADIUS Identifier and UDP > > IP Address and > > > port number are extracted and used in issuing the RADIUS reply." > > Accepted. > > > > 2. Multi-Round-Time-Out AVP is refered in section 6.1 & 6.1.1, > > > but in 7.1 we can't find this AVP from AAR/A AVP table. > > Ummm... it's there now. > > > > > > > 3. In Section 6.1.1 > > > "- The Route-Record AVPs MUST be added to the Diameter message, in > > > the same order they were present in the request." > > > Why the Route-Record AVP MUST be added in Diameter answer? > > Per rules of Base sections 6.1.8, 6.2 et.al. > > > > > > > 4. Why is the NAS-Session-Key AVP omitted in this draft? > > > It will be only in aaa-diameter-eap draft? > > Yes, that is why. > > > > 5. In Section 6.1.1, what is Acct-Session-Id AVP? > > > where is it defined? > > It is the AVP formerly named Acct-RADIUS-Session-Id in the Base. > The inclusion of -RADIUS in the AVP name is a gratuitous change from RADIUS > attribute 44 and the Base editor agreed to change it back. > > > > +------------------------------------------------------------+ > > > + Lee, Sokjoon (ICQ No : 69347005) > > > + Office : +82-42-860-5455 Fax : +82-42-860-5611 > > > + Cell : +82-17-344-1295 E-Mail : junny@etri.re.kr > > > > > > + Wireless Internet Security Research Team > > > + Electronics and Telecommunications Research Institute > > > + 161 Gajeongdong, Yuseonggu, Daejeon, 305-350, Korea > > > +------------------------------------------------------------+ > From owner-aaa-wg@merit.edu Tue Nov 26 06:52:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27821 for ; Tue, 26 Nov 2002 06:52:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 054389121B; Tue, 26 Nov 2002 06:55:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BAFF491259; Tue, 26 Nov 2002 06:55:08 -0500 (EST) 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 9EE609121B for ; Tue, 26 Nov 2002 06:55:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8369C5DDD6; Tue, 26 Nov 2002 06:55:07 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from emily.fle.fujitsu.com (unknown [193.122.18.249]) by segue.merit.edu (Postfix) with SMTP id E70EF5DDC3 for ; Tue, 26 Nov 2002 06:55:06 -0500 (EST) Received: from 10.142.50.249 by emily.fle.fujitsu.com (InterScan E-Mail VirusWall NT); Tue, 26 Nov 2002 11:46:04 -0000 Received: by fle2.fleblue.fujitsu.com with Internet Mail Service (5.5.2656.59) id ; Tue, 26 Nov 2002 11:53:42 -0000 Message-ID: From: x.chen@fle.fujitsu.com To: aaa-wg@merit.edu Subject: [AAA-WG]: Question regarding aaa-EAP "Diameter-EAP-Answer (DEA) Command" Date: Tue, 26 Nov 2002 11:53:35 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-2fa4ba4e-3420-499a-be7e-f730bda5207a" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPartTM-000-2fa4ba4e-3420-499a-be7e-f730bda5207a Content-Type: text/plain Hi, Aaa-EAP draft 3.2 says that "the EAP client has been successfully authenticated and authorized, in which case the message MUST include the Result-Code AVP indicating success, and SHOULD include an EAP-Payload of type EAP- Success. This event MUST cause the access device to provide service to the EAP client." I am thinking the case that the EAP client is only authenticated but not authorized to use service, then I will use Result-Code "DIAMETER_LIMITED_SUCCESS 2002" in the Diameter-EAP-Answer message and also includes the EAP success payload in the message since the authentication is successful. When receiving such a message, the device in the access network will not open the door to provide service to the EAP client, but the EAP client will think I am already authorised since it gets back the EAP-Success, and starts to send IP packets. Would this lead to bad user experience? Do you see the need to have a new "limited success" code for EAP as well? So that the authentication server can use the "Limited Success" EAP payload to indicate to the EAP client that further actions needs to be taken to be granted to the service. Thanks Xin Chen Mobile Network Architecture Fujitsu Laboratories of Europe LTD Tel: +44 (0) 2086064453 Mobile: +44 (0)7775741020 ------=_NextPartTM-000-2fa4ba4e-3420-499a-be7e-f730bda5207a Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit This e-mail has been scanned by Trend InterScan Software. This e-mail (and its attachment(s) if any) is intended for the named addressee(s) only. It may contain information which is privileged and confidential within the meaning of the applicable law. Unauthorised use, copying or disclosure is strictly prohibited and may be unlawful. If you are not the intended recipient please delete this email and contact the sender via email return. Fujitsu Laboratories of Europe Ltd (FLE) does not accept responsibility for changes made to this email after it was sent. The views expressed in this email may not necessarily be the views held by FLE. Unless expressly stated otherwise, this email does not form part of a legally binding contract or agreement between the recipient and Fujitsu Laboratories of Europe Ltd (FLE). ------=_NextPartTM-000-2fa4ba4e-3420-499a-be7e-f730bda5207a-- From owner-aaa-wg@merit.edu Wed Nov 27 13:26:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23103 for ; Wed, 27 Nov 2002 13:26:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AB9DE9129E; Wed, 27 Nov 2002 13:29:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6CE5B912A0; Wed, 27 Nov 2002 13:29:16 -0500 (EST) 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 4ABBC9129E for ; Wed, 27 Nov 2002 13:29:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 351595DFCD; Wed, 27 Nov 2002 13:29:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id 8E4BE5DDA1 for ; Wed, 27 Nov 2002 13:29:14 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gARISKB06540; Wed, 27 Nov 2002 10:28:20 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gARISQ302089; Wed, 27 Nov 2002 12:28:27 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Nov 2002 12:28:13 -0600 Message-ID: <23BDB0046F3ED51185CD0002A5608D240706F218@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: aaa-wg@merit.edu Cc: aboba@internaut.com, david@mitton.com, tony.johansson@bytemobile.com, charliep@iprg.nokia.com, pcalhoun@bstormnetworks.com, "Jayshree Bharatia" Subject: [AAA-WG]: AAA-MIP comments Date: Wed, 27 Nov 2002 12:28:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29642.BEC589A0" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C29642.BEC589A0 Content-Type: text/plain Hello all, I have a few comments on draft-ietf-aaa-diameter-mobileip-13.txt. My apology for sending these comments so late in the process. Most of the comments are editorial and I believe they can be easily fixed. Please let me know if you need further clarification on these comments. -Kuntal ----------------------------------------------------------------------- Section 1.4: In the event that the mobile node with AAA NAI extension support [AAANAI] has been previously authorized by the AAAH and now needs to be re-authenticated, and requests to keep the assigned home agent in the foreign network, the mobile node MUST include the HA NAI and the AAAH NAI in the registration request to the FA. Upon receipt, the FA will create the AMR including the MIP-Home-Agent-Address AVP, the Destination-Host AVP based on the AAAH NAI and include the MIP-Home- Agent-Host AVP based on the home agent NAI. If the AAAF authorizes the use of the requested home agent, the AAAF MUST set the Home- Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. In the event that the mobile node that does not support the AAA NAI extension has been previously authorized by the AAAH and now needs to be re-authenticated, and requests to keep the assigned home agent in the foreign network, the mobile node sends a registration request without the AAA NAI and the HA NAI. Upon receipt, the FA will create the AMR including the MIP-Home-Agent-Address AVP. If the AAAF authorizes the use of the requested home agent, and if it has knowledge that the requested home agent is in its own domain, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP- Feature-Vector AVP. Comment: If the requested HA is not in the same domain of the AAAF, then the AAAF cannot really authorize the use of it (paragraph 1 above). Therefore change the text like: " In the event that the mobile node with AAA NAI extension support [AAANAI] has been previously authorized by the AAAH and now needs to be re-authenticated, and requests to keep the assigned home agent in the foreign network, the mobile node MUST include the HA NAI and the AAAH NAI in the registration request to the FA. Upon receipt, the FA will create the AMR including the MIP-Home-Agent-Address AVP, the Destination-Host AVP based on the AAAH NAI and include the MIP-Home- Agent-Host AVP based on the home agent NAI. In the event that the mobile node that does not support the AAA NAI extension has been previously authorized by the AAAH and now needs to be re-authenticated, and requests to keep the assigned home agent in the foreign network, the mobile node sends a registration request without the AAA NAI and the HA NAI. Upon receipt, the FA will create the AMR including the MIP-Home-Agent-Address AVP. If the AAAF authorizes the use of the requested home agent, and if it has knowledge that the requested home agent is in its own domain, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP-Feature -Vector AVP. " Section 1.4: Mobile Node Foreign Agent Home Agent AAAF AAAH ----------- ------------- ------------- ---------- ---------- <----Challenge---- Reg-Req (Response)-> ------------AMR-------------> -----AMR----> <----HAR----- <-----HAR------ ------HAA------> -----HAA----> <----AMA----- <-------------AMA------------ <---Reg-Reply---- Figure 6: Mobile IP/Diameter Message Exchange when HA is allocated in Visited Realm Comment: Why is the FA sending back an AMA to the MN? I think it is an editorial problem. Section 2.1: If a foreign agent is used in a visited network, the AAAF MAY set the Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in the AMR message to indicate that it is willing to assign a Home Agent in the visited realm. Comment: It should be: "If a home agent is used in a visited....." Section 2.1: If the mobile node's home address is all ones, the foreign or home agent MUST include a MIP-Mobile-Node-Address AVP, set to all ones. Comment: 1. RFC 3344 talks about dynamic Home Address allocation based on Home Address= 0.0.0.0 in the RRQ. No mention of Home Address = 255.255.255.255. Section 2.1: ::= < Diameter Header: 260, REQ, PXY > < Session-ID > { Auth-Application-Id } { User-Name } { Destination-Realm } { Origin-Host } { Origin-Realm } { MIP-Reg-Request } { MIP-MN-AAA-Auth } [ Acct-Multi-Session-Id ] [ Destination-Host ] [ Origin-State-Id ] [ MIP-Mobile-Node-Address ] [ MIP-Home-Agent-Address ] [ MIP-Feature-Vector ] [ MIP-Originating-Foreign-AAA ] [ Authorization-Lifetime ] [ Auth-Session-State ] [ MIP-FA-Challenge ] [ MIP-Candidate-Home-Agent-Host ] * [ Proxy-Info ] * [ Route-Record ] * [ AVP ] Question: Why MIP-Home-Agent-Host AVP is missing? Section 2.3: If the HAR message does not include a MIP-Mobile-Node-Address AVP, and the Registration Request has 0.0.0.0 for the home address, and the HAR is successfully processed, the Home Agent MUST allocate one such address to the mobile node. Comment: The last sentence says "...one such address...". Which address? Section 4.5: If the mobile node includes a valid home address (i.e., not equal to 0.0.0.0 or 255.255.255.255) in its Registration Request, the foreign agent zeroes the Mobile-Node-Home-Address-Requested flag in the MIP- Feature-Vector AVP. If the mobile node sets the home address field equal to 0.0.0.0 in its Registration Request, the foreign agent sets the Mobile-Node- Home-Address-Requested flag to one. If the mobile node sets the home agent field equal to 255.255.255.255 in its Registration Request, the foreign agent sets both the Home- Agent-Requested flag and the Home-Address-Allocatable-Only-in-Home- Realm flag to one in the MIP-Feature-Vector AVP. Comment: Some of the options here are unnecessary. The Home Address request should only be analyzed by the AAAH and HA as the field appears in the MIP-Reg-Request AVP. The FA or the AAAF should not worry about Home Address field. Section 4.5: 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. Comment: MN requesting HA assignment by an indication in the Home Address field is unnecessary. Why can't the MN indicate it's preference for HA assignment in the HA field in the RRQ? Section 5.3: If, on the other hand, the home agent is to be allocated in the visited realm, the AAAH transmits the HAR to the foreign home agent, where, prior to delivery to the home agent, it is perused by the AAAF hosting the home agent. If the session key needs to be encrypted the AAAH will encrypt the MIP-HA-to-MN Key AVP and the MIP-FA-to-MN AVP with help of CMS security application [CMS] using the security association with the AAAF associated with the home agent. Comment: This paragraph is confusing. It starts with an if statement: "If, on the .....it is perused by the AAAF hosting the home agent." Question: Why AAAF is perusing/examining the Mobile-Home session key? If for some reason the AAAF finds the Mobile-Home session key to be wrong, what does it do? ---------------------------------------------------------------------------- -- ------_=_NextPart_001_01C29642.BEC589A0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable AAA-MIP comments

Hello all,
I have a few comments on = draft-ietf-aaa-diameter-mobileip-13.txt. My apology for sending these = comments so late in the process. Most of the comments are editorial and = I believe they can be easily fixed. Please let me know if you need = further clarification on these comments.

-Kuntal

---------------------------------------------------------------= --------

Section 1.4:

   In the event that the mobile node with = AAA NAI extension support
   [AAANAI] has been previously authorized = by the AAAH and now needs to
   be re-authenticated, and requests to = keep the assigned home agent in
   the foreign network, the mobile node = MUST include the HA NAI and the
   AAAH NAI in the registration request to = the FA. Upon receipt, the FA
   will create the AMR including the = MIP-Home-Agent-Address AVP, the
   Destination-Host AVP based on the AAAH = NAI and include the MIP-Home-
   Agent-Host AVP based on the home agent = NAI. If the AAAF authorizes
   the use of the requested home agent, = the AAAF MUST set the Home-
   Agent-In-Foreign-Network bit in the = MIP-Feature-Vector AVP.


   In the event that the mobile node that = does not support the AAA NAI
   extension has been previously = authorized by the AAAH and now needs to
   be re-authenticated, and requests to = keep the assigned home agent in
   the foreign network, the mobile node = sends a registration request
   without the AAA NAI and the HA NAI. = Upon receipt, the FA will create
   the AMR including the = MIP-Home-Agent-Address AVP. If the AAAF
   authorizes the use of the requested = home agent, and if it has
   knowledge that the requested home agent = is in its own domain, the
   AAAF MUST set the = Home-Agent-In-Foreign-Network bit in the MIP-
   Feature-Vector AVP.


Comment:
If the requested HA is not in the same domain of the = AAAF, then the AAAF
cannot really authorize the use of it (paragraph 1 = above).
Therefore change the text like:

" 
   In the event that the mobile node with = AAA NAI extension support
   [AAANAI] has been previously authorized = by the AAAH and now needs to
   be re-authenticated, and requests to = keep the assigned home agent in
   the foreign network, the mobile node = MUST include the HA NAI and the
   AAAH NAI in the registration request to = the FA. Upon receipt, the FA
   will create the AMR including the = MIP-Home-Agent-Address AVP, the
   Destination-Host AVP based on the AAAH = NAI and include the MIP-Home-
   Agent-Host AVP based on the home agent = NAI.

   In the event that the mobile node that = does not support the AAA NAI
   extension has been previously = authorized by the AAAH and now needs to
   be re-authenticated, and requests to = keep the assigned home agent in
   the foreign network, the mobile node = sends a registration request
   without the AAA NAI and the HA NAI. = Upon receipt, the FA will create
   the AMR including the = MIP-Home-Agent-Address AVP.

   If the AAAF authorizes the use of the = requested home agent, and if it
   has knowledge that the requested home = agent is in its own domain, the
   AAAF MUST set the = Home-Agent-In-Foreign-Network bit in the MIP-Feature
   -Vector AVP.
"


Section 1.4:

   Mobile Node   Foreign = Agent    Home = Agent        = AAAF         AAAH
   -----------   = -------------  -------------   = ----------    ----------

      = <----Challenge----
    Reg-Req (Response)->
          &nb= sp;           &nb= sp;  ------------AMR------------->
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;      -----AMR---->
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;      <----HAR-----
          &nb= sp;           &nb= sp;           &nb= sp;   <-----HAR------
          &nb= sp;           &nb= sp;           &nb= sp;   ------HAA------>
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;      -----HAA---->
  <----AMA-----
          &nb= sp;            = <-------------AMA------------
       = <---Reg-Reply----
   Figure 6: Mobile IP/Diameter Message = Exchange when HA is allocated in
         = ;            = ;          Visited = Realm

Comment: Why is the FA sending back an AMA to the MN? = I think it is an editorial
problem.


Section 2.1:

   If a foreign agent is used in a visited = network, the AAAF MAY set the
   Foreign-Home-Agent-Available flag in = the MIP-Feature-Vector AVP in
   the AMR message to indicate that it is = willing to assign a Home Agent
   in the visited realm.

Comment: It should be: "If a home agent is used = in a visited....."


Section 2.1:

If the mobile node's home address is all ones, the = foreign or home
agent MUST include a MIP-Mobile-Node-Address AVP, = set to all ones.

Comment:
1. RFC 3344 talks about dynamic Home Address = allocation based on Home
Address=3D 0.0.0.0 in the RRQ. No mention of Home = Address =3D 255.255.255.255.


Section 2.1:

      = <AA-Mobile-Node-Request> ::=3D < Diameter Header: 260, REQ, = PXY >
          &nb= sp;           &nb= sp;            = < Session-ID >
          &nb= sp;           &nb= sp;            { = Auth-Application-Id }
          &nb= sp;           &nb= sp;            { = User-Name }
          &nb= sp;           &nb= sp;            { = Destination-Realm }
          &nb= sp;           &nb= sp;            { = Origin-Host }
          &nb= sp;           &nb= sp;            { = Origin-Realm }
          &nb= sp;           &nb= sp;            { = MIP-Reg-Request }
          &nb= sp;           &nb= sp;            { = MIP-MN-AAA-Auth }
          &nb= sp;           &nb= sp;            [ = Acct-Multi-Session-Id ]
          &nb= sp;           &nb= sp;            [ = Destination-Host ]
         = ;            = ;            = ;  [ Origin-State-Id ]
          &nb= sp;           &nb= sp;            [ = MIP-Mobile-Node-Address ]
          &nb= sp;           &nb= sp;            [ = MIP-Home-Agent-Address ]
          &nb= sp;           &nb= sp;            [ = MIP-Feature-Vector ]
          &nb= sp;           &nb= sp;            [ = MIP-Originating-Foreign-AAA ]
          &nb= sp;           &nb= sp;            [ = Authorization-Lifetime ]
          &nb= sp;           &nb= sp;            [ = Auth-Session-State ]
          &nb= sp;           &nb= sp;            [ = MIP-FA-Challenge ]
          &nb= sp;           &nb= sp;            [ = MIP-Candidate-Home-Agent-Host ]
          &nb= sp;           &nb= sp;          * [ = Proxy-Info ]
          &nb= sp;           &nb= sp;          * [ = Route-Record ]
          &nb= sp;           &nb= sp;          * [ AVP = ]

Question: Why MIP-Home-Agent-Host AVP is = missing?

Section 2.3:

   If the HAR message does not include a = MIP-Mobile-Node-Address
   AVP, and the Registration Request has = 0.0.0.0 for the home address,
   and the HAR is successfully processed, = the Home Agent MUST allocate
   one such address to the mobile = node.

Comment: The last sentence says "...one such = address...". Which address?

Section 4.5:

   If the mobile node includes a valid home = address (i.e., not equal to
   0.0.0.0 or 255.255.255.255) in its = Registration Request, the foreign
   agent zeroes the = Mobile-Node-Home-Address-Requested flag in the MIP-
   Feature-Vector AVP.

   If the mobile node sets the home address = field equal to 0.0.0.0 in
   its Registration Request, the foreign = agent sets the Mobile-Node-
   Home-Address-Requested flag to = one.

   If the mobile node sets the home agent = field equal to 255.255.255.255
   in its Registration Request, the = foreign agent sets both the Home-
   Agent-Requested flag and the = Home-Address-Allocatable-Only-in-Home-
   Realm flag to one in the = MIP-Feature-Vector AVP.


Comment: Some of the options here are unnecessary. = The Home Address request
should only be analyzed by the AAAH and HA as the = field appears in the
MIP-Reg-Request AVP. The FA or the AAAF should not = worry about Home Address
field.

Section 4.5:

   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.

Comment: MN requesting HA assignment by an indication = in the Home Address
field is unnecessary. Why can't the MN indicate it's = preference for
HA assignment in the HA field in the RRQ?


Section 5.3:

   If, on the other hand, the home agent is = to be allocated in the
   visited realm, the AAAH transmits the = HAR to the foreign home agent,
   where, prior to delivery to the home = agent, it is perused by the AAAF
   hosting the home agent. If the session = key needs to be encrypted the
   AAAH will encrypt the MIP-HA-to-MN Key = AVP and the MIP-FA-to-MN AVP
   with help of CMS security application = [CMS] using the security
   association with the AAAF associated = with the home agent.

Comment: This paragraph is confusing. It starts with = an if statement: "If, on the
.....it is perused by the AAAF hosting the home = agent."

Question:
Why AAAF is perusing/examining the Mobile-Home = session key?
If for some reason the AAAF finds the Mobile-Home = session key to be wrong, what
does it do?

---------------------------------------------------------------= ---------------

------_=_NextPart_001_01C29642.BEC589A0-- From owner-aaa-wg@merit.edu Thu Nov 28 07:54:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26972 for ; Thu, 28 Nov 2002 07:54:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DDAAA9123A; Thu, 28 Nov 2002 07:56:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A5617912C6; Thu, 28 Nov 2002 07:56:54 -0500 (EST) 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 6C8DA9123A for ; Thu, 28 Nov 2002 07:56:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 52F245DEE2; Thu, 28 Nov 2002 07:56:53 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 699485DDA0 for ; Thu, 28 Nov 2002 07:56:52 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gASCuG915452 for ; Thu, 28 Nov 2002 14:56:16 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Nov 2002 14:56:51 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 14:56:50 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 14:56:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Some editorial nits in base-15 Date: Thu, 28 Nov 2002 14:56:49 +0200 Message-ID: Thread-Topic: [AAA-WG]: Some editorial nits in base-15 Thread-Index: AcJ/GuJwH7MezLlVT6i/WgriXHdrOAXwrdUw From: To: , X-OriginalArrivalTime: 28 Nov 2002 12:56:50.0388 (UTC) FILETIME=[9E148940:01C296DD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA26972 Changes made. John > -----Original Message----- > From: ext Mikael Jakobsson (EAB) > [mailto:Mikael.Jakobsson@epk.ericsson.se] > Sent: 29 October, 2002 09:14 > To: 'aaa-wg@merit.edu' > Subject: [AAA-WG]: Some editorial nits in base-15 > > > Hi, > > found some editorial nits while reading through draft 15 of > diameter base. > > 2.8.3 Redirect Agents > > First paragraph states > > "Since Redirect agents do not perform any application level > processing, the provide services for all Diameter applications, and > therefore MUST advertise the Relay Application Identifier." > > which is the same as last paragraph (except for spelling > error in the first one) > > "Since Redirect agents do not perform any application level > processing, they provide relaying services for all Diameter > applications, and therefore MUST advertise the Relay Application > Identifier." > > Suggestion is to remove the first one. > > > 8.6 Inferring Session Termination from Origin-State-Id > > Correct CER/CAA to CER/CEA in the following paragraph (the > second one). > > "By including Origin-State-Id in CER/CAA 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." > > > 11.3 Application Identifiers > > Second paragraph states 0xff00000000 - 0xfffffffe for vendor > specific applications. > There are too many zeros in 0xff00000000 so correct to > 0xff000000 - 0xff000000. > > "IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for > standards-track applications; and 0xff00000000 - 0xfffffffe for > vendor specific applications, on a first-come, first-served basis. > Assignment of standards-track application IDs are by Designated > Expert with Specification Required [IANA]." > > > 11.4.1 Result-Code AVP Values > > Correct value ranges for result codes from > > "As defined in Section 7.1, the Result-Code AVP (AVP Code 268) defines > the values 1001, 2001-2002, 3001-3010, 4001-4002 and 5001-5017." > > to > > "As defined in Section 7.1, the Result-Code AVP (AVP Code 268) defines > the values 1001, 2001-2002, 3001-3010, 4001-4003 and 5001-5016." > > > > Best Regards > > Mikael Jakobsson > > > > ----------------------------------------- > Mikael Jakobsson > Ericsson AB > Core Unit Service Network & Applications > Tel: +46 455 39 52 81 > Fax: +46 455 815 10 > Mobile: +46 703 10 52 81 > mailto:Mikael.Jakobsson@epk.ericsson.se > http://www.ericsson.com > > > From owner-aaa-wg@merit.edu Thu Nov 28 07:55:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27047 for ; Thu, 28 Nov 2002 07:55:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A02E0912C7; Thu, 28 Nov 2002 07:58:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BCD9912C8; Thu, 28 Nov 2002 07:58:28 -0500 (EST) 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 055E0912C7 for ; Thu, 28 Nov 2002 07:58:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id E57705DEE2; Thu, 28 Nov 2002 07:58:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 08F4A5DDA0 for ; Thu, 28 Nov 2002 07:58:26 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gASCvo916654 for ; Thu, 28 Nov 2002 14:57:50 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Nov 2002 14:57:01 +0200 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 14:57:01 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 14:57:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 376: Base-15 Nits Date: Thu, 28 Nov 2002 14:57:00 +0200 Message-ID: Thread-Topic: [AAA-WG]: Issue 376: Base-15 Nits Thread-Index: AcJ8q/PWR22Qom2KR3G6f8WTihvSqAaMa3fA From: To: , X-OriginalArrivalTime: 28 Nov 2002 12:57:01.0078 (UTC) FILETIME=[A473B360:01C296DD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA27047 changes made. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 26 October, 2002 06:53 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 376: Base-15 Nits > > > Issue 376: Base-15 Nits > Submitter name: David Mitton > Submitter email address: david@mitton.com > Date first submitted: October 23, 2002 > Reference: > Document: Base-15 > Comment type: E > Priority: 1 > Section: Several > Rationale/Explanation of issue: > > - "Acct-Interim-Interval" has lower case "interim" in two places > > - "Accounting-RADIUS-Session-Id" (44) is a really silly name change. > I have a line in NASREQ now that says basically insert the value of > attribute 44, into AVP 44 with a different name. Eg, no value change. > > The RADIUS attribute 44 as defined in RFC 2866 is "Acct-Session-Id" > and we have not changed the semantics (just added behaviors > to some other > AVPs elsewhere) > > Can we just revert to the old name? it does not conflict. > > In general, I would think that all RFC 2866 accounting attributes keep > their Acct-* names, and any new Diameter Accounting AVPs are named > Accounting-* > > This has been true except for this case and Acct-Application-Id (259) > {I guess because it pairs well with Auth-Application-Id (258)} > which really doesn't offer a dictionary conflict. > > Dave. > > > From owner-aaa-wg@merit.edu Thu Nov 28 08:04:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27193 for ; Thu, 28 Nov 2002 08:04:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D02F791214; Thu, 28 Nov 2002 08:07:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9143491218; Thu, 28 Nov 2002 08:07:27 -0500 (EST) 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 3C8E591214 for ; Thu, 28 Nov 2002 08:07:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2B6115DE62; Thu, 28 Nov 2002 08:07:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 7354F5DE5D for ; Thu, 28 Nov 2002 08:07:25 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gASD6n923967 for ; Thu, 28 Nov 2002 15:06:50 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Nov 2002 15:07:24 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 15:07:22 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 15:07:22 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 15:07:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Diameter Base Application ID values Date: Thu, 28 Nov 2002 15:07:21 +0200 Message-ID: Thread-Topic: [AAA-WG]: Issue 378: Yet More Base-15 Nits Thread-Index: AcKDRpuzChGO7mUlRrKjry7ZvcKwQQTmEmXQ From: To: , X-OriginalArrivalTime: 28 Nov 2002 13:07:21.0824 (UTC) FILETIME=[16720600:01C296DF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA27193 Hi all, Currently, we have the application IDs as follows in the Diameter base spec: NASREQ 1 [NASREQ] Mobile-IP 4 [DIAMMIP] Diameter Base Accounting 5 Relay 0xffffffff Would anyone complain if they were modified to: Diameter Base Accounting 0 NASREQ 1 [NASREQ] Mobile-IP 2 [DIAMMIP] Relay 0xffffffff thanks, John From owner-aaa-wg@merit.edu Thu Nov 28 08:10:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27253 for ; Thu, 28 Nov 2002 08:10:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3CCE491218; Thu, 28 Nov 2002 08:12:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04859912C6; Thu, 28 Nov 2002 08:12:32 -0500 (EST) 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 B7B3191218 for ; Thu, 28 Nov 2002 08:12:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id A24545DE5D; Thu, 28 Nov 2002 08:12:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id B623F5DDA0 for ; Thu, 28 Nov 2002 08:12:30 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gASDDU622907 for ; Thu, 28 Nov 2002 15:13:30 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Nov 2002 15:12:25 +0200 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 15:12:25 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 15:12:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 378: Yet More Base-15 Nits Date: Thu, 28 Nov 2002 15:12:24 +0200 Message-ID: Thread-Topic: [AAA-WG]: Issue 378: Yet More Base-15 Nits Thread-Index: AcKDRpuzChGO7mUlRrKjry7ZvcKwQQTmIwGg From: To: , X-OriginalArrivalTime: 28 Nov 2002 13:12:24.0632 (UTC) FILETIME=[CAEEDB80:01C296DF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA27253 Hi, > Since we agreed to adopt a base protocol standard accounting > application Id, the value needs to be included somewhere and > statements about support being implicit within CER/CEA need > to be removed. > > Section 1.2.4, Page 14: > > Change: > > "Since every Diameter implementation MUST support accounting, there is > no need to advertise support for the Base accounting application > within the CER/CEA, since this is implicit. This basic accounting > support is sufficient to handle any application that uses the ACR/ACA > commands defined in this document, as long as no new mandatory AVPs > are added. A mandatory AVP is defined as one which has the "M" bit > set when sent within an accounting command, regardless of whether it > is required or optional within the ABNF for the accounting > application." > > To: > > "Every Diameter implementation MUST support accounting. > Basic accounting support is sufficient to handle any application > that uses the ACR/ACA commands defined in this document, as long > as no new mandatory AVPs are added. A mandatory AVP is defined as > one which has the "M" bit set when sent within an accounting > command, regardless of whether it is required or optional > within the ABNF for the accounting application." OK. > Section 1.2.4, last paragraph: > > "If the base accounting is used without any mandatory AVPs, new > commands or additional mechanisms (e.g. application defined state > machine), then the base protocol defined standard accounting > application Id (section 2.4) MUST be used in ACR/ACA commands." > > The base protocol defined standard accounting application id is not > defined in section 2.4, 11.3 or anywhere else for that matter. > Suggest the value 0x00000000 be allocated in Section 11.3: > "IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for > standards-track applications; and 0xff00000000 - 0xfffffffe for > vendor specific applications, on a first-come, first-served basis. > The value 0x00000000 is allocated for use within the Diameter > Base standard accounting application. > Assignment of standards-track application IDs are by Designated > Expert with Specification Required [IANA]." OK > Section 3, Application-ID > > "See Section 11.3 for the possible values that the application-id may > use." > > Section 11.3 doesn't contain any such values. Should this > section include values for NASREQ or MIP? OK > Section 6.8 (Auth-Application-Id AVP) and 6.9 > (Acct-Application-ID AVP) > > "This AVP SHOULD be placed as close to the Diameter header as > possible." > > The ABNFs show this AVP 6th in commands as as RAR. Is this "as close as > possible"? Or was this a typo, made unnecessary by including the > application-Id in the header? Suggest deleting sentance. > Section 3: > > " Command-Code values in the range 0xfffffe through 0xffffff are > reserved for experimental use (see Section 11.3). Commands in > this range MUST also include a Vendor-Specific Application ID AVP > (see section 6.11)." > > There are only two experimental AVPs now, and this space is to be used > for experimental, not vendor-specific purposes. Please change to: > > "Command-Code values 16,777,214 and 16,777,215 (hexidecimal values FFFFFE - > FFFFFF) are reserved for experimental use (See Section 11.3). " OK > 6.11 Vendor-Specific-Application-Id AVP > > "Exactly one of the Auth-Application-Id and > Acct-Application-Id AVPs MAY be present." > > Shouldn't this statement have occurred earlier, such as in > section 6.9? Will add it to 6.9. John From owner-aaa-wg@merit.edu Thu Nov 28 08:18:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27430 for ; Thu, 28 Nov 2002 08:18:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A2ECA912C6; Thu, 28 Nov 2002 08:21:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C2BF912C8; Thu, 28 Nov 2002 08:21:30 -0500 (EST) 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 48230912C6 for ; Thu, 28 Nov 2002 08:21:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 28C2D5DE62; Thu, 28 Nov 2002 08:21:29 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 5B1BC5DDA0 for ; Thu, 28 Nov 2002 08:21:28 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gASDKq903775 for ; Thu, 28 Nov 2002 15:20:52 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 28 Nov 2002 15:21:27 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 15:21:26 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 15:21:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: RE: base 15 editorial Date: Thu, 28 Nov 2002 15:21:26 +0200 Message-ID: Thread-Topic: base 15 editorial Thread-Index: AcKGS/RzQgdBfMC3SEefNcGn5lpmWQAAHtCQBCUSYZA= From: To: , X-OriginalArrivalTime: 28 Nov 2002 13:21:26.0638 (UTC) FILETIME=[0DFE68E0:01C296E1] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA27430 > E2E-Sequence AVP is missing in 4.6 and the spec > does not allocate AVP-code (and flags?) for the AVP. Added: E2E-Sequence AVP 300 6.15 Grouped | M | P | | V | Y | John From owner-aaa-wg@merit.edu Thu Nov 28 08:29:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27638 for ; Thu, 28 Nov 2002 08:29:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9DCE8912C8; Thu, 28 Nov 2002 08:31:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66D14912C9; Thu, 28 Nov 2002 08:31:51 -0500 (EST) 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 2E754912C8 for ; Thu, 28 Nov 2002 08:31:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0A6E75DE5D; Thu, 28 Nov 2002 08:31:50 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 4E7865DDA0 for ; Thu, 28 Nov 2002 08:31:49 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gASDVD911715 for ; Thu, 28 Nov 2002 15:31:13 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Nov 2002 15:31:48 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 15:31:48 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 15:31:47 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 15:31:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Where can I find [RoamRev] Date: Thu, 28 Nov 2002 15:31:46 +0200 Message-ID: Thread-Topic: [AAA-WG]: Where can I find [RoamRev] Thread-Index: AcKEIF5T/0Ss3VWyTSWyfwrGbJZOxASv64rw From: To: , Cc: X-OriginalArrivalTime: 28 Nov 2002 13:31:47.0336 (UTC) FILETIME=[7FF56880:01C296E2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA27638 Added to the reference section. > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 04 November, 2002 17:33 > To: suresh.leroy@alcatel.be > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Where can I find [RoamRev] > > > This is RFC 2194. Isn't this listed in the reference section? > > On Mon, 4 Nov 2002 suresh.leroy@alcatel.be wrote: > > > Hello, > > > > Does anyone know where I can find the [ROAMREV] document > mentioned in the > > introduction of base-15 document. > > It is not in the reference list. > > "The ROAMOPS WG provided a survey of roaming > implementations [ROAMREV], detailed > > ..." > > > > > > Regards, > > Suresh > > > > From owner-aaa-wg@merit.edu Thu Nov 28 12:57:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01547 for ; Thu, 28 Nov 2002 12:57:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 31BAC912CB; Thu, 28 Nov 2002 12:59:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 03243912D1; Thu, 28 Nov 2002 12:59:58 -0500 (EST) 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 A5512912CB for ; Thu, 28 Nov 2002 12:59:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7CCED5DF7A; Thu, 28 Nov 2002 12:59:56 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from roam.psg.com (unknown [147.28.4.2]) by segue.merit.edu (Postfix) with ESMTP id 108AB5DE50 for ; Thu, 28 Nov 2002 12:59:56 -0500 (EST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18HSx7-000GnS-00; Thu, 28 Nov 2002 09:59:53 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter Base Application ID values References: Message-Id: Date: Thu, 28 Nov 2002 09:59:53 -0800 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Currently, we have the application IDs as follows in the Diameter base spec: > > NASREQ 1 [NASREQ] > Mobile-IP 4 [DIAMMIP] > Diameter Base Accounting 5 > Relay 0xffffffff > > Would anyone complain if they were modified to: > > Diameter Base Accounting 0 > NASREQ 1 [NASREQ] > Mobile-IP 2 [DIAMMIP] > Relay 0xffffffff should not these be an iana registry with allocations based on the iana considerations section? randy From owner-aaa-wg@merit.edu Thu Nov 28 15:20:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03802 for ; Thu, 28 Nov 2002 15:20:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7554F912D4; Thu, 28 Nov 2002 15:23:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44B80912D5; Thu, 28 Nov 2002 15:23:08 -0500 (EST) 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 1C8C2912D4 for ; Thu, 28 Nov 2002 15:23:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id E997B5E054; Thu, 28 Nov 2002 15:23:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 0CF6A5E063 for ; Thu, 28 Nov 2002 15:23:06 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gASKO6627408 for ; Thu, 28 Nov 2002 22:24:07 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Nov 2002 22:23:04 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 22:23:04 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 22:23:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Diameter Base Application ID values Date: Thu, 28 Nov 2002 22:23:02 +0200 Message-ID: Thread-Topic: [AAA-WG]: Diameter Base Application ID values Thread-Index: AcKXB/elrIM68A7HR6OuYMJOhSRReQAE9NOg From: To: Cc: X-OriginalArrivalTime: 28 Nov 2002 20:23:03.0821 (UTC) FILETIME=[F44A33D0:01C2971B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA03802 Randy, > > Currently, we have the application IDs as follows in the > Diameter base spec: > > > > NASREQ 1 [NASREQ] > > Mobile-IP 4 [DIAMMIP] > > Diameter Base Accounting 5 > > Relay 0xffffffff > > > > Would anyone complain if they were modified to: > > > > Diameter Base Accounting 0 > > NASREQ 1 [NASREQ] > > Mobile-IP 2 [DIAMMIP] > > Relay 0xffffffff > > should not these be an iana registry with allocations based on the > iana considerations section? Of course the values will be in an IANA considerations section, I just wanted to make sure the change in value would not cause anyone undue disruption. thanks, John From owner-aaa-wg@merit.edu Thu Nov 28 16:48:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05033 for ; Thu, 28 Nov 2002 16:48:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 589A6912D7; Thu, 28 Nov 2002 16:50:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D863912D8; Thu, 28 Nov 2002 16:50:27 -0500 (EST) 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 261E7912D7 for ; Thu, 28 Nov 2002 16:49:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 00F8A5DE5A; Thu, 28 Nov 2002 16:49:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7CF945DDF3 for ; Thu, 28 Nov 2002 16:49:25 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gASKhmW28457; Thu, 28 Nov 2002 12:43:48 -0800 Date: Thu, 28 Nov 2002 12:43:48 -0800 (PST) From: Bernard Aboba To: john.loughney@nokia.com Cc: randy@psg.com, Subject: RE: [AAA-WG]: Diameter Base Application ID values In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Of course the values will be in an IANA considerations section, > I just wanted to make sure the change in value would not cause > anyone undue disruption. I apologize for asking for 0 to be assigned for Diameter Base accounting; I didn't realize 5 was already assigned. So, take my request with a grain of salt :) Happy Thanksgiving! From owner-aaa-wg@merit.edu Fri Nov 29 18:31:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10884 for ; Fri, 29 Nov 2002 18:31:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4A7E291307; Fri, 29 Nov 2002 18:34:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 19BF191309; Fri, 29 Nov 2002 18:34:00 -0500 (EST) 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 5521D91307 for ; Fri, 29 Nov 2002 18:32:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2717C5DDF0; Fri, 29 Nov 2002 18:32:55 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by segue.merit.edu (Postfix) with ESMTP id 4CF0B5DD92 for ; Fri, 29 Nov 2002 18:32:54 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id gATNWdOL009375; Sat, 30 Nov 2002 08:32:39 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id gATNWdC24940; Sat, 30 Nov 2002 08:32:39 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA24939 ; Sat, 30 Nov 2002 08:32:39 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA15708; Sat, 30 Nov 2002 08:32:39 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA02427; Sat, 30 Nov 2002 08:32:38 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp (localhost [127.0.0.1]) by tsb-sgw.toshiba.co.jp with ESMTP id IAA21948; Sat, 30 Nov 2002 08:32:38 +0900 (JST) Received: from localhost (KDDI01-236.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0H6D005672QB1I@tsbpo1.po.toshiba.co.jp>; Sat, 30 Nov 2002 08:32:37 +0900 (JST) Date: Fri, 29 Nov 2002 18:32:40 -0500 From: Yoshihiro Ohba Subject: Re: [AAA-WG]: Diameter Base Application ID values In-reply-to: To: john.loughney@nokia.com Cc: aboba@internaut.com, aaa-wg@merit.edu Message-id: <20021129233240.GB3421@catfish> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.4i X-Dispatcher: imput version 20000414(IM141) Lines: 29 References: Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Nov 28, 2002 at 03:07:21PM +0200, john.loughney@nokia.com wrote: > Hi all, > > Currently, we have the application IDs as follows in the Diameter base spec: > > NASREQ 1 [NASREQ] > Mobile-IP 4 [DIAMMIP] > Diameter Base Accounting 5 > Relay 0xffffffff > > Would anyone complain if they were modified to: > > Diameter Base Accounting 0 > NASREQ 1 [NASREQ] > Mobile-IP 2 [DIAMMIP] > Relay 0xffffffff I have one question. Which Application ID value should be included in Diameter headers for messages that are common to all applications but not ACR/ACA? For example, my implementation is using 0 for CER/CEA. > > thanks, > John Regards, Yoshihiro Ohba From owner-aaa-wg@merit.edu Sat Nov 30 00:25:03 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17450 for ; Sat, 30 Nov 2002 00:25:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D55539123C; Sat, 30 Nov 2002 00:27:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D0B79130C; Sat, 30 Nov 2002 00:27:34 -0500 (EST) 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 809FE9123C for ; Sat, 30 Nov 2002 00:27:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 67E3E5DDE4; Sat, 30 Nov 2002 00:27:33 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 7D0945DDAD for ; Sat, 30 Nov 2002 00:27:32 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAU5SY600209 for ; Sat, 30 Nov 2002 07:28:34 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 30 Nov 2002 07:27:31 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 30 Nov 2002 07:27:31 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 30 Nov 2002 07:27:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [AAA-WG]: Diameter Base Application ID values Date: Sat, 30 Nov 2002 07:27:29 +0200 Message-ID: Thread-Topic: [AAA-WG]: Diameter Base Application ID values Thread-Index: AcKX/85eB0n3xzOfTPuiumJH4c/YoAAMTX3w From: To: Cc: , X-OriginalArrivalTime: 30 Nov 2002 05:27:30.0806 (UTC) FILETIME=[2DBE4960:01C29831] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Yoshihiro, > On Thu, Nov 28, 2002 at 03:07:21PM +0200, > john.loughney@nokia.com wrote: > > Hi all, > > > > Currently, we have the application IDs as follows in the > Diameter base spec: > > > > NASREQ 1 [NASREQ] > > Mobile-IP 4 [DIAMMIP] > > Diameter Base Accounting 5 > > Relay 0xffffffff > > > > Would anyone complain if they were modified to: > > > > Diameter Base Accounting 0 > > NASREQ 1 [NASREQ] > > Mobile-IP 2 [DIAMMIP] > > Relay 0xffffffff > > I have one question. > > Which Application ID value should be included in Diameter headers > for messages that are common to all applications but not ACR/ACA? > For example, my implementation is using 0 for CER/CEA. Actually, I was thinking the same thing. So we would have: Common 0 NASREQ 1 [NASREQ] Mobile-IP 2 [DIAMMIP] Base Accounting 3 Relay 0xffffffff John