From exim@www1.ietf.org Tue Jul 1 09:07:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19612 for ; Tue, 1 Jul 2003 09:07:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61D74P04855 for aaa-archive@odin.ietf.org; Tue, 1 Jul 2003 09:07:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XKqd-0001GE-W6 for aaa-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 09:07:04 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19457 for ; Tue, 1 Jul 2003 09:07:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XKq9-0000sx-Is for aaa-web-archive@ietf.org; Tue, 01 Jul 2003 09:06:33 -0400 Date: Tue, 01 Jul 2003 09:06:33 -0400 Message-ID: <20030701130633.18162.2826.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: aaa-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, aaa-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for aaa-web-archive@ietf.org: List Password // URL ---- -------- aaa@ietf.org wumate https://www1.ietf.org/mailman/options/aaa/aaa-web-archive%40ietf.org From sip-admin@ietf.org Tue Jul 1 09:09:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19973 for ; Tue, 1 Jul 2003 09:09:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XKs8-0002F7-3A for aaa-archive@lists.ietf.org; Tue, 01 Jul 2003 09:08:36 -0400 Date: Tue, 01 Jul 2003 09:08:36 -0400 Message-ID: <20030701130836.18162.60544.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: aaa-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, aaa-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for aaa-archive@lists.ietf.org: List Password // URL ---- -------- aaa@ietf.org kaithu https://www1.ietf.org/mailman/options/aaa/aaa-archive%40lists.ietf.org From owner-aaa-wg@merit.edu Tue Jul 1 10:48:23 2003 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 KAA03243 for ; Tue, 1 Jul 2003 10:48:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C07539125D; Tue, 1 Jul 2003 10:48:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 26C9C9125E; Tue, 1 Jul 2003 10:48:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 996BF9125D for ; Tue, 1 Jul 2003 10:47:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7C9BD5DDC7; Tue, 1 Jul 2003 10:47:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id 2E4B55DD96 for ; Tue, 1 Jul 2003 10:47:46 -0400 (EDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h61El0s19181; Tue, 1 Jul 2003 09:47:01 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h61Ekwr01965; Tue, 1 Jul 2003 09:46:58 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HHCP26-0000XG-00; Tue, 01 Jul 2003 10:46:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16129.40668.946230.750994@gargle.gargle.HOWL> Date: Tue, 1 Jul 2003 09:46:52 -0500 From: Pete McCann To: Cc: , Subject: RE: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt In-Reply-To: References: X-Mailer: VM 7.14 under 21.5 (beta13) "cauliflower" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, John, I don't think it's too soon to start considering this sort of interaction, especially because, as Hannes has indicated, there may be some impact on the NSIS protocol itself. Also, our hope is that we can make use of an IETF-specified Diameter application for the appropriate interfaces in the next release of 3GPP and 3GPP2 specifications, which means the sooner we can get started the better. We certainly intend to continue the discussion with Hannes and others on both the NSIS and AAA lists, as appropriate - hopefully the bandwidth we use will be tolerated by those not directly interested in the topic. -Pete john.loughney@nokia.com writes: > Hi Pete, > > Question for you - NSIS will obviously need some AAA interaction, > not just for QoS, but for middle box traversal (note, new NSIS > charter has been announced). > > It might be interesting to discuss this work in both AAA & NSIS, > but my feeling is that the AAA WG already has a lot to do. Perhaps > you could work with Hannes to incorporate aspects of the drafts > together. > > thanks, > John > > > -----Original Message----- > > From: ext Pete McCann [mailto:mccap@lucent.com] > > Sent: 26 June, 2003 23:20 > > To: nsis@ietf.org; aaa-wg@merit.edu > > Subject: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt > > > > > > > > Hi, > > > > We hope everyone who is interested in QoS/AAA has a chance to read the > > draft we have just submitted. > > > > Our work is definitely related to the 2 drafts-tschofenig that have > > been posted on the NSIS group (apologies for not acknowledging this > > explicitly in the draft, but we found them only recently and are still > > reading them). However, our work focuses more on the requirements for > > a AAA protocol rather than requirements for NSIS. Also, we are trying > > to set forth in our draft what we think is the proper relationship > > between NSIS/RSVP, AAA, and call control protocols like SIP. > > > > Please read/comment! > > > > -Pete > > > > Internet-Drafts@ietf.org writes: > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > > > > Title : Requirements for a QoS AAA Protocol > > > Author(s) : F. Alfano et al. > > > Filename : draft-alfano-aaa-qosreq-00.txt > > > Pages : 16 > > > Date : 2003-6-24 > > > > > > This document describes requirements for a protocol that would > > > perform Authentication, Authorization, and Accounting for > > Quality-of- > > > Service reservations. This protocol would be used by > > elements along > > > the path of a given application flow to authenticate a reservation > > > request, ensure that the reservation is authorized, and to account > > > for resources used during the life of the application flow. A QoS > > > AAA protocol should also support dynamic authorization of QoS as a > > > function of application and account state. While we assume the > > > existence of some QoS reservation protocol to allow endpoints to > > > request QoS from network elements, complete requirements > > for such a > > > protocol are outside the scope of this document and a QoS AAA > > > protocol could be used to support more than one kind of > > reservation > > > protocol. A QoS AAA protocol could be used between any > > bearer-level > > > network element that lies along the path of an application > > flow and > > > an application server that lies anywhere in the network, > > allowing for > > > a wide variety of flexible service deployment models. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosreq-00.txt > > > > > > From owner-aaa-wg@merit.edu Wed Jul 2 04:49:41 2003 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 EAA28763 for ; Wed, 2 Jul 2003 04:49:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A761D91210; Wed, 2 Jul 2003 04:49:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 794D391212; Wed, 2 Jul 2003 04:49:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 50A3391210 for ; Wed, 2 Jul 2003 04:49:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 671905DDE8; Wed, 2 Jul 2003 04:49:21 -0400 (EDT) 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 58AA35DD8F for ; Wed, 2 Jul 2003 04:49:20 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h628nI929494 for ; Wed, 2 Jul 2003 11:49:19 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 2 Jul 2003 11:49:21 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 2 Jul 2003 11:49:18 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 2 Jul 2003 11:49:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt Date: Wed, 2 Jul 2003 11:49:11 +0300 Message-ID: Thread-Topic: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt Thread-Index: AcM/36bh3JKkzNRTS8G9TrLyruilmAAlvflw From: To: Cc: , X-OriginalArrivalTime: 02 Jul 2003 08:49:17.0437 (UTC) FILETIME=[D24212D0:01C34076] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pete, > I don't think it's too soon to start considering this sort of > interaction, especially because, as Hannes has indicated, there may be > some impact on the NSIS protocol itself. Also, our hope is that we > can make use of an IETF-specified Diameter application for the > appropriate interfaces in the next release of 3GPP and 3GPP2 > specifications, which means the sooner we can get started the better. >=20 > We certainly intend to continue the discussion with Hannes and others > on both the NSIS and AAA lists, as appropriate - hopefully the > bandwidth we use will be tolerated by those not directly interested in > the topic. I think if we breakdown the problem into near term and longer term, the Diameter based solution is a good approach for the near term & may help generate useful material for the longer-term impact on NSIS. I don't see a problem discussing this on NSIS. thanks, John From owner-aaa-wg@merit.edu Wed Jul 2 04:51:05 2003 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 EAA28830 for ; Wed, 2 Jul 2003 04:51:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3890C91212; Wed, 2 Jul 2003 04:50:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 005DE91239; Wed, 2 Jul 2003 04:50:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F260E91212 for ; Wed, 2 Jul 2003 04:50:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E06625DDB9; Wed, 2 Jul 2003 04:50:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by segue.merit.edu (Postfix) with ESMTP id E878E5DDA0 for ; Wed, 2 Jul 2003 04:50:52 -0400 (EDT) Received: from fokus.fraunhofer.de (ekina [193.175.135.180]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id h628opQ19786 for ; Wed, 2 Jul 2003 10:50:51 +0200 (MEST) Message-ID: <3F029CEB.4090600@fokus.fraunhofer.de> Date: Wed, 02 Jul 2003 10:50:51 +0200 From: John Williams Floroiu Organization: FHG FOKUS - CC MOBIS User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Appl. integration into AAA Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have a question regarding the integration of new applications into AAA. I presume that when integrating a new application into AAA (by providing an appropriate ASM to run on relevant AAA entities), the application's signaling must be carried on over newly defined Diameter commands. It is however not straightforward how one-way notifications and three-way exchanges could be assimilated into request/answer pattern that govern all current AAA commands. Comments are greatly appreciated. John. From owner-aaa-wg@merit.edu Wed Jul 2 10:13:32 2003 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 KAA22203 for ; Wed, 2 Jul 2003 10:13:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9831D9126B; Wed, 2 Jul 2003 10:13:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BF089126C; Wed, 2 Jul 2003 10:13:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6E1B99126B for ; Wed, 2 Jul 2003 10:13:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5C8EC5DDE7; Wed, 2 Jul 2003 10:13:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id D11D95DD8D for ; Wed, 2 Jul 2003 10:13:16 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h62DlVY27346 for ; Wed, 2 Jul 2003 06:47:32 -0700 Date: Wed, 2 Jul 2003 06:47:31 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Revised Agenda for IETF 57 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Authentication, Authorization and Accounting WG (AAA) Wednesday, July 16, 2003 1300-1500 Afternoon Sessions I ============================= CHAIRS: Bernard Aboba David Mitton AGENDA: Preliminaries (10 minutes) Bluesheets Minutes Agenda Bashing Document Status Diameter MIPv4 (15 minutes), Tom Hiller http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-14.txt Diameter NASREQ (15 minutes), David Mitton http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-12.txt Diameter EAP (15 minutes), Pasi Eronen http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-02.txt Diameter Credit Control Application (15 minutes), John Loughney http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-00.txt Diameter Multimedia Application (15 minutes), M. Garcia-Martin http://www.ietf.org/internet-drafts/draft-belinchon-aaa-diameter-mm-app-01.txt Roadmap (15 minutes) WG Chairs and ADs From owner-aaa-wg@merit.edu Wed Jul 2 16:18:35 2003 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 QAA11664 for ; Wed, 2 Jul 2003 16:18:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 183549127F; Wed, 2 Jul 2003 16:17:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CD6BB91272; Wed, 2 Jul 2003 16:17:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 419EE9127F for ; Wed, 2 Jul 2003 16:17:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 24E645DDB9; Wed, 2 Jul 2003 16:17:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id E50825DDAD for ; Wed, 2 Jul 2003 16:17:16 -0400 (EDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h62KGUs05653; Wed, 2 Jul 2003 15:16:30 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h62KGSJ05058; Wed, 2 Jul 2003 15:16:28 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HHEYZB-0000R8-00; Wed, 02 Jul 2003 16:16:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16131.15765.566662.52588@gargle.gargle.HOWL> Date: Wed, 2 Jul 2003 15:16:21 -0500 From: Pete McCann To: Tschofenig Hannes Cc: "'john.loughney@nokia.com'" , nsis@ietf.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BBFF52@mchp905a.mch.sbs.de> References: <2A8DB02E3018D411901B009027FD3A3F03BBFF52@mchp905a.mch.sbs.de> X-Mailer: VM 7.14 under 21.5 (beta13) "cauliflower" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tschofenig Hannes writes: > hi pete, > > as promised i have read your draft and provided some comments inline. please > take a look at: > > http://www.tschofenig.com/comments/draft-alfano-aaa-qosreq-00-hannes.txt > > it is good that you join the discussion. > > ciao > hannes Hi, Hannes, Thanks for your detailed comments - unfortunately it is more difficult for me to post files to the web on short notice, so I will try to respond to each of your points in this e-mail, deleting most of the draft text. See below... # please see my comments inline. # general comment: # # it is good that someone finally joins the aaa/qos discussion. i # always had the impression that there are a number of things that # need to be discussed. It's good to find your work in progress here in NSIS: hopefully we can work together to produce something useful. # Section 1 discusses a number of issues which are not applicable for # AAA and QoS reservations (my opinion). The Introduction tries to motivate the scope of the work; perhaps it wouldn't be appropriate for the final requirements document, at least not in its current form. (but see below) # For the purpose of authorization it is not relevant which protocols # (nsis, rsvp, etc.) carry the qos request to the network. Yes, I agree - section 1 is just an introduction, and is an attempt to motivate the work in the context of several different reservation protocols. Note that our draft is a set of requirements for a AAA protocol, not a set of requirements for NSIS. # it would be good to have the documents more generic, link layer and # 3gpp (or similar) independent. Understood; the 3G examples are given simply as motivation. In particular, we think that some of the current architectures for authorizing QoS may be harmful, as they may tend to limit the deployability of new services by linking the signaling plane to the bearer plane in a certain inflexible way. The body of the document should be generic. # the term bearer is not used in nsis. We use this to refer to anything that is on the path of the application flow or to the resources used to support the application flow. Can you suggest the proper NSIS term? I guess we are showing our bellhead colors here... there will be no need to manage them with a reservation protocol. Also, if the transport or application layers can provide self- correcting congestion control, it may be possible to operate the network even with high utilization and still meet the QoS requirements of the various applications. # this is a motiviation for not using qos at all. Yes, it's one scenario where you don't necessarily need to signal for resources, and is designed to set up a contrast with the remainder of the paragraph... However, when bandwidth is expensive and must be carefully managed, such as in wide-area cellular networks, and/or when applications and transport protocols lack the capability or cannot be trusted to perform congestion control, explicit reservation techniques are required. Note that a reservation protocol might be used regardless of the mechanisms used to enforce QoS, e.g., IntSrv or DiffSrv. ... Despite the advantages of closer coupling between application and bearer, the use of private, local interfaces between SIP servers and the bearer path leads to several disadvantages: * Use of SIP servers other than the ones provided by the operator becomes more difficult. * Deployment of some new applications requires close coordination with the network operator. * It becomes impossible to handle mobility at the network layer when a change in the bearer element point of attachment to the Internet requires a change in the associated SIP server. * Use of protocols other than SIP to establish sessions becomes impossible. # I would like to understand the motivation for the tight # coupling between an application and a QoS signaling protocol. See the previous paragraphs in the draft; however, what is not covered there explicitly is the desire on the part of operators to participate in more than just transport of IP packets. They do this by preventing bearer application flows until some SIP server in their network says it is OK. Now, that may or may not be a good idea, but it seems to be a reality of the current 3G architectures. We think that by opening up a QoS/AAA interface, and by doing this work in the IETF, we can at least make sure that the interface between application and bearer is an open, inter-domain one and allows for application servers to be placed anywhere on the Internet, assuming they can connect to the AAA cloud. That will allow for easy deployment of new applications, in keeping with the end-to-end principle. # - which application knowledge is sometimes needed Sometimes it is just the fact that some particular application server participated in the call set-up. # - the should be a clearer distinction between " the qos protocol # obtains information from the application signaling protocol" and "tight coupling". We can work on this for the next version. # - does this related a bit to john's draft draft-ietf-sipping-aaa-req-03.txt? Only indirectly. I think sipping-aaa is an attempt to capture the requirements of a AAA protocol that would support SIP. That is, you need to authenticate & authorize registrations, INVITEs, etc. In contrast, we are proposing a AAA protocol that would be used to authenticate QoS reservation requests. Now, the reservation requests may have been triggered after some SIP interaction took place, but that is just happenstance --- in general there is no need to execute SIP prior to a QoS reservation request. ... To meet the requirements of network operators while at the same time preserving the best of the end-to-end Internet service model, we propose that a AAA protocol be developed that can be used by bearer elements to authenticate, authorize, and account for individual application flows that require QoS. # there is already a aaa protocol used for this purpose => # # [RFC2748] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, # R., Sastry, A.: "The COPS(Common Open Policy Service) Protocol", RFC # 2748, January, 2000. # # [RFC2749] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, # R., Sastry, A.: "COPS usage for RSVP", RFC 2749, January, 2000. # # [RFC2750] Herzog, S.: "RSVP Extensions for Policy Control", RFC # 2750, January, 2000. # # is this insufficient for your purpose? COPS is one approach, but my personal bias would be to do this sort of thing with Diameter. Mainly, this is because the 3GPP2 operators will already have an inter-domain AAA infrastructure based on RADIUS (hopefully evolving to Diameter) and it would be good to re-use this infrastructure for QoS authorization as well as basic network access authentication. I don't mean to restart the COPS vs. Diameter thread here, but I think Diameter has some advantages over COPS. ... +------+ +------+ | Subs | | | | DB | | AS | | | | | +---\--+ +---/--+ \ / \ / /-\----------/\ //// \\\\ || || | AAA Cloud | || || \\\\ //// \-------+-----/ | +---+--+ Application | | Flow ===============+ BE +==========>> | | +------+ Figure 1. An architecture supporting QoS-AAA Figure 1 depicts a bearer element # why is it necessary to talk about bearer elements? These are the nodes that would process NSIS (or other reservation) messages, i.e., the IP routers along the path of the flow. # what is the subs db? This is short for "Subscriber Database" --- it would be (or be "behind") the home AAA server, and would store information about the subscription, i.e., what sorts of QoS the user is allowed. # what information is used to compute this authorization decision? If the subscriber database is used, it might just be a check of the requested QoS (and perhaps the link type and/or some other indication of cost) against what the user has signed up for. If an application server is used, it might be a check of the requested QoS against the e.g., SIP SDP that was negotiated. In more complex deployment models, the authorization will be based on dynamic application state, so the request must be authenticated and authorized based on information from one or more application servers. # what information would you like to use to compute this authorization decision? # how does the message flow look like? We could get into that in a protocol document; I'm not sure it belongs here in the requirements. At a high level, I think the bearer element would pick up the QoS request, and then send a AAA message to the authorizing entity containing various parameters of the request. The authorizing entity would then consult internal data structures and return a yea/nay response. Also, the authorizing entity could update the bearer element proactively if the subscriber profile changes or if the application state changes. If defined properly, the interface between the bearer element and AAA cloud would be identical in both cases. # the interface propably but the message routing seems to be more complex since # some information from the application server needs be incorporated? I'm not sure it has to be. Assuming there is an identifier for an "authorizing entity" and that entity has the ability to update the bearer element dynamically, we can really hide the details of what kind of authorizing entity is being used. However, I think it's important to talk about application servers explicitly in the requirements so that we know what role they will be playing in the overall architecture. ... Termination Actions On-line accounting allows for the on-line accounting authorization entity to terminate flows in real time. A termination action defines the action to be taken by the bearer element for the case where a flow has been terminated. For example flow packets might be dropped, might be redirected, or might be allowed to continue but not be counted. # the term "On-line accounting" is new to me? is it something similar to real-time credit control? Yes, also called "pre-paid." We should be more explicit about that. ... 4.1 Identity Information The QoS signaling protocol MUST carry information sufficient to identify an authorizing entity for a QoS request. For instance, the identity may be represented as the NAI of a user or FQDN of an application server. # this requirement is already included in the nsis requirements draft. in section # 5.7.1 "Authentication of signaling requests" we require that the entity requesting resources # has to be authenticated. Ok, good. Again, our document is intended to be a requirement for a AAA protocol rather than NSIS, but we thought it was important to list at least the basic attributes that must be supported by a reservation protocol. This sort of requirement may or may not go into a final requirements document, depending on what the WG thinks. 4.2 Flow Information The QoS signaling protocol MUST carry information sufficient to identify the application flow(s). # this is a natural requirement for qos signaling and therefore covered by the nsis requirements draft. Ok, good, but see above. However, the protocol MUST allow flow information to be under-specified ("wild carded") in the case when specific endpoints are not known at the time of resource reservation. # this is a new requirement. why would you like to specify wildcards? # wildcards for what (ports, ip addresses, transport protocol; source or destination ? # that might raise a number of questions! This is just an attempt to capture e.g., the wildcard sender selection supported by RSVP. Depending on the signaling protocol, the endpoint may or may not have complete information about the sender IP address/port, and may only have a range of destination ports... anyway, we are open to re-wording this. 4.3 Authentication Information # the subsection title does not match the content Could you be more specific? Do you not think that checking the integrity of a message is a form of authentication? The QoS signaling protocol MUST be integrity protected. # covered by requirement 5.7.3 Integrity protection See above with respect to requirements on a generic reservation protocol in this document. For example, each message could carry a cryptographic message authentication code to ensure that only valid requests are granted by the network. This is especially important when a user is being held responsible for charges associated with a QoS session. # how would you enable that? "held responsible for charges" sounds like non-repudidation I'm not sure we need a strong form of non-repudiation (really, that would require MACs on every packet in the flow!) but at least we should have an initial/periodic authenticated request. ... 5.1 Inter-domain Support The QoS AAA protocol MUST support inter-domain operation where the bearer elements, subscriber databases, and application servers can each belong to different administrative domains. # covered by the fact that mobility is a goal for nsis. # additionally we specified "5.9.4 SHOULD provide hooks for AAA protocols " This one is important for the AAA protocol, and not necessarily covered by the 2 NSIS requirements you quote. It is possible to have a mobile-aware NSIS that provides hooks for AAA, but where the supporting AAA infrastructure does not support inter-domain operation. This is a critical point that we want to ensure is addressed by the AAA protocol. ... 5.2 Identity-based Routing The QoS AAA protocol MUST route AAA requests to the authorizing entity based on the identity information given in the QoS signaling protocol. # this is the general procedure. Clearly, this requirement could easily be met by a Diameter or RADIUS protocol, but I don't think its a "general procedure" of NSIS, right? ... 6.1 Authentication Check The QoS AAA protocol MUST support verification of authentication information present in QoS signaling messages. # should this requirement be combined with 4.1 and 4.3 of the previous section? Again, this section covers the AAA protocol, whereas Section 4 covers the QoS reservation protocol. ... 7.1 Flow Information The QoS AAA protocol MUST carry flow information to and from the authorizing entity. # is this a typo? how should the authorizing entity know information about the flow? # what whould the authorizing entity do with the flow information? # between which entity is the flow information carried? The idea is to carry the flow information from the bearer element (e.g., NSIS signaling-aware node) to the authorizing entity, so that it can be matched against the application-layer signaling that was carried out. For example, if SIP is the upper layer signaling, and the authorizing entity is a SIP server, you would check that the SDP matched the flow requested in the NSIS signaling. ... However, the protocol MUST allow flow information to be under-specified ("wild carded") in the case when specific endpoints are not known at the time of initial resource authorization. # hmm. i am not sure that i really understand what you really need this for. See discussion above in section 4. Maybe we need to re-state these requirments. 7.2 Application State Pointer The QoS AAA protocol MUST carry information sufficient for an application server to identify the appropriate application session. Note that this requirement might be met by the same mechanism as for requirement 7.1, if flow information alone is sufficient to identify an application session. # nsis adds a session identifier? would that be useful? An NSIS session identifier wouldn't necessarily help the authorizing entity find the session information - it would be more like a token that would appear separately in the NSIS signaling, and which would be carried via AAA to the authorizing entity. 7.3 Dynamic Authorization The QoS AAA protocol MUST support dynamic authorization; that is, it MUST be possible to push updates towards the bearer element(s) from authorizing entities. # what do you call "dynamic authorization"? # is a authorization request which is given an answer? The authorization state may change even after the initial (successful) authorization. For instance, if the user's subscription is updated to remove QoS service, we may need to revoke an existing session. Similarly, if the application state changes, the corresponding QoS session may need to be revoked. This requirement would support runtime changes to a subscriber profile or application state transitions that would authorize/de- authorize application flows. # this sounds like assynchronous notifications from the user's home # network (in case of profile changes) to the networks where the user reserved # resources. Yes, exactly. # what information is contained in the profile that would require such a notification? For example, an upgrade/downgrade to a subscriber's allowed bandwidth. ... The QoS AAA protocol MUST allow the authorizing entity to gate authorized application flows. # this sounds to me like an interworking with midcom. # i would like to make sure that i correctly understood this issue: # an unsuccessful qos authorization would cause packet filters to be installed that # data traffic is disallowed to flow? At least, the packet filters would *not* be installed to support QoS for that flow. Perhaps also the (best effort) packets would be discarded, but this is harder to justify. ... 8.1 Accounting Records The QoS AAA protocol MUST define QoS accounting records containing duration or volume (bytecount) usage information, or both duration and Volume usage information. The records MUST also contain a description of the QoS attributes (e.g., bandwidth, delay, loss rate) that were supported for the flow. # this sounds like a useful requriement. haven't other groups (such as the 3gpp, packetcable or 3gpp) # worked on similar things? Yes, there are various accounting formats defined; hopefully the IETF could define the generic "IP-layer" accounting for QoS that would be useful to a wide variety of specific link layers. 8.2 Accounting Rules The QoS AAA protocol MUST allow the authorizing entity to transfer accounting rules that are applicable to specific flows. These rules would define the on-line ("pre-paid") versus off-line ("post-paid") nature of the accounting as well as convey other associated parameters such as record identifiers, rating information, usage quota, on-line termination actions, etc. # why would the authorizing entity exchange such rules? most information is # already available to the pep (such as flow identifier, qos objects, session id, etc.) The rules are not what to do with the traffic; rather, they are how to count the traffic. For example, you should be told whether to count different senders in distinct buckets, or count everything for a single reservation together. If pre-paid is used, you should be told how much quota is available and in what units it is represented. These all fall under the generic term "Accounting Rules". Perhaps we need to expand on these. # why does accounting of qos differ so much from traditional accounting (except for some new # fields describing the qos parameters)? Maybe it wouldn't, but at least pre-paid might have some impact over and above "traditional" accounting (not sure which tradition you are making reference to, of course). The QoS AAA protocol MUST allow for accounting rules to be provided at authorization time as well as to be pushed later as dynamic updates. # which protocol provides such a capability (radius, diameter, cops)? Again, our bias is towards Diameter, but you can clearly do this sort of thing in both RADIUS and COPS with the right extensions/modifications. 8.3 Sending Accounting Records The bearer element MUST send accounting records for a particular application flow to the authorizing entity for that flow or to another entity identified by the authorizing entity. # previously i had the impression that you would like to send an initial authorization request around. # this requirement, however, sounds like shipping accounting records around and asking for an authorization # based on these accounting record. It wasn't intended that way: this requirement simply requires accounting records to be sent. The destination for the accounting records depends on who authorized the session. 8.4 Loss of Bearer Notification Requirements The QoS AAA protocol MUST allow the bearer element to report loss of bearer to the authorizing entity. # isn't it possible to specify this requirement as a "termination" reason. Yes, that might be a more generic way to put it. # i guess a loss of bearer is more relevant for network access in general. # how do you detect a loss of bearer in general. some link layer mechanisms do not provide # such a mechanism. Right, but this is a key requirement of some of the 3G deployments. Cellular link layers, especially when a voice call is ongoing, are very connection-oriented and a loss of bearer indication is in fact available. 8.5 Accounting Correlation The QoS AAA protocol MUST support the exchange of sufficient information to allow for correlation between bearer accounting records and application accounting records. # what type of information must be exchanged? Might just be the session ID / token I mentioned above. ... 9. Interaction with other AAA Applications It is likely that an endpoint attached to a first-hop bearer element was authenticated and authorized for basic, best-effort Internet access prior to requesting any special QoS from the network. If the subscriber database for basic network access is the same as the one containing a QoS subscription, it may be expeditious to define some interactions between the AAA protocol used for basic access (e.g., NASREQ [10]) and the one outlined here for QoS. For example, it may be useful to return some QoS-related attributes to the first-hop bearer element at the time the endpoint is granted basic, best-effort access. # This is an often mentioned example. I am, however, not sure whether it is # really useful. What it really make sense to send information like # 'user x is allowed to request max 5mbits for a duration of 10 min, then only # 3 mbits (but only during weekdays)' # what type of policies would you send around? The example you give actually sounds very similar to the pre-paid accounting application being developed by 3GPP2! There is a notion of a "Tariff Switch" event that would happen at a given time-of-day, and this time is given to the NAS when the user is authorized. When the tariff switch occurs, the rating for the call might change (i.e., 10c/minute before 7pm, 5c/minute after). Anyway, it doesn't always have to be that complicated. There might be a simple profile like "this user is authorized for 2Mbit/sec when connecting via WLAN, or 100kbit/sec when connecting via cdma2000". # i often have the impression that this sounds great but has no # practical value. i have also listed it in the aaa draft but later # got the impression that this is the difficult to accomplish. I wouldn't dismiss it so quickly. # what information is stored in the user profile that could be used # for this purpose? is is desired by the user's home network provide # to distribute this type of information? this also assumes that the # user profile is sort-of standardized. this is, however, not the # case. Home operators definitely will want to distribute such information. We can help with the standardization here in the IETF. ... Also, it may be useful to allow application servers to push QoS authorization information to a bearer element prior to any explicit request from the endpoint. This could support application endpoints that do not support an explicit QoS signaling mechanism. In this case, the authorization may be pushed via the home AAA server, which presumably knows to which NAS the endpoint is currently attached. Alternatively, the QoS AAA protocol may define some sort of redirection facility that would allow application servers to send AAA messages directly to selected bearer elements such as a NAS. # huch - that is certainly not easy to accomplish. there are a number # of assumptions in there we need to be clarified. Yes indeed - but I think it's clear that the Home AAA server that authorizes basic IP access will have some information that could be made available to other applications, especially if they are Diameter applications running on the same server. ... The application endpoint makes a request for resources from the bearer element. The video server and the bearer element will verify that the application endpoint has not requested more resources than what were negotiated and for which the application has agreed to be financially responsible. # this bearer element is somewhat confusing. whatis the relationship between # the video server, application end point and bearer element? # what is the trust relationship between these entities? Sorry, terminology problem again. Think of the bearer element as any NSIS-aware IP router. It has the same degree of trust as any IP router between server and application endpoint. In addition, it may have a special relationship with the server (possibly via AAA brokers) so that the server is allowed to authorize QoS sessions, even if the subscriber's profile on its own wouldn't normally allow it. ... 11. Security Considerations The QoS AAA protocol whose requirements are given in this draft assumes that a security relationship exists between the authorizing entity (the home AAA server or application server) and the bearer element (AAA client). # this is a rather strong assumption. that might not be true in all cases. It seems like precisely the relationship that is required: think about it. The bearer element is making a decision about whether to admit a flow. It consults an authorizing entity. In order to trust the result from the authorizing entity, there must be a (possibly indirect) security relationship in place. This relationship implies that the bearer element should grant service based on the say-so of the authorizing entity, presumably because the used resources will be paid for in some later settlement phase. # payment is provided later only? # what about pre-paid cards which require real-time credit control. Yes, we should re-word it to allow that. The relationship may be direct or it may be indirect via a AAA cloud consisting of brokers and proxies. Each link in this chain of relationships MUST be secured to prevent spoofed authorizations. # securing the aaa interaction does not prevent spoofing since the end point is authenticated. # is entity authentication between the user and the home network required with every qos reservation request? # (or is data origin authentication sufficient?) The security referenced here is between bearer element and authorizing entity, possibly via AAA proxies. To answer your question, yes, I think that if any AAA interaction is done at a given NSIS node, then every QoS reservation should be independently authenticated. The authentication outlined in Section 6 MUST be cryptographically strong and protected against replay and other attacks. Once QoS resources have been authorized, it may be possible for an unauthorized party to subvert them for its own use. Steps MUST be taken to bind the authorization to the actual flow of packets using the QoS bearer in the bearer element. # this can actually only be prevented if the data traffic is cryptographically protected (either link layer or network layer # protection). do you mandate this? No, I would not. But we can at least make sure that the packets using the QoS actually match the transport endpoints authorized by an application. Actual mechanisms applied to the bearer traffic for this purpose might include, e.g., ingress filtering and/or IPSec, but in general are beyond the scope of a QoS AAA protocol. # ingress filtering does not prevent all attacks. No, but it would make the QoS reservation useless unless the spoofed traffic was carrying the same source IP address/port. -Pete From owner-aaa-wg@merit.edu Thu Jul 3 06:19:15 2003 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 GAA05072 for ; Thu, 3 Jul 2003 06:19:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 27FD191203; Thu, 3 Jul 2003 06:19:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE0599120A; Thu, 3 Jul 2003 06:19:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8675891203 for ; Thu, 3 Jul 2003 06:19:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 729615DDF2; Thu, 3 Jul 2003 06:19:01 -0400 (EDT) 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 7CE015DDD1 for ; Thu, 3 Jul 2003 06:19:00 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h63AIwa05515 for ; Thu, 3 Jul 2003 13:18:58 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 3 Jul 2003 13:18:57 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Jul 2003 13:18:57 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Jul 2003 13:18:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: draft-ietf-aaa-eap-02.txt Date: Thu, 3 Jul 2003 13:18:56 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BB5C@esebe023.ntc.nokia.com> Thread-Topic: draft-ietf-aaa-eap-02.txt Thread-Index: AcNBTIL7Iy16K0UnRDSMnS26prd25w== From: To: X-OriginalArrivalTime: 03 Jul 2003 10:18:57.0515 (UTC) FILETIME=[837293B0:01C3414C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi everyone, A new version of the Diameter EAP application draft is now=20 available. It has substantial changes to -01, most of which=20 have not really received much WG discussion (and thus will be probably revised in the future). I would encourage=20 everyone interested to take a look and provide feedback. Major changes include: o Added lots of small protocol details: - Invalid packets (Sections 2.4 and 4.1.2): The particular AVP(s) are not yet fixed; better suggestions are welcome, especially if they don't require inter-request state from =20 RADIUS translation agents. - Retransmission timeouts (Section 2.5) - Fragmentation (Section 2.6 and 4.1.3) - Accounting AVPs (Section 2.7 and 4.1.5) o Added some usage guidelines (Section 2.8) - User-Name AVP=20 - Conflicting AVPs - Displayable messages - Role reversal o Added a section on how to avoid Diameter proxies (2.3).=20 Especially "scenario 3" is new and needs more discussion=20 to see if it would actually work as intended. o Added EAP-Master-Session-Key AVP. o Added a first attempt of RADIUS translation section (Section 6). o Added a security considerations section (Section 7). This is mostly written from scratch, and seems to contain=20 lots of material that actually should be somewhere else. (HTML diffs and changebar versions are also available from http://www.cs.hut.fi/~peronen/eap/diameter_eap.html) I'm in Vienna Saturday..Tuesday, so I won't make it to the=20 AAA WG meeting (if you'd like to meet and discuss this draft before that, drop me a note!). Best regards, Pasi ------------------------------------------------------- From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-aaa-eap-02.txt Date: Wed, 02 Jul 2003 16:14:48 -0400 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. This draft is a work item of the Authentication,=20 Authorization and Accounting Working Group of the IETF. Title : Diameter Extensible Authentication Protocol (EAP)=20 Application Author(s) : P. Eronen, T. Hiller, G. Zorn Filename : draft-ietf-aaa-eap-02.txt Pages : 40 Date : 2003-7-2 =09 The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary to carry EAP packets between a Network Access Server (NAS) and a back-end authentication server A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-02.txt .... From mailman-admin@ietf.org Thu Jul 3 18:51:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17266 for ; Thu, 3 Jul 2003 18:49:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YCe3-0005YM-2z for aaa-archive@lists.ietf.org; Thu, 03 Jul 2003 18:33:39 -0400 Date: Thu, 03 Jul 2003 18:33:39 -0400 Message-ID: <20030703223339.4508.55075.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: aaa-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk There was an error in the last monthly reminder, in that the NOTE WELL statement (below) was not included. Therefore, the reminder is being sent out again. This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, aaa-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for aaa-archive@lists.ietf.org: List Password // URL ---- -------- aaa@ietf.org kaithu https://www1.ietf.org/mailman/options/aaa/aaa-archive%40lists.ietf.org From exim@www1.ietf.org Thu Jul 3 19:46:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26958 for ; Thu, 3 Jul 2003 19:46:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDmS-0002bT-St for aaa-archive@odin.ietf.org; Thu, 03 Jul 2003 19:46:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63NkOgF009993 for aaa-archive@odin.ietf.org; Thu, 3 Jul 2003 19:46:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDkN-0002Bz-Cl for aaa-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 19:44:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25743 for ; Thu, 3 Jul 2003 19:28:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YD1q-00001i-00 for aaa-web-archive@ietf.org; Thu, 03 Jul 2003 18:58:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YCsA-0006wV-00 for aaa-web-archive@ietf.org; Thu, 03 Jul 2003 18:48:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YCdX-0004fS-P9 for aaa-web-archive@ietf.org; Thu, 03 Jul 2003 18:33:07 -0400 Date: Thu, 03 Jul 2003 18:33:07 -0400 Message-ID: <20030703223307.4508.37466.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: aaa-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk There was an error in the last monthly reminder, in that the NOTE WELL statement (below) was not included. Therefore, the reminder is being sent out again. This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, aaa-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for aaa-web-archive@ietf.org: List Password // URL ---- -------- aaa@ietf.org wumate https://www1.ietf.org/mailman/options/aaa/aaa-web-archive%40ietf.org From owner-aaa-wg@merit.edu Tue Jul 8 18:31:21 2003 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 SAA14119 for ; Tue, 8 Jul 2003 18:31:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BB68291240; Tue, 8 Jul 2003 18:30:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 871B69124B; Tue, 8 Jul 2003 18:30:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2FD5D91240 for ; Tue, 8 Jul 2003 18:30:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1C5AF5DD96; Tue, 8 Jul 2003 18:30:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id C3D715DD8E for ; Tue, 8 Jul 2003 18:30:27 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h68MUNP17800; Tue, 8 Jul 2003 17:30:23 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jul 2003 17:30:24 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746A4D@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'miguel.a.garcia@ericsson.com'" , "'maria.c.belinchon@ericsson.com'" Cc: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt Date: Tue, 8 Jul 2003 17:30:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C345A0.80DEEFA6" 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_01C345A0.80DEEFA6 Content-Type: text/plain Hello Miguel, I have the following comments on draft-belinchon-aaa-diameter-mm-app-01.txt. Global: - Since the description in this draft is specific to SIP, I like to suggest new title for this draft as "Diameter for SIP Based Multimedia Application". - Another suggestion is to include new "User De-registration" scenario as section 3.6 so that usages of commands RTR and RTA become more clear. Section:2 (Second paragraph) - Reword the paragraph "However, this document...between SIP and Diameter". Something is missing from this paragraph. Section 3 (Second paragraph) - The draft says that Figure 1 provides general overview of the integration of the SIP architecture with the AAA architecture but the next paragraph says that it is related to specific SIP server configuration. If UAR/UAA and LIR/LIA are applicable to just edge routers, it should be reflected in this model clearly. Section 3.1 and 3.2 (general) - I don't see much difference between the scenarios discussed in section 3.1-"Diameter server authenticate the user" and section 3.2 -"SIP server authenticate the user". There are just couple of steps (13 and 14) which are different from the description of these sections. Since these scenarios are discussed in different context, it's better to show which commands are used for what purpose and consolidate the description. Section 5.1 - In Open Issue Note, you have mentioned User-Name AVP being the mandatory parameter. I would think that UAR may be used for other SIP Requests as well (other than REGISTER). In those cases, do we have private id available also? Additionally, I would think that it will be better to mention what value will be assign to SIP-Public-User-Identity parameter in case of non-3GPP usage. - This section says that the Diameter server must include either the address of the SIP server or the capability needed by the SIP server. Does it mean that requesting SIP server always have capability to derive next hope based on the capabilities received from the AAA? Why do we have this additional requirement. Regards, Jayshree ------_=_NextPart_001_01C345A0.80DEEFA6 Content-Type: text/html Comments: draft-belinchon-aaa-diameter-mm-app-01.txt

Hello Miguel,

I have the following comments on draft-belinchon-aaa-diameter-mm-app-01.txt.

Global:
- Since the description in this draft is specific to SIP, I like to suggest new title
  for this draft as "Diameter for SIP Based Multimedia Application".
- Another  suggestion is to include new "User De-registration" scenario as section
  3.6 so that usages of commands RTR and RTA become more clear.
Section:2 (Second paragraph)
- Reword the paragraph "However, this document...between SIP and Diameter".
  Something is missing from this paragraph.
Section 3 (Second paragraph)
- The draft says that Figure 1 provides general overview of the integration of
  the SIP architecture with the AAA architecture but the next paragraph says
  that it is related to specific SIP server configuration. If UAR/UAA and
  LIR/LIA are applicable to just edge routers, it should be reflected in this
  model clearly.
Section 3.1 and 3.2 (general)
- I don't see much difference between the scenarios discussed in section
  3.1-"Diameter server authenticate the user" and section 3.2 -"SIP server
  authenticate the user". There are just couple of steps (13 and 14) which are 
  different from the description of these sections. Since these scenarios
  are discussed in different context, it's better to show which commands are
  used for what purpose and consolidate the description.
Section 5.1
- In Open Issue Note, you have mentioned User-Name AVP being the mandatory
  parameter. I would think that UAR may be used for other SIP Requests as well
  (other than REGISTER). In those cases, do we have private id available also?
  Additionally,  I would think that it will be better to mention what value will
  be assign to SIP-Public-User-Identity parameter in case of non-3GPP usage.
- This section says that the Diameter server must include either the address of
  the SIP server  or the capability needed by the SIP server. Does it mean that
  requesting SIP server always have capability to derive next hope based on the
  capabilities received from the AAA? Why do we have this additional
  requirement.

Regards,
Jayshree

------_=_NextPart_001_01C345A0.80DEEFA6-- From owner-aaa-wg@merit.edu Wed Jul 9 03:03:34 2003 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 DAA20818 for ; Wed, 9 Jul 2003 03:03:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1687B9122F; Wed, 9 Jul 2003 03:03:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C395191231; Wed, 9 Jul 2003 03:03:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E9C629122F for ; Wed, 9 Jul 2003 03:03:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CCF0F5DD98; Wed, 9 Jul 2003 03:03:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 40F775DD95 for ; Wed, 9 Jul 2003 03:03:14 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6973AIi027179; Wed, 9 Jul 2003 09:03:10 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NW4VVLPM; Wed, 9 Jul 2003 09:03:10 +0200 Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.31.68]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h6973ASZ028777; Wed, 9 Jul 2003 10:03:10 +0300 (EET DST) Message-ID: <3F0BBE2D.2010406@ericsson.com> Date: Wed, 09 Jul 2003 10:03:09 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" Organization: Ericsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: es,en MIME-Version: 1.0 To: Jayshree Bharatia Cc: "'maria.c.belinchon@ericsson.com'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Re: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt References: <870397D7C140C84DB081B88396458DAF746A4D@zrc2c000.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jayshree: Thanks a lot for your comments. See answers inline. Jayshree Bharatia wrote: > Hello Miguel, > > I have the following comments on > draft-belinchon-aaa-diameter-mm-app-01.txt. > > Global: > - Since the description in this draft is specific to SIP, I like to > suggest new title > for this draft as "Diameter for SIP Based Multimedia Application". The thing is that the RFC editor does not allow to have acronyms in the title (other than well known protocols such us IP, TCP, UDP). So your suggestion will become: "Diameter for Session Initiated Protocol (SIP) Based Multimedia Application" And I think when a reader gets the sentence will be lost to find out whether this is a Diameter application, a SIP extension or something else. I would rather keep the current title, unless I hear another proposal that is easy to read. > - Another suggestion is to include new "User De-registration" scenario > as section > 3.6 so that usages of commands RTR and RTA become more clear. Yes, I agree. Actually, section 3.5 deals with registration termination. I believe this section should contain a couple of flows showing examples of RTR/RTA. > Section:2 (Second paragraph) > - Reword the paragraph "However, this document...between SIP and Diameter". > Something is missing from this paragraph. Certainly. What is missing is a "mandate" word, so the text should read: "... nor this document mandates any particular sequence of events between SIP and Diameter." > Section 3 (Second paragraph) > - The draft says that Figure 1 provides general overview of the > integration of > the SIP architecture with the AAA architecture but the next paragraph > says > that it is related to specific SIP server configuration. If UAR/UAA and > LIR/LIA are applicable to just edge routers, it should be reflected in > this > model clearly. UAR/UAA and LIR/LIA are not only applicable to SIP edge proxies. They are "typically" used by SIP edge proxies, by we don't mandate to be supported exclusively in SIP edge proxies. Actually, the application provide means (commands, AVPs) to differentiate SIP edge proxies from non SIP edge proxies. However, both edge and non edge proxies will need to support the complete set of commands and AVPs, since there is only one Diameter application. So that is the reason why the figure discusses two different SIP proxies that, due to their role, use only a subset of the commands. But you could configure the SIP proxy to change role. So all commands have to be supported in all proxies. > Section 3.1 and 3.2 (general) > - I don't see much difference between the scenarios discussed in section > 3.1-"Diameter server authenticate the user" and section 3.2 -"SIP server > authenticate the user". There are just couple of steps (13 and 14) > which are > different from the description of these sections. Since these scenarios > are discussed in different context, it's better to show which commands > are > used for what purpose and consolidate the description. I think it is important to highlight the difference between these two scenarios. 3.1 is more aligned with the AAA architecture, where a Diameter server is authenticating users. This is the main role of the AAA server. Section 3.2 describes a scenario that is used in 3GPP, where the Diameter server delegates authentication to the SIP server. I believe both scenarios have different values in different networks. From the point of view of the application, we just want to provide the means to use either of the scenarios. 3GPP has chosen to go for scenario 3.2, but other networks will most likely use scenario 3.1. Please, let me know exactly what is missing. I am able to add any clarification to the text. > Section 5.1 > - In Open Issue Note, you have mentioned User-Name AVP being the mandatory > parameter. I would think that UAR may be used for other SIP Requests > as well > (other than REGISTER). In those cases, do we have private id available > also? I agree with you. I am sure that the username AVP will not be available in general, in all requests. It might be get acquiered, but that requires the SIP proxy to challenge the user. So this open issue is just an action point to make the AVP optional and discuss what are the procedures in the Diameter server when the AVP is not present in the UAR. > Additionally, I would think that it will be better to mention what > value will > be assign to SIP-Public-User-Identity parameter in case of non-3GPP > usage. This is not dependent on 3GPP or not-3GPP. The SIP-Public-User-Identity is what in normal SIP is called an Address Of Record (AOR). In an INVITE request, the SIP AOR comes in the Request-URI. In a REGISTER request it comes in the To field. The 4th paragraph in section 5.1 should answer your concern: The SIP or SIPS URI to be registered is conveyed in the SIP-Public-User-Identity AVP (Section 7.8). Typically this SIP or SIPS URI is found in the To header field value of the SIP REGISTER request that triggered the Diameter UAR message. And that makes me think that the SIP-Public-User-Identity should be renamed to SIP-AOR (Address of Record) to align the terminology with SIP... > - This section says that the Diameter server must include either the > address of > the SIP server or the capability needed by the SIP server. Does it > mean that > requesting SIP server always have capability to derive next hope based > on the > capabilities received from the AAA? Why do we have this additional > requirement. > Here I am lost. Are you still discussing section 5.1??? Which paragraph are you referring to??? I don't find the text you mention. Thanks a lot for reviewing the text. Please, keep on posting additional comments. Regards, Miguel > Regards, > Jayshree > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 From owner-aaa-wg@merit.edu Wed Jul 9 06:08:14 2003 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 GAA26099 for ; Wed, 9 Jul 2003 06:08:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 55DEB91243; Wed, 9 Jul 2003 06:08:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25A4991247; Wed, 9 Jul 2003 06:08:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DADD891243 for ; Wed, 9 Jul 2003 06:08:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C3C0A5DD8E; Wed, 9 Jul 2003 06:08:00 -0400 (EDT) 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 B24C75DD8D for ; Wed, 9 Jul 2003 06:07:59 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h69A7wa08967 for ; Wed, 9 Jul 2003 13:07:58 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 9 Jul 2003 13:07:51 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Jul 2003 13:07:49 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Jul 2003 13:07:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Re: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt Date: Wed, 9 Jul 2003 13:07:12 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222BF@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Re: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt Thread-Index: AcNF6D3QoO855wYITfix3eP+zkXVlQAGNeug From: To: X-OriginalArrivalTime: 09 Jul 2003 10:07:45.0143 (UTC) FILETIME=[F1294070:01C34601] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Miguel A. Garcia wrote: > Jayshree Bharatia wrote: > > Hello Miguel, > >=20 > > I have the following comments on=20 > > draft-belinchon-aaa-diameter-mm-app-01.txt. > >=20 > > Global: > > - Since the description in this draft is specific to SIP, I like to=20 > > suggest new title > > for this draft as "Diameter for SIP Based Multimedia Application". >=20 > The thing is that the RFC editor does not allow to have acronyms in = the=20 > title (other than well known protocols such us IP, TCP, UDP). So your=20 > suggestion will become: >=20 > "Diameter for Session Initiated Protocol (SIP) Based=20 > Multimedia Application" >=20 > And I think when a reader gets the sentence will be lost to find out=20 > whether this is a Diameter application, a SIP extension or=20 > something else. >=20 > I would rather keep the current title, unless I hear another=20 > proposal that is easy to read. I sort of like Jayshree's idea of including "SIP" somewhere in the title. A couple of alternatives that might be more readable? "Diameter SIP (Session Initiation Protocol) Application" (SIP can set up sessions that are not strictly speaking multimedia; and anyway the Diameter messages aren't multimedia :-) "Diameter Multimedia Application for SIP (Session Initiation Protocol)" Best regards, Pasi From owner-aaa-wg@merit.edu Wed Jul 9 06:22:50 2003 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 GAA26446 for ; Wed, 9 Jul 2003 06:22:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7796891247; Wed, 9 Jul 2003 06:22:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 475B79124B; Wed, 9 Jul 2003 06:22:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5189B91247 for ; Wed, 9 Jul 2003 06:22:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3DBD35DDB0; Wed, 9 Jul 2003 06:22:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id C7C195DDA7 for ; Wed, 9 Jul 2003 06:22:35 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 33CDF6A906; Wed, 9 Jul 2003 13:22:33 +0300 (EEST) Message-ID: <3F0BEC54.70505@kolumbus.fi> Date: Wed, 09 Jul 2003 13:20:04 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt References: <052E0C61B69C3741AFA5FE88ACC775A61222BF@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61222BF@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > "Diameter SIP (Session Initiation Protocol) Application" I like this. --Jari From owner-aaa-wg@merit.edu Wed Jul 9 06:31:24 2003 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 GAA26690 for ; Wed, 9 Jul 2003 06:31:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B6B799124B; Wed, 9 Jul 2003 06:30:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 43F339124D; Wed, 9 Jul 2003 06:30:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B22C49124B for ; Wed, 9 Jul 2003 06:30:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9D56E5DD9E; Wed, 9 Jul 2003 06:30:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 1C2875DD92 for ; Wed, 9 Jul 2003 06:30:49 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h69AUlIi027109; Wed, 9 Jul 2003 12:30:48 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NW4VW73W; Wed, 9 Jul 2003 12:30:47 +0200 Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.31.68]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h69AUlSZ010631; Wed, 9 Jul 2003 13:30:47 +0300 (EET DST) Message-ID: <3F0BEED6.3020103@ericsson.com> Date: Wed, 09 Jul 2003 13:30:46 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" Organization: Ericsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: es,en MIME-Version: 1.0 To: Jari Arkko Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt References: <052E0C61B69C3741AFA5FE88ACC775A61222BF@esebe023.ntc.nokia.com> <3F0BEC54.70505@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit This one sounds good to me as well. /Miguel Jari Arkko wrote: > Pasi.Eronen@nokia.com wrote: > >> "Diameter SIP (Session Initiation Protocol) Application" > > > I like this. > > --Jari > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 From owner-aaa-wg@merit.edu Wed Jul 9 07:29:39 2003 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 HAA27878 for ; Wed, 9 Jul 2003 07:29:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BB2539124C; Wed, 9 Jul 2003 07:29:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8CE299124D; Wed, 9 Jul 2003 07:29:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5E4709124C for ; Wed, 9 Jul 2003 07:29:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 49F865DD98; Wed, 9 Jul 2003 07:29:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from znsgs01r.nortelnetworks.com (h33s128a211n47.user.nortelnetworks.com [47.211.128.33]) by segue.merit.edu (Postfix) with ESMTP id 8759C5DD95 for ; Wed, 9 Jul 2003 07:29:23 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h69BTKF07849; Wed, 9 Jul 2003 12:29:20 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jul 2003 12:29:20 +0100 Message-ID: From: "Daniel Warren" To: "'Miguel A. Garcia'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Re: Comments: draft-belinchon-aaa-diameter-mm-app-0 1.txt Date: Wed, 9 Jul 2003 12:29:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3460D.575617C8" 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_01C3460D.575617C8 Content-Type: text/plain Another comment (or maybe it's a question). In section 3.3, there is text that says... 'Although the example shows the connection between a SIP INVITE request and the Diameter LIR message, any other SIP request (such as SUBSCRIBE, OPTIONS, etc.) would trigger the same Diameter message.' Could a REGISTER request trigger an LIR, and if so, in what situation? How does SIP server 1 determine if a REGISTER triggers an LIR or a UAR? My suspicion is that the text should read '... any other SIP request with the exception of a REGISTER request (such as SUBSCRIBE, OPTIONS, etc.) would trigger the same Diameter message', and that a REGISTER would always trigger a UAR to be sent. But I am prepared to be told I am wrong. I also have a whole host of minor editorial comments that I will forward on to Miguel-Angel and Maria-Carmen Belinchon away from the e-mail list. Dan Warren ------_=_NextPart_001_01C3460D.575617C8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Re: Comments: = draft-belinchon-aaa-diameter-mm-app-01.txt

Another comment (or maybe it's a question).  In = section 3.3, there is text that says...

'Although the example shows the connection between a = SIP INVITE request and the Diameter LIR message, any other SIP request = (such as SUBSCRIBE, OPTIONS, etc.) would trigger the same Diameter = message.'

Could a REGISTER request trigger an LIR, and if so, = in what situation?  How does SIP server 1 determine if a REGISTER = triggers an LIR or a UAR?  My suspicion is that the text should = read '... any other SIP request with the exception of a REGISTER = request (such as SUBSCRIBE, OPTIONS, etc.) would trigger the same = Diameter message', and that a REGISTER would always trigger a UAR to be = sent.  But I am prepared to be told I am wrong.

I also have a whole host of minor editorial comments = that I will forward on to Miguel-Angel and Maria-Carmen Belinchon away = from the e-mail list.

Dan Warren

------_=_NextPart_001_01C3460D.575617C8-- From owner-aaa-wg@merit.edu Wed Jul 9 07:42:59 2003 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 HAA28098 for ; Wed, 9 Jul 2003 07:42:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C9E059124D; Wed, 9 Jul 2003 07:42:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 958719124E; Wed, 9 Jul 2003 07:42:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4467D9124D for ; Wed, 9 Jul 2003 07:42:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2C3685DDC2; Wed, 9 Jul 2003 07:42:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from znsgs01r.nortelnetworks.com (h33s128a211n47.user.nortelnetworks.com [47.211.128.33]) by segue.merit.edu (Postfix) with ESMTP id 9893D5DDBF for ; Wed, 9 Jul 2003 07:42:44 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h69BgfF09330; Wed, 9 Jul 2003 12:42:41 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jul 2003 12:42:41 +0100 Message-ID: From: "Daniel Warren" To: "'Miguel A. Garcia'" , "Jayshree Bharatia" Cc: "'maria.c.belinchon@ericsson.com'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Re: Comments: draft-belinchon-aaa-diameter-mm-app-0 1.txt Date: Wed, 9 Jul 2003 12:42:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3460F.333DFCA0" 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_01C3460F.333DFCA0 Content-Type: text/plain If User-Name AVP is made optional, what is the impact of the text in 5.2 that reads... 'At reception of the Diameter UAR message, the Diameter server MUST verify the existence of the user in the realm, i.e., the User-Name AVP value is a valid user within that realm. If the Diameter server does not recognize the user name received in the User-Name AVP, the Diameter server MUST build a Diameter User-Authorization-Answer (UAA) message and MUST set the Result-Code AVP to DIAMETER_ERROR_USER_UNKNOWN. Then Diameter server MUST authorize that User-Name AVP value is able to register the SIP or SIPS URI included in the SIP-Public-User-Identity AVP. If this authorization fails, the Diameter server must set the Result-Code AVP to DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter User-Authorization-Answer (UAA) message.' If the User-Name AVP is made optional, is this behaviour still valid? Making User-Name AVP optional would seem to me to imply that any time it is missing, UAA has to report an error. Either it has to be mandatory or this behaviour needs to change too. Dan Warren ------------------------------- > Section 5.1 > - In Open Issue Note, you have mentioned User-Name AVP being the mandatory > parameter. I would think that UAR may be used for other SIP Requests > as well > (other than REGISTER). In those cases, do we have private id available > also? I agree with you. I am sure that the username AVP will not be available in general, in all requests. It might be get acquiered, but that requires the SIP proxy to challenge the user. So this open issue is just an action point to make the AVP optional and discuss what are the procedures in the Diameter server when the AVP is not present in the UAR. ------_=_NextPart_001_01C3460F.333DFCA0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Re: Comments: = draft-belinchon-aaa-diameter-mm-app-01.txt

If User-Name AVP is made optional, what is the impact = of the text in 5.2 that reads...

'At reception of the Diameter UAR message, the = Diameter server MUST
   verify the existence of the user in the = realm, i.e., the User-Name
   AVP value is a valid user within that = realm. If the Diameter server
   does not recognize the user name = received in the User-Name AVP, the
   Diameter server MUST build a Diameter = User-Authorization-Answer (UAA)
   message and MUST set the Result-Code = AVP to
   DIAMETER_ERROR_USER_UNKNOWN.

   Then Diameter server MUST authorize that = User-Name AVP value is able
   to register the SIP or SIPS URI = included in the
   SIP-Public-User-Identity AVP. If this = authorization fails, the
   Diameter server must set the = Result-Code AVP to
   DIAMETER_ERROR_IDENTITIES_DONT_MATCH = and send it in a Diameter
   User-Authorization-Answer (UAA) = message.'

If the User-Name AVP is made optional, is this = behaviour still valid?  Making User-Name AVP optional would seem = to me to imply that any time it is missing, UAA has to report an = error.  Either it has to be mandatory or this behaviour needs to = change too.

Dan Warren

-------------------------------


> Section 5.1
> - In Open Issue Note, you have mentioned = User-Name AVP being the mandatory
>   parameter. I would think that UAR = may be used for other SIP Requests
> as well
>   (other than REGISTER). In those = cases, do we have private id available
> also?

I agree with you. I am sure that the username AVP = will not be available in
general, in all requests. It might be get acquiered, = but that requires the
SIP proxy to challenge the user.

So this open issue is just an action point to make = the AVP optional and
discuss what are the procedures in the Diameter = server when the AVP is not
present in the UAR.

------_=_NextPart_001_01C3460F.333DFCA0-- From owner-aaa-wg@merit.edu Wed Jul 9 08:10:18 2003 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 IAA28468 for ; Wed, 9 Jul 2003 08:10:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 10E2D91225; Wed, 9 Jul 2003 08:10:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD0209124F; Wed, 9 Jul 2003 08:10:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A010891225 for ; Wed, 9 Jul 2003 08:10:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 898CB5DD8E; Wed, 9 Jul 2003 08:10:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 06D635DDB6 for ; Wed, 9 Jul 2003 08:10:03 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h69CA2Ii027074; Wed, 9 Jul 2003 14:10:02 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8XJBVBP; Wed, 9 Jul 2003 14:10:02 +0200 Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.31.68]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h69CA2SZ016573; Wed, 9 Jul 2003 15:10:02 +0300 (EET DST) Message-ID: <3F0C060F.9080400@ericsson.com> Date: Wed, 09 Jul 2003 15:09:51 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" Organization: Ericsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: es,en MIME-Version: 1.0 To: Daniel Warren Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Comments: draft-belinchon-aaa-diameter-mm-app-0 1.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Dan: You are opening the floor for an interesting discussion. I had the same sort of concerns about the similarities between UAR and LIR. The fact that UAR is triggered from a SIP REGISTER and LIR is triggered from any other SIP request is not enough to justify two different commands. I would then ask you what is the reason to have two different commands. Why is not possible to have a single command? Do you know the answer? /Miguel Daniel Warren wrote: > Another comment (or maybe it's a question). In section 3.3, there is > text that says... > > 'Although the example shows the connection between a SIP INVITE request > and the Diameter LIR message, any other SIP request (such as SUBSCRIBE, > OPTIONS, etc.) would trigger the same Diameter message.' > > Could a REGISTER request trigger an LIR, and if so, in what situation? > How does SIP server 1 determine if a REGISTER triggers an LIR or a UAR? > My suspicion is that the text should read '... any other SIP request > with the exception of a REGISTER request (such as SUBSCRIBE, OPTIONS, > etc.) would trigger the same Diameter message', and that a REGISTER > would always trigger a UAR to be sent. But I am prepared to be told I > am wrong. > > I also have a whole host of minor editorial comments that I will forward > on to Miguel-Angel and Maria-Carmen Belinchon away from the e-mail list. > > Dan Warren > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 From owner-aaa-wg@merit.edu Wed Jul 9 08:16:23 2003 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 IAA28588 for ; Wed, 9 Jul 2003 08:16:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 064689124F; Wed, 9 Jul 2003 08:16:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C800891251; Wed, 9 Jul 2003 08:15:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 74F3E9124F for ; Wed, 9 Jul 2003 08:15:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5B6E05DD9B; Wed, 9 Jul 2003 08:15:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 9F9155DD98 for ; Wed, 9 Jul 2003 08:15:57 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h69CFuIi028792; Wed, 9 Jul 2003 14:15:56 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NW4Q0M7Q; Wed, 9 Jul 2003 14:16:47 +0200 Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.31.68]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h69CFuSZ017048; Wed, 9 Jul 2003 15:15:56 +0300 (EET DST) Message-ID: <3F0C076C.3020500@ericsson.com> Date: Wed, 09 Jul 2003 15:15:40 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" Organization: Ericsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: es,en MIME-Version: 1.0 To: Daniel Warren Cc: Jayshree Bharatia , "'maria.c.belinchon@ericsson.com'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Re: Comments: draft-belinchon-aaa-diameter-mm-app-0 1.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dan: Of course that text will have be revisited if User-Name AVP is optional. But the fact is that, no matter what we write in the document, User-Name is optional except in 3GPP networks. 3GPP has optimized the flow to avoid two roundtrips, and therefore, User-Name comes in the first roundtrip. But this is not always the behaviour in an internet client. So the reason whey I noted down an Open Issue was to synchronize the behaviour when User-Name is available and when not. This will require to rewrite substantial parts of the document that assume User-Name is always available. /Miguel Daniel Warren wrote: > If User-Name AVP is made optional, what is the impact of the text in 5.2 > that reads... > > 'At reception of the Diameter UAR message, the Diameter server MUST > verify the existence of the user in the realm, i.e., the User-Name > AVP value is a valid user within that realm. If the Diameter server > does not recognize the user name received in the User-Name AVP, the > Diameter server MUST build a Diameter User-Authorization-Answer (UAA) > message and MUST set the Result-Code AVP to > DIAMETER_ERROR_USER_UNKNOWN. > > Then Diameter server MUST authorize that User-Name AVP value is able > to register the SIP or SIPS URI included in the > SIP-Public-User-Identity AVP. If this authorization fails, the > Diameter server must set the Result-Code AVP to > DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter > User-Authorization-Answer (UAA) message.' > > If the User-Name AVP is made optional, is this behaviour still valid? > Making User-Name AVP optional would seem to me to imply that any time it > is missing, UAA has to report an error. Either it has to be mandatory > or this behaviour needs to change too. > > Dan Warren > > ------------------------------- > > > > Section 5.1 > > - In Open Issue Note, you have mentioned User-Name AVP being the > mandatory > > parameter. I would think that UAR may be used for other SIP Requests > > as well > > (other than REGISTER). In those cases, do we have private id available > > also? > > I agree with you. I am sure that the username AVP will not be available in > general, in all requests. It might be get acquiered, but that requires the > SIP proxy to challenge the user. > > So this open issue is just an action point to make the AVP optional and > discuss what are the procedures in the Diameter server when the AVP is not > present in the UAR. > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 From owner-aaa-wg@merit.edu Wed Jul 9 11:49:55 2003 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 LAA06918 for ; Wed, 9 Jul 2003 11:49:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3B1B791257; Wed, 9 Jul 2003 11:49:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 12E7F91259; Wed, 9 Jul 2003 11:49:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 873B491257 for ; Wed, 9 Jul 2003 11:49:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 744905DDB5; Wed, 9 Jul 2003 11:49:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from znsgs01r.nortelnetworks.com (h33s128a211n47.user.nortelnetworks.com [47.211.128.33]) by segue.merit.edu (Postfix) with ESMTP id 7E7485DDAC for ; Wed, 9 Jul 2003 11:49:33 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h69FnUF12891; Wed, 9 Jul 2003 16:49:30 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jul 2003 16:49:31 +0100 Message-ID: From: "Daniel Warren" To: "'Miguel A. Garcia'" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Re: Comments: draft-belinchon-aaa-diameter-mm-app-0 1.txt Date: Wed, 9 Jul 2003 16:49:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34631.AF15734A" 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_01C34631.AF15734A Content-Type: text/plain I think I might (although I also think someone in your office probably could tell you too!!). The fundamental difference in usage I think is that the UAR is generally used for REGISTER because the SIP Server is the one on the call originating side, so when a user registers, it is the UAR that is sent to the Diameter Server to obtain the S-CSCF details and/or capabilities for the subscriber and ultimately to faciliate the registration of that subscriber with the network. LIR is used on a session terminating SIP Server to contact the Diameter Server for the location of the subscriber but does not involve the subscriber explicitly registering with the network as a consequence. I can't remember much more of the detailed rationale for why we ended up with two commands rather than one, and I am not entirely convinced that this explanation justifies it. I'll keep thinking about it. Dan -----Original Message----- From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] Sent: 09 July 2003 13:10 To: Warren, Daniel [MOP:EP10:EXCH] Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Comments: draft-belinchon-aaa-diameter-mm-app-0 1.txt Hi Dan: You are opening the floor for an interesting discussion. I had the same sort of concerns about the similarities between UAR and LIR. The fact that UAR is triggered from a SIP REGISTER and LIR is triggered from any other SIP request is not enough to justify two different commands. I would then ask you what is the reason to have two different commands. Why is not possible to have a single command? Do you know the answer? /Miguel Daniel Warren wrote: > Another comment (or maybe it's a question). In section 3.3, there is > text that says... > > 'Although the example shows the connection between a SIP INVITE > request > and the Diameter LIR message, any other SIP request (such as SUBSCRIBE, > OPTIONS, etc.) would trigger the same Diameter message.' > > Could a REGISTER request trigger an LIR, and if so, in what situation? > How does SIP server 1 determine if a REGISTER triggers an LIR or a UAR? > My suspicion is that the text should read '... any other SIP request > with the exception of a REGISTER request (such as SUBSCRIBE, OPTIONS, > etc.) would trigger the same Diameter message', and that a REGISTER > would always trigger a UAR to be sent. But I am prepared to be told I > am wrong. > > I also have a whole host of minor editorial comments that I will > forward > on to Miguel-Angel and Maria-Carmen Belinchon away from the e-mail list. > > Dan Warren > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 ------_=_NextPart_001_01C34631.AF15734A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Re: Comments: = draft-belinchon-aaa-diameter-mm-app-0 1.txt

I think I might (although I also think someone in = your office probably could tell you too!!).

The fundamental difference in usage I think is that = the UAR is generally used for REGISTER because the SIP Server is the = one on the call originating side, so when a user registers, it is the = UAR that is sent to the Diameter Server to obtain the S-CSCF details = and/or capabilities for the subscriber and ultimately to faciliate the = registration of that subscriber with the network.  LIR is used on = a session terminating SIP Server to contact the Diameter Server for the = location of the subscriber but does not involve the subscriber = explicitly registering with the network as a consequence.

I can't remember much more of the detailed rationale = for why we ended up with two commands rather than one, and I am not = entirely convinced that this explanation justifies it.

I'll keep thinking about it.

Dan



-----Original Message-----
From: Miguel A. Garcia [mailto:Miguel.A.Garcia@eric= sson.com]
Sent: 09 July 2003 13:10
To: Warren, Daniel [MOP:EP10:EXCH]
Cc: aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Re: Comments: = draft-belinchon-aaa-diameter-mm-app-0 1.txt


Hi Dan:

You are opening the floor for an interesting = discussion. I had the same
sort of concerns about the similarities between UAR = and LIR.

The fact that UAR is triggered from a SIP REGISTER = and LIR is triggered
from any other SIP request is not enough to justify = two different commands.

I would then ask you what is the reason to have two = different commands. Why
is not possible to have a single command? Do you = know the answer?

/Miguel

Daniel Warren wrote:
> Another comment (or maybe it's a = question).  In section 3.3, there is
> text that says...
>
> 'Although the example shows the connection = between a SIP INVITE
> request
> and the Diameter LIR message, any other SIP = request (such as SUBSCRIBE,
> OPTIONS, etc.) would trigger the same Diameter = message.'
>
> Could a REGISTER request trigger an LIR, and if = so, in what situation?
> How does SIP server 1 determine if a REGISTER = triggers an LIR or a UAR? 
> My suspicion is that the text should read '... = any other SIP request
> with the exception of a REGISTER request (such = as SUBSCRIBE, OPTIONS,
> etc.) would trigger the same Diameter message', = and that a REGISTER
> would always trigger a UAR to be sent.  = But I am prepared to be told I
> am wrong.
>
> I also have a whole host of minor editorial = comments that I will
> forward
> on to Miguel-Angel and Maria-Carmen Belinchon = away from the e-mail list.
>
> Dan Warren
>


--
Miguel-Angel = Garcia           =           Oy LM Ericsson = AB
          &nb= sp;           &nb= sp;           &nb= sp;      Jorvas, Finland
mailto:Miguel.A.Garcia@eric= sson.com     Phone:  +358 9 299 = 3553
mailto:Miguel.A.Garcia@piuha.n= et        Mobile: +358 40 = 5140002





------_=_NextPart_001_01C34631.AF15734A-- From owner-aaa-wg@merit.edu Wed Jul 9 19:01:26 2003 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 TAA28037 for ; Wed, 9 Jul 2003 19:01:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 95EE39124A; Wed, 9 Jul 2003 19:00:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F75291252; Wed, 9 Jul 2003 19:00:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3C2609124A for ; Wed, 9 Jul 2003 19:00:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 27CFC5DD92; Wed, 9 Jul 2003 19:00:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id C69745DD8F for ; Wed, 9 Jul 2003 19:00:10 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h69N03l28979; Wed, 9 Jul 2003 18:00:03 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jul 2003 18:00:03 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746A56@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Miguel A. Garcia'" Cc: "'maria.c.belinchon@ericsson.com'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: RE: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt Date: Wed, 9 Jul 2003 18:00:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3466D.D3A0B490" 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_01C3466D.D3A0B490 Content-Type: text/plain Hi Miguel, Please see my response below. Thanks, Jayshree > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Wednesday, July 09, 2003 2:03 AM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: 'maria.c.belinchon@ericsson.com'; 'aaa-wg@merit.edu' > Subject: Re: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt > > ... > > Section 3.1 and 3.2 (general) > > - I don't see much difference between the scenarios > discussed in section > > 3.1-"Diameter server authenticate the user" and section > 3.2 -"SIP server > > authenticate the user". There are just couple of steps (13 and 14) > > which are > > different from the description of these sections. Since > these scenarios > > are discussed in different context, it's better to show > which commands > > are > > used for what purpose and consolidate the description. > > I think it is important to highlight the difference between these two > scenarios. 3.1 is more aligned with the AAA architecture, > where a Diameter > server is authenticating users. This is the main role of the > AAA server. > Section 3.2 describes a scenario that is used in 3GPP, where > the Diameter > server delegates authentication to the SIP server. > [JB] The current title of section 3.2 is "SIP server authenticates the user" so you may need to correct this to reflect your above point. I am not sure how (and where) SIP server delegates authentication to the SIP server in the current flow. I thought SAR basically does what MAR is doing plus provides SIP server address to the Diameter Server for the future use. Is it what you are referring to? It will be useful if you show set of commands used when the Diameter server is authenticate the user vs the SIP server authenticate the user. > I believe both scenarios have different values in different > networks. From > the point of view of the application, we just want to provide > the means to > use either of the scenarios. 3GPP has chosen to go for > scenario 3.2, but > other networks will most likely use scenario 3.1. > > Please, let me know exactly what is missing. I am able to add any > clarification to the text. > ... > > Additionally, I would think that it will be better to > mention what > > value will > > be assign to SIP-Public-User-Identity parameter in case > of non-3GPP > > usage. > > This is not dependent on 3GPP or not-3GPP. The > SIP-Public-User-Identity is > what in normal SIP is called an Address Of Record (AOR). In an INVITE > request, the SIP AOR comes in the Request-URI. In a REGISTER > request it > comes in the To field. > > The 4th paragraph in section 5.1 should answer your concern: > > The SIP or SIPS URI to be registered is conveyed in the > SIP-Public-User-Identity AVP (Section 7.8). Typically this SIP or > SIPS URI is found in the To header field value of the SIP REGISTER > request that triggered the Diameter UAR message. > > And that makes me think that the SIP-Public-User-Identity > should be renamed > to SIP-AOR (Address of Record) to align the terminology with SIP... > > [JB] Agree. It will be good if you can rename this field. > > > - This section says that the Diameter server must include either the > > address of > > the SIP server or the capability needed by the SIP > server. Does it > > mean that > > requesting SIP server always have capability to derive > next hope based > > on the > > capabilities received from the AAA? Why do we have this additional > > requirement. > > > [JB] Sorry for the confusion I am referring to section 5.2 only (4th paragraph) which is specific to UAA. "When the authorization procedure succeeds, the Diameter server constructs a User-Authorization-Answer (UAA) message that MUST include either the address of the SIP server already assigned to the user or the capabilities needed by the SIP server (Diameter client) to select another SIP server for the user." My point is why UAA (and hence UAR) is tied with having SIP server address or SIP server capabilities? My understanding from reading this draft is that UAR can be triggered upon receipt of any SIP request and may be used any time during the transaction. If this is the case than the requirement on having the SIP server address or capabilities should be soften. My suggestion is to separate Authorization operation from the explicit Assignment/Retrieval of the SIP server address. > Here I am lost. Are you still discussing section 5.1??? Which > paragraph are > you referring to??? I don't find the text you mention. > > Thanks a lot for reviewing the text. Please, keep on posting > additional > comments. > > Regards, > > Miguel > > > Regards, > > Jayshree > > > > > -- > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 > > > > > > ------_=_NextPart_001_01C3466D.D3A0B490 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt

Hi Miguel,

Please see my response below.

Thanks,
Jayshree

> -----Original Message-----
> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@eric= sson.com]
> Sent: Wednesday, July 09, 2003 2:03 AM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: 'maria.c.belinchon@ericsson.com'; = 'aaa-wg@merit.edu'
> Subject: Re: Comments: = draft-belinchon-aaa-diameter-mm-app-01.txt
>
>
...
> > Section 3.1 and 3.2 (general)
> > - I don't see much difference between the = scenarios
> discussed in section
> >   3.1-"Diameter server = authenticate the user" and section
> 3.2 -"SIP server
> >   authenticate the user". = There are just couple of steps (13 and 14)
> > which are
> >   different from the description = of these sections. Since
> these scenarios
> >   are discussed in different = context, it's better to show
> which commands
> > are
> >   used for what purpose and = consolidate the description.
>
> I think it is important to highlight the = difference between these two
> scenarios. 3.1 is more aligned with the AAA = architecture,
> where a Diameter
> server is authenticating users. This is the = main role of the
> AAA server.
> Section 3.2 describes a scenario that is used = in 3GPP, where
> the Diameter
> server delegates authentication to the SIP = server.
>
[JB] The current title of section 3.2 is "SIP = server authenticates the user" so you may need to correct this to = reflect your above point. I am not sure how (and where) SIP server = delegates authentication to the SIP server in the current flow. I = thought SAR basically does what MAR is doing plus provides SIP server = address to the Diameter Server for the future use. Is it what you are = referring to? It will be useful if you show set of commands used when = the Diameter server is authenticate the user vs the SIP server = authenticate the user.

 
> I believe both scenarios have different values = in different
> networks. From
> the point of view of the application, we just = want to provide
> the means to
> use either of the scenarios. 3GPP has chosen to = go for
> scenario 3.2, but
> other networks will most likely use scenario = 3.1.
>
> Please, let me know exactly what is missing. I = am able to add any
> clarification to the text.
>
...
> >   Additionally,  I would = think that it will be better to
> mention what
> > value will
> >   be assign to = SIP-Public-User-Identity parameter in case
> of non-3GPP
> > usage.
>
> This is not dependent on 3GPP or not-3GPP. The =
> SIP-Public-User-Identity is
> what in normal SIP is called an Address Of = Record (AOR). In an INVITE
> request, the SIP AOR comes in the Request-URI. = In a REGISTER
> request it
> comes in the To field.
>
> The 4th paragraph in section 5.1 should answer = your concern:
>
>     The SIP or SIPS URI to = be registered is conveyed in the
>     = SIP-Public-User-Identity AVP (Section 7.8). Typically this SIP = or
>     SIPS URI is found in = the To header field value of the SIP REGISTER
>     request that triggered = the Diameter UAR message.
>
> And that makes me think that the = SIP-Public-User-Identity
> should be renamed
> to SIP-AOR (Address of Record) to align the = terminology with SIP...
>
>
[JB] Agree. It will be good if you can rename this = field.
>
> > - This section says that the Diameter = server must include either the
> > address of
> >   the SIP server  or the = capability needed by the SIP
> server. Does it
> > mean that
> >   requesting SIP server always = have capability to derive
> next hope based
> > on the
> >   capabilities received from the = AAA? Why do we have this additional
> >   requirement.
> >
>
[JB] Sorry for the confusion I am referring to = section 5.2 only (4th paragraph) which is specific to UAA.

"When the authorization procedure succeeds, the = Diameter server constructs a User-Authorization-Answer (UAA) message = that MUST include either the address of the SIP server already assigned = to the user or the capabilities needed by the SIP server (Diameter = client) to select another SIP server for the user."

My point is why UAA (and hence UAR) is tied with = having SIP server address or SIP server capabilities? My understanding = from reading this draft is that UAR can be triggered upon receipt of = any SIP request and may be used any time during the transaction. If = this is the case than the requirement on having the SIP server address = or capabilities should be soften. My suggestion is to separate = Authorization operation from the explicit Assignment/Retrieval of the = SIP server address.

> Here I am lost. Are you still discussing section = 5.1??? Which
> paragraph are
> you referring to??? I don't find the text you = mention.
>
> Thanks a lot for reviewing the text. Please, = keep on posting
> additional
> comments.
>
> Regards,
>
>      Miguel
>
> > Regards,
> > Jayshree
> >
>
>
> --
> Miguel-Angel = Garcia           =           Oy LM Ericsson = AB
>          = ;            = ;            = ;        Jorvas, Finland
> mailto:Miguel.A.Garcia@eric= sson.com     Phone:  +358 9 299 = 3553
> mailto:Miguel.A.Garcia@piuha.n= et        Mobile: +358 40 = 5140002
>
>
>
>
>
>

------_=_NextPart_001_01C3466D.D3A0B490-- From owner-aaa-wg@merit.edu Thu Jul 10 06:16:28 2003 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 GAA25186 for ; Thu, 10 Jul 2003 06:16:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 73D3F91269; Thu, 10 Jul 2003 06:16:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B6A191268; Thu, 10 Jul 2003 06:16:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4632A91269 for ; Thu, 10 Jul 2003 06:16:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 320275DDCA; Thu, 10 Jul 2003 06:16:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id 6D0C05DDAF for ; Thu, 10 Jul 2003 06:16:05 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6AAFwGJ002320; Thu, 10 Jul 2003 12:15:58 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 3S6BRD5H; Thu, 10 Jul 2003 12:16:52 +0200 Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.31.68]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h6AAFwSZ019791; Thu, 10 Jul 2003 13:15:58 +0300 (EET DST) Message-ID: <3F0D3CDD.4060002@ericsson.com> Date: Thu, 10 Jul 2003 13:15:57 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" Organization: Ericsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: es,en MIME-Version: 1.0 To: Daniel Warren Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Comments: draft-belinchon-aaa-diameter-mm-app-0 1.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dan: I did some research and I got some convincing answers. UAR is a request for authorization to perform an action. In the case of 3GPP such action is always to accept a registration. The authorization considers whether the Public user identity is defined in the realm, whether hte user is allowed to roam in a particular visited network and such things. LIR is a request for routing information. A SIP server has received a request address to a user of the realm, but it does not have enough routing information to forward it. Therefore, it contacts the Diameter server to ask for routing information (e.g., the address of the SIP server serving the user). Therefore, both commands have different semantics, and should remain as different commands. Regards, Miguel Daniel Warren wrote: > I think I might (although I also think someone in your office probably > could tell you too!!). > > The fundamental difference in usage I think is that the UAR is generally > used for REGISTER because the SIP Server is the one on the call > originating side, so when a user registers, it is the UAR that is sent > to the Diameter Server to obtain the S-CSCF details and/or capabilities > for the subscriber and ultimately to faciliate the registration of that > subscriber with the network. LIR is used on a session terminating SIP > Server to contact the Diameter Server for the location of the subscriber > but does not involve the subscriber explicitly registering with the > network as a consequence. > > I can't remember much more of the detailed rationale for why we ended up > with two commands rather than one, and I am not entirely convinced that > this explanation justifies it. > > I'll keep thinking about it. > > Dan > > > > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: 09 July 2003 13:10 > To: Warren, Daniel [MOP:EP10:EXCH] > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Re: Comments: > draft-belinchon-aaa-diameter-mm-app-0 1.txt > > > Hi Dan: > > You are opening the floor for an interesting discussion. I had the same > sort of concerns about the similarities between UAR and LIR. > > The fact that UAR is triggered from a SIP REGISTER and LIR is triggered > from any other SIP request is not enough to justify two different commands. > > I would then ask you what is the reason to have two different commands. Why > is not possible to have a single command? Do you know the answer? > > /Miguel > > Daniel Warren wrote: > > Another comment (or maybe it's a question). In section 3.3, there is > > text that says... > > > > 'Although the example shows the connection between a SIP INVITE > > request > > and the Diameter LIR message, any other SIP request (such as SUBSCRIBE, > > OPTIONS, etc.) would trigger the same Diameter message.' > > > > Could a REGISTER request trigger an LIR, and if so, in what situation? > > How does SIP server 1 determine if a REGISTER triggers an LIR or a UAR? > > My suspicion is that the text should read '... any other SIP request > > with the exception of a REGISTER request (such as SUBSCRIBE, OPTIONS, > > etc.) would trigger the same Diameter message', and that a REGISTER > > would always trigger a UAR to be sent. But I am prepared to be told I > > am wrong. > > > > I also have a whole host of minor editorial comments that I will > > forward > > on to Miguel-Angel and Maria-Carmen Belinchon away from the e-mail list. > > > > Dan Warren > > > > > -- > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 > > > > > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 From owner-aaa-wg@merit.edu Thu Jul 10 07:14:30 2003 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 HAA26730 for ; Thu, 10 Jul 2003 07:14:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DC0AA9126C; Thu, 10 Jul 2003 07:14:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ADCFD9126D; Thu, 10 Jul 2003 07:14:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4C74B9126C for ; Thu, 10 Jul 2003 07:14:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 36E1D5DDD9; Thu, 10 Jul 2003 07:14:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id A8E4D5DDD1 for ; Thu, 10 Jul 2003 07:14:13 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6ABECGJ015067; Thu, 10 Jul 2003 13:14:12 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8XJJNH2; Thu, 10 Jul 2003 13:14:12 +0200 Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.31.68]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h6ABECSZ022935; Thu, 10 Jul 2003 14:14:12 +0300 (EET DST) Message-ID: <3F0D4A51.2010106@ericsson.com> Date: Thu, 10 Jul 2003 14:13:21 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" Organization: Ericsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: es,en MIME-Version: 1.0 To: Jayshree Bharatia Cc: "'maria.c.belinchon@ericsson.com'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Re: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt References: <870397D7C140C84DB081B88396458DAF746A56@zrc2c000.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Inline... Jayshree Bharatia wrote: > [JB] The current title of section 3.2 is "SIP server authenticates the > user" so you may need to correct this to reflect your above point. I am > not sure how (and where) SIP server delegates authentication to the SIP > server in the current flow. I thought SAR basically does what MAR is > doing plus provides SIP server address to the Diameter Server for the > future use. Is it what you are referring to? It will be useful if you > show set of commands used when the Diameter server is authenticate the > user vs the SIP server authenticate the user. I will change the title of section 3.2 to reflect the delegation. The Diameter server delegates authentication to the user in a MAA command. MAA contains, in this case, one or more SIP-Auth-Data-Item (authentication vectors). SAR has another functionality of downloading the user profile. [snap] > > > > > - This section says that the Diameter server must include either the > > > address of > > > the SIP server or the capability needed by the SIP > > server. Does it > > > mean that > > > requesting SIP server always have capability to derive > > next hope based > > > on the > > > capabilities received from the AAA? Why do we have this additional > > > requirement. > > > > > > [JB] Sorry for the confusion I am referring to section 5.2 only (4th > paragraph) which is specific to UAA. > > "When the authorization procedure succeeds, the Diameter server > constructs a User-Authorization-Answer (UAA) message that MUST include > either the address of the SIP server already assigned to the user or the > capabilities needed by the SIP server (Diameter client) to select > another SIP server for the user." > > My point is why UAA (and hence UAR) is tied with having SIP server > address or SIP server capabilities? My understanding from reading this > draft is that UAR can be triggered upon receipt of any SIP request and > may be used any time during the transaction. If this is the case than > the requirement on having the SIP server address or capabilities should > be soften. My suggestion is to separate Authorization operation from the > explicit Assignment/Retrieval of the SIP server address. We agree that the SIP server uses UAR (and UAA) to request Authorization to provide a service. The service may be "user wants to register (REGISTER message)" or "user wants to establish a session with another guy (INVITE message)". That is clear for you and me. I think that in any case a SIP edge proxy may need to know: a) Whether the proxy is authorized to provide the service to the user b) If the proxy needs some routing information (e.g., the address of another proxy that is serving the user). We could of course separate both commands, but then we require one more roundtrip operation, because afterach each UAR, the Diameter client will require routing information, always. That's the reason why they are combined. And because this command is used for routing realtime traffic, I wouldn't like to add one more rountrip of delays to the session setup time. Don't you agree with this motivation? Regards, Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 From owner-aaa-wg@merit.edu Thu Jul 10 11:38:37 2003 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 LAA07854 for ; Thu, 10 Jul 2003 11:38:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C73299120E; Thu, 10 Jul 2003 11:38:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92FEE91274; Thu, 10 Jul 2003 11:38:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ABD9C9120E for ; Thu, 10 Jul 2003 11:38:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8BFAD5DDC5; Thu, 10 Jul 2003 11:38:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id 355D35DD90 for ; Thu, 10 Jul 2003 11:38:21 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6AFcFV10063; Thu, 10 Jul 2003 10:38:15 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jul 2003 10:38:16 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746A5B@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Miguel A. Garcia'" Cc: "'maria.c.belinchon@ericsson.com'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: RE: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt Date: Thu, 10 Jul 2003 10:38:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C346F9.465EB51E" 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_01C346F9.465EB51E Content-Type: text/plain > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Thursday, July 10, 2003 6:13 AM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: 'maria.c.belinchon@ericsson.com'; 'aaa-wg@merit.edu' > Subject: Re: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt > > > Inline... > > Jayshree Bharatia wrote: > > > [JB] The current title of section 3.2 is "SIP server > authenticates the > > user" so you may need to correct this to reflect your above > point. I am > > not sure how (and where) SIP server delegates > authentication to the SIP > > server in the current flow. I thought SAR basically does > what MAR is > > doing plus provides SIP server address to the Diameter > Server for the > > future use. Is it what you are referring to? It will be > useful if you > > show set of commands used when the Diameter server is > authenticate the > > user vs the SIP server authenticate the user. > > I will change the title of section 3.2 to reflect the delegation. > > The Diameter server delegates authentication to the user in a > MAA command. > MAA contains, in this case, one or more SIP-Auth-Data-Item > (authentication > vectors). SAR has another functionality of downloading the > user profile. > [JB] Ok. Currently, the description of steps 5 and 6 (MAR/MAA) in both sections (3.1 and 3.2) have similar text. So please clarify your point further in section 3.2 so that this functionality becomes obvious. > [snap] > > > > > > > - This section says that the Diameter server must > include either > > the > > address of > > > > the SIP server or the capability needed by the SIP > > > server. Does it > > > > mean that > > > > requesting SIP server always have capability to derive > > > next hope based > > > > on the > > > > capabilities received from the AAA? Why do we have > this additional > > > > requirement. > > > > > > > > > [JB] Sorry for the confusion I am referring to section 5.2 only (4th > > paragraph) which is specific to UAA. > > > > "When the authorization procedure succeeds, the Diameter server > > constructs a User-Authorization-Answer (UAA) message that > MUST include > > either the address of the SIP server already assigned to > the user or the > > capabilities needed by the SIP server (Diameter client) to select > > another SIP server for the user." > > > > My point is why UAA (and hence UAR) is tied with having SIP server > > address or SIP server capabilities? My understanding from > reading this > > draft is that UAR can be triggered upon receipt of any SIP > request and > > may be used any time during the transaction. If this is the > case than > > the requirement on having the SIP server address or > capabilities should > > be soften. My suggestion is to separate Authorization > operation from the > > explicit Assignment/Retrieval of the SIP server address. > > We agree that the SIP server uses UAR (and UAA) to request > Authorization to > provide a service. The service may be "user wants to > register (REGISTER > message)" or "user wants to establish a session with another > guy (INVITE > message)". That is clear for you and me. > > I think that in any case a SIP edge proxy may need to know: > a) Whether the proxy is authorized to provide the service to the user > b) If the proxy needs some routing information (e.g., the address of > another proxy that is serving the user). > > We could of course separate both commands, but then we > require one more > roundtrip operation, because afterach each UAR, the Diameter > client will > require routing information, always. That's the reason why they are > combined. And because this command is used for routing > realtime traffic, I > wouldn't like to add one more rountrip of delays to the > session setup time. > Don't you agree with this motivation? > [JB] As I have indicated in my earlier email, we may not need both the functionality (mentioned as points a and b in your reply) at all of the time. So it will be good if you can replace MUST to SHOULD in the following quote of section 5.2. "When the authorization procedure succeeds, the Diameter server constructs a User-Authorization-Answer (UAA) message that MUST include either the address of the SIP server already assigned to the user or the capabilities needed by the SIP server (Diameter client) to select another SIP server for the user." > Regards, > > Miguel > > > > -- > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 > > > > > > ------_=_NextPart_001_01C346F9.465EB51E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt

> -----Original Message-----
> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@eric= sson.com]
> Sent: Thursday, July 10, 2003 6:13 AM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: 'maria.c.belinchon@ericsson.com'; = 'aaa-wg@merit.edu'
> Subject: Re: Comments: = draft-belinchon-aaa-diameter-mm-app-01.txt
>
>
> Inline...
>
> Jayshree Bharatia wrote:
>
> > [JB] The current title of section 3.2 is = "SIP server
> authenticates the
> > user" so you may need to correct this = to reflect your above
> point. I am
> > not sure how (and where) SIP server = delegates
> authentication to the SIP
> > server in the current flow. I thought SAR = basically does
> what MAR is
> > doing plus provides SIP server address to = the Diameter
> Server for the
> > future use. Is it what you are referring = to? It will be
> useful if you
> > show set of commands used when the = Diameter server is
> authenticate the
> > user vs the SIP server authenticate the = user.
>
> I will change the title of section 3.2 to = reflect the delegation.
>
> The Diameter server delegates authentication to = the user in a
> MAA command.
> MAA contains, in this case, one or more = SIP-Auth-Data-Item 
> (authentication
> vectors). SAR has another functionality of = downloading the
> user profile.
>
[JB] Ok.  Currently, the description of steps 5 = and 6 (MAR/MAA) in both sections (3.1 and 3.2) have similar text. So = please clarify your point further in section 3.2 so that this = functionality becomes obvious.

> [snap]
> >  >
> >  > > - This section says that = the Diameter server must
> include either
> > the  > > address of
> >  > >   the SIP = server  or the capability needed by the SIP
> >  > server. Does it
> >  > > mean that
> >  > >   requesting SIP = server always have capability to derive
> >  > next hope based
> >  > > on the
> >  > >   capabilities = received from the AAA? Why do we have
> this additional
> >  > >   = requirement.
> >  > >
> >  >
> > [JB] Sorry for the confusion I am = referring to section 5.2 only (4th
> > paragraph) which is specific to = UAA.
> >
> > "When the authorization procedure = succeeds, the Diameter server
> > constructs a User-Authorization-Answer = (UAA) message that
> MUST include
> > either the address of the SIP server = already assigned to
> the user or the
> > capabilities needed by the SIP server = (Diameter client) to select
> > another SIP server for the = user."
> >
> > My point is why UAA (and hence UAR) is = tied with having SIP server
> > address or SIP server capabilities? My = understanding from
> reading this
> > draft is that UAR can be triggered upon = receipt of any SIP
> request and
> > may be used any time during the = transaction. If this is the
> case than
> > the requirement on having the SIP server = address or
> capabilities should
> > be soften. My suggestion is to separate = Authorization
> operation from the
> > explicit Assignment/Retrieval of the SIP = server address.
>
> We agree that the SIP server uses UAR (and UAA) = to request
> Authorization to
>   provide a service. The service may = be "user wants to
> register (REGISTER
> message)" or "user wants to establish = a session with another
> guy (INVITE
> message)". That is clear for you and = me.
>
> I think that in any case a SIP edge proxy may = need to know:
> a) Whether the proxy is authorized to provide = the service to the user
> b) If the proxy needs some routing information = (e.g., the address of
> another proxy that is serving the user).
>
> We could of course separate both commands, but = then we
> require one more
> roundtrip operation, because afterach each UAR, = the Diameter
> client will
> require routing information, always. That's the = reason why they are
> combined. And because this command is used for = routing
> realtime traffic, I
> wouldn't like to add one more rountrip of = delays to the
> session setup time.
> Don't you agree with this motivation?
>
[JB] As I have indicated in my earlier email, we may = not need both the functionality (mentioned as points a and b in your = reply) at all of the time. So it will be good if you can replace MUST = to SHOULD in the following quote of section 5.2.

"When the authorization procedure succeeds, the = Diameter server constructs a User-Authorization-Answer (UAA) message = that MUST include either the address of the SIP server already assigned = to the user or the capabilities needed by the SIP server (Diameter = client) to select another SIP server for the user."

> Regards,
>
>        = Miguel
>
>
>
> --
> Miguel-Angel = Garcia           =           Oy LM Ericsson = AB
>          = ;            = ;            = ;        Jorvas, Finland
> mailto:Miguel.A.Garcia@eric= sson.com     Phone:  +358 9 299 = 3553
> mailto:Miguel.A.Garcia@piuha.n= et        Mobile: +358 40 = 5140002
>
>
>
>
>
>

------_=_NextPart_001_01C346F9.465EB51E-- From owner-aaa-wg@merit.edu Thu Jul 10 12:01:51 2003 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 MAA08733 for ; Thu, 10 Jul 2003 12:01:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6298091273; Thu, 10 Jul 2003 12:01:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A30291274; Thu, 10 Jul 2003 12:01:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 741A591273 for ; Thu, 10 Jul 2003 12:01:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3D6175DDA9; Thu, 10 Jul 2003 12:01:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id AD9705DD99 for ; Thu, 10 Jul 2003 12:01:15 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6AG1EGJ023858; Thu, 10 Jul 2003 18:01:14 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8XJLMV1; Thu, 10 Jul 2003 18:01:14 +0200 Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.31.68]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h6AG1FSZ008288; Thu, 10 Jul 2003 19:01:15 +0300 (EET DST) Message-ID: <3F0D8C56.3080101@ericsson.com> Date: Thu, 10 Jul 2003 18:55:02 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" Organization: Ericsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: es,en MIME-Version: 1.0 To: Jayshree Bharatia Cc: "'maria.c.belinchon@ericsson.com'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Re: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt References: <870397D7C140C84DB081B88396458DAF746A5B@zrc2c000.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jayshree Bharatia wrote: > > > [JB] As I have indicated in my earlier email, we may not need both the > functionality (mentioned as points a and b in your reply) at all of the > time. So it will be good if you can replace MUST to SHOULD in the > following quote of section 5.2. > > "When the authorization procedure succeeds, the Diameter server > constructs a User-Authorization-Answer (UAA) message that MUST include > either the address of the SIP server already assigned to the user or the > capabilities needed by the SIP server (Diameter client) to select > another SIP server for the user." > Jayshree, I am trying to find out the applicability of your comment. It would be good to understand the scenario you are thinking of. As far as I understand, you are saying that there may be a third scenario where the SIP proxy is just interesting in the User Authorization but not in doing further routing. Is this correct? If it is, I think it is a dangerous scenario, because the SIP proxy will not be able to determine whether the request has to be routed to another proxy or not. So if you have a scenario in mind, it would be nice to understanding. Further more, your proposal to downgrade the "MUST" to a "SHOULD" does not help, because from what I understand from your comments, what you want is to deploy SIP servers that do no have the server allocation functionality. If that is the case, writing normative text to the Diameter server will not help. /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 From owner-aaa-wg@merit.edu Thu Jul 10 13:19:06 2003 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 NAA12988 for ; Thu, 10 Jul 2003 13:19:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 699FA91211; Thu, 10 Jul 2003 13:18:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 397C091275; Thu, 10 Jul 2003 13:18:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8926191211 for ; Thu, 10 Jul 2003 13:18:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 722585DDBB; Thu, 10 Jul 2003 13:18:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id 264C95DD91 for ; Thu, 10 Jul 2003 13:18:55 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6AHIpV10742; Thu, 10 Jul 2003 12:18:51 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jul 2003 12:18:52 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746A5D@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Miguel A. Garcia'" Cc: "'maria.c.belinchon@ericsson.com'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: RE: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt Date: Thu, 10 Jul 2003 12:18:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34707.5400FD40" 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_01C34707.5400FD40 Content-Type: text/plain Hello Miguel, Please see my reply inline. Thanks, Jayshree > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Thursday, July 10, 2003 10:55 AM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: 'maria.c.belinchon@ericsson.com'; 'aaa-wg@merit.edu' > Subject: Re: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt > > > > > Jayshree Bharatia wrote: > > > > > > > [JB] As I have indicated in my earlier email, we may not > need both the > > functionality (mentioned as points a and b in your reply) > at all of the > > time. So it will be good if you can replace MUST to SHOULD in the > > following quote of section 5.2. > > > > "When the authorization procedure succeeds, the Diameter server > > constructs a User-Authorization-Answer (UAA) message that > MUST include > > either the address of the SIP server already assigned to > the user or the > > capabilities needed by the SIP server (Diameter client) to select > > another SIP server for the user." > > > > Jayshree, I am trying to find out the applicability of your > comment. It > would be good to understand the scenario you are thinking of. > As far as I > understand, you are saying that there may be a third scenario > where the SIP > proxy is just interesting in the User Authorization but not in doing > further routing. Is this correct? > > If it is, I think it is a dangerous scenario, because the SIP > proxy will > not be able to determine whether the request has to be routed > to another > proxy or not. So if you have a scenario in mind, it would be nice to > understanding. > [JB] My scenario is simple where only authorization of the user is required. The problem I see in the current document is that you are tying the authorization with the routing. And my suggestion is provide an option so that if someone wants to use UAR/UAA just for the authorization it will still be possible. > Further more, your proposal to downgrade the "MUST" to a > "SHOULD" does not > help, because from what I understand from your comments, what > you want is > to deploy SIP servers that do no have the server allocation > functionality. > If that is the case, writing normative text to the Diameter > server will not > help. [JB] Why do you think that writing normative text to the Diameter server will not help? You are still using the AAA server for authorizing the user. > > /Miguel > > > -- > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 > > > > > > ------_=_NextPart_001_01C34707.5400FD40 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt

Hello Miguel,

Please see my reply inline.

Thanks,
Jayshree

> -----Original Message-----
> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@eric= sson.com]
> Sent: Thursday, July 10, 2003 10:55 AM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: 'maria.c.belinchon@ericsson.com'; = 'aaa-wg@merit.edu'
> Subject: Re: Comments: = draft-belinchon-aaa-diameter-mm-app-01.txt
>
>
>
>
> Jayshree Bharatia wrote:
> >
> >
>
> > [JB] As I have indicated in my earlier = email, we may not
> need both the
> > functionality (mentioned as points a and b = in your reply)
> at all of the
> > time. So it will be good if you can = replace MUST to SHOULD in the
> > following quote of section 5.2.
> >
> > "When the authorization procedure = succeeds, the Diameter server
> > constructs a User-Authorization-Answer = (UAA) message that
> MUST include
> > either the address of the SIP server = already assigned to
> the user or the
> > capabilities needed by the SIP server = (Diameter client) to select
> > another SIP server for the = user."
> >
>
> Jayshree, I am trying to find out the = applicability of your
> comment. It
> would be good to understand the scenario you = are thinking of.
> As far as I
> understand, you are saying that there may be a = third scenario
> where the SIP
> proxy is just interesting in the User = Authorization but not in doing
> further routing. Is this correct?
>
> If it is, I think it is a dangerous scenario, = because the SIP
> proxy will
> not be able to determine whether the request = has to be routed
> to another
> proxy or not. So if you have a scenario in = mind, it would be nice to
> understanding.
>
[JB] My scenario is simple where only authorization = of the user is required. The problem I see in the current document is = that you are tying the authorization with the routing. And my = suggestion is provide an option so that if someone wants to use UAR/UAA = just for the authorization it will still be possible.

> Further more, your proposal to downgrade the = "MUST" to a
> "SHOULD" does not
> help, because from what I understand from your = comments, what
> you want is
> to deploy SIP servers that do no have the = server allocation
> functionality.
> If that is the case, writing normative text to = the Diameter
> server will not
> help.

[JB] Why do you think that writing normative text to = the Diameter server will not help? You are still using the AAA server = for authorizing the user.

>
> /Miguel
>
>
> --
> Miguel-Angel = Garcia           =           Oy LM Ericsson = AB
>          = ;            = ;            = ;        Jorvas, Finland
> mailto:Miguel.A.Garcia@eric= sson.com     Phone:  +358 9 299 = 3553
> mailto:Miguel.A.Garcia@piuha.n= et        Mobile: +358 40 = 5140002
>
>
>
>
>
>

------_=_NextPart_001_01C34707.5400FD40-- From owner-aaa-wg@merit.edu Fri Jul 11 03:10:44 2003 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 DAA18922 for ; Fri, 11 Jul 2003 03:10:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4868891279; Fri, 11 Jul 2003 03:10:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 367039127A; Fri, 11 Jul 2003 03:10:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A69F191279 for ; Fri, 11 Jul 2003 03:10:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 727455DDB8; Fri, 11 Jul 2003 03:10:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id 8EA7D5DDAD for ; Fri, 11 Jul 2003 03:10:03 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6B7A2GJ021473; Fri, 11 Jul 2003 09:10:02 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8XJPR9P; Fri, 11 Jul 2003 09:10:02 +0200 Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.31.68]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h6B7A1SZ019168; Fri, 11 Jul 2003 10:10:01 +0300 (EET DST) Message-ID: <3F0E62C9.6040900@ericsson.com> Date: Fri, 11 Jul 2003 10:10:01 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" Organization: Ericsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: es,en MIME-Version: 1.0 To: Jayshree Bharatia Cc: "'maria.c.belinchon@ericsson.com'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Re: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt References: <870397D7C140C84DB081B88396458DAF746A5D@zrc2c000.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Inline as well. Jayshree Bharatia wrote: > Hello Miguel, > > Please see my reply inline. > > Thanks, > Jayshree > > > -----Original Message----- > > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > > Sent: Thursday, July 10, 2003 10:55 AM > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > Cc: 'maria.c.belinchon@ericsson.com'; 'aaa-wg@merit.edu' > > Subject: Re: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt > > > > > > > > > > Jayshree Bharatia wrote: > > > > > > > > > > > [JB] As I have indicated in my earlier email, we may not > > need both the > > > functionality (mentioned as points a and b in your reply) > > at all of the > > > time. So it will be good if you can replace MUST to SHOULD in the > > > following quote of section 5.2. > > > > > > "When the authorization procedure succeeds, the Diameter server > > > constructs a User-Authorization-Answer (UAA) message that > > MUST include > > > either the address of the SIP server already assigned to > > the user or the > > > capabilities needed by the SIP server (Diameter client) to select > > > another SIP server for the user." > > > > > > > Jayshree, I am trying to find out the applicability of your > > comment. It > > would be good to understand the scenario you are thinking of. > > As far as I > > understand, you are saying that there may be a third scenario > > where the SIP > > proxy is just interesting in the User Authorization but not in doing > > further routing. Is this correct? > > > > If it is, I think it is a dangerous scenario, because the SIP > > proxy will > > not be able to determine whether the request has to be routed > > to another > > proxy or not. So if you have a scenario in mind, it would be nice to > > understanding. > > > [JB] My scenario is simple where only authorization of the user is > required. The problem I see in the current document is that you are > tying the authorization with the routing. And my suggestion is provide > an option so that if someone wants to use UAR/UAA just for the > authorization it will still be possible. So the scenario you are thinking is just a SIP server that will require an authorization to provide a service (e.g., initiate a session) to a particular user. And that SIP server is no longer intersted on further routing, perhaps because the SIP server is configured as an outbound proxy. That sounds like a real scenario that we need to take care of. I suspect that the SIP server should have an indication (perhaps in an AVP) requesting routing information to the Diameter server or not. > > > Further more, your proposal to downgrade the "MUST" to a > > "SHOULD" does not > > help, because from what I understand from your comments, what > > you want is > > to deploy SIP servers that do no have the server allocation > > functionality. > > If that is the case, writing normative text to the Diameter > > server will not > > help. > > [JB] Why do you think that writing normative text to the Diameter server > will not help? You are still using the AAA server for authorizing the user. Yes, for authorizing the user it is ok. But the SIP server should be able to either request routing information or not. I mean, it does no help if the Diameter server includes routing information and the SIP server does not care or viceversa. That's the reason why I think that just downgrading the MUST to a SHOULD in the Diameter server normative text will not help. But I am convinced of a new AVP that the SIP server will use to request routing information. If requested, the Diameter server SHOULD return MUST return either the address of another SIP server or service capabilities selection data. -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 From owner-aaa-wg@merit.edu Fri Jul 11 10:12:17 2003 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 KAA00504 for ; Fri, 11 Jul 2003 10:12:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0C2B29127F; Fri, 11 Jul 2003 10:12:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D015791280; Fri, 11 Jul 2003 10:12:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D8C6C9127F for ; Fri, 11 Jul 2003 10:12:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE0105DDD1; Fri, 11 Jul 2003 10:12:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id 664255DDD0 for ; Fri, 11 Jul 2003 10:12:01 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6BEBvq24344; Fri, 11 Jul 2003 09:11:57 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jul 2003 09:11:57 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746A5F@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Miguel A. Garcia'" Cc: "'maria.c.belinchon@ericsson.com'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: RE: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt Date: Fri, 11 Jul 2003 09:11:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C347B6.61B988F8" 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_01C347B6.61B988F8 Content-Type: text/plain Hello Miguel, Looks like we are in sort of agreement now. Please see my response inline. Regards, Jayshree > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Friday, July 11, 2003 2:10 AM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: 'maria.c.belinchon@ericsson.com'; 'aaa-wg@merit.edu' > Subject: Re: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt > > > Inline as well. > > Jayshree Bharatia wrote: > > Hello Miguel, > > > > Please see my reply inline. > > > > Thanks, > > Jayshree > > > > > -----Original Message----- > > > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > > > Sent: Thursday, July 10, 2003 10:55 AM > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > Cc: 'maria.c.belinchon@ericsson.com'; 'aaa-wg@merit.edu' > > > Subject: Re: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt > > > > > > > > > > > > > > > Jayshree Bharatia wrote: > > > > > > > > > > > > > > > [JB] As I have indicated in my earlier email, we may > not > need > > both the > > functionality (mentioned as points a and b in your > > reply) > at all of the > > > > time. So it will be good if you can replace MUST to > SHOULD in the > > > > following quote of section 5.2. > > > > > > > > "When the authorization procedure succeeds, the Diameter server > > > > constructs a User-Authorization-Answer (UAA) message that > > > MUST include > > > > either the address of the SIP server already assigned to > > > the user or the > > > > capabilities needed by the SIP server (Diameter > client) to select > > > > another SIP server for the user." > > > > > > > > > > Jayshree, I am trying to find out the applicability of your > > > comment. It > > > would be good to understand the scenario you are thinking of. > > > As far as I > > > understand, you are saying that there may be a third scenario > > > where the SIP > > > proxy is just interesting in the User Authorization but > not in doing > > > further routing. Is this correct? > > > > > > If it is, I think it is a dangerous scenario, because the SIP > > > proxy will > > > not be able to determine whether the request has to be routed > > > to another > > > proxy or not. So if you have a scenario in mind, it > would be nice to > > > understanding. > > > > > [JB] My scenario is simple where only authorization of the user is > > required. The problem I see in the current document is that you are > > tying the authorization with the routing. And my suggestion > is provide > > an option so that if someone wants to use UAR/UAA just for the > > authorization it will still be possible. > > > > So the scenario you are thinking is just a SIP server that > will require an > authorization to provide a service (e.g., initiate a session) to a > particular user. And that SIP server is no longer intersted > on further > routing, perhaps because the SIP server is configured as an > outbound proxy. > > That sounds like a real scenario that we need to take care > of. I suspect > that the SIP server should have an indication (perhaps in an AVP) > requesting routing information to the Diameter server or not. > > > [JB] Yes. This can be one of the solution. > > > > > Further more, your proposal to downgrade the "MUST" to a > > > "SHOULD" does not > > > help, because from what I understand from your comments, what > > > you want is > to deploy SIP servers that do no have the server > > allocation > functionality. > > > If that is the case, writing normative text to the Diameter > > > server will not > > > help. > > > > [JB] Why do you think that writing normative text to the Diameter > > server > > will not help? You are still using the AAA server for > authorizing the user. > > > Yes, for authorizing the user it is ok. But the SIP server > should be able > to either request routing information or not. I mean, it does > no help if > the Diameter server includes routing information and the SIP > server does > not care or viceversa. That's the reason why I think that > just downgrading > the MUST to a SHOULD in the Diameter server normative text > will not help. > > But I am convinced of a new AVP that the SIP server will use > to request > routing information. If requested, the Diameter server SHOULD > return MUST > return either the address of another SIP server or service > capabilities > selection data. > > [JB] Based on the current text, I thought changing "MUST" to "SHOULD" might be the easiest solution. But seems like you may have cleaner way of supporting the authorization only functionality. > > > -- > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 > > > > > > ------_=_NextPart_001_01C347B6.61B988F8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt

Hello Miguel,

Looks like we are in sort of agreement now. Please = see my response inline.

Regards,
Jayshree

> -----Original Message-----
> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@eric= sson.com]
> Sent: Friday, July 11, 2003 2:10 AM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: 'maria.c.belinchon@ericsson.com'; = 'aaa-wg@merit.edu'
> Subject: Re: Comments: = draft-belinchon-aaa-diameter-mm-app-01.txt
>
>
> Inline as well.
>
> Jayshree Bharatia wrote:
> > Hello Miguel,
> >
> > Please see my reply inline.
> >
> > Thanks,
> > Jayshree
> >
> >  > -----Original = Message-----
> >  > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@eric= sson.com]
> >  > Sent: Thursday, July 10, 2003 = 10:55 AM
> >  > To: Bharatia, Jayshree = [RICH1:2H13:EXCH]
> >  > Cc: = 'maria.c.belinchon@ericsson.com'; 'aaa-wg@merit.edu'
> >  > Subject: Re: Comments: = draft-belinchon-aaa-diameter-mm-app-01.txt
> >  >
> >  >
> >  >
> >  >
> >  > Jayshree Bharatia wrote:
> >  > >
> >  > >
> >  >
> >  > > [JB] As I have indicated = in my earlier email, we may
> not  > need
> > both the  > > functionality = (mentioned as points a and b in your
> > reply)  > at all of the
> >  > > time. So it will be good = if you can replace MUST to
> SHOULD in the
> >  > > following quote of section = 5.2.
> >  > >
> >  > > "When the = authorization procedure succeeds, the Diameter server
> >  > > constructs a = User-Authorization-Answer (UAA) message that
> >  > MUST include
> >  > > either the address of the = SIP server already assigned to
> >  > the user or the
> >  > > capabilities needed by the = SIP server (Diameter
> client) to select
> >  > > another SIP server for the = user."
> >  > >
> >  >
> >  > Jayshree, I am trying to find = out the applicability of your
> >  > comment. It
> >  > would be good to understand the = scenario you are thinking of.
> >  > As far as I
> >  > understand, you are saying that = there may be a third scenario
> >  > where the SIP
> >  > proxy is just interesting in = the User Authorization but
> not in doing
> >  > further routing. Is this = correct?
> >  >
> >  > If it is, I think it is a = dangerous scenario, because the SIP
> >  > proxy will
> >  > not be able to determine = whether the request has to be routed
> >  > to another
> >  > proxy or not. So if you have a = scenario in mind, it
> would be nice to
> >  > understanding.
> >  >
> > [JB] My scenario is simple where only = authorization of the user is
> > required. The problem I see in the current = document is that you are
> > tying the authorization with the routing. = And my suggestion
> is provide
> > an option so that if someone wants to use = UAR/UAA just for the
> > authorization it will still be = possible.
>
>
> <miguel>
> So the scenario you are thinking is just a SIP = server that
> will require an
> authorization to provide a service (e.g., = initiate a session) to a
> particular user. And that SIP server is no = longer intersted
> on further
> routing, perhaps because the SIP server is = configured as an
> outbound proxy.
>
> That sounds like a real scenario that we need = to take care
> of. I suspect
> that the SIP server should have an indication = (perhaps in an AVP)
> requesting routing information to the Diameter = server or not.
>
> </miguel>
>
[JB] Yes. This can be one of the solution.

> >
> >  > Further more, your proposal to = downgrade the "MUST" to a
> >  > "SHOULD" does = not
> >  > help, because from what I = understand from your comments, what  >
> > you want is  > to deploy SIP = servers that do no have the server
> > allocation  > = functionality.
> >  > If that is the case, writing = normative text to the Diameter
> >  > server will not
> >  > help.
> >
> > [JB] Why do you think that writing = normative text to the Diameter
> > server
> > will not help? You are still using the AAA = server for
> authorizing the user.
>
> <miguel>
> Yes, for authorizing the user it is ok. But the = SIP server
> should be able
> to either request routing information or not. I = mean, it does
> no help if
> the Diameter server includes routing = information and the SIP
> server does
> not care or viceversa. That's the reason why I = think that
> just downgrading
> the MUST to a SHOULD in the Diameter server = normative text
> will not help.
>
> But I am convinced of a new AVP that the SIP = server will use
> to request
> routing information. If requested, the Diameter = server SHOULD
> return MUST
> return either the address of another SIP server = or service
> capabilities
> selection data.
>
> </miguel>

[JB] Based on the current text, I thought changing = "MUST" to "SHOULD" might be the easiest solution. = But seems like you may have cleaner way of supporting the authorization = only functionality.

>
>
> --
> Miguel-Angel = Garcia           =           Oy LM Ericsson = AB
>          = ;            = ;            = ;        Jorvas, Finland
> mailto:Miguel.A.Garcia@eric= sson.com     Phone:  +358 9 299 = 3553
> mailto:Miguel.A.Garcia@piuha.n= et        Mobile: +358 40 = 5140002
>
>
>
>
>
>

------_=_NextPart_001_01C347B6.61B988F8-- From owner-aaa-wg@merit.edu Fri Jul 11 14:16:42 2003 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 OAA08870 for ; Fri, 11 Jul 2003 14:16:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9845F91282; Fri, 11 Jul 2003 14:15:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 69D8791283; Fri, 11 Jul 2003 14:15:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AFD6491282 for ; Fri, 11 Jul 2003 14:15:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E3D335DD9C; Fri, 11 Jul 2003 14:15:41 -0400 (EDT) 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 A1BEC5DD90 for ; Fri, 11 Jul 2003 14:15:41 -0400 (EDT) Received: (cpmta 3721 invoked from network); 11 Jul 2003 11:15:40 -0700 Received: from 24.61.72.177 (HELO djmlap.mitton.com) by smtp.mitton.com (209.228.32.64) with SMTP; 11 Jul 2003 11:15:40 -0700 X-Sent: 11 Jul 2003 18:15:40 GMT Message-Id: <5.2.1.1.2.20030711140826.00a622c0@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 11 Jul 2003 14:12:46 -0400 To: aaa-wg@merit.edu From: David Mitton Subject: [AAA-WG]: Issues 403, 405, 406 - Closed in Nasreq draft 11 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Bernard, If you are keeping the Issues page up-to-date http://www.drizzle.com/~aboba/AAA/issues.html I believe that I addressed and/or incorporated issues 403, 405, and 406 in Nasreq draft 11. I did post emails if you wish to point at the archives. Dave. From owner-aaa-wg@merit.edu Fri Jul 11 14:17:32 2003 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 OAA08907 for ; Fri, 11 Jul 2003 14:17:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D6ADC91281; Fri, 11 Jul 2003 14:15:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E2CE91284; Fri, 11 Jul 2003 14:15:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7B08091281 for ; Fri, 11 Jul 2003 14:15:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4DA715DD96; Fri, 11 Jul 2003 14:15:41 -0400 (EDT) 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 CBDBC5DD90 for ; Fri, 11 Jul 2003 14:15:40 -0400 (EDT) Received: (cpmta 3655 invoked from network); 11 Jul 2003 11:15:36 -0700 Received: from 24.61.72.177 (HELO djmlap.mitton.com) by smtp.mitton.com (209.228.32.64) with SMTP; 11 Jul 2003 11:15:36 -0700 X-Sent: 11 Jul 2003 18:15:36 GMT Message-Id: <5.2.1.1.2.20030711140032.00a5f2a0@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 11 Jul 2003 14:06:13 -0400 To: aaa-wg@merit.edu From: David Mitton Subject: [AAA-WG]: Issue 402 - Closing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Issues #402: JARI: Comments marked with "JARI:" DJM: Responses marked with "DJM:" major snips to document marked with "..." 1.2. Advertising Application Support . . . . . . . . . . . . . . . 6 JARI: A terms section might be useful. NAS, ARAP, IPX, CHAP, PAP etc. DJM: Added. 2. NAS Calls, Ports, and Sessions . . . . . . . . . . . . . . . . . 6 JARI: Looking at the contents list, it might make sense to change the section titles from "NAS " to simply ""? What do you think? DJM: I like the "NAS". At least it is a simplification from previously, everything was NASREQ. ... 2.1. Diameter Session Establishment When the authentication or authorization exchange completes successfully, the NAS application SHOULD start a session context, and MAY send an Accounting START_RECORD message [Base]. The failure to JARI: The MAY above is a bit weak? Is this a configuration issue again, or are NASes generally allowed to skip accounting if they feel like it? ;-) DJM: Yes, I've reworded this per your later comments. Accounting should not be skipped if implemented, but the spec doesn't require the capability either. JARI: Is there an AVP which holds the type of failure? Or are all EVENT_RECORD messages for this particular error? DJM: Yes, typically Termination-Cause, but it depends on the error. 2.2. Diameter Session Re-Authentication or Re-Authorization ... JARI: Is this always possible? I think it is possible on PPP, but perhaps there are other access types for which it might not be possible. Is re-auth possible on all types of WLAN links? DJM: Maybe, maybe not. The feature is here, because it is possible on some services. JARI: While re-auth is going on, can service still be provided? DJM: That too would be service specific. JARI: Shouldn't we somehow take in account also Accounting-Realtime-Required AVP from base? DJM: A Note: is added. More information on Diameter Session Termination is in [Base] section 8.4. 3.1. AA-Request (AAR) Command The AA-Request message (AAR), indicated by the Command-Code field set to 265 and the 'R' bit set in the Command Flags field, is used in order to request authentication and/or authorization for a given NAS user. The type of request is identified through the Auth-Request-Type AVP, and the default mode is both authentication and authorization. JARI: Default... hmm... does this mean Auth-Request-Type AVP is optional? Base 8.7 does not talk about this. Please clarify. Suggestion: don't talk about defaults. DJM: On some AAR messages it is. Because this message is used for Multi-round exchanges, many AVPs are not used in all cases. I believe that the use of a default is obvious. It also helps with translation issues. ... 8. NAS Accounting JARI: Earlier in the document there was some confusion about when accounting messages should be sent. DJM: This description and the earlier Session description have been redone. Authentication or Authorization transaction and at the end of a Session. The Accounting-Record-Type value indicates the type of event. All other AVPs identify the session and provide additional information relevant to the event. If Authentication and Authorization are contained in one message (typical case), then one START_RECORD should be sent. If Authentication and Authorization occur in seperate transactions, the first message should generate a START_RECORD, and the later, an INTERIM_RECORD. For a given session, there should only be one set of matching START and STOP records, with any number of INTERIM_RECORDS in between, or one EVENT_RECORD. JARI: Compare to Section 2.1. I'm not sure I understand what "failure to start a session" exactly means, but let's assume we do a successful authentication, successful authorization, and the "fail to start a session". It would be incorrect in this case to send START_RECORD, INTERIM_RECORD, EVENT_RECORD, as seems to be indicated by 2.1. Suggestion: make 2.1 inline with the text here. DJM: Your example is indeed incorrect. Every START_RECORD MUST be paired with a STOP_RECORD. EVENT_RECORDs are for non-session events. This text and others related have been rewritten. ... The corresponding Diameter response is always guaranteed to be received by the same Translation Agent that translated the original request, due to the contents of the Origin-Host AVP in the Diameter request. The following steps are applied to the response message during the Diameter to RADIUS translation: - If the Diameter Command-Code is set to AA-Answer and the Result- Code AVP is set to DIAMETER_MULTI_ROUND_AUTH, the gateway must send a RADIUS Access-Challenge with the Diameter Session-Id and the Origin-Host AVPs encapsulated in the RADIUS State attribute, with the prefix "Diameter/". This is necessary in order to ensure that the Translation Agent that will receive the subsequent RADIUS Access-Request will have access to the Session Identifier, and be able to set the Destination-Host to the correct value. If the Multi-Round-Time-Out AVP is present, the value of the AVP MUST be inserted in the RADIUS Session-Timeout AVP. - If the Command-Code is set to AA-Answer, the Diameter Session-Id AVP is saved in a new RADIUS Class attribute, whose format consists of the string "Diameter/" followed by the Diameter Session Identifier. This will ensure that the subsequent Accounting messages, which could be received by any Translation Agent, would have access to the original Diameter Session Identifier. - If a Proxy-State attribute was present in the RADIUS request, the same attribute is added in the response. This information may be found in the Proxy-Info AVP group, or in a local state table. - 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. JARI: Question: Does the above rules work even in a situation where there's been a change to another translation agent due to load balancing or a fault? DJM: I'm not sure. That would depend on how such a handover was implemented, and this spec does not describe or specify such behavior even for non-RADIUS cases. ... 10.1. AA-Request/Answer AVP Table The table in this section is limited to the Command Codes defined in this specification. JARI: I don't understand the above comment. Remove? DJM: This is needed. I have improved the text. ... 10.2.1. Accounting Framed Access AVP Table JARI: I don't fully understand the construction of this table vs. the one in the base spec. The above attribute, for instance, is included but not discussed in this specification. But some other base attributes such as Auth-Application-Id are not included. Is this an old version of the base table, with the NASREQ additions? May I suggest taking a new version from base-17...? DJM: Please name any other AVPs not included? Are they required for all Accounting applications? Do they have application for NASreq? I will include them. The BASE does not, and cannot describe this application, I must. This application uses Base AVPs, how it uses them (not what they are) must be described here, even if it's just an inclusion that says it's allowable. I have added more verbage to make these tables self explanatory. ... 12. Security Considerations The security considerations of the Diameter protocol itself have been discussed in [Base]. This document does not contain a security protocol, but does discuss how PPP authentication protocols can be carried within the Diameter protocol. The PPP authentication protocols that are described are PAP and CHAP. The use of PAP SHOULD be discouraged, since it exposes user's passwords to possibly non-trusted entities. However, PAP is also frequently used for use with One-Time Passwords (OTP), which do not expose a security risk. This document also describes how CHAP can be carried within the Diameter protocol, which is required for RADIUS backward compatibility. The CHAP protocol, as used in a RADIUS environment, facilitates authentication replay attacks. JARI: Any references to the attacks discussed above? JARI: Maybe there should be some discussion of what it implies if authorization-only AAA requests are made, and in which cases such usage is safe. DJM: Submissions are welcome. JARI: What are the security impacts of RADIUS-DIAMETER translation? Are all or only some of the known radius vulnerabilities carried onto DIAMETER in such a setup? See reference "Joshua Hill. An Analysis of the RADIUS Authentication Protocol. http://www.untruth.org/~josh/security/radius/, 2001." DJM: I have read that document in the past, however, we have tried to document the Diameter NAS Application protocol in this document, and avoided including a full treatis on Diameter/RADIUS how-to build a gateway. This really requires another document. If I could make it relate to my job (what's that?) I'd write it myself. From owner-aaa-wg@merit.edu Fri Jul 11 14:17:42 2003 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 OAA08955 for ; Fri, 11 Jul 2003 14:17:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1EE9A91283; Fri, 11 Jul 2003 14:16:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2BD191288; Fri, 11 Jul 2003 14:16:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 07EC691283 for ; Fri, 11 Jul 2003 14:16:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D6DAA5DD9C; Fri, 11 Jul 2003 14:16:07 -0400 (EDT) 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 948C75DD90 for ; Fri, 11 Jul 2003 14:16:07 -0400 (EDT) Received: (cpmta 4085 invoked from network); 11 Jul 2003 11:16:04 -0700 Received: from 24.61.72.177 (HELO djmlap.mitton.com) by smtp.mitton.com (209.228.32.64) with SMTP; 11 Jul 2003 11:16:04 -0700 X-Sent: 11 Jul 2003 18:16:04 GMT Message-Id: <5.2.1.1.2.20030711140429.036fcb80@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 11 Jul 2003 14:06:03 -0400 To: aaa-wg@merit.edu From: David Mitton Subject: [AAA-WG]: Issue 404 - Closing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 404: NASREQ-11 Issues Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: March 11, 2003 Section 4.l0 " 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." This contradicts Section 2.2, which says that the Authorization-Lifetime AVP SHOULD NOT be used with RADIUS clients. The only alternative is to use Session-Timeout and Termination-Action, but that doesn't do the job, since the meaning has been changed. This leaves a Diameter server incapable of communicating that it would like a RADIUS client to re-authenticate at a given interval. The suggested fix is to change the meaning of Termination-Action so that it is compatible with RADIUS. DJM: - change Termination-Action, so that it does not require the resetting Session-ID and sending STR. more consistent with RADIUS - Rework Auth-Lifetime description so it offers gwy solutions - Add to RADIUS interactions section, what to do with A-L AVP --- 9.1.something... " - The Diameter Origin-Host and Origin-Realm AVPs MUST be created and added using the information from the NAS-Identifier attribute, and/or the FQDN corresponding to the NAS-IP-Address attribute. The AAA protocol specified in the identity would be set to "RADIUS"." I think that the FQDN corresponding to the NAS-IP-Address is preferred, if available. DJM: Okay, done. 9.1.1 " - The Origin-Host AVP's value is inserted in the NAS-Identifier attribute." How about also supporting translation of Origin-Host AVP to NAS-IP-Address or NAS-IPv6-Adddress? DJM: This is a server response. The NAS id information is not present in the RADIUS message. I have reworked this section to make it clearer. The information must either be saved at request time or derived from context. 9.5.2 " The Diameter AVP will consist of the following fields; Diameter Flags: V=1, M=0, P=0 Diameter Vendor code = RADIUS VSA Vendor code Diameter AVP code = RADIUS VSA Vendor type code Diameter AVP length = length of AVP (header + data + padding) Diameter Data = RADIUS VSA vendor data If the RADIUS receiving code knows of vendor specific fields interpretations for the specific vendor, it may employ them to parse an extended AVP code or data length, Otherwise the recommended standard fields will be used. Nested Multiple vendor data fields MUST be expanded into multiple Diameter AVPs." Forwarding a RADIUS Vendor-Specific AVP as non-mandatory could be dangerous in some circumstances, such as when a proprietary filter or key attribute is included. I'd suggest setting M=1 by default. DJM: Hmmm... this is a toughie. I agree with your intent, but I think in practice some RADIUS services are used to sending a scattershot VSA list that covers all of their configured vendors. They know the equipment will ignore the unrecognized attributes. Funk's SBR takes a slightly more sophisticated approach in that it will filter VSAs in the response profile from in the Access Response message if it knows the NAS vendor type (by configuration). This would be a good filter option for a gateway. Well maybe if we default mandatory, but allow local modification? 13.1 DJM: I'm sure there are a number of drafts to update in this section. A couple documents have gone to RFC now too. I will do this as a last pass before the next submission. Additional comments I believe that it would be useful to talk about translation of unsolicited disconnect or change of filters messages to their RADIUS equivalents, defined in [DynAuth]. DJM: DynAuth support is optional. Should be treated like server-initiated AAR, with RE-Auth=X - RADIUS message (per Chiba) translated or processed as above - Response translated From owner-aaa-wg@merit.edu Fri Jul 11 15:17:28 2003 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 PAA12105 for ; Fri, 11 Jul 2003 15:17:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 53D6C91284; Fri, 11 Jul 2003 15:17:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D5A991285; Fri, 11 Jul 2003 15:17:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4535391284 for ; Fri, 11 Jul 2003 15:17:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 26EF45DDCF; Fri, 11 Jul 2003 15:17:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep20-app.kolumbus.fi (fep20-0.kolumbus.fi [193.229.0.47]) by segue.merit.edu (Postfix) with ESMTP id 50B4E5DDCD for ; Fri, 11 Jul 2003 15:17:04 -0400 (EDT) Received: from kolumbus.fi ([62.248.149.3]) by fep20-app.kolumbus.fi with ESMTP id <20030711191702.GYGF20713.fep20-app.kolumbus.fi@kolumbus.fi>; Fri, 11 Jul 2003 22:17:02 +0300 Message-ID: <3F0F0C95.5040004@kolumbus.fi> Date: Fri, 11 Jul 2003 22:14:29 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Mitton Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 402 - Closing References: <5.2.1.1.2.20030711140032.00a5f2a0@getmail.mitton.com> In-Reply-To: <5.2.1.1.2.20030711140032.00a5f2a0@getmail.mitton.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit David Mitton wrote: > Issues #402: > > JARI: Comments marked with "JARI:" DJM: Responses marked with "DJM:" major > snips to document marked with "..." > > > 1.2. Advertising Application Support . . . . . . . . . . . . . . . 6 > > JARI: A terms section might be useful. NAS, ARAP, IPX, CHAP, PAP etc. > DJM: Added. > Great! > 2. NAS Calls, Ports, and Sessions . . . . . . . . . . . . . . . . . 6 > > JARI: Looking at the contents list, it might make sense to change the > section titles from "NAS " to simply ""? > What do you think? > > DJM: I like the "NAS". At least it is a simplification from previously, > everything was NASREQ. > > ... No problem. > 2.1. Diameter Session Establishment > > When the authentication or authorization exchange completes > successfully, the NAS application SHOULD start a session context, and > MAY send an Accounting START_RECORD message [Base]. The failure to > > JARI: The MAY above is a bit weak? Is this a configuration issue > again, or are NASes generally allowed to skip accounting > if they feel like it? ;-) > DJM: Yes, I've reworded this per your later comments. > Accounting should not be skipped if implemented, but the spec > doesn't require the capability either. Is this is in the latest document or on some private version? I agree with what you say above. But I wonder if there should be some words about configuration as well. If you implement it, you may not in all cases need accounting. > JARI: Is there an AVP which holds the type of failure? Or are all > EVENT_RECORD messages for this particular error? > > DJM: Yes, typically Termination-Cause, but it depends on the error. Ok. Is this described now somewhere? > 2.2. Diameter Session Re-Authentication or Re-Authorization > > > ... > JARI: Is this always possible? I think it is possible on PPP, but > perhaps there are other access types for which it might not > be possible. Is re-auth possible on all types of WLAN > links? > DJM: Maybe, maybe not. The feature is here, because it is possible on > some services. > > JARI: While re-auth is going on, can service still be provided? > DJM: That too would be service specific. Ok. Are there words warning about the above in the latest version? > JARI: Shouldn't we somehow take in account also > Accounting-Realtime-Required AVP from base? > > DJM: A Note: is added. Great! > More information on Diameter Session Termination is in [Base] section > 8.4. > > > 3.1. AA-Request (AAR) Command > > The AA-Request message (AAR), indicated by the Command-Code field set > to 265 and the 'R' bit set in the Command Flags field, is used in > order to request authentication and/or authorization for a given NAS > user. The type of request is identified through the Auth-Request-Type > AVP, and the default mode is both authentication and authorization. > > JARI: Default... hmm... does this mean Auth-Request-Type AVP > is optional? Base 8.7 does not talk about this. Please > clarify. Suggestion: don't talk about defaults. > > DJM: On some AAR messages it is. Because this message is used for > Multi-round exchanges, many AVPs are not used in all cases. > I believe that the use of a default is obvious. It also helps with > translation issues. > ... Ok. > 8. NAS Accounting > > JARI: Earlier in the document there was some confusion about when > accounting messages should be sent. > DJM: This description and the earlier Session description have been > redone. > > Authentication or Authorization transaction and at the end of a > Session. The Accounting-Record-Type value indicates the type of > event. All other AVPs identify the session and provide additional > information relevant to the event. > > If Authentication and Authorization are contained in one message > (typical case), then one START_RECORD should be sent. If > Authentication and Authorization occur in seperate transactions, the > first message should generate a START_RECORD, and the later, an > INTERIM_RECORD. For a given session, there should only be one set of > matching START and STOP records, with any number of INTERIM_RECORDS > in between, or one EVENT_RECORD. Ok. > JARI: Compare to Section 2.1. I'm not sure I understand what "failure > to start a session" exactly means, but let's assume we do a > successful authentication, successful authorization, and the > "fail to start a session". It would be incorrect in this case to > send START_RECORD, INTERIM_RECORD, EVENT_RECORD, as seems to be > indicated by 2.1. Suggestion: make 2.1 inline with the text > here. > DJM: Your example is indeed incorrect. Every START_RECORD MUST be > paired with a STOP_RECORD. EVENT_RECORDs are for non-session > events. > This text and others related have been rewritten. Great, thanks! > ... > The corresponding Diameter response is always guaranteed to be > received by the same Translation Agent that translated the original > request, due to the contents of the Origin-Host AVP in the Diameter > request. The following steps are applied to the response message > during the Diameter to RADIUS translation: > > - If the Diameter Command-Code is set to AA-Answer and the Result- > Code AVP is set to DIAMETER_MULTI_ROUND_AUTH, the gateway must > send a RADIUS Access-Challenge with the Diameter Session-Id and > the Origin-Host AVPs encapsulated in the RADIUS State attribute, > with the prefix "Diameter/". This is necessary in order to > ensure that the Translation Agent that will receive the > subsequent RADIUS Access-Request will have access to the Session > Identifier, and be able to set the Destination-Host to the > correct value. If the Multi-Round-Time-Out AVP is present, the > value of the AVP MUST be inserted in the RADIUS Session-Timeout > AVP. > - If the Command-Code is set to AA-Answer, the Diameter Session-Id > AVP is saved in a new RADIUS Class attribute, whose format > consists of the string "Diameter/" followed by the Diameter > Session Identifier. This will ensure that the subsequent > Accounting messages, which could be received by any Translation > Agent, would have access to the original Diameter Session > Identifier. > - If a Proxy-State attribute was present in the RADIUS request, > the same attribute is added in the response. This information > may be found in the Proxy-Info AVP group, or in a local state > table. > - 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. Ok. > JARI: Question: Does the above rules work even in a situation where > there's been a change to another translation agent due to > load balancing or a fault? > DJM: I'm not sure. That would depend on how such a handover was > implemented, and this spec does not describe or specify such > behavior even for non-RADIUS cases. Ok. But maybe the limitation should be documented. > ... > 10.1. AA-Request/Answer AVP Table > > The table in this section is limited to the Command Codes defined in > this specification. > > JARI: I don't understand the above comment. Remove? > DJM: This is needed. I have improved the text. > Ok. > ... > 10.2.1. Accounting Framed Access AVP Table > > JARI: I don't fully understand the construction of this table > vs. the one in the base spec. The above attribute, > for instance, is included but not discussed in this > specification. But some other base attributes such > as Auth-Application-Id are not included. Is this > an old version of the base table, with the NASREQ > additions? May I suggest taking a new version from > base-17...? > > DJM: Please name any other AVPs not included? Are they required for all > Accounting applications? Do they have application for NASreq? I > will include them. > > The BASE does not, and cannot describe this application, I must. > This application uses Base AVPs, how it uses them (not what they > are) must be described here, even if it's just an inclusion that > says it's allowable. I have added more verbage to make > these tables self explanatory. I'll have to take a more detailed look at this later. What you say makes sense. I'll try to do a check of the tables. > ... > 12. Security Considerations > > The security considerations of the Diameter protocol itself have > been discussed in [Base]. > > This document does not contain a security protocol, but does discuss > how PPP authentication protocols can be carried within the Diameter > protocol. The PPP authentication protocols that are described are PAP > and CHAP. > > The use of PAP SHOULD be discouraged, since it exposes user's > passwords to possibly non-trusted entities. However, PAP is also > frequently used for use with One-Time Passwords (OTP), which do not > expose a security risk. > > This document also describes how CHAP can be carried within the > Diameter protocol, which is required for RADIUS backward > compatibility. The CHAP protocol, as used in a RADIUS environment, > facilitates authentication replay attacks. > > JARI: Any references to the attacks discussed above? > > JARI: Maybe there should be some discussion of what it implies > if authorization-only AAA requests are made, and in which > cases such usage is safe. > DJM: Submissions are welcome. The one below may be sufficient for the second attack. 2869bis talks about some of the PAP attacks, though not the one discussed above. A ten minute search to the net on PAP attacks did not reveal anything interesting. Maybe its too obvious. > JARI: What are the security impacts of RADIUS-DIAMETER translation? > Are all or only some of the known radius vulnerabilities carried > onto DIAMETER in such a setup? See reference "Joshua Hill. An > Analysis of the RADIUS Authentication Protocol. > http://www.untruth.org/~josh/security/radius/, 2001." > > DJM: I have read that document in the past, however, we have tried > to document the Diameter NAS Application protocol in this document, and > avoided including a full treatis on Diameter/RADIUS how-to build a > gateway. This really requires another document. If I could make it > relate to my job (what's that?) I'd write it myself. Ok. --Jari From owner-aaa-wg@merit.edu Fri Jul 11 15:31:28 2003 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 PAA13069 for ; Fri, 11 Jul 2003 15:31:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BEF2591286; Fri, 11 Jul 2003 15:30:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 909D391289; Fri, 11 Jul 2003 15:30:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8CBD991286 for ; Fri, 11 Jul 2003 15:30:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 78AC95DDA3; Fri, 11 Jul 2003 15:30:54 -0400 (EDT) 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 EA1E95DD9C for ; Fri, 11 Jul 2003 15:30:53 -0400 (EDT) Received: (cpmta 9850 invoked from network); 11 Jul 2003 12:30:52 -0700 Received: from 24.61.72.177 (HELO dmitton.mitton.com) by smtp.mitton.com (209.228.32.64) with SMTP; 11 Jul 2003 12:30:52 -0700 X-Sent: 11 Jul 2003 19:30:52 GMT Message-Id: <5.2.1.1.2.20030711152127.03474ec0@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 11 Jul 2003 15:25:07 -0400 To: Jari Arkko From: David Mitton Subject: Re: [AAA-WG]: Issue 402 - Closing Cc: aaa-wg@merit.edu In-Reply-To: <3F0F0C95.5040004@kolumbus.fi> References: <5.2.1.1.2.20030711140032.00a5f2a0@getmail.mitton.com> <5.2.1.1.2.20030711140032.00a5f2a0@getmail.mitton.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk On 7/11/2003 10:14 PM +0300, Jari Arkko wrote: >>2.1. Diameter Session Establishment >> When the authentication or authorization exchange completes >> successfully, the NAS application SHOULD start a session context, and >> MAY send an Accounting START_RECORD message [Base]. The failure to >>JARI: The MAY above is a bit weak? Is this a configuration issue >> again, or are NASes generally allowed to skip accounting >> if they feel like it? ;-) >>DJM: Yes, I've reworded this per your later comments. >> Accounting should not be skipped if implemented, but the spec >> doesn't require the capability either. > >Is this is in the latest document or on some private version? >I agree with what you say above. But I wonder if there should >be some words about configuration as well. If you implement it, >you may not in all cases need accounting. Draft 12 is availible from the IETF server. I don't have a rev ... yet. Let me try again - Accounting is not a required capability of a NASreq application, but if Accounting is implemented, it MUST follow the specifications given. In particular the type and sequence of records must be conformant to allow interoperable server implementations. Dave. From owner-aaa-wg@merit.edu Mon Jul 14 04:32:57 2003 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 EAA01714 for ; Mon, 14 Jul 2003 04:32:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4D7E491217; Mon, 14 Jul 2003 04:32:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0FCBF9121A; Mon, 14 Jul 2003 04:32:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1E60D91217 for ; Mon, 14 Jul 2003 04:32:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EB8655DDB6; Mon, 14 Jul 2003 04:32:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 66C275DD93 for ; Mon, 14 Jul 2003 04:32:26 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h6E85Yc03219 for ; Mon, 14 Jul 2003 01:05:34 -0700 Date: Mon, 14 Jul 2003 01:05:34 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Slides for IETF 57... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk If you have slides to present at IETF 57, please sent them to me. Thanks! From owner-aaa-wg@merit.edu Mon Jul 14 19:16:18 2003 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 TAA04473 for ; Mon, 14 Jul 2003 19:16:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8D93791220; Mon, 14 Jul 2003 19:16:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5379A91221; Mon, 14 Jul 2003 19:16:06 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B38B791220 for ; Mon, 14 Jul 2003 19:16:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 88CEB5DD8C; Mon, 14 Jul 2003 19:16:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id 232435DD91 for ; Mon, 14 Jul 2003 19:16:01 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6ENFrj22339 for ; Mon, 14 Jul 2003 18:15:54 -0500 (CDT) Received: from zrc2c009.us.nortel.com ([47.103.120.49]) by zrc2c011.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NL40B72F; Mon, 14 Jul 2003 18:15:54 -0500 Received: from iqmail.net (chowdury-2.us.nortel.com [47.103.84.37]) by zrc2c009.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3V903QFN; Mon, 14 Jul 2003 18:15:54 -0500 Message-ID: <3F133930.20209@iqmail.net> Date: Mon, 14 Jul 2003 18:13:52 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Kuntal Chowdhury User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Fwd: I-D ACTION:draft-belinchon-aaa-diameter-mm-app-01.txt] References: <3EEF2CD0.2080601@ericsson.com> <3EEF7F6D.3040502@iqmail.net> <3EF028DF.4000402@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Miguel and all, Here are my review comments for this draft. Sorry for the delay in posting them. -Kuntal ----------------------------------------------------------------------- Section 2. We assume that the SIP server and the Diameter client are located in the same node, so that the SIP server is able to receive and process SIP requests and responses which in turn relies on the AAA infrastructure for authenticating the SIP request and authorizing the usage of particular SIP services. Comment: I think the better way to say will be - It is assumed that the SIP server supports a Diameter interface... Section 3.1: SIP server 1 will forward the SIP REGISTER request (step 4) to an appropriate SIP server (SIP server 2). The Diameter client in SIP server 2 will then request user authentication from the Diameter server by sending a Diameter Multimedia-Auth-Request (MAR) message (step 5). Comment: The apparent assumption in this document that the SIP server 2 will talk to the same AAA server. What if it is not talking to the same AAA server? What identifies the AAA server to SIP server 2 that has related information from SIP server 1? Section 3.1: This request will also serve to make the Diameter server aware of the SIP or SIPS URI of the SIP server 2, so as to return subsequent requests of the same user to the same SIP server 2. Comment: the text above is not clear. the SIP server 2 can be identified by which entity (AAA or the SIP server 1?)? Suggestion: This request will also serve to make the Diameter server aware of the SIP or SIPS URI of the SIP server 2. The AAA server shall store this information so that it can return the same to the SIP server 1 during subsequent re-registration by the same user. Section 3.1: When the SIP server 1 receives a next SIP REGISTER request containing the user credentials (step 9), as there SIP server 1 does not need to keep a state (even there is not guarantee the SIP request to arrive to the same SIP server 1), the Diameter client in SIP server 1 will contact again the Diameter server by sending a Diameter UAR message (step 10) to determine the SIP server allocated to the user. The Diameter server will send the SIP or SIPS URI of SIP server 2 in a Diameter UAA message (step 11). Comment: the paragraph needs some editorial scrub as suggested below. Also I think we need to mention how the same AAA server is selected (when multiple AAA servers are in the network). Suggestion: When the SIP server 1 receives a next SIP REGISTER request containing the user's credentials (step 9), as the SIP server 1 is stateless (even there is no guarantee that the SIP request arrives at the same SIP server 1), the Diameter client in SIP server 1 will contact the Diameter server again by sending a Diameter UAR message (step 10) to determine the SIP server 2 allocated to the user. The Diameter server will send the SIP or SIPS URI of SIP server 2 in a Diameter UAA message (step 11). Section 3.2 SIP server authenticates the user: This should not be included in the draft. Local authentication/authorization is certainly out of scope in AAA WG, IMHO. The draft also uses AAA server to perform SIP server assignment, store non-AAA specific info such as location of the SIP servers etc. These facts needs to discussed in the AAA WG. Section 3.2: Figure 3 shows an example where a SIP server is dynamically allocated to serve a SIP User Agent with the support of the Diameter server. This may be the case of certain architectures, such as the 3rd Generation Partnership Project (3GPP) IP Core Network Multimedia Subsystem (IMS). Comment: the SIP server 2 is dynamically allocated in section 3.1 as well. Nevertheless user authentication/authorization solely by the SIP server is possible w/o AAA server's involvement (in this scheme) and dynamic SIP server assignment is not the main topic of the discussion. Therefore I suggest deleting this text. Section 3.4: It must be noted that the Diameter server also attaches the user profile in the Diameter Server-Assignment-Request (SAR) message Comment: I think Diameter server needs to attach the user profile in the MAA message as well. Section 3.5: Last, if the Diameter server receives a Diameter Server-Assignment-Request (SAR) message that contains a SIP-Server-Assignment-Type set to the value DE-REGISTRATION, the Diameter server will proceed with the deregistration of the user. Comment: What is the criteria for the Diameter client (SIP server 2 in this case) to use SAR instead of STR? Section 5.2: Then Diameter server MUST authorize that User-Name AVP value is able to register the SIP or SIPS URI included in the SIP-Public-User-Identity AVP. Comment: need a little editorial scrub: Then Diameter server MUST authorize the user as identified in the User-Name AVP value so that the user is able to register the SIP or SIPS URI included in the SIP-Public-User-Identity AVP. Section 5.2: o In some cases, the Diameter server is aware of a previously assigned SIP server for the same or different public user identity allocated to the same user name. Comment: it is not clear why user name AVP will map into more than one different public user identities? More specifically why do we need to include the user name AVP at all when public user identity is present? Section 5.3: Typically the reception of a SIP REGISTER request in a SIP server will trigger the Diameter client in the SIP server to send the Diameter SAR message. However, if a SIP server is receiving other SIP request, such as INVITE, and the SIP server does not have the user profile, the Diameter client in the SIP server may send the Diameter SAR message to the Diameter server in order to download the user profile and make the Diameter server aware of the SIP server assigned to the user. Comment: When the user is not registered and the SIP server receives an INVITE for/from the user, then by directly sending a SAR the SIP server is bypassing auth/authz. This scenario (auth/authz bypass) may not be allowed in all networks. Moreover, receiving a REGISTER for a user that has no context in the SIP server should generate MAR message not SAR. Section 5.6: [ Auth-Grace-Period ] [ Authorization-Lifetime ] Comment: Since SIP server 1 is stateless, therefore what is the purpose of these two AVPs in the LIA message? Section 5.12: OPEN ISSUE: How to avoid that the same SIP server is chosen again, and we enter a loop. Comment: Ideally, the Diameter server flags the SIP server to be "busy" or a similar tag, so that while returning a UAA next time it does not include this server for a new user. Section 6.1.1: o DIAMETER_SERVER_SELECTION 2xx5 The Diameter server has authorized the registration. The user has already a SIP server assigned, but it may be necessary to select a new SIP server for the user. Comment: Not sure how often this will happen, but the appropriate value name should be DIAMETER_SERVER_RESELECTION Section 7.1: SIP-Charging-Information :: = < AVP Header: TBD > [ Primary-Event-Charging-Function-Name ] [ Secondary-Event-Charging-Function-Name ] [ Primary-Charging-Collection-Function-Name ] [ Secondary-Charging-Collection-Function-Name ] * [ AVP] Comment: There should be a sentence that says that these functions can all have the same value. These things may very well be part of the Diameter server (AAA server) and charging and accounting is part of AAA. Section 7.4: o UNREGISTERED_USER (3) The SIP server has received a SIP request (e.g., SIP INVITE) addressed for a public user identity that is not registered. Comment: Why doesn't the SIP server send a MAR in this case? Section 7.4: o AUTHENTICATION_FAILURE (9) The authentication of a user has failed. Comment: Why would the SIP sever send a SAR with Auth failure code? Ideally the Authentication needs to be done in the Diameter server. From owner-aaa-wg@merit.edu Thu Jul 17 07:52:26 2003 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 HAA01810 for ; Thu, 17 Jul 2003 07:52:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2BFAE9125D; Thu, 17 Jul 2003 07:52:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E79609125C; Thu, 17 Jul 2003 07:52:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 604EA9125B for ; Thu, 17 Jul 2003 07:52:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4DA3C5DDA2; Thu, 17 Jul 2003 07:52:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cms3.cms.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by segue.merit.edu (Postfix) with ESMTP id 1715E5DDEA for ; Thu, 17 Jul 2003 07:52:08 -0400 (EDT) Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jul 2003 20:52:02 +0900 Message-ID: <9E664A0522ABD711827B00D0B7A8AC4A62BAA0@cms3.etri.re.kr> From: haenamu@etri.re.kr To: aaa-wg@merit.edu Subject: [AAA-WG]: about "Diameter Mobile IPv6 Application" Date: Thu, 17 Jul 2003 20:52:01 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34C59.D5B40150" 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_01C34C59.D5B40150 Content-Type: text/plain; charset="euc-kr" Hi everyone, I have a question to you. At Diameter Mobile IPv6 Application , I saw the following section. My question is "Where I can find the document for the extension to ICMPv6 to convey information between the mobile node and the AAA Client." If you know, please, let me know where it is. 6. Information exchange between the mobile node and the AAA Client Although this document is not intended to specify any particular mechanism to convey information between the mobile node and the AAA Client, the information that needs to be exchanged is described. The set of information identified in the follow can actually be conveyed between the mobile node and the network in a different suitable manner outside the scope of this document (e.g. ICMP, the protocol defined by the PANA WG, etc.). ... Best regards, Lee ------_=_NextPart_001_01C34C59.D5B40150 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable about "Diameter Mobile IPv6 Application"

Hi everyone,

I have a question to you.

At Diameter Mobile IPv6 Application = <draft-le-aaa-diameter-mobileipv6-03.txt>,
I saw the following section.
 
My question is
"Where I can find the document for the = extension to ICMPv6  to convey information between the mobile node = and the AAA  Client."

If you know, please, let me know where it is.


6.  Information exchange between the mobile node = and the AAA Client

   Although this document is not intended = to specify any particular
   mechanism to convey information between = the mobile node and the AAA
   Client, the information that needs to = be exchanged is described. The
   set of information identified in the = follow can actually be conveyed
   between the mobile node and the network = in a different suitable
   manner outside the scope of this = document (e.g. ICMP, the protocol
   defined by the PANA WG, etc.). = ...


Best regards,
Lee=20

------_=_NextPart_001_01C34C59.D5B40150-- From owner-aaa-wg@merit.edu Mon Jul 21 10:20:58 2003 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 KAA28925 for ; Mon, 21 Jul 2003 10:20:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4A84191222; Mon, 21 Jul 2003 10:20:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 124E591223; Mon, 21 Jul 2003 10:20:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CE06191222 for ; Mon, 21 Jul 2003 10:20:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B7ABB5DDAE; Mon, 21 Jul 2003 10:20:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id D4D975DDAD for ; Mon, 21 Jul 2003 10:20:42 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6LEKRGJ019045; Mon, 21 Jul 2003 16:20:27 +0200 (MEST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 366DB4J1; Mon, 21 Jul 2003 16:20:56 +0200 Received: from ericsson.com by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA10506; Mon, 21 Jul 2003 16:20:26 +0200 Message-ID: <3F1BF6AA.6010302@ericsson.com> Date: Mon, 21 Jul 2003 17:20:26 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" Organization: Ericsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, es MIME-Version: 1.0 To: Kuntal Chowdhury Cc: aaa-wg@merit.edu, =?ISO-8859-1?Q?Mari_Carmen_Belinch=F3n?= , miguel.pallares@ericsson.com, carolina.canales-valenzuela@ece.ericsson.se, Pete McCann , jaakko.rajaniemi@nokia.com, kalle.tammi@nokia.com Subject: Re: [AAA-WG]: [Fwd: I-D ACTION:draft-belinchon-aaa-diameter-mm-app-01.txt] References: <3EEF2CD0.2080601@ericsson.com> <3EEF7F6D.3040502@iqmail.net> <3EF028DF.4000402@ericsson.com> <3F133930.20209@iqmail.net> In-Reply-To: <3F133930.20209@iqmail.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Kuntal: Thanks a lot for your comments. Please see some answers inline. /Miguel Kuntal Chowdhury wrote: > Miguel and all, > > Here are my review comments for this draft. Sorry for the delay in > posting them. > > -Kuntal > > ----------------------------------------------------------------------- > Section 2. > > We assume that the SIP server and the Diameter client are located in > the same node, so that the SIP server is able to receive and process > SIP requests and responses which in turn relies on the AAA > infrastructure for authenticating the SIP request and authorizing the > usage of particular SIP services. > > Comment: I think the better way to say will be - > > It is assumed that the SIP server supports a Diameter interface... Yes, another way to express the same sentence. > > > Section 3.1: > > SIP server 1 will forward the SIP REGISTER request (step 4) to an > appropriate SIP server (SIP server 2). The Diameter client in SIP > server 2 will then request user authentication from the Diameter > server by sending a Diameter Multimedia-Auth-Request (MAR) message > (step 5). > > Comment: The apparent assumption in this document that the SIP server 2 > will > talk to the same AAA server. What if it is not talking to the same AAA > server? Yes, the assumption is correct: there is only a single Diameter server. Of course you can have a cluseter configuration supporting redundancy and all the fancy things you want, but from the logical perspective the assumption is that there is a single Diameter server per realm. > What identifies the AAA server to SIP server 2 that has related information > from SIP server 1? I am not sure if I understand your question. The idea is that SIP server 2 is something allocated dynamically, perhaps when the user registers or something like that. So it may change from time to time... The Diameter server keeps track of the SIP server 2 URI, as a way to provide extra routing information (apart from the authorization function) to SIP server 1. > > > Section 3.1: > > This request will also serve to make the Diameter server > aware of the SIP or SIPS URI of the SIP server 2, so as to return > subsequent requests of the same user to the same SIP server 2. > > Comment: the text above is not clear. the SIP server 2 can be identified > by which entity (AAA or the SIP server 1?)? Ok, I will try to clarify. The SIP server 2 will instruct the Diameter server to "save" its URI, so that subsequent request like step 2 end up with the same routing information (SIP server 2 URI) in step 3. > > Suggestion: > This request will also serve to make the Diameter server aware of the > SIP or > SIPS URI of the SIP server 2. The AAA server shall store this > information so > that it can return the same to the SIP server 1 during subsequent > re-registration by the same user. > In general your proposed text is fine, but the word is not correct. First, there shouldn be any "shall", whichi is normative information, in section 3, which is "Overview of operation". Second, you are assuming that the request is always a register (subsequent re-registration), which is not correct. It could be any other request address for the same user (e.g., see section 3.3 and the LIR/LIA commands). So if you combined the above correction to your text, you will most likely end up with the same text I wrote originally ;-) > > Section 3.1: > > When the SIP server 1 receives a next SIP REGISTER request containing > the user credentials (step 9), as there SIP server 1 does not need to > keep a state (even there is not guarantee the SIP request to arrive > to the same SIP server 1), the Diameter client in SIP server 1 will > contact again the Diameter server by sending a Diameter UAR message > (step 10) to determine the SIP server allocated to the user. The > Diameter server will send the SIP or SIPS URI of SIP server 2 in a > Diameter UAA message (step 11). > > Comment: the paragraph needs some editorial scrub as suggested below. > Also I think we need to mention how the same AAA server is selected > (when multiple AAA servers are in the network). Do we have a requirement to cover the case when there are multiple diameter servers in the same network? 3GPP contains a solution, over a different interface (so called Dx interface) to provide this functionality, but I think this something of no interest outside 3GPP. > > Suggestion: > > When the SIP server 1 receives a next SIP REGISTER request containing the > user's credentials (step 9), as the SIP server 1 is stateless (even > there is > no guarantee that the SIP request arrives at the same SIP server 1), the > Diameter client in SIP server 1 will contact the Diameter server again by > sending a Diameter UAR message (step 10) to determine the SIP server 2 > allocated to the user. The Diameter server will send the SIP or SIPS URI of > SIP server 2 in a Diameter UAA message (step 11). > > OK with the suggestion. > > Section 3.2 SIP server authenticates the user: > > This should not be included in the draft. Local > authentication/authorization > is certainly out of scope in AAA WG, IMHO. The draft also uses AAA > server to perform SIP server assignment, store non-AAA specific info > such as location of the SIP servers etc. These facts needs to discussed > in the AAA WG. Today SIP servers can authenticate users. It is happening everyday in the Internet. What this draft offers is two possibilities, so that operators can decided which one to choose to suit their needs. These two posibilities are: a) The Diameter server is authenticating the users. In this case, the SIP server terminates the SIP authentication, but the SIP server merely proxies the credentials to the Diameter server. This may be a case widely agreable for most of the internet needs. b) The Diameter server delegates the authentication to the SIP server. In this case, the SIP server terminates the SIP authentication and downloads some authentication vectors from the Diameter server, as for to execute authentication in the SIP server. This is the solution chosen by 3GPP. It has a number of advantages, like providing a distributed architecutre that relieves the Diameter server from the burden of computing authentication. This mechanism is also in use today, so I don't thing that precluding its standardisation will help to achieve interoperability between different implementations. > > > Section 3.2: > > Figure 3 shows an example where a SIP server is dynamically allocated > to serve a SIP User Agent with the support of the Diameter server. > This may be the case of certain architectures, such as the 3rd > Generation Partnership Project (3GPP) IP Core Network Multimedia > Subsystem (IMS). > > Comment: the SIP server 2 is dynamically allocated in section 3.1 as well. Yes, is that a problem? They are two mutually exclusive scenarios. > > Nevertheless user authentication/authorization solely by the SIP server > is possible w/o AAA server's involvement (in this scheme) and dynamic > SIP server assignment is not the main topic of the discussion. Therefore > I suggest deleting this text. I don't agree. I think that deleting text is not the way to expressing ideas, and I don't believe we will achive much by deleting this text. What this section is demonstrating is how to achieve authentication in a SIP server with support from a Diameter server. The Diameter server is still performing a number of functions, being authorization the most significant one. The SIP server does not include a database of users of the realm, not even credentials whatsoever. So the only mechanism to authorize the user is to contact the Diameter server. > > > Section 3.4: > > It must be > noted that the Diameter server also attaches the user profile in the > Diameter Server-Assignment-Request (SAR) message > > Comment: I think Diameter server needs to attach the user profile in the > MAA > message as well. > > Mmmm... Yes, I think there is an inconsistency in the text, because if the Diameter server is authenticating the user (like it's described in section 3.2), the Diameter server has to send the user profile in MAA. However, MAA does not allow the SIP-User-Data AVP to be carried in. I need to solve this inconsistency. > Section 3.5: > > Last, if the Diameter server receives a Diameter > Server-Assignment-Request (SAR) message that contains a > SIP-Server-Assignment-Type set to the value DE-REGISTRATION, the > Diameter server will proceed with the deregistration of the user. > > Comment: What is the criteria for the Diameter client (SIP server 2 in this > case) to use SAR instead of STR? > RTR flows in the direction from Diameter server to Diameter client, whereas SAR flows from Diameter client to Diameter server. Consequently, the SIP server always sends SAR. > > Section 5.2: > > Then Diameter server MUST authorize that User-Name AVP value is able > to register the SIP or SIPS URI included in the > SIP-Public-User-Identity AVP. > > Comment: need a little editorial scrub: > Then Diameter server MUST authorize the user as identified in the User-Name > AVP value so that the user is able to register the SIP or SIPS URI > included in > the SIP-Public-User-Identity AVP. > > Ok with it. > Section 5.2: > > o In some cases, the Diameter server is aware of a previously > assigned SIP server for the same or different public user identity > allocated to the same user name. > > Comment: it is not clear why user name AVP will map into more than one > different public user identities? More specifically why do we need to > include > the user name AVP at all when public user identity is present? Yes, yes. Public User identity (something that will change soon to SIP-AOR (Address of record, as per RFC 3261), is a SIP or SIPS URI. It is some address that you distribute in your business cards (similar to your e-mail address) and other users initiate communications to you by pointing to your SIP AOR. The user name is just some identity used to authenticate the user. It is not a SIP or SIPS URI, it is not widely known, and it is know known to initiate communications against you. So both identities have to be present for different purposes. > > > Section 5.3: > > Typically the reception of a SIP REGISTER request in a SIP server > will trigger the Diameter client in the SIP server to send the > Diameter SAR message. However, if a SIP server is receiving other SIP > request, such as INVITE, and the SIP server does not have the user > profile, the Diameter client in the SIP server may send the Diameter > SAR message to the Diameter server in order to download the user > profile and make the Diameter server aware of the SIP server assigned > to the user. > > Comment: When the user is not registered and the SIP server receives an > INVITE > for/from the user, then by directly sending a SAR the SIP server is > bypassing > auth/authz. This scenario (auth/authz bypass) may not be allowed in all > networks. Moreover, receiving a REGISTER for a user that has no context in > the SIP server should generate MAR message not SAR. > A lot of staff in the previous paragraph... First, let me try to describe a scenario. Imagine that you're SIP phone is off, so you are not registered to the network, and someone calls you. The call will end-up in a SIP server that knows nothing about you, other than "this is a call addressed to Kuntal". The SIP server cannot authenticate you, because you are offline. But the SIP server still needs to download the user profile, because it needs to know if you have services (e.g., voicemail service or similar) to execute. So the SIP server contacts the Diameter server to authorize the call for this user, download the user profile, and informs the Diameter server that this SIP server is now serving the non-registered user. Can you see an authentication bypass in this scenario? I don't. When the user goes online and registers, then it will be authenticated. > Section 5.6: > > [ Auth-Grace-Period ] > [ Authorization-Lifetime ] > > Comment: Since SIP server 1 is stateless, therefore what is the purpose > of these two AVPs in the LIA message? I need to double check this. I must say I am not sure why these AVPs are here. But the fact is that SIP server 1 MAY be stateless, we don't force it to be stateless (but I don't think this changes the question about the presence of the AVPs). > > > Section 5.12: > > OPEN ISSUE: How to avoid that the same SIP server is chosen again, > and we enter a loop. > > Comment: Ideally, the Diameter server flags the SIP server to be "busy" > or a > similar tag, so that while returning a UAA next time it does not include > this > server for a new user. No, this does not work. The thing is that UAA does not return a list of possible SIP servers, but it returns a list of "capabilities" that the selected SIP server need to fulfil for this particular user. So a user may require a SIP server that is able to execute Java (capability x) and SIP CGI (capability y). The Diameter server will indicate (in UAA) that the user requires a SIP server with capabilities x and y. SIP server 1 will use this information to select SIP server 2 (according t those capabilities). The situation that we discribe in this paragraph will force the whole allocation process to start, but there is a chance that SIP server 2 is again chosen (by SIP server 1 or any other SIP server), so we will be in a look. So that is open issue that I have listed. > > > Section 6.1.1: > > o DIAMETER_SERVER_SELECTION 2xx5 > The Diameter server has authorized the registration. The user has > already a SIP server assigned, but it may be necessary to select a > new SIP server for the user. > > Comment: Not sure how often this will happen, but the appropriate value > name > should be DIAMETER_SERVER_RESELECTION Ok. > > > Section 7.1: > > SIP-Charging-Information :: = < AVP Header: TBD > > [ Primary-Event-Charging-Function-Name ] > [ Secondary-Event-Charging-Function-Name ] > [ Primary-Charging-Collection-Function-Name ] > [ Secondary-Charging-Collection-Function-Name ] > * [ AVP] > > Comment: There should be a sentence that says that these functions can > all have the same value. These things may very well be part of the > Diameter server (AAA > server) and charging and accounting is part of AAA. Yes, that is correct. Actually, I think the there should be a couple of AVPs that allow repetition, and we should forget about Primary and Secondary. I will make these changes in the next version. > > > Section 7.4: > > o UNREGISTERED_USER (3) > The SIP server has received a SIP request (e.g., SIP INVITE) > addressed for a public user identity that is not registered. > > Comment: Why doesn't the SIP server send a MAR in this case? Because this in this case the SIP server is interested to server the request, and download the user profile. SAR carries a "store" operation, whereby the Diameter server stores the address of the SIP server serving the user. MAR carries an authorization operation to install a registration. > > Section 7.4: > > o AUTHENTICATION_FAILURE (9) > The authentication of a user has failed. > > Comment: Why would the SIP sever send a SAR with Auth failure code? Ideally > the Authentication needs to be done in the Diameter server. We discussed before the scenario where the Diameter server delegates the authentication to a SIP server. So this is the mechanism whereby the SIP server indicates the Diameter server that authentication failed. > > > Regards, Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 From owner-aaa-wg@merit.edu Mon Jul 21 12:07:58 2003 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 MAA02060 for ; Mon, 21 Jul 2003 12:07:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E046A91201; Mon, 21 Jul 2003 12:07:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B03229120E; Mon, 21 Jul 2003 12:07:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7F5CF91201 for ; Mon, 21 Jul 2003 12:07:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 647505DDAE; Mon, 21 Jul 2003 12:07:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax2.ext.nokia.com (unknown [63.78.179.217]) by segue.merit.edu (Postfix) with ESMTP id E94435DDAA for ; Mon, 21 Jul 2003 12:07:43 -0400 (EDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6LG7dG25029 for ; Mon, 21 Jul 2003 11:07:39 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 21 Jul 2003 11:07:36 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 21 Jul 2003 09:07:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34FA2.27CFADCC" Subject: RE: [AAA-WG]: about "Diameter Mobile IPv6 Application" Date: Mon, 21 Jul 2003 11:07:16 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44025F50F8@daebe007.americas.nokia.com> Thread-Topic: [AAA-WG]: about "Diameter Mobile IPv6 Application" Thread-Index: AcNMWeaG48MC2/50RcydhKVWbJu6vgA8iwTw From: To: , X-OriginalArrivalTime: 21 Jul 2003 16:07:17.0955 (UTC) FILETIME=[28842130:01C34FA2] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C34FA2.27CFADCC Content-Type: text/plain; charset="KS_C_5601-1987" Content-Transfer-Encoding: quoted-printable =20 I believe you are looking for the AAAv6 draft authored by Charles = Perkins and Ernie Tacsik. Look for I-D : draft-perkins-aaav6-06.txt =20 -Basavaraj Hi everyone,=20 I have a question to you.=20 At Diameter Mobile IPv6 Application = ,=20 I saw the following section.=20 =20 My question is=20 "Where I can find the document for the extension to ICMPv6 to convey = information between the mobile node and the AAA Client." If you know, please, let me know where it is.=20 6. Information exchange between the mobile node and the AAA Client=20 Although this document is not intended to specify any particular=20 mechanism to convey information between the mobile node and the AAA=20 Client, the information that needs to be exchanged is described. The=20 set of information identified in the follow can actually be conveyed=20 between the mobile node and the network in a different suitable=20 manner outside the scope of this document (e.g. ICMP, the protocol=20 defined by the PANA WG, etc.). ...=20 Best regards,=20 Lee=20 ------_=_NextPart_001_01C34FA2.27CFADCC Content-Type: text/html; charset="KS_C_5601-1987" Content-Transfer-Encoding: quoted-printable about "Diameter Mobile IPv6 Application"
 
I = believe you are=20 looking for the AAAv6 draft authored by Charles Perkins = and
Ernie = Tacsik. Look=20 for I-D : draft-perkins-aaav6-06.txt
 
-Basavaraj

Hi everyone,

I have a question to you.

At Diameter Mobile IPv6 Application=20 <draft-le-aaa-diameter-mobileipv6-03.txt>,
I saw=20 the following section.
  =
My question is
"Where I can find = the document=20 for the extension to ICMPv6  to convey information between the = mobile=20 node and the AAA  Client."

If you know, please, let me know where it is. =


6.  Information exchange between the mobile = node and the=20 AAA Client

   Although this document is not intended = to specify=20 any particular
   mechanism to = convey=20 information between the mobile node and the AAA
   Client, the information that needs to be = exchanged is=20 described. The
   set of = information=20 identified in the follow can actually be conveyed
   between the mobile node and the network in a = different=20 suitable
   manner outside the = scope of this=20 document (e.g. ICMP, the protocol
   defined=20 by the PANA WG, etc.). ...


Best regards,
Lee=20

------_=_NextPart_001_01C34FA2.27CFADCC-- From owner-aaa-wg@merit.edu Tue Jul 22 01:10:32 2003 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 BAA19788 for ; Tue, 22 Jul 2003 01:10:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2321C9122D; Tue, 22 Jul 2003 01:10:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E73119122E; Tue, 22 Jul 2003 01:10:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A62069122D for ; Tue, 22 Jul 2003 01:10:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7FB005DDF7; Tue, 22 Jul 2003 01:10:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cms3.cms.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by segue.merit.edu (Postfix) with ESMTP id 2E99A5DDF1 for ; Tue, 22 Jul 2003 01:10:15 -0400 (EDT) Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jul 2003 14:10:07 +0900 Message-ID: <9E664A0522ABD711827B00D0B7A8AC4A78E5C0@cms3.etri.re.kr> From: bglee@etri.re.kr To: Basavaraj.Patil@nokia.com, aaa-wg@merit.edu Subject: [Re] [AAA-WG]: about "Diameter Mobile IPv6 Application" Date: Tue, 22 Jul 2003 14:10:06 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3500F.8403F810" 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_01C3500F.8403F810 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Hi, We must careful choice of the ICMPv6 or PANA for implementation of = Mobile IPv6 with AAA. but i don't know which is better. Would you recommand which is proper ? or any comment about that ?=20 Bset regards, B. G. Lee =BF=F8=BA=BB =B3=BB=BF=EB: =BA=B8=B3=BD=BB=E7=B6=F7: = Basavaraj.Patil@nokia.com[Basavaraj.Patil@nokia.com] =B9=DE=B4=C2=BB=E7=B6=F7: haenamu@etri.re.kr; aaa-wg@merit.edu =C1=A6=B8=F1: RE: [AAA-WG]: about "Diameter Mobile IPv6 Application" =B9=DE=C0=BA=B3=AF=C2=A5: 2003/07/22 =C8=AD 01:07 I believe you are looking for the AAAv6 draft authored by Charles = Perkins and Ernie Tacsik. Look for I-D : draft-perkins-aaav6-06.txt -Basavaraj Hi everyone,=20 I have a question to you. At Diameter Mobile IPv6 Application ,=20 I saw the following section.=20 =20 My question is=20 "Where I can find the document for the extension to ICMPv6 to convey information between the mobile node and the AAA Client." If you know, please, let me know where it is. 6. Information exchange between the mobile node and the AAA Client Although this document is not intended to specify any particular=20 mechanism to convey information between the mobile node and the AAA=20 Client, the information that needs to be exchanged is described. The = set of information identified in the follow can actually be conveyed = between the mobile node and the network in a different suitable=20 manner outside the scope of this document (e.g. ICMP, the protocol=20 defined by the PANA WG, etc.). ... Best regards,=20 Lee ------_=_NextPart_001_01C3500F.8403F810 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable [Re] [AAA-WG]: about "Diameter Mobile IPv6 = Application"

Hi,

We must careful choice of the ICMPv6 or PANA  = for implementation of Mobile IPv6 with AAA.
but i don't know which is better.
Would you recommand which is proper ?
or any comment about that ?

Bset regards,
B. G.  Lee

=BF=F8=BA=BB =B3=BB=BF=EB:

=BA=B8=B3=BD=BB=E7=B6=F7: = Basavaraj.Patil@nokia.com[Basavaraj.Patil@nokia.com]
=B9=DE=B4=C2=BB=E7=B6=F7: haenamu@etri.re.kr; = aaa-wg@merit.edu
=C1=A6=B8=F1: RE: [AAA-WG]: about "Diameter = Mobile IPv6 Application"
=B9=DE=C0=BA=B3=AF=C2=A5: 2003/07/22 =C8=AD = 01:07


I believe you are looking for the AAAv6 draft = authored by Charles Perkins and
Ernie Tacsik. Look for I-D : = draft-perkins-aaav6-06.txt
-Basavaraj

Hi everyone,
I have a question to you.
At Diameter Mobile IPv6 Application = <draft-le-aaa-diameter-mobileipv6-03.txt>,
I saw the following section.
 
My question is
"Where I can find the document for the = extension to ICMPv6  to convey information between the mobile node = and the AAA  Client."

If you know, please, let me know where it is.

6.  Information exchange between the mobile node = and the AAA Client
   Although this document is not intended = to specify any particular
   mechanism to convey information between = the mobile node and the AAA
   Client, the information that needs to = be exchanged is described. The
   set of information identified in the = follow can actually be conveyed
   between the mobile node and the network = in a different suitable
   manner outside the scope of this = document (e.g. ICMP, the protocol
   defined by the PANA WG, etc.). = ...

Best regards,
Lee

------_=_NextPart_001_01C3500F.8403F810-- From owner-aaa-wg@merit.edu Tue Jul 22 11:49:35 2003 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 LAA17894 for ; Tue, 22 Jul 2003 11:49:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BA7879123E; Tue, 22 Jul 2003 11:49:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8C5CF9123F; Tue, 22 Jul 2003 11:49:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2CE769123E for ; Tue, 22 Jul 2003 11:49:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 16A015DE36; Tue, 22 Jul 2003 11:49:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by segue.merit.edu (Postfix) with ESMTP id 41AFB5DE1D for ; Tue, 22 Jul 2003 11:49:19 -0400 (EDT) Date: Tue, 22 Jul 2003 08:50:53 -0700 Subject: Re: [Re] [AAA-WG]: about "Diameter Mobile IPv6 Application" From: Alper Yegin To: , , Message-ID: In-Reply-To: <9E664A0522ABD711827B00D0B7A8AC4A78E5C0@cms3.etri.re.kr> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3141708654_2196272" 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. --B_3141708654_2196272 Content-type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello B.G. Lee, If you are looking for a network-layer last-hop AAA protocol between a host and access network, then IETF=E2=80=99s solution to that is PANA. Please see the relevant documents at http://www.ietf.org/html.charters/pana-charter.html . Feel free to ask questions if you have any.. Alper=20 > Hi,=20 >=20 > We must careful choice of the ICMPv6 or PANA for implementation of Mobil= e > IPv6 with AAA.=20 > but i don't know which is better. > Would you recommand which is proper ? > or any comment about that ? >=20 > Bset regards,=20 > B. G. Lee=20 >=20 > =EC=9B=90=EB=B3=B8 =EB=82=B4=EC=9A=A9:=20 >=20 > =EB=B3=B4=EB=82=B8=EC=82=AC=EB=9E=8C: Basavaraj.Patil@nokia.com[Basavaraj.Patil@nokia.com] > =EB=B0=9B=EB=8A=94=EC=82=AC=EB=9E=8C: haenamu@etri.re.kr; aaa-wg@merit.edu > =EC=A0=9C=EB=AA=A9: RE: [AAA-WG]: about "Diameter Mobile IPv6 Application" > =EB=B0=9B=EC=9D=80=EB=82=A0=EC=A7=9C: 2003/07/22 =ED=99=94 01:07 >=20 >=20 > I believe you are looking for the AAAv6 draft authored by Charles Perkins= and > Ernie Tacsik. Look for I-D : draft-perkins-aaav6-06.txt > -Basavaraj=20 >=20 > Hi everyone,=20 > I have a question to you. > At Diameter Mobile IPv6 Application , > I saw the following section. > =20 > My question is=20 > "Where I can find the document for the extension to ICMPv6 to convey > information between the mobile node and the AAA Client." >=20 > If you know, please, let me know where it is. >=20 > 6. Information exchange between the mobile node and the AAA Client > Although this document is not intended to specify any particular > mechanism to convey information between the mobile node and the AAA > Client, the information that needs to be exchanged is described. The > set of information identified in the follow can actually be conveyed > between the mobile node and the network in a different suitable > manner outside the scope of this document (e.g. ICMP, the protocol > defined by the PANA WG, etc.). ... >=20 > Best regards,=20 > Lee=20 >=20 --B_3141708654_2196272 Content-type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Re: [Re] [AAA-WG]: about "Diameter Mobile IPv6 Application"= ;
Hello B.G. Lee,

If you are looking for a network-layer last-hop AAA protocol between a host= and access network, then IETF’s solution to that is PANA. Please see = the relevant documents at http://www.ietf.org/html.charters/pana-charter.htm= l . Feel free to ask questions if you have any..

Alper



Hi,

We must careful choice of the ICMPv6 or PANA  for imple= mentation of Mobile IPv6 with AAA.
but i don't know which is better.
Would you recommand which is proper ?
or any comment about that ?

Bset regards,
B. G.  Lee

=EC=9B=90=EB=B3=B8 =EB=82=B4=EC=9A=A9:

=EB=B3=B4=EB=82=B8=EC=82=AC=EB=9E=8C: Basavaraj.Pat= il@nokia.com[Basavaraj.Patil@nokia.com] <= BR> =EB=B0=9B=EB=8A=94=EC=82=AC=EB=9E=8C: haenamu@etri.= re.kr; aaa-wg@merit.edu
=EC=A0=9C=EB=AA=A9: RE: [AAA-WG]: about= "Diameter Mobile IPv6 Application"
=EB=B0=9B=EC=9D=80=EB=82=A0=EC=A7=9C: 2003/07/22 =ED=99= =94 01:07


I believe you are looking for the AAAv6 draft authored by Ch= arles Perkins and
Ernie Tacsik. Look for I-D : draft-perkins-aaav6-06.txt
-Basavaraj

Hi everyone,
I have a question to you.
At Diameter Mobile IPv6 Application <draft-le-aaa-diamete= r-mobileipv6-03.txt>,
I saw the following section.
  
My question is
"Where I can find the document for the extension to ICMPv6  to co= nvey information between the mobile node and the AAA  Client."

If you know, please, let me know where it is.

6.  Information exchange between the mobile node and th= e AAA Client
  Although this document is not intended to speci= fy any particular
   mechanism to convey information between the mobile node a= nd the AAA
   Client, the information that needs to be exchanged is des= cribed. The
   set of information identified in the follow can actually = be conveyed
   between the mobile node and the network in a different su= itable
   manner outside the scope of this document (e.g. ICMP, the= protocol
   defined by the PANA WG, etc.). ...

Best regards,
Lee


--B_3141708654_2196272-- From owner-aaa-wg@merit.edu Tue Jul 22 22:40:20 2003 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 WAA03593 for ; Tue, 22 Jul 2003 22:40:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DE3E99125F; Tue, 22 Jul 2003 22:40:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1D5F91261; Tue, 22 Jul 2003 22:40:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6B0EE9125F for ; Tue, 22 Jul 2003 22:40:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5A3145DDCA; Tue, 22 Jul 2003 22:40:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cms3.cms.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by segue.merit.edu (Postfix) with ESMTP id 86FD55DDC9 for ; Tue, 22 Jul 2003 22:40:05 -0400 (EDT) Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jul 2003 11:40:00 +0900 Message-ID: <9E664A0522ABD711827B00D0B7A8AC4ADB2946@cms3.etri.re.kr> From: mariekim@etri.re.kr To: aaa-wg@merit.edu Subject: [AAA-WG]: about "Diameter Path Authorization" Date: Wed, 23 Jul 2003 11:39:59 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C350C3.B5EE6450" 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_01C350C3.B5EE6450 Content-Type: text/plain; charset="euc-kr" Hi~~ We are about to implement IPv6-based Diameter AAA system. But....It's not clear about the "Diameter Path Authorization" My Question is......................... Will you permit any Diameter response authorizing a session to include Route-Record AVP ? Chapter 2.10 of Diameter Base Protocol A home realm may also wish to check that each accounting request message corresponds to a Diameter response authorizing the session. Accounting requests without corresponding authorization responses SHOULD be subjected to further scrutiny, as should accounting requests indicating a difference between the requested and provided service. Similarly, the local Diameter agent, on receiving a Diameter response authorizing a session, MUST check the Route-Record AVPs to make sure that the route traversed by the response is acceptable. At each step, forwarding of an authorization response is considered evidence of a willingness to take on financial risk relative to the session. According to any draft for Diameter, Diameter response authorizing a session cannot include Route-Record AVP. For example, AMA for MIPv4 application, RAA for re-auth. ------_=_NextPart_001_01C350C3.B5EE6450 Content-Type: text/html; charset="euc-kr" about "Diameter Path Authorization"

Hi~~

We are about to implement IPv6-based Diameter AAA system.

But....It's not clear about the "Diameter Path Authorization"


My Question is.........................
Will you permit any Diameter response authorizing a session to include Route-Record AVP ?

Chapter 2.10 of Diameter Base Protocol <draft-ietf-aaa-diameter-17.txt>

A home realm may also wish to check that each accounting request
   message corresponds to a Diameter response authorizing the session.
   Accounting requests without corresponding authorization responses
   SHOULD be subjected to further scrutiny, as should accounting
   requests indicating a difference between the requested and provided
   service.

Similarly, the local Diameter agent, on receiving a Diameter response
   authorizing a session, MUST check the Route-Record AVPs to make sure
   that the route traversed by the response is acceptable. At each step,
   forwarding of an authorization response is considered evidence of a
   willingness to take on financial risk relative to the session.

According to any draft for Diameter, Diameter response authorizing a session cannot include Route-Record AVP.
For example, AMA for MIPv4 application, RAA for re-auth.

------_=_NextPart_001_01C350C3.B5EE6450-- From owner-aaa-wg@merit.edu Sat Jul 26 13:13:17 2003 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 NAA13361 for ; Sat, 26 Jul 2003 13:13:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1315D91201; Sat, 26 Jul 2003 13:13:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D70D79120E; Sat, 26 Jul 2003 13:13:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DF29B91201 for ; Sat, 26 Jul 2003 13:13:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C35925DEB9; Sat, 26 Jul 2003 13:13:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 0BF265DE8B for ; Sat, 26 Jul 2003 13:13:07 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h6QGj4o27016 for ; Sat, 26 Jul 2003 09:45:05 -0700 Date: Sat, 26 Jul 2003 09:45:04 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG last call on draft-ietf-aaa-diameter-nasreq-12.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is to announce AAA WG last call on the Diameter NASREQ draft, prior to sending it on to the IESG for consideration as an IETF Proposed Standard. The Diameter NASREQ draft is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-12.txt Comments should be sent to the AAA WG mailing list in the format specified in the AAA Issues Web page: http://www.drizzle.com/~aboba/AAA/issues.html AAA WG last call will last until August 15, 2003. From owner-aaa-wg@merit.edu Thu Jul 31 11:48:51 2003 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 LAA02293 for ; Thu, 31 Jul 2003 11:48:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C1F07912AA; Thu, 31 Jul 2003 11:48:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D4E9912A9; Thu, 31 Jul 2003 11:48:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 463CD912AA for ; Thu, 31 Jul 2003 11:48:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2980F5DE78; Thu, 31 Jul 2003 11:48:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 7D21E5DE54 for ; Thu, 31 Jul 2003 11:48:13 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2656.59) id ; Thu, 31 Jul 2003 11:48:07 -0400 Message-ID: From: Avi Lior To: "'miguel.a.garcia@ericsson.com'" , "'maria.c.belinchon@ericsson.com'" Cc: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Avi Comments: draft-belinchon-aaa-diameter-mm-app-01.txt Date: Thu, 31 Jul 2003 11:48:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is my first installment of comments up to section 5. Stay tuned for the next section [AL] General Comments: I did not read other peoples reviews. This way if there is duplication you will get an amplication effect which could be useful. After my review i will read the other ones. However, I did read the first couple of reviews that talked about the name change and perhaps it would be a good idea to change the name to reflect the "SIPness" of this draft. Also I am not a SIP expert so you are getting the view of a non-sip expert reviewer which is a good thing. But make sure you get a SIP type person to review. [AL] End of general comments 2. Introduction This document specifies the Diameter Multimedia Application. This is a Diameter application that allows a Diameter client to request authentication and authorization information to a Diameter server for Session Initiation Protocol (SIP) [6] based IP multimedia services. We assume that the SIP server and the Diameter client are located in the same node, so that the SIP server is able to receive and process SIP requests and responses which in turn relies on the AAA infrastructure for authenticating the SIP request and authorizing the usage of particular SIP services. [AL] What is a node? The SIP server is acting as a Diameter Client. Perhaps a better way to say this is: In this document we assume that the SIP server is acting as a Diameter Client..... This document provides Diameter procedures to implement certain required functionality when SIP is the protocol chosen to initiate and tear-down multimedia sessions. However, this document does not mandate any particular mapping of SIP procedures to Diameter Multimedia procedures, nor this document [AL] mandate any particular sequence of events between SIP and Diameter. In some cases, though, this document provides with useful examples to show the interaction between SIP and Diameter Multimedia in order to achieve the desired functionality. [AL] Delete " In some cases, though," and "with" The Overview chapter (Section 3) provides the reader with non-normative description of the Diameter multimedia commands and responses and some guidance of its linkage with SIP procedures. [AL] Can't you use Informative for non-normative? ..... 3. Overview of operation This section provides an informative description of how the Diameter Multimedia application can be used together with SIP. By no means this section mandates any specific usage of the Diameter Multimedia application nor it mandates a specific mapping between SIP and Diameter messages. This section is just a collection of examples that shows how the required AAA functionality can be achieved in conjunction with SIP. [AL] Change: "application nor it mandates a " to: "application nor does it mandates a " above. According to Figure 2 a SIP User Agent Client (UAC) sends a SIP REGISTER request (step 1) to its home domain. SIP server 1 will receive the SIP request. We assume that this SIP server may be located, e.g., at the edge of the administrative home domain. The Diameter client in SIP server 1 will contact its Diameter server by sending a Diameter User-Authorization-Request (UAR) message (step 2) to determine if this user is allowed to receive service, and if so, request the address of a local SIP server capable of handling this user. [AL] What do you mean by SIP server 1 will contact *its* Diameter server. Couldn't it contact a Diameter server? There could be more then one Diameter server no? The Diameter server will answer with a Diameter User-Authorization-Answer (UAA) message (step 3), which will indicate either a list of capabilities that the SIP server 1 may use to select an appropriate SIP server (SIP server 2) or a SIP or SIPS URI pointing to SIP server 2. SIP server 1 will forward the SIP REGISTER request (step 4) to an appropriate SIP server (SIP server 2). The Diameter client in SIP server 2 will then request user authentication from the Diameter server by sending a Diameter Multimedia-Auth-Request (MAR) message (step 5). [AL] Must it be the same Diameter server? Couldnt it be a different one? This request will also serve to make the Diameter server aware of the SIP or SIPS URI of the SIP server 2, so as to return subsequent requests of the same user to the same SIP server 2. [AL] So what you are saying here is that you inform the Diameter server of the SIP Server selected by SIP1. [AL] What subsequent requests? Why wouldnt subsequent commands go directly to SIP2? [AL] Also if you have multiple Diameter servers one used by SIP1 the other used by SIP2 will this work? It would only work if the state (which SIP server) can be shared by both Diameter servers. Alternatively it would work if Diameter serving SIP1 returns SIP2 again. The Diameter server will respond with a Diameter Multimedia-Auth-Answer (MAA) message (step 6) with Result-Code AVP set to the value DIAMETER_MULTI_ROUND_AUTH. The Diameter server will also include a challenge, which the SIP server 2 will use to map into the WWW-authentication header in the SIP 401 (Unauthorized) response (step 7), which is sent back to the SIP server 1 and then to the SIP UAC (step 8). [AL] Seems to me that if SIP1 kept state there would be fewer messages. When the SIP server 1 receives a next SIP REGISTER request containing the user credentials (step 9), as there SIP server 1 does not need to keep a state (even there is not guarantee the SIP request to arrive to the same SIP server 1), the Diameter client in SIP server 1 will contact again the Diameter server by sending a Diameter UAR message (step 10) to determine the SIP server allocated to the user. The Diameter server will send the SIP or SIPS URI of SIP server 2 in a Diameter UAA message (step 11). [AL] The above par. in paritucal the first sentence needs to be cleaned up. The first sentence is almost the entire paragraph ;-) SIP server 1 will then forward the SIP REGISTER request to SIP server 2 (step 12). SIP server 2 will extract the credentials from the SIP REGISTER request. The Diameter client in SIP server 2 will send those credentials in a Diameter MAR message (step 13)to the Diameter server. This message will also enable the Diameter server to identify Garcia-Martin, et al. Expires December 15, 2003 [Page 7] Internet-Draft Diameter Multimedia application June 2003 the URI of SIP server 2, so as to return subsequent requests to the same SIP server 2. At this point, the Diameter server will be able to authenticate the user, and upon success, will return a Diameter MAA message (step 14) with the AVP Result-Code set to the value DIAMETER_SUCCESS. The Diameter MAA message will also include the user profile information, which the SIP server 2 will use to give service to the user. [AL] I thought Diameter already remembered the URI of SIP server 2 in the exchange that took place in Step 5? SIP server 2 will then generate a SIP 200 (OK) response (step 15) which is forwarded to SIP server 1 and eventually to the SIP UAC (step 16). [AL] How does Diameter Server know that the second UAR in (step 10) is associated with the same session as the one in MAR/MAA in (step 6)? What happens if the UAC is involved in multiple simultaneous operations some of which would be routed to different SIP servers? 3.2 SIP server authenticates the user [AL] Very little difference between this scenario and the one above. I found it uncessary to re-read steps 1 to 12 again. Suggest that you truncate this section and talk about the salient differences so we dont have to re-read. An operator with a large base of installed SIP servers may wish to minimize the impact of modifying SIP servers to interact with Diameter servers. This can be achieved by allowing SIP servers to retain the functionality of authentication, rather than centralizing this capability in a Diameter server. However, it should be noted that this mode will not leverage the extensive array of authentication and authorization services which will already be present regardless in Diameter servers. [AL] I think you want to say an *existing* installed based. Because new deployements would probably not have the SIP server do the authentication for the reasons you mention. ............. When the SIP server 1 receives a next SIP REGISTER request containing the user credentials (step 9), as the SIP server 1 does not need to keep a state (even there is no guarantee that the SIP request arrives to the same SIP server 1), the Diameter client in SIP server 1 will contact again the Diameter server by sending a Diameter UAR message (step 10) to determine the SIP server allocated to the user. The Diameter server will send the SIP or SIPS URI of SIP server 2 in a Diameter UAA message (step 11). [AL] Change "When the SIP server 1" to: "When SIP server 1" above. SIP server 1 will then forward the SIP REGISTER request to SIP server 2 (step 12). SIP server 2 will validate the credentials, and will send a Diameter Server-Assignment-Request (SAR) message (step 13) requesting the Diameter server to store the SIP or SIPS URI of the SIP server that is currently serving the user. The Diameter SAR message also serves the purpose to request the Diameter server to send the user profile to the SIP server. The Diameter server will respond with a Diameter Server-Assignment-Answer (SAA) message (step 14). If the Result-Code AVP value does not inform about an error, the User-Data AVP will contain the information that SIP server 2 needs in order to provide a service to the user. The SIP server 2 will generate then a SIP 200 (OK) response (step 15) that will be forwarded to SIP server 1 and eventually to the SIP UAC (step 16). [AL] Change "The SIP server 2 will generate then a" to "SIP server 2 generates a" above. 3.3 Session attempt Figure 4 shows the scenario where the SIP server 1 receives a SIP INVITE request (step 1). The SIP server 1 needs to find the address of the SIP server 2, which is serving the addressed UA. Therefore, the Diameter client in SIP server 1 sends Diameter Location-Info-Request (LIR) message (step 2) to the Diameter server. The Diameter server responds with a Diameter Location-Info-Answer (LIA) message (step 3) that contains the SIP or SIPS URI of the SIP server 2. SIP server 1 then forwards the SIP INVITE to SIP server 2 (step 4). SIP server 2 will eventually forward the SIP INVITE to the appropriate UAS (step 5). [AL] Change "where the SIP server 1 receives" to "where SIP server 1 receives" above. [AL] Change "The SIP server 1 needs to" to "SIP Server 1 needs to" +--------+ +--------+ +--------+ | SIP | |Diameter| | SIP | |server 1| | server | |server 2| +--------+ +--------+ +--------+ | | | 1. SIP INVITE | | | Garcia-Martin, et al. Expires December 15, 2003 [Page 10] Internet-Draft Diameter Multimedia application June 2003 -------------->| 2. LIR | | |------------------>| | | 3. LIA | | |<------------------| | | 4. SIP INVITE | |-------------------------------------->| | | | 5. SIP INVITE | | |--------------> | | | | | | Figure 4 Although the example shows the connection between a SIP INVITE request and the Diameter LIR message, any other SIP request (such as SUBSCRIBE, OPTIONS, etc.) would trigger the same Diameter message. [AL] So from the above par. I get that a SIP REGISTER will generate a Diameter LIR message. Is that true? 3.4 Update of the user profile The Diameter Multimedia application provides a mechanism for a Diameter server to asynchronously download a user profile to a SIP server whenever there is an update of such user profile. It must be noted that the Diameter server also attaches the user profile in the Diameter Server-Assignment-Request (SAR) message. Although this is valid for most of the daily situations, it may happen that the administrator decides to update or modify the user profile for a particular user, due to, e.g., new services made available to the user. This may involve a human intervention in the Diameter server or some mechanism outside the scope of this specification. In this situation, the Diameter server is able to push the new user profile into the SIP server allocated to the user. [AL] Change "This may involve a human intervention in the Diameter server or some mechanism outside the scope of this specification" to "This may involve mechanisms outside the scope of this specification such as human intervention in the Diameter server" [AL] Change "The scenario is described in Figure 5" to "The scenario is illustrated in Figure 5" below. The scenario is described in Figure 5. In case the user profile changes, the Diameter server will send a Diameter Push-Profile-Request (PPR) message (step 1) to the Diameter client in the SIP server allocated to that user (SIP server 2 in the examples). The Diameter PPR message will contain a SIP-User-Data AVP, a User-Name AVP and zero or more SIP-Public-User-Identity AVPs. The presence of the User-Name AVP without any SIP-Public-User-Identity AVPs serves to indicate that the entire user profile (included in the SIP-User-Data AVP) associated with the User-Name AVP is updated. A Diameter PPR message with a User-Name AVP and one or more SIP-Public-User-Identity AVPs serves to indicate that the user profile data associated with each of the SIP-Public-User-Identity AVPs is updated. The Diameter client in SIP server 2 will acknowledge the Diameter PPR message by sending a Diameter Push-Profile-Answer (PPA) message (step 2) to the Diameter server. ......... 3.5 Registration termination Termination of a user registration can be achieved by either of the following three mechanisms: [AL] I am having trouble with this because i dont know where or when Auth-Session-State AVP is delivered. In the event that NO_STATE_MAINTAINED (i.e., No Diameter user session-id is maintained) has been indicated in a prior Auth-Session-State AVP, termination is handled with a Diameter Session-Termination-Request (STR) message (if it is initiated by the Diameter Client/SIP Proxy) or with a Diameter Registration-Termination-Request (RTR) message (if it is initiated by the Diameter server). On the other hand, if STATE_MAINTAINED has been indicated in a prior Auth-Session-State AVP, the use of Diameter Session-Termination-Request (STR) and Abort-Session-Request (ASR) messages as defined in the base Diameter specification [2] are used to terminate a user registration. Last, if the Diameter server receives a Diameter Server-Assignment-Request (SAR) message that contains a SIP-Server-Assignment-Type set to the value DE-REGISTRATION, the Diameter server will proceed with the deregistration of the user. [AL] Move the stuff below to the start of the section. Reasons for terminating a user registration include: o Expiration of the SIP registration timer in the SIP server. o Administrative action taken at the Diameter server. o The SIP UAC generates a SIP REGISTER request setting the Expires header field value to zero or the expires parameter in the Contact header field to zero (e.g., user initiated deregistration). 4. Advertising Application Support Diameter nodes conforming to this specification MAY advertise its support by including the Auth-Application-Id AVP in the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands, according to the Diameter base protocol [2]. Avi Lior Bridgewater Systems Corporation Phone : (613) 591-9104 x6417 or (613) 591-6655 Fax : (613) 591-6656 E-mail : avi@bridgewatersystems.com www.bridgewatersystems.com