From dime-bounces@ietf.org Wed Jan 02 08:36:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA3m8-00007v-An; Wed, 02 Jan 2008 08:36:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA3m6-00007q-QH for dime@ietf.org; Wed, 02 Jan 2008 08:36:50 -0500 Received: from wa-out-1112.google.com ([209.85.146.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JA3m4-0001za-H9 for dime@ietf.org; Wed, 02 Jan 2008 08:36:50 -0500 Received: by wa-out-1112.google.com with SMTP id k40so10826826wah.25 for ; Wed, 02 Jan 2008 05:36:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; bh=S22mDkalQd/iZ1KqNEiTtd+m85ju5LNcY7b1l6Ps/qA=; b=kh979DaAoH2nGcEZPJqZ7VT6k1Lf0uIgDiK/EG84XP16Y3lAvYkTvNee7B55ZwO7NVf2CS4TdvCZNXivVoa1djPy3DBU4C4IdBOiJtkcFmvTuCxLOpw48h2fJh1EyNU6QmmWFIixwiy9tdFgBB15P45rc8SpDCVc72G+M7zt2Ow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type; b=iGMqyhBSPmPqqn58F3DMLn+SGi3yi8wlKDOg/6opIQ1UT7Au42oaeC1p0NfDhsMt+TiMNCgSg+65cgs3fGfWPxvWISh1DGkNdj8tAnZ45/lIsyyfQHTob9H39pG+fY33XVdnM/EIXVARu40DsS8ZKJiny/Oi4QRqFMIKBX/NGKM= Received: by 10.110.62.14 with SMTP id k14mr2300690tia.18.1199281006409; Wed, 02 Jan 2008 05:36:46 -0800 (PST) Received: by 10.110.26.14 with HTTP; Wed, 2 Jan 2008 05:36:46 -0800 (PST) Message-ID: Date: Wed, 2 Jan 2008 22:36:46 +0900 From: "Jong-Hyouk Lee" To: jouni.korhonen@iki.fi MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: dime@ietf.org Subject: [Dime] Comments on Diameter Proxy Mobile IPv6 (draft-korhonen-dime-pmip6-02.txt). X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1785825734==" Errors-To: dime-bounces@ietf.org --===============1785825734== Content-Type: multipart/alternative; boundary="----=_Part_27696_22475290.1199281006398" ------=_Part_27696_22475290.1199281006398 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear colleagues. I'm happy to see that a document regarding Diameter supports for PMIPv6 appears in dime wg. Here are some comments. Through the document, the authors describe that a mobile node performs an access authentication procedure. However, the authors should describe that the mobile node is performed the access authentication procedure by the network entities. For instance, the mobile node is authenticated by the mobile access gateway acting as a network access server. In page 6, the authors mention about a dynamic security association between the mobile access gateway and the local mobility anchor. Well, as you know, according to the base document of PMIPv6, the signaling messages between the mobility entities must be protected within the integrity and data origin authentication manners. However, there is not only a dynamic security association. We can use a static security association and others. Why are you mentioning only for the dynamic method? In addition, the text ("Prior to ... is out of scope of this specification.") seems to be a superfluous text. Cheers. -- Internet Management Technology Lab, Sungkyunkwan University. Jong-Hyouk Lee. #email: jonghyouk (at) gmail (dot) com #webpage: http://cv.hurryon.org ------=_Part_27696_22475290.1199281006398 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Dear colleagues.
I'm happy to see that a document regarding Diameter supports for PMIPv6 appears in dime wg. Here are some comments.
 
Through the document, the authors describe that a mobile node performs an access authentication procedure. However, the authors should describe that the mobile node is performed the access authentication procedure by the network entities. For instance, the mobile node is authenticated by the mobile access gateway acting as a network access server.
 
In page 6, the authors mention about a dynamic security association between the mobile access gateway and the local mobility anchor. Well, as you know, according to the base document of PMIPv6, the signaling messages between the mobility entities must be protected within the integrity and data origin authentication manners. However, there is not only a dynamic security association. We can use a static security association and others. Why are you mentioning only for the dynamic method? In addition, the text ("Prior to ... is out of scope of this specification.") seems to be a superfluous text.
 
Cheers.

--
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://cv.hurryon.org
------=_Part_27696_22475290.1199281006398-- --===============1785825734== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1785825734==-- From dime-bounces@ietf.org Wed Jan 02 15:41:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAAOb-0007Nf-Eq; Wed, 02 Jan 2008 15:41:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAAOZ-0007Na-Dt for dime@ietf.org; Wed, 02 Jan 2008 15:40:59 -0500 Received: from gw01.mail.saunalahti.fi ([195.197.172.115]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAAOY-0001PK-DT for dime@ietf.org; Wed, 02 Jan 2008 15:40:59 -0500 Received: from [88.112.205.179] (a88-112-205-179.elisa-laajakaista.fi [88.112.205.179]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 62DC4151530; Wed, 2 Jan 2008 22:40:55 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <047BD4FA-475B-412D-8E19-C2D8EFDB1BEE@iki.fi> Content-Transfer-Encoding: 7bit From: Jouni Korhonen Date: Wed, 2 Jan 2008 22:40:46 +0200 To: Jong-Hyouk Lee X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: dime@ietf.org Subject: [Dime] Re: Comments on Diameter Proxy Mobile IPv6 (draft-korhonen-dime-pmip6-02.txt). X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Jong-Hyouk, Thank you for the review. I have included some initial comments. See those inline. On Jan 2, 2008, at 3:36 PM, Jong-Hyouk Lee wrote: > Dear colleagues. > I'm happy to see that a document regarding Diameter supports for > PMIPv6 appears in dime wg. Here are some comments. > > Through the document, the authors describe that a mobile node > performs an access authentication procedure. However, the authors > should describe that the mobile node is performed the access > authentication procedure by the network entities. For instance, the > mobile node is authenticated by the mobile access gateway acting as > a network access server. There is definitely room for improving text here. E.g. in the case of EAP-based network access authentication the MAG acts as a pass-through authenticator, when AAA backend is used. In this case the MAG is essentially a NAS but does not really authenticate the mobile. Other authentication method could be different. Do you have any text to propose that would address your concern? > > In page 6, the authors mention about a dynamic security association > between the mobile access gateway and the local mobility anchor. > Well, as you know, according to the base document of PMIPv6, the > signaling messages between the mobility entities must be protected > within the integrity and data origin authentication manners. Section 6.3 is a bit more verbal on the MAG-LMA SA setup. > However, there is not only a dynamic security association. We can > use a static security association and others. Why are you > mentioning only for the dynamic method? In addition, the text > ("Prior to ... is out of scope of Section 6.3 mentions statically configured SAs. I still believe that most of the MAG-LMA SA setup is out of scope of PMIP6 AAA documents. > this specification.") seems to be a superfluous text. We have been intentionally rather short on the MAG-LMA SA setup procedures. This is mainly because PMIP6 has very little or nothing to do with this SA setup. If the SA was manually configured, nothing is done AAA wise when the mobile roams into the PMIP6 domain. If the SA is dynamically configured then the only relation between the PMIP6 and the SAs setup is that the roaming mobile triggers the creation of the SA. This holds for IKE/IPSec based SAs. And there are existing AAA specs for those already. Of course there can be tighter coupling but that then falls more into system specific solutions and imho are out of scope. Cheers, Jouni > > Cheers. > > -- > Internet Management Technology Lab, Sungkyunkwan University. > Jong-Hyouk Lee. > > #email: jonghyouk (at) gmail (dot) com > #webpage: http://cv.hurryon.org _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 03 06:05:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JANsm-0004mt-MX; Thu, 03 Jan 2008 06:05:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JANsl-0004mo-Hh for dime@ietf.org; Thu, 03 Jan 2008 06:05:03 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JANsj-0005cB-LH for dime@ietf.org; Thu, 03 Jan 2008 06:05:03 -0500 Received: (qmail invoked by alias); 03 Jan 2008 11:05:00 -0000 Received: from proxy2-nsn.nsn-inter.net (EHLO [217.115.75.230]) [217.115.75.230] by mail.gmx.net (mp034) with SMTP; 03 Jan 2008 12:05:00 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18kQgpD620kOmxwa9U61vyHhjJRnyiEUgjrln9Up3 xU6xz5OiSGksLH Message-ID: <477CC15B.2040809@gmx.net> Date: Thu, 03 Jan 2008 12:04:59 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Dime] 2nd WGLC: Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, this message marks the issuance of the second working group last call (WGLC) on DIME's Internet Draft entitled "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction" (draft-ietf-dime-mip6-integrated-07.txt). You may view this document at http://tools.ietf.org/html/draft-ietf-dime-mip6-integrated-07 In August 2007 we initiated the 1st WGLC on draft-ietf-dime-mip6-integrated-05.txt, see http://www1.ietf.org/mail-archive/web/dime/current/msg01940.html Based on the feedback from the group version 6 and version 7 of the draft have seen some changes: http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-dime-mip6-integrated-06.txt http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-dime-mip6-integrated-07.txt We would therefore like to initiate a short 2nd WGLC to ensure that all comments have been properly captured. Please post comments and questions to the DIME mailing list no later than 12th Jan 2008. Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 08 03:35:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC9vH-00080D-P4; Tue, 08 Jan 2008 03:34:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JByjZ-0004xQ-03; Mon, 07 Jan 2008 15:38:09 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JByjW-0008LI-Ho; Mon, 07 Jan 2008 15:38:08 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m07KbOEm019541; Mon, 7 Jan 2008 14:37:54 -0600 (CST) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.8]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 14:37:33 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Dime] dime-diameter-qos-01 handling of QoS Signaling Proxies Date: Mon, 7 Jan 2008 14:37:31 -0600 Message-ID: <09C9068466B79E4C938DC7737562404D011B8A50@ILEXC2U01.ndc.lucent.com> In-Reply-To: <48864988-1E39-4E55-A087-A0FDFC974C50@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] dime-diameter-qos-01 handling of QoS Signaling Proxies Thread-Index: AchIcK9C3Vje7sBVRSSbNeTf3ZUuKgI+JFSw References: <8CA3470D-D813-4184-9F09-66766FA33ED1@cisco.com> <09C9068466B79E4C938DC7737562404D01170015@ILEXC2U01.ndc.lucent.com> <48864988-1E39-4E55-A087-A0FDFC974C50@cisco.com> From: "Sun, Dong \(Dong\)" To: "Francois Le Faucheur IMAP" X-OriginalArrivalTime: 07 Jan 2008 20:37:33.0822 (UTC) FILETIME=[21AB51E0:01C8516D] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: d27bcecefa39151076cbd05fb7126916 X-Mailman-Approved-At: Tue, 08 Jan 2008 03:34:57 -0500 Cc: dime@ietf.org, tsvwg tsvwg X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1870392678==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1870392678== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8516D.2147628F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8516D.2147628F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois, =20 Concerning the behavior of source/receiver proxy in NE, not sure if an explicit dictation (e.g. whether or not the proxy initiates or terminates the signaling) should be sent from the authorizing entity. As said in last email, this will make the AE more complicated and impractical in certain scenarios. =20 This is my 2 cents how the NE behaves. When NE receives the QoS decision from the AE (e.g. reserve certain amount of BW. Certainly the AE may specify which network segment the resource should be reserved), it will decide how to check the resource availability and perform the resource reservation based on the deployed network technology, for instance, initiates an NSIS/RSVP signaling to reserve the BW on a specific network segment (rather than using e2e signaling).=20 =20 Moreover, from the stds document perspective, the QoS specific AVPs is out of scope in this protocol document and should be define in another document i.e. QoS attributes (although I don't think there is a need to define an explicit AVP for this purpose, but it is a separate issue). =20 Anyway, in order to clarify this matter, I'd like to add some words into the example section to indicate the NE can serve as signaling proxy and process the QoS signaling accordingly in addition to the words about e2e signaling handling.=20 =20 any comments? =20 Regards, =20 Dong ________________________________ From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com]=20 Sent: Thursday, December 27, 2007 5:10 AM To: Sun, Dong (Dong) Cc: Francois Le Faucheur IMAP; dime@ietf.org; tsvwg tsvwg Subject: Re: [Dime] dime-diameter-qos-01 handling of QoS Signaling Proxies Hello Dong,=20 Thanks for looking into how to incorporate handling of signaling proxies into Diameter QoS Application.=20 Thoughts embedded below: On 27 Dec 2007, at 00:05, Sun, Dong ((Dong)) wrote: Hi Francois, =20 I have no disagreement to make NEs serve as QoS signaling proxy and support non-e2e signaling scenarios.=20 Great. However, not sure if I understood your examples correctly, it seems the Authorizing entity is required to instruct the NE for initiating and/or terminating the QoS signaling, which makes AE become a QoS signaling aware entity. The idea is not to turn the AE into a QoS signaling aware entity.=20 However, I think the AE has to be aware of a few very very basic things related to QoS signaling. I don't see this as a departure from the current model of DQA operation in the case of e2e signaling. With e2e signaling, the AE is not really QoS signaling aware, however the AE understands just enough to realize that it needs to authorize the user to request an e2e reservation (ie not just a local resource reservation).=20 Similarly in the case of signaling proxies, again the AE is not really QoS signaling aware, but it would understand a few very basic things about QoS signaling. For example, in the scenario where the AE is used to trigger signaling initiation on the signaling _sender_ proxy, the AE has to be sufficiently aware of what it is trying to do in order to initiate a DQA Push towards the Network Element on the sender side (as opposed to the NE on the receiver side). And in this case, I think the AE simply has to be able to say inside the DQA push message: "I authorize the QoS resources, and the corresponding reservation needs to be established".=20 Similarly, in the scenario where the AE is used to authorize a QoS signaling reservation in the Pull-model, it would be useful for the AE to be able to provide a hint in the response as to whether signaling should be terminated by a receiver proxy or not. This is because the need to activate receiver proxy behavior (or not) may depend on the per-user-policy (so the NE cannot know, while AE does). =09 =20 IMHO, it would be better to allow NE itself decide how to operate on QoS signaling based on the policy decisions from AE for the following reasons: - It is more flexible to make AE as a transport signaling independent entity, especially for support of various signalings used by different transport networks, including RSVP, NSIS, even ANCP and others since AE is usually an overlay logical (and off path) Diameter node per se, and in certain circumstances e.g. inter-domain case, it is awkward to have AE involved in the decision and instruction of QoS signaling handling across the administrative domain. - According to the current modeling (see fig. 2 in "qos-01"), there is a resource management function (and other signaling processing functions) co-located with Diameter client in the NE, it would be more appropriate to handle this kind of function by these underneath blocks rather than Diameter nodes. =20 In order to reflect this kind of capability (i.e. support non-e2e QoS signaling), the examples in section 7 of "qos-02" can be edited to indicate that NE should be able to initiate and/or terminate the QoS signaling based on policy decisions received from Authorizing entity I think I am agreeing with the statement above that "the NE should be able to initiate/terminate the QoS signaling based on policy decisions received from AE".=20 But I am saying that this "policy decision received from the AE" needs to contain a few hints about whether source proxy/receiver proxy behavior should be activated by NE.=20 I have no opinion about how the hints should be conveyed (new flags/fields in existing AVP, new AVP,...), as long as the information is conveyed. I think the information that needs to be conveyed boils down to: * sender proxy behavior requested/not-requested * receiver proxy behavior requested/not-requested Makes sense? Francois (it seems no need to add additional example call flows dedicatedly for this feature).=20 =20 Best Regards, Dong ________________________________ From: Francois Le Faucheur [mailto:flefauch@cisco.com]=20 Sent: Tuesday, September 11, 2007 8:55 AM To: dime@ietf.org Cc: Le Faucheur Francois; tsvwg tsvwg Subject: [Dime] dime-diameter-qos-01 handling of QoS Signaling Proxies =09 =09 Hello,=20 =09 =09 dime-diameter-qos-01 defines a Diameter application for QoS reservations. When dealing with QoS signaling (such as RSVP or NSIS), it seems to assume that reservation signaling always takes place end-to-end. However, there are useful QoS reservation deployment models where reservation signaling does not quite happen end-to-end. Instead QoS signaling may be initiated by a Signaling Sender Proxy (on behalf of the actual sender) or terminated by a Signaling Receiver Proxy (on behalf of the actual receiver). =09 =09 draft-ietf-tsvwg-rsvp-proxy-approaches discusses RSVP Sender Proxy and RSVP Receiver Proxy. NSIS has defined similar NSIS signaling proxy entities. =09 =09 I believe it would be very useful if the "Diameter Application for QoS reservations" could be extended to deal with scenarios involving QoS Reservation Proxies operating inside the AAA-controlled Network Elements. Two key example additional capabilities I would see are: *A* ability for the AAA Authorizing Entity to instruct a Network Element (eg the sender-facing NE) to initiate QoS signaling on behalf of the sender (e.g. instructing the NE to behave as a RSVP Sender Proxy). *B* on receipt of a QoS Authorization Request from a NE, ability for the AAA Authorizing Entity to instruct the NE to close the signaling loop on behalf of the receiver (e.g. instructing the NE to behave as a RSVP Receiver Proxy). =09 =09 Just for illustration, *A* could perhaps look something like this: =09 =09 Authorizing End-Host Network Element Entity requesting QoS ( Diameter ( Diameter QoS Client) QoS Server) | | | | | +--------+--------------+ | | | Authorize new flow | | | | .... | | | | Sig Sender Proxy needed| | | +--------+--------------+ | |< - - - - XXX - - - - - -+ | | (...Sender-Proxy) | | +-------+---------+ | |Install QoS state| | | + | | | Initiate QoS | | | Reservation | QoS Responder | | | Node | +-------+---------+ | | +----------QoS-Reserve---....--->| | | | | |<---------QoS-Response--....----| | | | = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DData = Flow=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D....=3D=3D=3D>| | | | +- - - - - ACR - - - - - >| | |(START,QoS-Resources,Cost| | |CC-Time,Acc-Multisess-id)| | | +--------+--------------+ | | | Report for successful | | | | QoS reservation | | | |Update of reserved QoS | | | | resources | | | +--------+--------------+ | |< - - - - ACA - - - - - -+ | | | =09 =09 =09 =09 =09 =09 Just for illustration, *B* could perhaps look something like this: =09 =09 Authorizing End-Host Network Element Entity requesting QoS ( Diameter ( Diameter QoS Client) QoS Server) | | | +---QoS-Reserve---->| | | +- - - - - QAR - - - - - >| | |(QoS-Resources,Cost, | | | QoS-Auth-Data,User-ID)| | | +--------+--------------+ | | | Authorize request | | | | ... | | | | Sig Receiver Proxy needed| | | +--------+--------------+ | |< - - - - YYY - - - - - -+ | |(Result-Code,CC-Time,Cost| | |... Receiver-Proxy)| | +-------+---------+ | |Install QoS state| | | + | | | Authz. session | | | /Authz-time, | QoS Responder | | CC-Time,Cost/ | Node | |+ Receiver Proxy | | | +-------+---------+ | | + | | | | | | | |<--QoS-Response----+ | | | | = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DData = Flow=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D....=3D=3D=3D>| | | | +- - - - - ACR - - - - - >| | |(START,QoS-Resources,Cost| | |CC-Time,Acc-Multisess-id)| | | +--------+--------------+ | | | Report for successful | | | | QoS reservation | | | |Update of reserved QoS | | | | resources | | | +--------+--------------+ | |< - - - - ACA - - - - - -+ | | | =09 =09 =09 =09 Using the terminology of section 3.2 of dime-diameter-qos-01: - *A* above can be used to support the Push model augmented with QoS reservation inside the network. It is applicable to sender endpoints of Category 1, 2 and 3. - *B* above can be used to support the Push Model augmented with QoS reservation inside the network. It is applicable to receiver endpoints of Category 1, 2 and 3. - *B* above can also be used to support the Pull Model even with non-QoS_signaling Capable Receiver endpoints (ie of Category 1 and 2) =09 =09 Would the DIME WG be willing to address these QOS reservation proxy scenarios in dime-diameter-qos? =09 =09 Thank you =09 =09 FRancois =09 =09 ------_=_NextPart_001_01C8516D.2147628F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Francois,
 
Concerning the behavior of source/receiver = proxy in NE, not=20 sure if an explicit dictation (e.g. whether or not the proxy initiates = or=20 terminates the signaling) should be sent from the authorizing = entity. As=20 said in last email, this will make the AE more complicated=20 and impractical in certain scenarios.
 
This is my 2 cents how the NE behaves. When NE = receives the=20 QoS decision from the AE (e.g. reserve certain amount of BW. Certainly = the AE=20 may specify which network segment the resource should be reserved), it = will=20 decide how to check the resource availability and perform the resource=20 reservation based on the deployed network technology, for instance, = initiates an NSIS/RSVP signaling to reserve the BW on a specific = network=20 segment (rather than using e2e signaling).
 
Moreover, from the stds document perspective, = the QoS=20 specific AVPs is out of scope in this protocol document and should be = define in=20 another document i.e. QoS attributes (although I don't think there is a = need to=20 define an explicit AVP for this purpose, but it is a separate=20 issue).
 
Anyway, in order to clarify this matter, I'd = like to add=20 some words into the example section to indicate the NE can serve as = signaling proxy and process the QoS signaling accordingly in addition to = the=20 words about e2e signaling handling.
 
any comments?
 
Regards,
 
Dong

From: Francois Le Faucheur IMAP=20 [mailto:flefauch@cisco.com]
Sent: Thursday, December 27, 2007 = 5:10=20 AM
To: Sun, Dong (Dong)
Cc: Francois Le Faucheur = IMAP;=20 dime@ietf.org; tsvwg tsvwg
Subject: Re: [Dime] = dime-diameter-qos-01=20 handling of QoS Signaling Proxies

Hello Dong,

Thanks for looking into how to incorporate handling of signaling = proxies=20 into Diameter QoS Application. 
Thoughts embedded below:

On 27 Dec 2007, at 00:05, Sun, Dong ((Dong)) wrote:
Hi Francois,
 
I have no disagreement to make NEs serve as = QoS=20 signaling proxy and support non-e2e signaling=20 scenarios. 

Great.

However, not sure if I understood your = examples=20 correctly, it seems the Authorizing entity is required to instruct the = NE for=20 initiating and/or terminating the QoS signaling, which makes AE become = a QoS=20 signaling aware entity.

The idea is not to turn the AE into a QoS signaling aware=20 entity. 

However, I think the AE has to be aware of a few very very basic = things=20 related to QoS signaling. I don't see this as a departure from the = current model=20 of DQA operation in the case of e2e signaling. With e2e signaling, the = AE is not=20 really QoS signaling aware, however the AE understands just enough to = realize=20 that it needs to authorize the user to request an e2e reservation (ie = not just a=20 local resource reservation). 

Similarly in the case of signaling proxies, again the AE is not = really QoS=20 signaling aware, but it would understand a few very basic things about = QoS=20 signaling.
For example, in the scenario where the AE is used to trigger = signaling=20 initiation on the signaling _sender_ proxy, the AE has to be = sufficiently aware=20 of what it is trying to do in order to initiate a DQA Push towards the = Network=20 Element on the sender side (as opposed to the NE on the receiver = side).
And in this case, I think the AE simply has to be able to say = inside the=20 DQA push message: "I authorize the QoS resources, and the corresponding=20 reservation needs to be established". 

Similarly, in the scenario where the AE is used = to authorize a=20 QoS signaling reservation in the Pull-model, it would be useful for the = AE to be=20 able to provide a hint in the response as to whether signaling should be = terminated by a receiver proxy or not. This is because the need to = activate=20 receiver proxy behavior (or not) may depend on the per-user-policy (so = the NE=20 cannot know, while AE does).


 
IMHO, it would be better to allow NE itself = decide=20 how to operate on QoS signaling based on the policy decisions from AE = for the=20 following reasons:
- It is more flexible to make AE as a = transport=20 signaling independent entity, especially for support of various = signalings=20 used by different transport networks, including RSVP, NSIS, even = ANCP and=20 others since AE is usually an overlay logical (and off=20 path) Diameter node per se, and in certain circumstances e.g.=20 inter-domain case, it is awkward to have AE involved in the decision = and=20 instruction of QoS signaling handling across the administrative=20 domain.
- According to the current modeling (see = fig. 2 in=20 "qos-01"), there is a resource management function (and other = signaling=20 processing functions) co-located with Diameter client in the = NE, it=20 would be more appropriate to handle this kind of function by these = underneath=20 blocks rather than Diameter nodes.
 
In order to reflect this kind of capability = (i.e.=20 support non-e2e QoS signaling), the examples in section 7 of "qos-02" = can be=20 edited to indicate that NE should be able to initiate and/or terminate = the QoS=20 signaling based on policy decisions received from Authorizing=20 entity

I think I am agreeing with the statement above that "the NE should = be able=20 to initiate/terminate the QoS signaling based on policy decisions = received from=20 AE". 
But I am saying that this "policy decision received from the AE" = needs to=20 contain a few hints about whether source proxy/receiver proxy behavior = should be=20 activated by NE. 
I have no opinion about how the hints should be conveyed (new = flags/fields=20 in existing AVP, new AVP,...), as long as the information is=20 conveyed.

I think the information that needs to be conveyed boils down = to:
* = sender proxy=20 behavior requested/not-requested
* = receiver proxy=20 behavior requested/not-requested

Makes sense?

Francois

(it seems no need to add additional example = call=20 flows dedicatedly for this feature).=20
 
Best Regards,
Dong

From: Francois Le Faucheur [mailto:flefauch@cisco.com]=20
Sent: Tuesday, September 11, 2007 8:55 AM
To: dime@ietf.org
Cc: Le = Faucheur=20 Francois; tsvwg tsvwg
Subject: [Dime] dime-diameter-qos-01 = handling=20 of QoS Signaling Proxies

Hello, =
dime-diameter-qos-01 defines a=20 Diameter application for QoS reservations. When dealing with QoS = signaling=20 (such as RSVP or NSIS), it seems to assume that reservation signaling = always=20 takes place end-to-end. However, there are useful QoS reservation = deployment=20 models where reservation signaling does not quite happen end-to-end. = Instead=20 QoS signaling may be initiated by a Signaling Sender Proxy (on behalf=20 of the actual sender) or terminated by a Signaling Receiver Proxy = (on=20 behalf of the actual receiver).
draft-ietf-tsvwg-rsvp-proxy-approaches discusses RSVP = Sender=20 Proxy and RSVP Receiver Proxy. NSIS has defined similar NSIS signaling = proxy=20 entities.
I believe it would = be very=20 useful if the "Diameter Application for QoS reservations" could be = extended to=20 deal with scenarios involving QoS Reservation Proxies operating inside = the=20 AAA-controlled Network Elements. Two key example additional = capabilities=20 I would see are:
*A* ability for the AAA = Authorizing Entity=20 to instruct a Network Element (eg the sender-facing NE) to initiate = QoS=20 signaling on behalf of the sender (e.g. instructing the NE to behave = as a RSVP=20 Sender Proxy).
*B* on receipt of a = QoS Authorization=20 Request from a NE, ability for the AAA Authorizing Entity to = instruct the=20 NE to close the signaling loop on behalf of the receiver (e.g. = instructing the=20 NE to behave as a RSVP Receiver Proxy).
Just for = illustration, *A*=20 could perhaps look something like this:
    =    =20                     =  =20                 =20 Authorizing
     = End-Host         Network Element    =  =20        Entity
   = requesting=20 QoS      ( Diameter          =  =20   ( Diameter
    =    =20                 QoS = Client) =20            QoS Server)
    =   =20 |                   = | =20                    =20    |
   =   =20  |                =   =20 |               =20 +--------+--------------+
    =   =20 |                   = | =20               |  Authorize new = flow   |
   =   =20  |                =   =20 |                |  =  =20     ....         =20  |
   =   =20  |                =   =20 |                | Sig Sender = Proxy=20 needed|
   =   =20  |                =   =20 |               =20 +--------+--------------+
    =   =20 |                   = |< -=20 - - - XXX - - - - - -+
   =   =20  |                =    |=20    (...Sender-Proxy)    |
    =   =20 |           = +-------+---------+
    =   =20 |           |Install QoS = state|
    =   =20 |           |       = + =20        |
    =   =20 |           | Initiate QoS  =20  |
    =   =20 |           | Reservation   =20  |                QoS=20 Responder
    =   =20 |           |      =20           |      =  =20             Node
    =   =20 |           +-------+---------+  =  =20                   = |
    =   =20 |                  =20 +----------QoS-Reserve---....--->|
    =   =20 |                   = | =20                     =  =20         |
    =   =20 |                  =20 |<---------QoS-Response--....----|
   =   =20  |                =   =20 |                    =  =20           |
    =   =20 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DData = Flow=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D....=3D=3D=3D>|
    =   =20 |                  =20 |
    =   =20 |                   = +- - - -=20 - ACR - - - - - >|
    =   =20 |                  =20 |(START,QoS-Resources,Cost|
    =   =20 |                  =20 |CC-Time,Acc-Multisess-id)|
    =   =20 |                   = | =20              =20 +--------+--------------+
    =   =20 |                   = | =20               | Report for = successful=20 |
    =   =20 |                   = | =20               |   QoS=20 reservation     |
    =   =20 |                   = | =20               |Update of reserved = QoS=20 |
    =   =20 |                   = | =20               |      = resources        |
    =   =20 |                   = | =20              =20 +--------+--------------+
    =   =20 |                   = |< -=20 - - - ACA - - - - - -+
    =   =20 |                   = | =20                    =20    |
Just for = illustration, *B*=20 could perhaps look something like this:
    =   =20                =   =20                =   =20     Authorizing
     = End-Host         Network Element    =  =20        Entity
   = requesting=20 QoS      ( Diameter          =  =20   ( Diameter
    =    =20                 QoS = Client) =20            QoS Server)
    =   =20 |                   = | =20                    =20    |
    =   =20 +---QoS-Reserve---->|            =  =20            |
    =   =20 |                   = +- - - -=20 - QAR - - - - - >|
    =   =20 |                  =20 |(QoS-Resources,Cost,     |
    =   =20 |                  =20 |   QoS-Auth-Data,User-ID)|
    =   =20 |                   = | =20              =20 +--------+--------------+
    =   =20 |                   = | =20               |  Authorize=20 request    |
    =   =20 |                   = | =20               |      =    ...          =  |
   =   =20  |                =   =20 |                | Sig = Receiver Proxy=20 needed|
    =   =20 |                   = | =20              =20 +--------+--------------+
    =   =20 |                   = |< -=20 - - - YYY - - - - - -+
    =   =20 |                  =20 |(Result-Code,CC-Time,Cost|
    =   =20 |                   = |...=20 Receiver-Proxy)|
    =   =20 |           = +-------+---------+
    =   =20 |           |Install QoS = state|
    =   =20 |           |       = + =20        |
    =   =20 |           | Authz. session =20 |
    =   =20 |           | /Authz-time,    = | =20               QoS = Responder
    =   =20 |           |  CC-Time,Cost/  = | =20                  =20 Node
   =   =20  |           |+ Receiver Proxy | =  =20                =   =20  |
   =   =20  |           = +-------+---------+ =20                    =20 |
    =   =20 |                   = + =20               =   =20             =  |
    =   =20 |                   = | =20                     =  =20         |
    =   =20 |                   = | =20               =   =20             =  |
    =   =20 |<--QoS-Response----+            =  =20                   = |
    =   =20 |                   = | =20                     =  =20         |
    =   =20 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DData = Flow=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D....=3D=3D=3D>|
    =   =20 |                  =20 |
    =   =20 |                   = +- - - -=20 - ACR - - - - - >|
    =   =20 |                  =20 |(START,QoS-Resources,Cost|
    =   =20 |                  =20 |CC-Time,Acc-Multisess-id)|
    =   =20 |                   = | =20              =20 +--------+--------------+
    =   =20 |                   = | =20               | Report for = successful=20 |
    =   =20 |                   = | =20               |   QoS=20 reservation     |
    =   =20 |                   = | =20               |Update of reserved = QoS=20 |
    =   =20 |                   = | =20               |      = resources        |
    =   =20 |                   = | =20              =20 +--------+--------------+
    =   =20 |                   = |< -=20 - - - ACA - - - - - -+
    =   =20 |                   = | =20                    =20    |
Using the = terminology of=20 section 3.2 of dime-diameter-qos-01:
- *A* above can be used to support = the Push=20 model augmented with QoS reservation inside the network. It = is=20 applicable to sender endpoints of Category 1, 2 and 3.
- *B* above can be used to support = the Push=20 Model augmented with QoS reservation inside the network. It is = applicable=20 to receiver endpoints of Category 1, 2 and 3.
- *B* above can also be used = to support=20 the Pull Model even with non-QoS_signaling Capable Receiver endpoints = (ie=20 of Category = 1 and=20 2)
Would the DIME WG = be willing to=20 address these QOS reservation proxy scenarios in=20 dime-diameter-qos?
Thank = you
FRancois

------_=_NextPart_001_01C8516D.2147628F-- --===============1870392678== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1870392678==-- From dime-bounces@ietf.org Tue Jan 08 11:08:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCH0c-0001pV-I2; Tue, 08 Jan 2008 11:08:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCH0a-0001pN-Uq for dime@ietf.org; Tue, 08 Jan 2008 11:08:56 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JCH0a-0006st-En for dime@ietf.org; Tue, 08 Jan 2008 11:08:56 -0500 Received: (qmail invoked by alias); 08 Jan 2008 16:08:55 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp047) with SMTP; 08 Jan 2008 17:08:55 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/g085pIjzgi3GIouDCUxRfOV+r9oHQH8MTPznABL HIsuWvR2btRksR Message-ID: <4783A016.8030509@gmx.net> Date: Tue, 08 Jan 2008 18:08:54 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [Dime] DIME Status Update, Jan. 2008 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Here is a new status update for the group: http://www.tschofenig.priv.at/twiki/bin/view/Dime/DimeStatusUpdate _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jan 11 14:16:06 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDPMM-0006a4-6S; Fri, 11 Jan 2008 14:16:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDPML-0006Zw-Hp for dime@ietf.org; Fri, 11 Jan 2008 14:16:05 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JDPMJ-00035s-R9 for dime@ietf.org; Fri, 11 Jan 2008 14:16:05 -0500 Received: (qmail invoked by alias); 11 Jan 2008 19:16:01 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp056) with SMTP; 11 Jan 2008 20:16:01 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19/PlcdxDN/YlRnvLo+4RQ+JcuVllt3AQ4fCvissq V9BhK/WWH4GwS4 Message-ID: <4787C06E.5020900@gmx.net> Date: Fri, 11 Jan 2008 21:15:58 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Dime] [Fwd: [MEXT] WGLC for draft-ietf-mext-aaa-ha-goals-00.txt] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This document lists the requirements for our Diameter mobility bootstrapping work. We should review it and provide feedback. Ciao Hannes -------- Original Message -------- Subject: [MEXT] WGLC for draft-ietf-mext-aaa-ha-goals-00.txt Date: Fri, 11 Jan 2008 19:35:14 +0100 From: marcelo bagnulo braun To: mext@ietf.org Hi, With this email we issue the WGLC for draft-ietf-mext-aaa-ha- goals-00.txt The WGLC will be open till the 31 of january. We kindly ask the WG to review the document and provide comments. Please note that a valid comment at this stage is positive feedback about the document being ready to be shipped. So, please if you think the doc is ready, do express this to the ml (or to the chairs) For you convenience, additional information about the document: Title : AAA Goals for Mobile IPv6 Author(s) : G. Giaretta, et al. Filename : draft-ietf-mext-aaa-ha-goals-00.txt Pages : 12 Date : 2007-12-27 In commercial and enterprise deployments Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the AAA infrastructure (e.g. NAS and AAA server) offers also a solution component for Mobile IPv6 bootstrapping. This document describes various scenarios where a AAA interface for Mobile IPv6 is required. Additionally, it lists design goals and requirements for such an interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-aaa-ha-goals-00.txt Regards, Julien and marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jan 14 02:38:17 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEJtg-0006Xk-CJ; Mon, 14 Jan 2008 02:38:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEJtf-0006Xb-7K for dime@ietf.org; Mon, 14 Jan 2008 02:38:15 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JEJte-0001Tg-CF for dime@ietf.org; Mon, 14 Jan 2008 02:38:15 -0500 Received: (qmail invoked by alias); 14 Jan 2008 07:38:12 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp043) with SMTP; 14 Jan 2008 08:38:12 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/wkrZNk+Pw2u76V7tJAOutfpGwpTOrSnyk+q2qVT za+6vgj+HgINbb Message-ID: <478B1163.9070005@gmx.net> Date: Mon, 14 Jan 2008 09:38:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: marcelo bagnulo braun References: <42D1E119-3163-42DE-BE95-4D32214BEFCD@bagnulo.net> In-Reply-To: <42D1E119-3163-42DE-BE95-4D32214BEFCD@bagnulo.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: dime@ietf.org, mext@ietf.org Subject: [Dime] Re: [MEXT] WGLC for draft-ietf-mext-aaa-ha-goals-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org A few minor comments below. FROM: The Home Agent can the assigned either in the Access Service Provider's network or in the seprate network. TO: The Home Agent can be assigned either in the Access Service Provider's network or in the separate network. G1.1 The AAAH server and the HA MUST be able to authenticate each other (mutual authentication) in order to prevent the installation of unauthorized state on the HA. In some deployment scenarios, it may not be feasible for HA and AAA server to mutually authenticate each other. In such a case, several AAA intermediate proxies could forward MIP6 bootstrapping information between HA and AAA. Thus, to prevent the installation of unauthorized state on the HA, the path between HA and AAAH should be secure. [hannes] "should be secure" is a bit fuzzy. In essence you are building on the AAA model with a hop-by-hop security mechanisms. Maybe a better wording would be " Thus, to prevent the installation of unauthorized state on the HA, the communication security mechanisms available with the AAA infrastructure MUST be used between adjacent AAA peers. " I would fold requirement G1.2 and G1.3 into G1.1 since they are so closely related. G2.10 The AAAH server MUST be able to authorize the MN for Dual Stack operation [9]. What exactly does this mean? G2.11 The AAAH server MUST be able to indicate to the HA whether the bearer traffic for the MN needs to receive IPsec ESP protection. I don't understand this either. G2.12 The HA MUST be able to authenticate the MN through the AAAH in case a pre-share key is used in IKEv2 for user authentication. The exact procedure is part of the solution space. Why do you list this requirement? I believe it is pretty much useless given that it is a consequence of the solution. I suggest to delete this requirement. G4.1 The AAA-HA interface MUST allow the HA to act as a pass-through EAP authenticator. This is a consequence of the already established solution. I suggest to delete it. G4.2 The AAA - HA interface SHOULD support authentication based on the Mobility Message Authentication Options defined in [5]. A solution must be specified in the specification but it's usage is optional. Section 5.4. about Mobile Node Authentication: G4.5 The HA MUST include the Mobile Node Identifier option [7] in the AAA transactions with the AAAH server. This requirement almost sounds like a solution description already. Isn't this a solution detail that does not need to be mentioned in such a document? The same is true for requirement G4.7, which says: G4.7 If the MN-AAA Mobility Message Authentication Option is not included by the HA or the MN-AAA Mobility Message Authentication Option is included and the MN-AAA authentication is successful, the AAAH MUST send the keying material for MN-HA key to the HA if the HA requested for MN-HA keying material only. The AAAH MUST send the MN-HA key and the corresponding SPI value to the HA if the HA requested for MN-HA key and SPI. This paragraph sounds really complex. The first sentence is pretty much irrelevant for such a requirements document. Isn't the 2nd sentence covered by requirement in G4.3 already? G4.6 The AAAH server SHOULD be able to authenticate the MN identified by the value in the Mobile Node Identifier option using the value in MN-AAA Mobility Message Authentication Option and the corresponding value of the SPI. Isn't requirement G4.6 already covered by the previous requirements? G6.2 The NAS SHOULD be able to notify the AAAH of the functionalities described in [4]. Couldn't we just list what it should notify the AAAH about? It isn't a lot. Ciao Hannes marcelo bagnulo braun wrote: > Hi, > > With this email we issue the WGLC for draft-ietf-mext-aaa-ha-goals-00.txt > The WGLC will be open till the 31 of january. > We kindly ask the WG to review the document and provide comments. > > Please note that a valid comment at this stage is positive feedback > about the document being ready to be shipped. > So, please if you think the doc is ready, do express this to the ml > (or to the chairs) > > For you convenience, additional information about the document: > > > Title : AAA Goals for Mobile IPv6 > Author(s) : G. Giaretta, et al. > Filename : draft-ietf-mext-aaa-ha-goals-00.txt > Pages : 12 > Date : 2007-12-27 > > In commercial and enterprise deployments Mobile IPv6 can be a service > offered by a Mobility Services Provider (MSP). In this case all > protocol operations may need to be explicitly authorized and traced, > requiring the interaction between Mobile IPv6 and the AAA > infrastructure. Integrating the AAA infrastructure (e.g. NAS and > AAA server) offers also a solution component for Mobile IPv6 > bootstrapping. This document describes various scenarios where a AAA > interface for Mobile IPv6 is required. Additionally, it lists design > goals and requirements for such an interface. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mext-aaa-ha-goals-00.txt > > Regards, Julien and marcelo > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jan 14 20:45:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEarv-0007ur-Cj; Mon, 14 Jan 2008 20:45:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEaru-0007uj-0p; Mon, 14 Jan 2008 20:45:34 -0500 Received: from wolverine02.qualcomm.com ([199.106.114.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEarr-0001mK-Rr; Mon, 14 Jan 2008 20:45:34 -0500 DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:Received:Received: X-MimeOLE:Content-class:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:Date:Message-ID: In-Reply-To:X-MS-Has-Attach:X-MS-TNEF-Correlator: Thread-Topic:Thread-Index:From:To:Cc: X-OriginalArrivalTime; b=M3EFvDWkKTKlj+i8hQpJ4NzXEvWPKQQII+/h9Wy+AvsD7A46bHvfCjvy Bd8WmfyBLMlL+znIv+Pkv8/agv9f6TFISN3BOeGZQWvl4U5ea9qXvXUsK ERKKAVLrThMKJEr4HIemt7jpk1lwzt0g84M6iNdeh5cXmjFQCFoo4wMvM M=; X-IronPort-AV: E=McAfee;i="5100,188,5206"; a="520864" Received: from numenor.qualcomm.com ([129.46.51.58]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jan 2008 17:45:27 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0F1jRSC023880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Jan 2008 17:45:27 -0800 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0F1jQqG006355; Mon, 14 Jan 2008 17:45:27 -0800 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jan 2008 17:45:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Jan 2008 17:45:25 -0800 Message-ID: In-Reply-To: <478B1163.9070005@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] WGLC for draft-ietf-mext-aaa-ha-goals-00.txt Thread-Index: AchWgHrr+fuLodV3QviY2PVH3F3MeAAlJjLg From: "Giaretta, Gerardo" To: "Hannes Tschofenig" , "marcelo bagnulo braun" X-OriginalArrivalTime: 15 Jan 2008 01:45:26.0910 (UTC) FILETIME=[4D6119E0:01C85718] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: dime@ietf.org, mext@ietf.org Subject: [Dime] RE: [MEXT] WGLC for draft-ietf-mext-aaa-ha-goals-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes, Thanks for the comments. Please see inline >=20 > A few minor comments below. >=20 >=20 > FROM: >=20 > The Home Agent can the assigned either in the Access Service > Provider's network or in the seprate network. >=20 >=20 > TO: >=20 > The Home Agent can be assigned either in the Access Service > Provider's network or in the separate network. >=20 > Good catch, thanks. =20 > G1.1 The AAAH server and the HA MUST be able to authenticate each > other (mutual authentication) in order to prevent the installation > of unauthorized state on the HA. > In some deployment scenarios, it > may not be feasible for HA and AAA server to mutually authenticate > each other. In such a case, several AAA intermediate proxies > could forward MIP6 bootstrapping information between HA and AAA. > Thus, to prevent the installation of unauthorized state on the HA, > the path between HA and AAAH should be secure. >=20 > [hannes] "should be secure" is a bit fuzzy. In essence you are building > on the > AAA model with a hop-by-hop security mechanisms. Maybe a better wording > would be >=20 > " > Thus, to prevent the installation of unauthorized state on the HA, > the communication security mechanisms available with the AAA > infrastructure > MUST be used between adjacent AAA peers. > " >=20 Good. I will change the text to the proposed one. Thanks > I would fold requirement G1.2 and G1.3 into G1.1 since they are so closely > related. >=20 What do you mean exactly? Are you suggesting to have a single requirement? >=20 >=20 >=20 > G2.10 The AAAH server MUST be able to authorize the MN for Dual > Stack operation [9]. >=20 > What exactly does this mean? >=20 It means that a MN may be authorized to use MIPv6 as in RFC3775 or may be authorized also to have an IPv4 HoA assigned for DSMIPv6.=20 >=20 > G2.11 The AAAH server MUST be able to indicate to the HA whether the > bearer traffic for the MN needs to receive IPsec ESP protection. >=20 > I don't understand this either. >=20 The AAA may indicate if the MIPv6 tunnel should be an IP-in-IP tunnel or an ESP tunnel.=20 >=20 >=20 > G2.12 The HA MUST be able to authenticate the MN through the AAAH in > case a pre-share key is used in IKEv2 for user authentication. > The exact procedure is part of the solution space. >=20 >=20 > Why do you list this requirement? I believe it is pretty much useless > given > that it is a consequence of the solution. I suggest to delete this > requirement. >=20 I agree it is a consequence of the solution. However, I think it is good to make it clear here as RFC 5026 provides text for PSK, EAP and certificates. I don't think it is bad to have it. > G4.1 The AAA-HA interface MUST allow the HA to act as a pass-through > EAP authenticator. >=20 > This is a consequence of the already established solution. I suggest to > delete it. >=20 >=20 Same as above. >=20 > G4.2 The AAA - HA interface SHOULD support authentication based on > the Mobility Message Authentication Options defined in [5]. >=20 > A solution must be specified in the specification but it's usage is > optional. >=20 Can you clarify your comment please? >=20 > Section 5.4. about Mobile Node Authentication: >=20 > G4.5 The HA MUST include the Mobile Node Identifier option [7] in > the AAA transactions with the AAAH server. >=20 >=20 > This requirement almost sounds like a solution description already. > Isn't this a solution detail that does not need to be mentioned in such > a document? >=20 Yes, you are probably right. The idea was that the HA MUST include an identifier of the MN in the AAA transactions.=20 A possible rewording could be "The HA MUST include an identifier of the mobile node in the AAA transactions with the AAAH server" Would that work? Or are you suggesting removing completely the goal? >=20 > The same > is true for requirement G4.7, which says: >=20 > G4.7 If the MN-AAA Mobility Message Authentication Option is not > included by the HA or the MN-AAA Mobility Message Authentication > Option is included and the MN-AAA authentication is successful, > the AAAH MUST send the keying material for MN-HA key to the HA if > the HA requested for MN-HA keying material only. The AAAH MUST > send the MN-HA key and the corresponding SPI value to the HA if > the HA requested for MN-HA key and SPI. >=20 >=20 > This paragraph sounds really complex. The first sentence is pretty much > irrelevant for such a requirements document. Isn't the 2nd sentence > covered > by requirement in G4.3 already? >=20 I agree we can remove the first sentence. The second sentence is different form G4.3, though: G4.3 is about the HA to request the keying material while G4.7 is about the AAAH sending it. Would you prefer merge the two goals? >=20 > G4.6 The AAAH server SHOULD be able to authenticate the MN > identified by the value in the Mobile Node Identifier option using > the value in MN-AAA Mobility Message Authentication Option and the > corresponding value of the SPI. >=20 >=20 > Isn't requirement G4.6 already covered by the previous requirements? >=20 >=20 Yes, agree. I hope Kuntal is fine if we remove this goal. >=20 >=20 > G6.2 The NAS SHOULD be able to notify the AAAH of the > functionalities described in [4]. >=20 >=20 > Couldn't we just list what it should notify the AAAH about? It isn't a lot. >=20 OK, suggested rewording: G6.2 The NAS MUST be able to notify the AAAH if it supports the AAA extensions designed to receive the HA assignment information [4]. Gerardo >=20 > Ciao > Hannes >=20 >=20 > marcelo bagnulo braun wrote: > > Hi, > > > > With this email we issue the WGLC for draft-ietf-mext-aaa-ha-goals- > 00.txt > > The WGLC will be open till the 31 of january. > > We kindly ask the WG to review the document and provide comments. > > > > Please note that a valid comment at this stage is positive feedback > > about the document being ready to be shipped. > > So, please if you think the doc is ready, do express this to the ml > > (or to the chairs) > > > > For you convenience, additional information about the document: > > > > > > Title : AAA Goals for Mobile IPv6 > > Author(s) : G. Giaretta, et al. > > Filename : draft-ietf-mext-aaa-ha-goals-00.txt > > Pages : 12 > > Date : 2007-12-27 > > > > In commercial and enterprise deployments Mobile IPv6 can be a service > > offered by a Mobility Services Provider (MSP). In this case all > > protocol operations may need to be explicitly authorized and traced, > > requiring the interaction between Mobile IPv6 and the AAA > > infrastructure. Integrating the AAA infrastructure (e.g. NAS and > > AAA server) offers also a solution component for Mobile IPv6 > > bootstrapping. This document describes various scenarios where a AAA > > interface for Mobile IPv6 is required. Additionally, it lists design > > goals and requirements for such an interface. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mext-aaa-ha-goals-00.txt > > > > Regards, Julien and marcelo > > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 16 15:00:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFER8-0003p0-8P; Wed, 16 Jan 2008 15:00:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFER7-0003oi-3d; Wed, 16 Jan 2008 15:00:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFER6-00089u-Nh; Wed, 16 Jan 2008 15:00:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 6127A175C1; Wed, 16 Jan 2008 20:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JFEQb-0004qb-Tq; Wed, 16 Jan 2008 15:00:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 16 Jan 2008 15:00:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-api-05.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : The Diameter API Author(s) : P. Calhoun, D. Frascone Filename : draft-ietf-dime-diameter-api-05.txt Pages : 48 Date : 2008-01-16 The Diameter authentication, authorization, and accounting (AAA) protocol provides support for peering AAA transactions across the Internet. This document describes a standardized API for the Diameter protocol. The API is defined for the C language. The intent of the API is to foster source code portability across multiple programming platforms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-api-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-diameter-api-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-diameter-api-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-16145415.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-diameter-api-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-diameter-api-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-16145415.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Thu Jan 17 05:04:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFRc7-0006oJ-16; Thu, 17 Jan 2008 05:04:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFRc6-0006n4-Io for dime@ietf.org; Thu, 17 Jan 2008 05:04:46 -0500 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFRc5-0006Bs-3I for dime@ietf.org; Thu, 17 Jan 2008 05:04:46 -0500 Received: from IBM52A5038A94F ([88.234.6.213]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1JFRc22knk-0004OF; Thu, 17 Jan 2008 05:04:44 -0500 From: "Alper Yegin" To: Date: Thu, 17 Jan 2008 12:04:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchY8F0pxnb58kA0Q0qNRlSbrtTELg== Message-Id: <0MKp8S-1JFRc22knk-0004OF@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18qHYUWHhvwf/6lIZKAVZA0HWxqOBJpvY7iccZ TdZmGyf3VKzZTv07bOh7MkVphVuxaYygHjYQxeugousfFBm0ec GPoTQ7ZEZe6xaGjKpOl2w== X-Spam-Score: -0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Dime] draft-ietf-dime-mip6-integrated-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This I-D allows HA assignment by the NAS and HAAA. But how about HA assignment by VAAA? In WiMAX architecture, there are three distinct networks involved: - ASN: that's where the NAS is. - VCSN: VAAA is in that network. - HCSN: HAAA is here. Is there a particular way to read this I-D such that it can support HA assignment by the VAAA? Or, can we introduce specific text towards that? Thanks. Alper _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 17 10:53:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFX38-0003Ns-GE; Thu, 17 Jan 2008 10:53:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFX36-00030n-Km for dime@ietf.org; Thu, 17 Jan 2008 10:53:00 -0500 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFX34-0006vl-Sk for dime@ietf.org; Thu, 17 Jan 2008 10:53:00 -0500 Received: by py-out-1112.google.com with SMTP id x19so838155pyg.24 for ; Thu, 17 Jan 2008 07:52:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; bh=8ZerWaKDT2CZdYrUtAVLVTzXOP9TLvqFRfSVmN1HedU=; b=hB89NdBsQQ+U5bvnv+OLSJryjBl7MZWxfJs9W5qtLnWhXWDoJaxXW4+znLg2wzc+WbJBZVKOWxtR9s1lMh10FjEGoEN+liZoTra2OIGBROq4LRR8HpPxMuZEeXDfa9WakR48xxOOODJUp35AiHzGqT8I0y9lmg4jxKsK2cb350E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=dncqpo8Eq4gXCfewC0IS5Yt33fEyQ9xELAAU0XX1BhxtMrObRZPGlWWuidbZfWedKqCC/bmvWdXefSE62HTnsQ9LiOkEB7f+HdXQuOOGWQO9OqpBLxRYJcIRumHXeIV9Vjm0STdG0cThvW4c/kqToLx7KS0txHdyHg1yv8YI/2I= Received: by 10.141.132.8 with SMTP id j8mr1575614rvn.7.1200585177371; Thu, 17 Jan 2008 07:52:57 -0800 (PST) Received: by 10.141.50.5 with HTTP; Thu, 17 Jan 2008 07:52:57 -0800 (PST) Message-ID: <9cf5ced20801170752i35b854dfic711587d9a921b32@mail.gmail.com> Date: Thu, 17 Jan 2008 10:52:57 -0500 From: "David Frascone" To: dime@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: edcacda9dc9e78bb X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [Dime] Review of draft-ietf-dime-mip6-integrated-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1239907084==" Errors-To: dime-bounces@ietf.org --===============1239907084== Content-Type: multipart/alternative; boundary="----=_Part_518_8292018.1200585177359" ------=_Part_518_8292018.1200585177359 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This review is entirely editorial . . . The content / protocol changes seemed fine. Section 1, Paragraph 2: "The aformentioned information may be statically" is not a sentence. "to react on sudden" -> "to react to sudden" "Static Provisioning may not be desirable, in light of the mentioned limitations" -- I'd change "the mentioned" to these -- since you just described them. Section 3, Paragraph 1 The phrase "required by for the MIPv6" didn't pass my parser. "required by" would be sufficient. Section 3, Paragraph 4 "... the Diamater server in the ASA/MSA detects that ..." I'm not sure how Diameter servers detect anything -- What is the Diameter server really doing at this point? This needs to be clarified and re-written. Section 3, Paragraph 5 "Depending on the details of the d bootstrapping solution interaction . . ." I'd get rid of the word "solution" Section 4 The first sentence has a comma, but only lists two things that the section defines. Use the word "and" instead. Section 4.1 The first sentence has a phrase added, "and in all new applications" that is out of place in the sentence. I'd re-write it to something like this: "... related AVPs that can be used in existing Diameter applications (and in all new applications), where permitted by the command ABNF. Section 4.2, Paragraph 2 "respective used applications" fails my grammar parser. Section 4.2, Paragraph 3 Last sentence is a run-on -- may be a typo: However is capitalized. Also, "However, for example, " Should either be "However, " or "For example, " -- not both. Section 4.7.3, Paragraph 2 I've read this paragraph three times, and still don't know what it is trying to say. I keep getting lost in the grammar. Section 4.7.4 Remove "a" from "prefix information in a network byte order" Section 4.7.5 Even though it seems strange, "bit fields" contain multiple bits. There is no such thing as a "bits field" So -- "64 bits flags field" should be "64 bit flags field" Section 5.3, Paragraph 1 "shows a message flows" -> "shows a message flow" "The Diameter server is also able to provide a HA to the MN but also authorizes . . " -- too many also's That's all I found -- so far -- hehe . . -Dave ------=_Part_518_8292018.1200585177359 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
This review is entirely editorial . . . The content / protocol changes seemed fine.

Section 1, Paragraph 2: 
   "The aformentioned information may be statically"  is not a sentence.
   "to react on sudden" -> "to react to sudden"
   "Static Provisioning may not be desirable, in light of the mentioned limitations" -- I'd change "the mentioned" to these -- since you just described them.

Section 3, Paragraph 1
    The phrase "required by for the MIPv6" didn't pass my parser.  "required by" would be sufficient.

Section 3, Paragraph 4
   "... the Diamater server in the ASA/MSA detects that ..."  I'm not sure how Diameter servers detect anything -- What is the Diameter server really doing at this point?  This needs to be clarified and re-written.

Section 3, Paragraph 5
  "Depending on the details of the d bootstrapping solution interaction . . ." I'd get rid of the word "solution"

Section 4
   The first sentence has a comma, but only lists two things that the section defines.  Use the word "and" instead.

Section 4.1
   The first sentence has a phrase added, "and in all new applications" that is out of place in the sentence.  I'd re-write it to something like this:  "... related AVPs that can be used in existing Diameter applications (and in all new applications), where permitted by the command ABNF.

Section 4.2, Paragraph 2
   "respective used applications" fails my grammar parser. 

Section 4.2, Paragraph 3
   Last sentence is a run-on -- may be a typo:  However is capitalized.  Also, "However, for example, " Should either be "However, " or "For example, " -- not both.

Section 4.7.3, Paragraph 2
   I've read this paragraph three times, and still don't know what it is trying to say.  I keep getting lost in the grammar.

Section 4.7.4
   Remove "a" from "prefix information in a network byte order"

Section 4.7.5
   Even though it seems strange, "bit fields" contain multiple bits.  There is no such thing as a "bits field"  So -- "64 bits flags field" should be "64 bit flags field"

Section 5.3, Paragraph 1
   "shows a message flows" -> "shows a message flow"
   "The Diameter server is also able to provide a HA to the MN but also authorizes . . " -- too many also's

That's all I found -- so far -- hehe . .

-Dave
  
------=_Part_518_8292018.1200585177359-- --===============1239907084== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1239907084==-- From dime-bounces@ietf.org Fri Jan 18 03:20:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFmTC-0006xf-EM; Fri, 18 Jan 2008 03:20:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFmTA-0006xU-HT for dime@ietf.org; Fri, 18 Jan 2008 03:20:56 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JFmT9-0003cm-7y for dime@ietf.org; Fri, 18 Jan 2008 03:20:56 -0500 Received: (qmail invoked by alias); 18 Jan 2008 08:20:52 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp022) with SMTP; 18 Jan 2008 09:20:52 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19yyedXk3Ny1YBMt4eTnENSVxM4iWs+51nU43S/62 Oa2oOcHsrB2qNa Message-ID: <47906163.4040607@gmx.net> Date: Fri, 18 Jan 2008 10:20:51 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Giaretta, Gerardo" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b Cc: marcelo bagnulo braun , dime@ietf.org, mext@ietf.org Subject: [Dime] Re: [MEXT] WGLC for draft-ietf-mext-aaa-ha-goals-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Gerardo, please find my comments inline: Giaretta, Gerardo wrote: > Hi Hannes, > > Thanks for the comments. Please see inline > >> A few minor comments below. >> >> >> FROM: >> >> The Home Agent can the assigned either in the Access Service >> Provider's network or in the seprate network. >> >> >> TO: >> >> The Home Agent can be assigned either in the Access Service >> Provider's network or in the separate network. >> >> >> > > Good catch, thanks. > > > >> G1.1 The AAAH server and the HA MUST be able to authenticate each >> other (mutual authentication) in order to prevent the >> > installation > >> of unauthorized state on the HA. >> In some deployment scenarios, it >> may not be feasible for HA and AAA server to mutually >> > authenticate > >> each other. In such a case, several AAA intermediate proxies >> could forward MIP6 bootstrapping information between HA and AAA. >> Thus, to prevent the installation of unauthorized state on the >> > HA, > >> the path between HA and AAAH should be secure. >> >> [hannes] "should be secure" is a bit fuzzy. In essence you are >> > building > >> on the >> AAA model with a hop-by-hop security mechanisms. Maybe a better >> > wording > >> would be >> >> " >> Thus, to prevent the installation of unauthorized state on the HA, >> the communication security mechanisms available with the AAA >> infrastructure >> MUST be used between adjacent AAA peers. >> " >> >> > > Good. I will change the text to the proposed one. Thanks > > >> I would fold requirement G1.2 and G1.3 into G1.1 since they are so >> > closely > >> related. >> >> > > What do you mean exactly? Are you suggesting to have a single > requirement? > I would write: G1.1 The communication between the AAAH server and the HA MUST reuse existing AAA security mechanisms with regard to authentication, replay, integrity, and confidentiality protection. These communication security mechanisms prevent a number of classical threats, including the alteration of exchanged data (e.g., Mobile IPv6 configuration parameters) and the installation of unauthorized state. Then, delete G1.2 and G1.3. >> >> G2.10 The AAAH server MUST be able to authorize the MN for Dual >> Stack operation [9]. >> >> What exactly does this mean? >> >> > > It means that a MN may be authorized to use MIPv6 as in RFC3775 or may > be authorized also to have an IPv4 HoA assigned for DSMIPv6. > > Maybe we should then write: G2.10 The AAAH server MUST be able to support different levels of Mobile IPv6 authorization. For example, the AAAH server may authorize the MN to use of MIPv6 (as defined in [RFC3775]) or may authorize the MN to utilize an IPv4 HoA assigned for Dual Stack MIPv6 [9]. >> G2.11 The AAAH server MUST be able to indicate to the HA whether >> > the > >> bearer traffic for the MN needs to receive IPsec ESP protection. >> >> I don't understand this either. >> >> > > The AAA may indicate if the MIPv6 tunnel should be an IP-in-IP tunnel or > an ESP tunnel. > Hmmm. I might have missed something but Mobile IP establishes IP-in-IP (or GRE tunnels) and not ESP tunnels. > >> G2.12 The HA MUST be able to authenticate the MN through the AAAH >> > in > >> case a pre-share key is used in IKEv2 for user authentication. >> The exact procedure is part of the solution space. >> >> >> Why do you list this requirement? I believe it is pretty much useless >> given >> that it is a consequence of the solution. I suggest to delete this >> requirement. >> >> > > I agree it is a consequence of the solution. However, I think it is good > to make it clear here as RFC 5026 provides text for PSK, EAP and > certificates. I don't think it is bad to have it. > > Then, I would write make it more explicitly. Just say that RFC 5026 supports different authentication mechanisms (PSK, EAP and certificates) and the solution specification MUST specify all variants. >> G4.1 The AAA-HA interface MUST allow the HA to act as a >> > pass-through > >> EAP authenticator. >> >> This is a consequence of the already established solution. I suggest >> > to > >> delete it. >> >> >> > > Same as above. > > >> G4.2 The AAA - HA interface SHOULD support authentication based on >> the Mobility Message Authentication Options defined in [5]. >> >> A solution must be specified in the specification but it's usage is >> optional. >> >> > > Can you clarify your comment please? > > I believe that this requirement refers to the usage rather than the functionality of the specification. Here, I would place a MUST since we have to specify it in the solution document. >> Section 5.4. about Mobile Node Authentication: >> >> G4.5 The HA MUST include the Mobile Node Identifier option [7] in >> the AAA transactions with the AAAH server. >> >> >> This requirement almost sounds like a solution description already. >> Isn't this a solution detail that does not need to be mentioned in >> > such > >> a document? >> >> > > Yes, you are probably right. The idea was that the HA MUST include an > identifier of the MN in the AAA transactions. > > A possible rewording could be > > "The HA MUST include an identifier of the mobile node in the AAA > transactions with the AAAH server" > > Would that work? Or are you suggesting removing completely the goal? > > That's fine. >> The same >> is true for requirement G4.7, which says: >> >> G4.7 If the MN-AAA Mobility Message Authentication Option is not >> included by the HA or the MN-AAA Mobility Message Authentication >> Option is included and the MN-AAA authentication is successful, >> the AAAH MUST send the keying material for MN-HA key to the HA >> > if > >> the HA requested for MN-HA keying material only. The AAAH MUST >> send the MN-HA key and the corresponding SPI value to the HA if >> the HA requested for MN-HA key and SPI. >> >> >> This paragraph sounds really complex. The first sentence is pretty >> > much > >> irrelevant for such a requirements document. Isn't the 2nd sentence >> covered >> by requirement in G4.3 already? >> >> > > I agree we can remove the first sentence. The second sentence is > different form G4.3, though: G4.3 is about the HA to request the keying > material while G4.7 is about the AAAH sending it. Would you prefer merge > the two goals? > > I would combine it since it is a requirement for requesting a keying material would (in my opinion) also imply that you have a way to receive it. >> G4.6 The AAAH server SHOULD be able to authenticate the MN >> identified by the value in the Mobile Node Identifier option >> > using > >> the value in MN-AAA Mobility Message Authentication Option and >> > the > >> corresponding value of the SPI. >> >> >> Isn't requirement G4.6 already covered by the previous requirements? >> >> >> > > Yes, agree. I hope Kuntal is fine if we remove this goal. > > >> G6.2 The NAS SHOULD be able to notify the AAAH of the >> functionalities described in [4]. >> >> >> Couldn't we just list what it should notify the AAAH about? It isn't a >> > lot. > > > OK, suggested rewording: > > G6.2 The NAS MUST be able to notify the AAAH if it supports the AAA > extensions designed to receive the HA assignment information [4]. > > Sounds good. Ciao Hannes > Gerardo > > >> Ciao >> Hannes >> >> >> marcelo bagnulo braun wrote: >> >>> Hi, >>> >>> With this email we issue the WGLC for draft-ietf-mext-aaa-ha-goals- >>> >> 00.txt >> >>> The WGLC will be open till the 31 of january. >>> We kindly ask the WG to review the document and provide comments. >>> >>> Please note that a valid comment at this stage is positive feedback >>> about the document being ready to be shipped. >>> So, please if you think the doc is ready, do express this to the ml >>> (or to the chairs) >>> >>> For you convenience, additional information about the document: >>> >>> >>> Title : AAA Goals for Mobile IPv6 >>> Author(s) : G. Giaretta, et al. >>> Filename : draft-ietf-mext-aaa-ha-goals-00.txt >>> Pages : 12 >>> Date : 2007-12-27 >>> >>> In commercial and enterprise deployments Mobile IPv6 can be a >>> > service > >>> offered by a Mobility Services Provider (MSP). In this case all >>> protocol operations may need to be explicitly authorized and traced, >>> requiring the interaction between Mobile IPv6 and the AAA >>> infrastructure. Integrating the AAA infrastructure (e.g. NAS and >>> AAA server) offers also a solution component for Mobile IPv6 >>> bootstrapping. This document describes various scenarios where a >>> > AAA > >>> interface for Mobile IPv6 is required. Additionally, it lists >>> > design > >>> goals and requirements for such an interface. >>> >>> A URL for this Internet-Draft is: >>> >>> > http://www.ietf.org/internet-drafts/draft-ietf-mext-aaa-ha-goals-00.txt > >>> Regards, Julien and marcelo >>> >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jan 18 19:38:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG1jY-0002BN-5l; Fri, 18 Jan 2008 19:38:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG1jW-0002BF-Qp; Fri, 18 Jan 2008 19:38:50 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JG1jU-0001aL-Dv; Fri, 18 Jan 2008 19:38:50 -0500 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0J0chYb004434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 Jan 2008 16:38:43 -0800 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0J0cg7a025719; Fri, 18 Jan 2008 16:38:42 -0800 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Jan 2008 16:38:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Jan 2008 16:38:41 -0800 Message-ID: In-Reply-To: <47906163.4040607@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] WGLC for draft-ietf-mext-aaa-ha-goals-00.txt Thread-Index: AchZqxN7VmVaZgMEQRuwrkPfveYl3AAhupRw From: "Giaretta, Gerardo" To: "Hannes Tschofenig" X-OriginalArrivalTime: 19 Jan 2008 00:38:42.0491 (UTC) FILETIME=[A43640B0:01C85A33] X-Spam-Score: -4.0 (----) X-Scan-Signature: 23336e92cd9b2f166f17126afcdd84ec Cc: marcelo bagnulo braun , dime@ietf.org, mext@ietf.org Subject: [Dime] RE: [MEXT] WGLC for draft-ietf-mext-aaa-ha-goals-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes, Please see inline > >> > >> FROM: > >> > >> The Home Agent can the assigned either in the Access Service > >> Provider's network or in the seprate network. > >> > >> > >> TO: > >> > >> The Home Agent can be assigned either in the Access Service > >> Provider's network or in the separate network. > >> > >> > >> > > > > Good catch, thanks. > > > > > > > >> G1.1 The AAAH server and the HA MUST be able to authenticate each > >> other (mutual authentication) in order to prevent the > >> > > installation > > > >> of unauthorized state on the HA. > >> In some deployment scenarios, it > >> may not be feasible for HA and AAA server to mutually > >> > > authenticate > > > >> each other. In such a case, several AAA intermediate proxies > >> could forward MIP6 bootstrapping information between HA and AAA. > >> Thus, to prevent the installation of unauthorized state on the > >> > > HA, > > > >> the path between HA and AAAH should be secure. > >> > >> [hannes] "should be secure" is a bit fuzzy. In essence you are > >> > > building > > > >> on the > >> AAA model with a hop-by-hop security mechanisms. Maybe a better > >> > > wording > > > >> would be > >> > >> " > >> Thus, to prevent the installation of unauthorized state on the HA, > >> the communication security mechanisms available with the AAA > >> infrastructure > >> MUST be used between adjacent AAA peers. > >> " > >> > >> > > > > Good. I will change the text to the proposed one. Thanks > > > > > >> I would fold requirement G1.2 and G1.3 into G1.1 since they are so > >> > > closely > > > >> related. > >> > >> > > > > What do you mean exactly? Are you suggesting to have a single > > requirement? > > >=20 > I would write: >=20 >=20 > G1.1 The communication between the AAAH server and the HA > MUST reuse existing AAA security mechanisms with regard to > authentication, replay, integrity, and confidentiality protection. > These communication security mechanisms > prevent a number of classical threats, including the alteration > of exchanged data (e.g., Mobile IPv6 configuration parameters) > and the installation of unauthorized state. >=20 >=20 > Then, delete G1.2 and G1.3. > This is fine to me. I will change it. =20 >=20 > >> > >> G2.10 The AAAH server MUST be able to authorize the MN for Dual > >> Stack operation [9]. > >> > >> What exactly does this mean? > >> > >> > > > > It means that a MN may be authorized to use MIPv6 as in RFC3775 or may > > be authorized also to have an IPv4 HoA assigned for DSMIPv6. > > > > > Maybe we should then write: >=20 > G2.10 The AAAH server MUST be able to support different levels of > Mobile IPv6 authorization. For example, the AAAH server may > authorize the MN to use of MIPv6 (as defined in [RFC3775]) or may > authorize the MN to utilize an IPv4 HoA assigned for Dual Stack MIPv6 [9]. >=20 That's fine too.=20 >=20 >=20 >=20 > >> G2.11 The AAAH server MUST be able to indicate to the HA whether > >> > > the > > > >> bearer traffic for the MN needs to receive IPsec ESP protection. > >> > >> I don't understand this either. > >> > >> > > > > The AAA may indicate if the MIPv6 tunnel should be an IP-in-IP tunnel or > > an ESP tunnel. > > > Hmmm. I might have missed something but Mobile IP establishes IP-in-IP > (or GRE tunnels) and not ESP tunnels. >=20 The HA and MN may configure a child SA to protect payload traffic. In this way the packets from HA to MN are protected using ESP.=20 >=20 > > > >> G2.12 The HA MUST be able to authenticate the MN through the AAAH > >> > > in > > > >> case a pre-share key is used in IKEv2 for user authentication. > >> The exact procedure is part of the solution space. > >> > >> > >> Why do you list this requirement? I believe it is pretty much useless > >> given > >> that it is a consequence of the solution. I suggest to delete this > >> requirement. > >> > >> > > > > I agree it is a consequence of the solution. However, I think it is good > > to make it clear here as RFC 5026 provides text for PSK, EAP and > > certificates. I don't think it is bad to have it. > > > > > Then, I would write make it more explicitly. Just say that RFC 5026 > supports different > authentication mechanisms (PSK, EAP and certificates) and the solution > specification MUST > specify all variants. >=20 This was suggested by Vijay. The point is that the HA may be able to fetch the PSK from the AAAH in case it does not have it. It's not only supporting PSK within IKEv2, rather contacting the AAAH to verify the PSK. > >> G4.1 The AAA-HA interface MUST allow the HA to act as a > >> > > pass-through > > > >> EAP authenticator. > >> > >> This is a consequence of the already established solution. I suggest > >> > > to > > > >> delete it. > >> > >> > >> > > > > Same as above. > > > > > >> G4.2 The AAA - HA interface SHOULD support authentication based on > >> the Mobility Message Authentication Options defined in [5]. > >> > >> A solution must be specified in the specification but it's usage is > >> optional. > >> > >> > > > > Can you clarify your comment please? > > > > > I believe that this requirement refers to the usage rather than the > functionality of the specification. > Here, I would place a MUST since we have to specify it in the solution > document. >=20 MUST is fine >=20 > >> Section 5.4. about Mobile Node Authentication: > >> > >> G4.5 The HA MUST include the Mobile Node Identifier option [7] in > >> the AAA transactions with the AAAH server. > >> > >> > >> This requirement almost sounds like a solution description already. > >> Isn't this a solution detail that does not need to be mentioned in > >> > > such > > > >> a document? > >> > >> > > > > Yes, you are probably right. The idea was that the HA MUST include an > > identifier of the MN in the AAA transactions. > > > > A possible rewording could be > > > > "The HA MUST include an identifier of the mobile node in the AAA > > transactions with the AAAH server" > > > > Would that work? Or are you suggesting removing completely the goal? > > > > > That's fine. >=20 > >> The same > >> is true for requirement G4.7, which says: > >> > >> G4.7 If the MN-AAA Mobility Message Authentication Option is not > >> included by the HA or the MN-AAA Mobility Message Authentication > >> Option is included and the MN-AAA authentication is successful, > >> the AAAH MUST send the keying material for MN-HA key to the HA > >> > > if > > > >> the HA requested for MN-HA keying material only. The AAAH MUST > >> send the MN-HA key and the corresponding SPI value to the HA if > >> the HA requested for MN-HA key and SPI. > >> > >> > >> This paragraph sounds really complex. The first sentence is pretty > >> > > much > > > >> irrelevant for such a requirements document. Isn't the 2nd sentence > >> covered > >> by requirement in G4.3 already? > >> > >> > > > > I agree we can remove the first sentence. The second sentence is > > different form G4.3, though: G4.3 is about the HA to request the keying > > material while G4.7 is about the AAAH sending it. Would you prefer merge > > the two goals? > > > > > I would combine it since it is a requirement for requesting a keying > material would (in my opinion) > also imply that you have a way to receive it. >=20 Can you please propose some text? I still don't fully understand the implications of the proposal.=20 >=20 > >> G4.6 The AAAH server SHOULD be able to authenticate the MN > >> identified by the value in the Mobile Node Identifier option > >> > > using > > > >> the value in MN-AAA Mobility Message Authentication Option and > >> > > the > > > >> corresponding value of the SPI. > >> > >> > >> Isn't requirement G4.6 already covered by the previous requirements? > >> > >> > >> > > > > Yes, agree. I hope Kuntal is fine if we remove this goal. > > > > > >> G6.2 The NAS SHOULD be able to notify the AAAH of the > >> functionalities described in [4]. > >> > >> > >> Couldn't we just list what it should notify the AAAH about? It isn't a > >> > > lot. > > > > > > OK, suggested rewording: > > > > G6.2 The NAS MUST be able to notify the AAAH if it supports the AAA > > extensions designed to receive the HA assignment information [4]. > > > > > Sounds good. >=20 Thanks again for the review Gerardo > Ciao > Hannes >=20 > > Gerardo > > > > > >> Ciao > >> Hannes > >> > >> > >> marcelo bagnulo braun wrote: > >> > >>> Hi, > >>> > >>> With this email we issue the WGLC for draft-ietf-mext-aaa-ha-goals- > >>> > >> 00.txt > >> > >>> The WGLC will be open till the 31 of january. > >>> We kindly ask the WG to review the document and provide comments. > >>> > >>> Please note that a valid comment at this stage is positive feedback > >>> about the document being ready to be shipped. > >>> So, please if you think the doc is ready, do express this to the ml > >>> (or to the chairs) > >>> > >>> For you convenience, additional information about the document: > >>> > >>> > >>> Title : AAA Goals for Mobile IPv6 > >>> Author(s) : G. Giaretta, et al. > >>> Filename : draft-ietf-mext-aaa-ha-goals-00.txt > >>> Pages : 12 > >>> Date : 2007-12-27 > >>> > >>> In commercial and enterprise deployments Mobile IPv6 can be a > >>> > > service > > > >>> offered by a Mobility Services Provider (MSP). In this case all > >>> protocol operations may need to be explicitly authorized and traced, > >>> requiring the interaction between Mobile IPv6 and the AAA > >>> infrastructure. Integrating the AAA infrastructure (e.g. NAS and > >>> AAA server) offers also a solution component for Mobile IPv6 > >>> bootstrapping. This document describes various scenarios where a > >>> > > AAA > > > >>> interface for Mobile IPv6 is required. Additionally, it lists > >>> > > design > > > >>> goals and requirements for such an interface. > >>> > >>> A URL for this Internet-Draft is: > >>> > >>> > > http://www.ietf.org/internet-drafts/draft-ietf-mext-aaa-ha-goals-00.txt > > > >>> Regards, Julien and marcelo > >>> > >>> > >>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mext > >>> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mext > >> > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jan 19 14:19:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGJDY-00013P-CY; Sat, 19 Jan 2008 14:19:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGJDX-00013J-5R for dime@ietf.org; Sat, 19 Jan 2008 14:18:59 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JGJDW-0002bt-FS for dime@ietf.org; Sat, 19 Jan 2008 14:18:58 -0500 Received: (qmail invoked by alias); 19 Jan 2008 19:18:56 -0000 Received: from proxy4-nsn.nsn-inter.net (EHLO [217.115.75.232]) [217.115.75.232] by mail.gmx.net (mp034) with SMTP; 19 Jan 2008 20:18:56 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+4Cq44fy+4Wmh3R42aqFzAJKwdltFA5UewiSxV4l 4QwBQziy5mGXDR Message-ID: <47924D1C.9080903@gmx.net> Date: Sat, 19 Jan 2008 21:18:52 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Dime] NEW REQUIREMENT -- WGLC for draft-ietf-mext-aaa-ha-goals-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, reading carefully through draft-ietf-mext-aaa-ha-goals-00.txt and I noticed a new requirement, namely G2.11 The AAAH server MUST be able to indicate to the HA whether the bearer traffic for the MN needs to receive IPsec ESP protection. To me it appears that a solution for such a requirement requires a separate exchange between the HA and the AAAH to perform an authorization check. This might require modifications to draft-ietf-dime-mip6-split-06.txt since authentication and authorization are currently done at the same time. I am correctly understanding the requirement and the implications? Feedback appreciated. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jan 19 14:19:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGJDj-00014G-IC; Sat, 19 Jan 2008 14:19:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGJDi-000146-QR for dime@ietf.org; Sat, 19 Jan 2008 14:19:10 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JGJDg-0005Mr-Ry for dime@ietf.org; Sat, 19 Jan 2008 14:19:10 -0500 Received: (qmail invoked by alias); 19 Jan 2008 19:19:07 -0000 Received: from proxy4-nsn.nsn-inter.net (EHLO [217.115.75.232]) [217.115.75.232] by mail.gmx.net (mp022) with SMTP; 19 Jan 2008 20:19:07 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18f/AFxRksf4B5v5DnVRXiE46kwivTrJ70QWLL3Vt bMQfnZdOGFe55L Message-ID: <47924D28.4020903@gmx.net> Date: Sat, 19 Jan 2008 21:19:04 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Giaretta, Gerardo" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: dime@ietf.org, mext@ietf.org Subject: [Dime] Re: [MEXT] WGLC for draft-ietf-mext-aaa-ha-goals-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Gerardo, thanks for your quick response. Please find my comments inline: ~snip~ >> >> >>>> G2.11 The AAAH server MUST be able to indicate to the HA >>>> > whether > >>> the >>> >>> >>>> bearer traffic for the MN needs to receive IPsec ESP >>>> > protection. > >>>> I don't understand this either. >>>> >>>> >>>> >>> The AAA may indicate if the MIPv6 tunnel should be an IP-in-IP >>> > tunnel or > >>> an ESP tunnel. >>> >>> >> Hmmm. I might have missed something but Mobile IP establishes IP-in-IP >> (or GRE tunnels) and not ESP tunnels. >> >> > > The HA and MN may configure a child SA to protect payload traffic. In > this way the packets from HA to MN are protected using ESP. > > This is a somewhat new requirement for me and we have not addressed this aspect in our DIME documents. The additional issue with this requirement is that one needs to have a way to run an authorization exchange between the HA and the AAAS after the authentication. At the moment the authorization exchange and the authentication exchange happen at the same time. I will post a separate mail to the DIME list to see what implication this has with respect to the protocol design. >>>> G2.12 The HA MUST be able to authenticate the MN through the >>>> > AAAH > >>> in >>> >>> >>>> case a pre-share key is used in IKEv2 for user >>>> > authentication. > >>>> The exact procedure is part of the solution space. >>>> >>>> >>>> Why do you list this requirement? I believe it is pretty much >>>> > useless > >>>> given >>>> that it is a consequence of the solution. I suggest to delete this >>>> requirement. >>>> >>>> >>>> >>> I agree it is a consequence of the solution. However, I think it is >>> > good > >>> to make it clear here as RFC 5026 provides text for PSK, EAP and >>> certificates. I don't think it is bad to have it. >>> >>> >>> >> Then, I would write make it more explicitly. Just say that RFC 5026 >> supports different >> authentication mechanisms (PSK, EAP and certificates) and the solution >> specification MUST >> specify all variants. >> >> > > This was suggested by Vijay. The point is that the HA may be able to > fetch the PSK from the AAAH in case it does not have it. It's not only > supporting PSK within IKEv2, rather contacting the AAAH to verify the > PSK. > > The way how IKEv2 works would not allow PSK based authentication to be relayed to the AAA server. It does not work with legacy PSK credentials. Hence, the only reasonable way is to request the PSK from the AAAH. But this is fine with me. I don't see a contradiction between the requirements text I wrote and the one envisioned by Vijay. ~snip~ >>>> The same >>>> is true for requirement G4.7, which says: >>>> >>>> G4.7 If the MN-AAA Mobility Message Authentication Option is >>>> > not > >>>> included by the HA or the MN-AAA Mobility Message >>>> > Authentication > >>>> Option is included and the MN-AAA authentication is >>>> > successful, > >>>> the AAAH MUST send the keying material for MN-HA key to the >>>> > HA > >>> if >>> >>> >>>> the HA requested for MN-HA keying material only. The AAAH >>>> > MUST > >>>> send the MN-HA key and the corresponding SPI value to the HA >>>> > if > >>>> the HA requested for MN-HA key and SPI. >>>> >>>> >>>> This paragraph sounds really complex. The first sentence is pretty >>>> >>>> >>> much >>> >>> >>>> irrelevant for such a requirements document. Isn't the 2nd sentence >>>> covered >>>> by requirement in G4.3 already? >>>> >>>> >>>> >>> I agree we can remove the first sentence. The second sentence is >>> different form G4.3, though: G4.3 is about the HA to request the >>> > keying > >>> material while G4.7 is about the AAAH sending it. Would you prefer >>> > merge > >>> the two goals? >>> >>> >>> >> I would combine it since it is a requirement for requesting a keying >> material would (in my opinion) >> also imply that you have a way to receive it. >> >> > > Can you please propose some text? I still don't fully understand the > implications of the proposal. > > Here is G4.7 G4.7 If the MN-AAA Mobility Message Authentication Option is not included by the HA or the MN-AAA Mobility Message Authentication Option is included and the MN-AAA authentication is successful, the AAAH MUST send the keying material for MN-HA key to the HA if the HA requested for MN-HA keying material only. The AAAH MUST send the MN-HA key and the corresponding SPI value to the HA if the HA requested for MN-HA key and SPI. Here is G4.3: G4.3 The HA SHOULD be able to request either the keying material to generate MN-HA key for MN-HA Mobility Message Authentication Option or SHOULD be able to request the MN-HA key and the related SPI values from the AAAH server. The new requirement as a replacement of the above 2: The AAAH MUST be able to provide a MN-HA key (or data used for subsequent key derivation of the MN-HA key by the HA) to the HA if requested. Additional data, such as the SPI or lifetime parameters, are sent along with the keying material. ~snip~ Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jan 21 02:52:06 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGrRt-0000Wf-LA; Mon, 21 Jan 2008 02:52:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGrRs-0000WO-Dn for dime@ietf.org; Mon, 21 Jan 2008 02:52:04 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JGrRr-00054T-Mw for dime@ietf.org; Mon, 21 Jan 2008 02:52:04 -0500 Received: (qmail invoked by alias); 21 Jan 2008 07:52:03 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp032) with SMTP; 21 Jan 2008 08:52:03 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18UxUUlns8UUT3PGiCGM8xdI/5yGTrlxa68NEIaRp tEL3PN56wLCHQH Message-ID: <47944F22.1080901@gmx.net> Date: Mon, 21 Jan 2008 09:52:02 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: keyprov@ietf.org, dime@ietf.org, ECRIT , "nsis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Subject: [Dime] FW: Internet-Drafts Submission Cutoff Dates for the 71st IETF Meeting in Philadelphia, PA, USA X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Please keep the deadlines in mind. Ciao Hannes -----Original Message----- From: ietf-secretariat@ietf.org [mailto:ietf-secretariat@ietf.org] Sent: Friday, January 18, 2008 12:00 AM To: ietf-announce@ietf.org Subject: Internet-Drafts Submission Cutoff Dates for the 71st IETF Meeting in Philadelphia, PA, USA There are two (2) Internet-Draft cutoff dates for the 71st IETF Meeting in Philadelphia, PA, USA: February 18th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, February 18th at 9:00 AM ET (14:00 UTC/GMT).The only exception is for version -00 WG drafts that replace existing non-WG drafts. Such drafts may be submitted until the cutoff date for version -01 and higher drafts. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, February 11th at 9:00 AM ET (14:00 UTC/GMT). February (14:00 UTC/GMT): Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, February 25th at 9:00 AM ET (14:00 UTC/GMT). Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, March 10th at 9:00 AM ET (13:00 UTC/GMT), when Internet-Draft posting resumes. Please do not wait until the last minute to submit. The Secretariat encourages you to submit your Internet-Drafts via the Internet-Draft Submission Tool (IDST) https://datatracker.ietf.org/idst/upload.cgi. If you are unable to do so, then you may still submit your Internet- Drafts manually by sending them to internet-drafts@ietf.org. If you are submitting a version -00 WG draft that replaces non-WG draft, then you must submit it manually as the current IDST cannot handle replacements. Please be sure to state that one draft replaces another in the cover note that accompanies your submission. Also, please note that the IDST will not accept drafts submitted after their respective cutoff dates. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 71st IETF Meeting can be found at http://www.ietf.org/meetings/71-cutoff_dates.html. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jan 21 06:10:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGuXy-0000g0-Nr; Mon, 21 Jan 2008 06:10:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGuXx-0000fr-Fa; Mon, 21 Jan 2008 06:10:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGuXx-00024K-2w; Mon, 21 Jan 2008 06:10:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id B8C29175C3; Mon, 21 Jan 2008 11:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JGuXS-00023n-9g; Mon, 21 Jan 2008 06:10:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 21 Jan 2008 06:10:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-qos-attributes-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Quality of Service Attributes for Diameter Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-qos-attributes-04.txt Pages : 15 Date : 2008-01-21 This document extends the QoSFilterRule AVP functionality of the Diameter Base protocol and the functionality of the QoS-Filter-Rule AVP defined in RFC 4005. The ability to convey Quality of Service information using the AVPs defined in this document is available to existing Diameter applications where permitted by the command ABNF and to all new applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-qos-attributes-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-qos-attributes-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-21060109.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-qos-attributes-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-qos-attributes-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-21060109.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Tue Jan 22 11:25:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHLwO-00006d-FW; Tue, 22 Jan 2008 11:25:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHLwM-00006Y-TS for dime@ietf.org; Tue, 22 Jan 2008 11:25:34 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHLwM-0001E8-BP for dime@ietf.org; Tue, 22 Jan 2008 11:25:34 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m0MGPWxP076374; Tue, 22 Jan 2008 11:25:32 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <479618FF.6000903@tari.toshiba.com> Date: Tue, 22 Jan 2008 11:25:35 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Jouni Korhonen Subject: Re: 3588bis review was: Re: [Dime] (no subject) References: <2DA96CD9-305A-4E73-8C76-B897A7CCBE4D@iki.fi> In-Reply-To: <2DA96CD9-305A-4E73-8C76-B897A7CCBE4D@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Jouni, Thanks for the review and sorry for the very late reply. I'm currently updating 3588bis based on comments from reviewers. I've integrated most of your comments below. Some answers to your post are inlined: >> ------------------ >> >> o This bis version e.g. deprecates a few things from the RFC3588 like >> E2E-Sequence AVP, SLP2 and AVP P-flag. Also there are considerable >> changes in the security department. I would like to see a small >> section actually describing the major changes. For a new reader that >> would be a nice quick-start. Good idea. >> >> o Application Id has been written using 3-4 different conventions >> in the text. Pick one and stay with it ;) Ok. >> >> >> Section 4.1. AVP Header >> >> I would actually leave the P-flag in place but have a description >> in flags related text stating something like "The 'P' bit has been >> deprecated and MUST be set to zero when sending and ignored on >> receiving". IMHO this is more cleaner way than changing it to 'r' >> bit. Good point. >> >> 6.11. Vendor-Specific-Application-Id AVP >> >> ".. >> The Vendor-Id AVP is an informational AVP pertaining to the vendor >> who may have authorship of the vendor-specific Diameter application. >> It MUST NOT be used as a means of defining a completely >> separate >> vendor-specific application identifier space. >> >> o A question.. now that section 11.3. under IANA considerations say: >> >> "Vendor-Specific Application Identifiers, are for Private Use. Vendor- >> Specific Application Identifiers are assigned on a First Come, First >> Served basis by IANA." >> >> o what is the actual value of having Vendor-Id AVP in the group if >> the vendor specific application Ids need to be reserved from AINA >> anyway? If it is just FYI, couldn't that be removed..? though that >> might hurt backwards compatibility, slightly ;) As you mentioned, backward compatibility is the reason why we had to keep vendor-id avp despite it being redundant from the base protocol perspective. If I'm not mistaken, its actually being used by other SDO's. >> >> 6.11. Vendor-Specific-Application-Id AVP >> >> ::= < AVP Header: 260 > >> { Vendor-Id } >> ({ Auth-Application-Id } / >> { Acct-Application-Id }) >> >> o I think the above does not comply with the ABNF described in >> section 3.2. We've fixed this by integrating reviews from Ralph. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 22 15:00:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHPHv-0004L5-UM; Tue, 22 Jan 2008 15:00:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHPHu-0004FJ-KO; Tue, 22 Jan 2008 15:00:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHPHu-0005aK-8j; Tue, 22 Jan 2008 15:00:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 3BDCB328F0; Tue, 22 Jan 2008 20:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JHPHu-0002gq-4j; Tue, 22 Jan 2008 15:00:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 22 Jan 2008 15:00:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-10.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-rfc3588bis-10.txt Pages : 161 Date : 2008-01-22 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-rfc3588bis-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-rfc3588bis-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-22145023.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-rfc3588bis-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-22145023.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Tue Jan 22 18:06:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHSCn-0006eZ-RU; Tue, 22 Jan 2008 18:06:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHSCm-0006e7-8k for dime@ietf.org; Tue, 22 Jan 2008 18:06:56 -0500 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHSCl-0006Wc-Lh for dime@ietf.org; Tue, 22 Jan 2008 18:06:56 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 00:06:54 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: 3588bis review was: Re: [Dime] (no subject) Date: Wed, 23 Jan 2008 00:06:49 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30288A948@SEHAN021MB.tcad.telia.se> In-Reply-To: <479618FF.6000903@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3588bis review was: Re: [Dime] (no subject) Thread-Index: AchdE3iq8IioQLaiTyWQ01/Rv4Ok6AANuaFA From: To: X-OriginalArrivalTime: 22 Jan 2008 23:06:54.0054 (UTC) FILETIME=[7A947860:01C85D4B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, I have two more nits ;) o Section 4.1 AVP format acsii figure. It seems you forgot to put the deprecated 'P' bit back even if the text mentions it again. o Appendix B and DNS RR examples are still formatted wrong imho. They should be: ;; order pref flags service regexp replacement IN NAPTR 50 50 "s" "AAA+D2S" "" =20 _diameter._sctp.example.com IN NAPTR 100 50 "s" "AAA+D2T" "" _aaa._tcp.example.com and: ;; Priority Weight Port Target IN SRV 0 1 5060 server1.example.com IN SRV 0 2 5060 server2.example.com Cheers, Jouni > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] =20 > Sent: 22. tammikuuta 2008 18:26 > To: Jouni Korhonen > Cc: dime@ietf.org > Subject: Re: 3588bis review was: Re: [Dime] (no subject) >=20 >=20 > Hi Jouni, >=20 > Thanks for the review and sorry for the very late reply. I'm=20 > currently updating 3588bis based on comments from reviewers.=20 > I've integrated most of your comments below. Some answers to=20 > your post are inlined: >=20 >=20 > >> ------------------ > >> > >> o This bis version e.g. deprecates a few things from the=20 > RFC3588 like > >> E2E-Sequence AVP, SLP2 and AVP P-flag. Also there are=20 > considerable > >> changes in the security department. I would like to see a small > >> section actually describing the major changes. For a new=20 > reader that > >> would be a nice quick-start. >=20 > Good idea. >=20 > >> > >> o Application Id has been written using 3-4 different conventions > >> in the text. Pick one and stay with it ;) >=20 > Ok. >=20 > >> > >> > >> Section 4.1. AVP Header > >> > >> I would actually leave the P-flag in place but have a description > >> in flags related text stating something like "The 'P'=20 > bit has been > >> deprecated and MUST be set to zero when sending and ignored on > >> receiving". IMHO this is more cleaner way than changing it to 'r' > >> bit. >=20 > Good point. >=20 >=20 > >> > >> 6.11. Vendor-Specific-Application-Id AVP > >> =20 > >> ".. =20 > >> The Vendor-Id AVP is an informational AVP pertaining=20 > to the vendor > >> who may have authorship of the vendor-specific=20 > Diameter application. > >> It MUST NOT be used as a means of defining a completely=20 > >> separate =20 > >> vendor-specific application identifier space. =20 > >> =20 > >> o A question.. now that section 11.3. under IANA=20 > considerations say: > >> > >> "Vendor-Specific Application Identifiers, are for=20 > Private Use. Vendor- > >> Specific Application Identifiers are assigned on a=20 > First Come, First > >> Served basis by IANA." > >> > >> o what is the actual value of having Vendor-Id AVP in=20 > the group if > >> the vendor specific application Ids need to be=20 > reserved from AINA > >> anyway? If it is just FYI, couldn't that be removed..?=20 > though that > >> might hurt backwards compatibility, slightly ;) >=20 > As you mentioned, backward compatibility is the reason why we=20 > had to keep vendor-id avp despite it being redundant from the=20 > base protocol perspective. If I'm not mistaken, its actually=20 > being used by other SDO's. >=20 > >> > >> 6.11. Vendor-Specific-Application-Id AVP =20 > >> =20 > >> ::=3D < AVP Header: 260 > =20 > >> { Vendor-Id } =20 > >> ({ Auth-Application-Id } / =20 > >> { Acct-Application-Id }) > >> > >> o I think the above does not comply with the ABNF described in > >> section 3.2. >=20 > We've fixed this by integrating reviews from Ralph. >=20 >=20 > regards, > victor >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 22 18:31:15 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHSaJ-0003qS-Ge; Tue, 22 Jan 2008 18:31:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHSaI-0003qN-Sw for dime@ietf.org; Tue, 22 Jan 2008 18:31:14 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHSaI-00078t-8O for dime@ietf.org; Tue, 22 Jan 2008 18:31:14 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m0MNVCMw078346; Tue, 22 Jan 2008 18:31:13 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <47967CCB.4010903@tari.toshiba.com> Date: Tue, 22 Jan 2008 18:31:23 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com Subject: Re: 3588bis review was: Re: [Dime] (no subject) References: <59D7431DE2527D4CB0F1EFEDA5683ED30288A948@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30288A948@SEHAN021MB.tcad.telia.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Jouni, Thanks :) We'll fix the nits. -- victor > Hi Victor, > > I have two more nits ;) > > o Section 4.1 AVP format acsii figure. It seems you > forgot to put the deprecated 'P' bit back even if > the text mentions it again. > > o Appendix B and DNS RR examples are still formatted > wrong imho. They should be: > > ;; order pref flags service regexp replacement > IN NAPTR 50 50 "s" "AAA+D2S" "" > _diameter._sctp.example.com > IN NAPTR 100 50 "s" "AAA+D2T" "" > _aaa._tcp.example.com > > and: > > ;; Priority Weight Port Target > IN SRV 0 1 5060 server1.example.com > IN SRV 0 2 5060 server2.example.com > > > Cheers, > Jouni > > > >> -----Original Message----- >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> Sent: 22. tammikuuta 2008 18:26 >> To: Jouni Korhonen >> Cc: dime@ietf.org >> Subject: Re: 3588bis review was: Re: [Dime] (no subject) >> >> >> Hi Jouni, >> >> Thanks for the review and sorry for the very late reply. I'm >> currently updating 3588bis based on comments from reviewers. >> I've integrated most of your comments below. Some answers to >> your post are inlined: >> >> >> >>>> ------------------ >>>> >>>> o This bis version e.g. deprecates a few things from the >>>> >> RFC3588 like >> >>>> E2E-Sequence AVP, SLP2 and AVP P-flag. Also there are >>>> >> considerable >> >>>> changes in the security department. I would like to see a small >>>> section actually describing the major changes. For a new >>>> >> reader that >> >>>> would be a nice quick-start. >>>> >> Good idea. >> >> >>>> o Application Id has been written using 3-4 different conventions >>>> in the text. Pick one and stay with it ;) >>>> >> Ok. >> >> >>>> Section 4.1. AVP Header >>>> >>>> I would actually leave the P-flag in place but have a description >>>> in flags related text stating something like "The 'P' >>>> >> bit has been >> >>>> deprecated and MUST be set to zero when sending and ignored on >>>> receiving". IMHO this is more cleaner way than changing it to 'r' >>>> bit. >>>> >> Good point. >> >> >> >>>> 6.11. Vendor-Specific-Application-Id AVP >>>> >>>> ".. >>>> The Vendor-Id AVP is an informational AVP pertaining >>>> >> to the vendor >> >>>> who may have authorship of the vendor-specific >>>> >> Diameter application. >> >>>> It MUST NOT be used as a means of defining a completely >>>> separate >>>> vendor-specific application identifier space. >>>> >>>> o A question.. now that section 11.3. under IANA >>>> >> considerations say: >> >>>> "Vendor-Specific Application Identifiers, are for >>>> >> Private Use. Vendor- >> >>>> Specific Application Identifiers are assigned on a >>>> >> First Come, First >> >>>> Served basis by IANA." >>>> >>>> o what is the actual value of having Vendor-Id AVP in >>>> >> the group if >> >>>> the vendor specific application Ids need to be >>>> >> reserved from AINA >> >>>> anyway? If it is just FYI, couldn't that be removed..? >>>> >> though that >> >>>> might hurt backwards compatibility, slightly ;) >>>> >> As you mentioned, backward compatibility is the reason why we >> had to keep vendor-id avp despite it being redundant from the >> base protocol perspective. If I'm not mistaken, its actually >> being used by other SDO's. >> >> >>>> 6.11. Vendor-Specific-Application-Id AVP >>>> >>>> ::= < AVP Header: 260 > >>>> { Vendor-Id } >>>> ({ Auth-Application-Id } / >>>> { Acct-Application-Id }) >>>> >>>> o I think the above does not comply with the ABNF described in >>>> section 3.2. >>>> >> We've fixed this by integrating reviews from Ralph. >> >> >> regards, >> victor >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 23 02:58:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHaV0-00072o-U6; Wed, 23 Jan 2008 02:58:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHaV0-00072h-8C for dime@ietf.org; Wed, 23 Jan 2008 02:58:18 -0500 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHaUy-0006j2-DB for dime@ietf.org; Wed, 23 Jan 2008 02:58:18 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 08:58:14 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] draft-ietf-dime-mip6-integrated-07.txt Date: Wed, 23 Jan 2008 08:58:14 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30288A953@SEHAN021MB.tcad.telia.se> In-Reply-To: <0MKp8S-1JFRc22knk-0004OF@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] draft-ietf-dime-mip6-integrated-07.txt Thread-Index: AchY8F0pxnb58kA0Q0qNRlSbrtTELgEoZtkg References: <0MKp8S-1JFRc22knk-0004OF@mrelay.perfora.net> From: To: , X-OriginalArrivalTime: 23 Jan 2008 07:58:14.0426 (UTC) FILETIME=[B4C32FA0:01C85D95] X-Spam-Score: -4.0 (----) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Alper, > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: 17. tammikuuta 2008 12:05 > To: dime@ietf.org > Subject: [Dime] draft-ietf-dime-mip6-integrated-07.txt >=20 > This I-D allows HA assignment by the NAS and HAAA. But how=20 > about HA assignment by VAAA? A good point. The current text does not reflect this type of deployment clearly enough, as the MIP6 integrated scenario=20 bootstrapping does not really define such. Local HA is within ASP and the current architecture does not make explicit distinction between NAS and VAAA roles when it comes to local HA assigment.=20 However, in my opinion the I-D does not prohibit such deployment either. > In WiMAX architecture, there are three distinct networks involved: > - ASN: that's where the NAS is. > - VCSN: VAAA is in that network.=20 > - HCSN: HAAA is here. >=20 > Is there a particular way to read this I-D such that it can=20 > support HA assignment by the VAAA? Or, can we introduce=20 > specific text towards that? I would reword a bit the text in section 4.7.5 and add an example under section 5 to cover situations where the HA is assigned by the visited AAA. The rough logic for VAAA assigned HA would be the following: 1) NAS may or may not set the LOCAL_HOME_AGENT_ASSIGNMENT =20 capability.. it does not really matter if VAAA is in charge of local HA assignment and the NAS won't do anything regarding to local HA assignment anyway 2) VAAA overwrites the capability bits to indicate its preferences to HAAA regarding to the local HA assignment 3) HAAA functions as normally 4) In the reply the VAAA adds its local HA to the reply message 5) NAS receives 0-n assigned HAs, out of which some may be=20 assigned by the VAAA. NAS may find the which HA is from VAAA and which from HAAA by examing MIP6-Agent-Info AVP and associated HA FQDNs Would this cover your needs? The above is within the current I-D but could be expressed more clearly. Cheers, Jouni >=20 > Thanks. >=20 > Alper >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 23 09:16:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHgPS-0002vB-UZ; Wed, 23 Jan 2008 09:16:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHgPR-0002op-42 for dime@ietf.org; Wed, 23 Jan 2008 09:16:57 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHgPQ-0008DO-Jj for dime@ietf.org; Wed, 23 Jan 2008 09:16:57 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 6C7041880EC for ; Wed, 23 Jan 2008 09:16:50 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06794-03 for ; Wed, 23 Jan 2008 09:16:49 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 23 Jan 2008 09:16:49 -0500 (EST) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 09:14:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] draft-ietf-dime-mip6-integrated-07.txt Date: Wed, 23 Jan 2008 09:14:29 -0500 Message-ID: <4D35478224365146822AE9E3AD4A2666011EFEF4@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] draft-ietf-dime-mip6-integrated-07.txt Thread-Index: AchY8F0pxnb58kA0Q0qNRlSbrtTELgEoZtkgAA2oB8A= References: <0MKp8S-1JFRc22knk-0004OF@mrelay.perfora.net> <59D7431DE2527D4CB0F1EFEDA5683ED30288A953@SEHAN021MB.tcad.telia.se> From: "Marks, Robert" To: , , X-OriginalArrivalTime: 23 Jan 2008 14:14:15.0699 (UTC) FILETIME=[3C543E30:01C85DCA] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Jouni, The VAAA should not be allowed to overwrite the reply. Instead, the VAAA should propose the local HA in the request, as is done for NAS assigned HA. Bob -----Original Message----- From: jouni.korhonen@teliasonera.com [mailto:jouni.korhonen@teliasonera.com]=20 Sent: Wednesday, January 23, 2008 1:58 AM To: alper.yegin@yegin.org; dime@ietf.org Subject: RE: [Dime] draft-ietf-dime-mip6-integrated-07.txt Hi Alper, > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: 17. tammikuuta 2008 12:05 > To: dime@ietf.org > Subject: [Dime] draft-ietf-dime-mip6-integrated-07.txt >=20 > This I-D allows HA assignment by the NAS and HAAA. But how=20 > about HA assignment by VAAA? A good point. The current text does not reflect this type of deployment clearly enough, as the MIP6 integrated scenario=20 bootstrapping does not really define such. Local HA is within ASP and the current architecture does not make explicit distinction between NAS and VAAA roles when it comes to local HA assigment.=20 However, in my opinion the I-D does not prohibit such deployment either. > In WiMAX architecture, there are three distinct networks involved: > - ASN: that's where the NAS is. > - VCSN: VAAA is in that network.=20 > - HCSN: HAAA is here. >=20 > Is there a particular way to read this I-D such that it can=20 > support HA assignment by the VAAA? Or, can we introduce=20 > specific text towards that? I would reword a bit the text in section 4.7.5 and add an example under section 5 to cover situations where the HA is assigned by the visited AAA. The rough logic for VAAA assigned HA would be the following: 1) NAS may or may not set the LOCAL_HOME_AGENT_ASSIGNMENT =20 capability.. it does not really matter if VAAA is in charge of local HA assignment and the NAS won't do anything regarding to local HA assignment anyway 2) VAAA overwrites the capability bits to indicate its preferences to HAAA regarding to the local HA assignment 3) HAAA functions as normally 4) In the reply the VAAA adds its local HA to the reply message 5) NAS receives 0-n assigned HAs, out of which some may be=20 assigned by the VAAA. NAS may find the which HA is from VAAA and which from HAAA by examing MIP6-Agent-Info AVP and associated HA FQDNs Would this cover your needs? The above is within the current I-D but could be expressed more clearly. Cheers, Jouni >=20 > Thanks. >=20 > Alper >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 23 09:32:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHgev-0007vL-Ll; Wed, 23 Jan 2008 09:32:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHgeu-0007v5-Tz for dime@ietf.org; Wed, 23 Jan 2008 09:32:56 -0500 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHget-0000Sc-4h for dime@ietf.org; Wed, 23 Jan 2008 09:32:56 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 15:32:53 +0100 Received: from 131.115.14.48 ([131.115.14.48]) by SEHAN021MB.tcad.telia.se ([131.115.18.162]) with Microsoft Exchange Server HTTP-DAV ; Wed, 23 Jan 2008 14:32:53 +0000 From: "Korhonen, Jouni /TeliaSonera Finland Oyj" To: "Marks, Robert" , , Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] draft-ietf-dime-mip6-integrated-07.txt Date: Wed, 23 Jan 2008 16:32:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 thread-topic: [Dime] draft-ietf-dime-mip6-integrated-07.txt thread-index: AchY8F0pxnb58kA0Q0qNRlSbrtTELgEoZtkgAA2oB8AAAQ92xg== Message-ID: <0fe001c85dcc$d684643f$300e7383@tcad.telia.se> X-Mailer: EAS Version 1.00 MIME-Version: 1.0 Content-Language: i-default X-OriginalArrivalTime: 23 Jan 2008 14:32:53.0650 (UTC) FILETIME=[D6AE0720:01C85DCC] X-Spam-Score: -1.4 (-) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Robert. --- alkuper=C3=A4inen viesti --- L=C3=A4hett=C3=A4j=C3=A4: "Marks, Robert" Aihe: RE: [Dime] draft-ietf-dime-mip6-integrated-07.txt P=C3=A4iv=C3=A4m=C3=A4=C3=A4r=C3=A4: 23. tammikuuta 2008 Aika: 16:17:16 Hi Jouni, The VAAA should not be allowed to overwrite the reply. Instead, the VAAA should propose the local HA in the request, as is done for NAS assigned HA. Bob -----Original Message----- From: jouni.korhonen@teliasonera.com [mailto:jouni.korhonen@teliasonera.com]=20 Sent: Wednesday, January 23, 2008 1:58 AM To: alper.yegin@yegin.org; dime@ietf.org Subject: RE: [Dime] draft-ietf-dime-mip6-integrated-07.txt Hi Alper, > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: 17. tammikuuta 2008 12:05 > To: dime@ietf.org > Subject: [Dime] draft-ietf-dime-mip6-integrated-07.txt >=20 > This I-D allows HA assignment by the NAS and HAAA. But how=20 > about HA assignment by VAAA? A good point. The current text does not reflect this type of deployment clearly enough, as the MIP6 integrated scenario=20 bootstrapping does not really define such. Local HA is within ASP and the current architecture does not make explicit distinction between NAS and VAAA roles when it comes to local HA assigment.=20 However, in my opinion the I-D does not prohibit such deployment either. > In WiMAX architecture, there are three distinct networks involved: > - ASN: that's where the NAS is. > - VCSN: VAAA is in that network.=20 > - HCSN: HAAA is here. >=20 > Is there a particular way to read this I-D such that it can=20 > support HA assignment by the VAAA? Or, can we introduce=20 > specific text towards that? I would reword a bit the text in section 4.7.5 and add an example under section 5 to cover situations where the HA is assigned by the visited AAA. The rough logic for VAAA assigned HA would be the following: 1) NAS may or may not set the LOCAL_HOME_AGENT_ASSIGNMENT =20 capability.. it does not really matter if VAAA is in charge of local HA assignment and the NAS won't do anything regarding to local HA assignment anyway 2) VAAA overwrites the capability bits to indicate its preferences to HAAA regarding to the local HA assignment 3) HAAA functions as normally 4) In the reply the VAAA adds its local HA to the reply message 5) NAS receives 0-n assigned HAs, out of which some may be=20 assigned by the VAAA. NAS may find the which HA is from VAAA and which from HAAA by examing MIP6-Agent-Info AVP and associated HA FQDNs Would this cover your needs? The above is within the current I-D but could be expressed more clearly. Cheers, Jouni >=20 > Thanks. >=20 > Alper >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime "This email message and any attachments are confidential information of = Starent Networks, Corp. The information transmitted may not be used to = create or change any contractual obligations of Starent Networks, Corp. = Any review, retransmission, dissemination or other use of, or taking of = any action in reliance upon this e-mail and its attachments by persons = or entities other than the intended recipient is prohibited. If you are = not the intended recipient, please notify the sender immediately -- by = replying to this message or by sending an email to = postmaster@starentnetworks.com -- and destroy all copies of this message = and any attachments without reading or disclosing their contents. Thank = you." _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 23 10:00:32 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHh5c-0003xM-So; Wed, 23 Jan 2008 10:00:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHh5b-0003x9-VY; Wed, 23 Jan 2008 10:00:31 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHh5b-00014V-Jg; Wed, 23 Jan 2008 10:00:31 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 9086C3287E; Wed, 23 Jan 2008 15:00:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JHh57-0008J3-Fn; Wed, 23 Jan 2008 10:00:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 23 Jan 2008 10:00:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-app-design-guide-06.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Applications Design Guidelines Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-app-design-guide-06.txt Pages : 22 Date : 2008-01-23 The Diameter Base protocol provides updated rules on how to extend Diameter by modifying and/or deriving from existing applications or creating entirely new applications. This is a companion document to the Diameter Base protocol which further explains and/or clarify these rules. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-app-design-guide-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-app-design-guide-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-23095814.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-app-design-guide-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-app-design-guide-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-23095814.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Wed Jan 23 14:48:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHla6-0000pr-F4; Wed, 23 Jan 2008 14:48:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHla5-0000kh-EB for dime@ietf.org; Wed, 23 Jan 2008 14:48:17 -0500 Received: from gw02.mail.saunalahti.fi ([195.197.172.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHla3-0002sJ-Ex for dime@ietf.org; Wed, 23 Jan 2008 14:48:17 -0500 Received: from [88.112.141.24] (a88-112-141-24.elisa-laajakaista.fi [88.112.141.24]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 173F6139B74; Wed, 23 Jan 2008 21:48:10 +0200 (EET) In-Reply-To: <4D35478224365146822AE9E3AD4A2666011EFEF4@exchtewks3.starentnetworks.com> References: <0MKp8S-1JFRc22knk-0004OF@mrelay.perfora.net> <59D7431DE2527D4CB0F1EFEDA5683ED30288A953@SEHAN021MB.tcad.telia.se> <4D35478224365146822AE9E3AD4A2666011EFEF4@exchtewks3.starentnetworks.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jouni Korhonen Subject: Re: [Dime] draft-ietf-dime-mip6-integrated-07.txt Date: Wed, 23 Jan 2008 21:48:06 +0200 To: "Marks, Robert" X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Robert, Seemed that my previous mail took off a bit early ;) Anyway.. In step 4) the VAAA does not need to overwrite AVPs in the reply, it just adds its own HA info to the reply. Cheers, Jouni On Jan 23, 2008, at 4:14 PM, Marks, Robert wrote: > Hi Jouni, > > The VAAA should not be allowed to overwrite the reply. Instead, the > VAAA > should propose the local HA in the request, as is done for NAS > assigned > HA. > > Bob > > -----Original Message----- > From: jouni.korhonen@teliasonera.com > [mailto:jouni.korhonen@teliasonera.com] > Sent: Wednesday, January 23, 2008 1:58 AM > To: alper.yegin@yegin.org; dime@ietf.org > Subject: RE: [Dime] draft-ietf-dime-mip6-integrated-07.txt > > Hi Alper, > >> -----Original Message----- >> From: Alper Yegin [mailto:alper.yegin@yegin.org] >> Sent: 17. tammikuuta 2008 12:05 >> To: dime@ietf.org >> Subject: [Dime] draft-ietf-dime-mip6-integrated-07.txt >> >> This I-D allows HA assignment by the NAS and HAAA. But how >> about HA assignment by VAAA? > > A good point. The current text does not reflect this type of > deployment clearly enough, as the MIP6 integrated scenario > bootstrapping does not really define such. Local HA is within > ASP and the current architecture does not make explicit > distinction between NAS and VAAA roles when it comes to local > HA assigment. > > However, in my opinion the I-D does not prohibit such > deployment either. > >> In WiMAX architecture, there are three distinct networks involved: >> - ASN: that's where the NAS is. >> - VCSN: VAAA is in that network. >> - HCSN: HAAA is here. >> >> Is there a particular way to read this I-D such that it can >> support HA assignment by the VAAA? Or, can we introduce >> specific text towards that? > > I would reword a bit the text in section 4.7.5 and add an > example under section 5 to cover situations where the HA > is assigned by the visited AAA. > > The rough logic for VAAA assigned HA would be the following: > > 1) NAS may or may not set the LOCAL_HOME_AGENT_ASSIGNMENT > capability.. it does not really matter if VAAA is in charge > of local HA assignment and the NAS won't do anything regarding > to local HA assignment anyway > > 2) VAAA overwrites the capability bits to indicate its preferences > to HAAA regarding to the local HA assignment > > 3) HAAA functions as normally > > 4) In the reply the VAAA adds its local HA to the reply message > > 5) NAS receives 0-n assigned HAs, out of which some may be > assigned by the VAAA. NAS may find the which HA is from VAAA > and which from HAAA by examing MIP6-Agent-Info AVP and > associated HA FQDNs > > Would this cover your needs? The above is within the current I-D > but could be expressed more clearly. > > Cheers, > Jouni > > > > >> >> Thanks. >> >> Alper >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 24 02:50:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHwr3-0000pl-KM; Thu, 24 Jan 2008 02:50:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHwr2-0000pb-50; Thu, 24 Jan 2008 02:50:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHwr1-0001yp-PI; Thu, 24 Jan 2008 02:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id AA7672AC49; Thu, 24 Jan 2008 07:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JHwqX-00063u-DN; Thu, 24 Jan 2008 02:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 24 Jan 2008 02:50:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-qos-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Quality of Service Application Author(s) : D. Sun, et al. Filename : draft-ietf-dime-diameter-qos-03.txt Pages : 58 Date : 2008-01-24 This document describes framework, messages and procedures for the Diameter QoS application. The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation - Pull and Push are defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-diameter-qos-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-diameter-qos-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-24024936.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-diameter-qos-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-diameter-qos-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-24024936.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Thu Jan 24 04:08:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHy4O-0007m2-1Z; Thu, 24 Jan 2008 04:08:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHy4M-0007km-Jh for dime@ietf.org; Thu, 24 Jan 2008 04:08:22 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JHy4L-00049o-Ny for dime@ietf.org; Thu, 24 Jan 2008 04:08:22 -0500 Received: (qmail invoked by alias); 24 Jan 2008 09:08:19 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp050) with SMTP; 24 Jan 2008 10:08:19 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX197tc5DftF7Zb3PKJWKAj6a6zs1Ozjt8rA/cnY2ii 2ClHpayqGZyA3c Message-ID: <4798557F.4030707@gmx.net> Date: Thu, 24 Jan 2008 11:08:15 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com References: <0MKp8S-1JFRc22knk-0004OF@mrelay.perfora.net> <59D7431DE2527D4CB0F1EFEDA5683ED30288A953@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30288A953@SEHAN021MB.tcad.telia.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: dime@ietf.org Subject: [Dime] Reviews of draft-ietf-dime-mip6-integrated-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Thank you Alper for the review comments with regard to the applicability of the document to the Wimax environment. Thank you Robert for the feedback. I like Jouni's suggestion to make the text in the draft a bit more explicit regarding the functionality described below: 1) The NAS may set the LOCAL_HOME_AGENT_ASSIGNMENT capability. 2) A VAAA may set or overwrite the capability bits to indicate the preference for the visited network. 3) The HAAA performs authentication and authorization (as usual) and returns a reply message. 4) The VAAA may add its local HA to the reply message 5) The NAS may receive zero or more HAs, out of which some may be assigned by the VAAA. The NAS is able to determine which HA is from the VAAA or from the HAAA by examing MIP6-Agent-Info AVP and associated HA FQDNs Ciao Hannes jouni.korhonen@teliasonera.com wrote: > Hi Alper, > > >> -----Original Message----- >> From: Alper Yegin [mailto:alper.yegin@yegin.org] >> Sent: 17. tammikuuta 2008 12:05 >> To: dime@ietf.org >> Subject: [Dime] draft-ietf-dime-mip6-integrated-07.txt >> >> This I-D allows HA assignment by the NAS and HAAA. But how >> about HA assignment by VAAA? >> > > A good point. The current text does not reflect this type of > deployment clearly enough, as the MIP6 integrated scenario > bootstrapping does not really define such. Local HA is within > ASP and the current architecture does not make explicit > distinction between NAS and VAAA roles when it comes to local > HA assigment. > > However, in my opinion the I-D does not prohibit such > deployment either. > > >> In WiMAX architecture, there are three distinct networks involved: >> - ASN: that's where the NAS is. >> - VCSN: VAAA is in that network. >> - HCSN: HAAA is here. >> >> Is there a particular way to read this I-D such that it can >> support HA assignment by the VAAA? Or, can we introduce >> specific text towards that? >> > > I would reword a bit the text in section 4.7.5 and add an > example under section 5 to cover situations where the HA > is assigned by the visited AAA. > > The rough logic for VAAA assigned HA would be the following: > > 1) NAS may or may not set the LOCAL_HOME_AGENT_ASSIGNMENT > capability.. it does not really matter if VAAA is in charge > of local HA assignment and the NAS won't do anything regarding > to local HA assignment anyway > > 2) VAAA overwrites the capability bits to indicate its preferences > to HAAA regarding to the local HA assignment > > 3) HAAA functions as normally > > 4) In the reply the VAAA adds its local HA to the reply message > > 5) NAS receives 0-n assigned HAs, out of which some may be > assigned by the VAAA. NAS may find the which HA is from VAAA > and which from HAAA by examing MIP6-Agent-Info AVP and > associated HA FQDNs > > Would this cover your needs? The above is within the current I-D > but could be expressed more clearly. > > Cheers, > Jouni > > > > > >> Thanks. >> >> Alper >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 24 05:27:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHzIw-0005T1-RD; Thu, 24 Jan 2008 05:27:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHzIv-0005Sm-9G for dime@ietf.org; Thu, 24 Jan 2008 05:27:29 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JHzIu-0000av-F0 for dime@ietf.org; Thu, 24 Jan 2008 05:27:29 -0500 Received: (qmail invoked by alias); 24 Jan 2008 10:27:26 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp050) with SMTP; 24 Jan 2008 11:27:26 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18GTcNGxQEGAaaj43sb+dXZUhtsYUOp6RPEskZJAY lktZjhMzG0Typv Message-ID: <4798680C.4010507@gmx.net> Date: Thu, 24 Jan 2008 12:27:24 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: David Frascone Subject: Re: [Dime] Review of draft-ietf-dime-mip6-integrated-07.txt References: <9cf5ced20801170752i35b854dfic711587d9a921b32@mail.gmail.com> In-Reply-To: <9cf5ced20801170752i35b854dfic711587d9a921b32@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Dave, Thank you for your comments. I updated the draft based on your feedback. The updated version can be found here: http://www.tschofenig.priv.at/svn/draft-ietf-dime-mip6-integrated/draft-ietf-dime-mip6-integrated-08.txt David Frascone wrote: > This review is entirely editorial . . . The content / protocol changes > seemed fine. > > Section 1, Paragraph 2: > "The aformentioned information may be statically" is not a sentence. > Fixed. > "to react on sudden" -> "to react to sudden" > OK. > "Static Provisioning may not be desirable, in light of the mentioned > limitations" -- I'd change "the mentioned" to these -- since you just > described them. > OK > Section 3, Paragraph 1 > The phrase "required by for the MIPv6" didn't pass my parser. "required > by" would be sufficient. > Fixed. > Section 3, Paragraph 4 > "... the Diamater server in the ASA/MSA detects that ..." I'm not sure > how Diameter servers detect anything -- What is the Diameter server really > doing at this point? This needs to be clarified and re-written. > > Fixed. > Section 3, Paragraph 5 > "Depending on the details of the d bootstrapping solution interaction . . > ." I'd get rid of the word "solution" > > Fixed. > Section 4 > The first sentence has a comma, but only lists two things that the > section defines. Use the word "and" instead. > Fixed. > Section 4.1 > The first sentence has a phrase added, "and in all new applications" that > is out of place in the sentence. I'd re-write it to something like this: > "... related AVPs that can be used in existing Diameter applications (and in > all new applications), where permitted by the command ABNF. > > Fixed. > Section 4.2, Paragraph 2 > "respective used applications" fails my grammar parser. > > Fixed. > Section 4.2, Paragraph 3 > Last sentence is a run-on -- may be a typo: However is capitalized. > Also, "However, for example, " Should either be "However, " or "For example, > " -- not both. > Fixed. > Section 4.7.3, Paragraph 2 > I've read this paragraph three times, and still don't know what it is > trying to say. I keep getting lost in the grammar. > Deleted it. > Section 4.7.4 > Remove "a" from "prefix information in a network byte order" > > Fixed. > Section 4.7.5 > Even though it seems strange, "bit fields" contain multiple bits. There > is no such thing as a "bits field" So -- "64 bits flags field" should be > "64 bit flags field" > > Fixed. > Section 5.3, Paragraph 1 > "shows a message flows" -> "shows a message flow" > Ok. > "The Diameter server is also able to provide a HA to the MN but also > authorizes . . " -- too many also's > OK. > That's all I found -- so far -- hehe . . > > Ciao Hannes > -Dave > > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 24 07:04:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI0p4-0007Qr-Fl; Thu, 24 Jan 2008 07:04:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI0p3-0007Qm-Ge for dime@ietf.org; Thu, 24 Jan 2008 07:04:45 -0500 Received: from mout.perfora.net ([74.208.4.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI0p2-0001CZ-Sf for dime@ietf.org; Thu, 24 Jan 2008 07:04:45 -0500 Received: from IBM52A5038A94F ([88.234.143.76]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1JI0on2Swg-0004OZ; Thu, 24 Jan 2008 07:04:37 -0500 From: "Alper Yegin" To: "'Hannes Tschofenig'" , Date: Thu, 24 Jan 2008 14:04:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcheaKp9duW2La0cQzWmPKPB0+jtTQAF4AGA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4798557F.4030707@gmx.net> Message-Id: <0MKp8S-1JI0on2Swg-0004OZ@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/uVYuhE4uz+6t7ojEU6GRu32tkylKQNYJGN3H 1MwsNIVLTDixeyPONFxAYeJ76sRTjnpESLaqa8egjJ9Jz1Fi54 pC+5jI10Pg1xqjkU4g3uQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: dime@ietf.org Subject: [Dime] RE: Reviews of draft-ietf-dime-mip6-integrated-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Thank you Jouni and Hannes for the responses. In WiMAX use of RADIUS, we have dedicated attributes for both home-assigned HAs and visited-assigned HAs. I see you are making that distinction by relying on the FQDN of the assigning domain. I guess that works as well. I'm also considering how we can deal with protocol translation between RADIUS and Diameter for these payloads. Can we assume if VCSN receives a RADIUS message with the home-assigned HA IP address in it, the VAAA can generate the Diameter AVP with the right FQDN for that HA as it forwards the message towards a Diameter-only ASN? Alper > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Thursday, January 24, 2008 11:08 AM > To: jouni.korhonen@teliasonera.com > Cc: alper.yegin@yegin.org; dime@ietf.org; Marks, Robert > Subject: Reviews of draft-ietf-dime-mip6-integrated-07.txt > > Thank you Alper for the review comments with regard to the applicability > of the document to the Wimax environment. > Thank you Robert for the feedback. > > I like Jouni's suggestion to make the text in the draft a bit more > explicit regarding the functionality described below: > > 1) The NAS may set the LOCAL_HOME_AGENT_ASSIGNMENT > capability. > > 2) A VAAA may set or overwrite the capability bits to > indicate the preference for the visited network. > > 3) The HAAA performs authentication and authorization (as usual) > and returns a reply message. > > 4) The VAAA may add its local HA to the reply message > > 5) The NAS may receive zero or more HAs, out of which some may be > assigned by the VAAA. The NAS is able to determine > which HA is from the VAAA or from the HAAA by examing > MIP6-Agent-Info AVP and associated HA FQDNs > > Ciao > Hannes > > > > > jouni.korhonen@teliasonera.com wrote: > > Hi Alper, > > > > > >> -----Original Message----- > >> From: Alper Yegin [mailto:alper.yegin@yegin.org] > >> Sent: 17. tammikuuta 2008 12:05 > >> To: dime@ietf.org > >> Subject: [Dime] draft-ietf-dime-mip6-integrated-07.txt > >> > >> This I-D allows HA assignment by the NAS and HAAA. But how > >> about HA assignment by VAAA? > >> > > > > A good point. The current text does not reflect this type of > > deployment clearly enough, as the MIP6 integrated scenario > > bootstrapping does not really define such. Local HA is within > > ASP and the current architecture does not make explicit > > distinction between NAS and VAAA roles when it comes to local > > HA assigment. > > > > However, in my opinion the I-D does not prohibit such > > deployment either. > > > > > >> In WiMAX architecture, there are three distinct networks involved: > >> - ASN: that's where the NAS is. > >> - VCSN: VAAA is in that network. > >> - HCSN: HAAA is here. > >> > >> Is there a particular way to read this I-D such that it can > >> support HA assignment by the VAAA? Or, can we introduce > >> specific text towards that? > >> > > > > I would reword a bit the text in section 4.7.5 and add an > > example under section 5 to cover situations where the HA > > is assigned by the visited AAA. > > > > The rough logic for VAAA assigned HA would be the following: > > > > 1) NAS may or may not set the LOCAL_HOME_AGENT_ASSIGNMENT > > capability.. it does not really matter if VAAA is in charge > > of local HA assignment and the NAS won't do anything regarding > > to local HA assignment anyway > > > > 2) VAAA overwrites the capability bits to indicate its preferences > > to HAAA regarding to the local HA assignment > > > > 3) HAAA functions as normally > > > > 4) In the reply the VAAA adds its local HA to the reply message > > > > 5) NAS receives 0-n assigned HAs, out of which some may be > > assigned by the VAAA. NAS may find the which HA is from VAAA > > and which from HAAA by examing MIP6-Agent-Info AVP and > > associated HA FQDNs > > > > Would this cover your needs? The above is within the current I-D > > but could be expressed more clearly. > > > > Cheers, > > Jouni > > > > > > > > > > > >> Thanks. > >> > >> Alper > >> > >> > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > >> > >> > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 24 07:22:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI16J-0005Yl-27; Thu, 24 Jan 2008 07:22:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI16H-0005WP-Mc for dime@ietf.org; Thu, 24 Jan 2008 07:22:33 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JI16G-0001ma-NG for dime@ietf.org; Thu, 24 Jan 2008 07:22:33 -0500 Received: (qmail invoked by alias); 24 Jan 2008 12:22:30 -0000 Received: from proxy4-nsn.nsn-inter.net (EHLO [217.115.75.232]) [217.115.75.232] by mail.gmx.net (mp011) with SMTP; 24 Jan 2008 13:22:30 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1//H/gHHTP/P4GyUxTEQ/FP86V/kQfdHNoB1nbeLN uW8ZtqHl8fjxo/ Message-ID: <479882FD.7070306@gmx.net> Date: Thu, 24 Jan 2008 14:22:21 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Alper Yegin References: <0MKp8S-1JI0on2Swg-0004OZ@mrelay.perfora.net> In-Reply-To: <0MKp8S-1JI0on2Swg-0004OZ@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: dime@ietf.org Subject: [Dime] Re: Reviews of draft-ietf-dime-mip6-integrated-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Alper, Alper Yegin wrote: > Thank you Jouni and Hannes for the responses. > > In WiMAX use of RADIUS, we have dedicated attributes for both home-assigned > HAs and visited-assigned HAs. I see you are making that distinction by > relying on the FQDN of the assigning domain. > That's interesting. Since we would re-use the approach we develop in DIME for the work in the corresponding RADIUS document there would be a misalignment. > I guess that works as well. I'm also considering how we can deal with > protocol translation between RADIUS and Diameter for these payloads. Can we > assume if VCSN receives a RADIUS message with the home-assigned HA IP > address in it, the VAAA can generate the Diameter AVP with the right FQDN > for that HA as it forwards the message towards a Diameter-only ASN? > That's a good question. The level of difficulty would largely depend on the placement of the translation device. I can imagine that there are potential translation device placements where the processing step wouldn't be so easy todo. Ciao Hannes > > Alper > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Thursday, January 24, 2008 11:08 AM >> To: jouni.korhonen@teliasonera.com >> Cc: alper.yegin@yegin.org; dime@ietf.org; Marks, Robert >> Subject: Reviews of draft-ietf-dime-mip6-integrated-07.txt >> >> Thank you Alper for the review comments with regard to the applicability >> of the document to the Wimax environment. >> Thank you Robert for the feedback. >> >> I like Jouni's suggestion to make the text in the draft a bit more >> explicit regarding the functionality described below: >> >> 1) The NAS may set the LOCAL_HOME_AGENT_ASSIGNMENT >> capability. >> >> 2) A VAAA may set or overwrite the capability bits to >> indicate the preference for the visited network. >> >> 3) The HAAA performs authentication and authorization (as usual) >> and returns a reply message. >> >> 4) The VAAA may add its local HA to the reply message >> >> 5) The NAS may receive zero or more HAs, out of which some may be >> assigned by the VAAA. The NAS is able to determine >> which HA is from the VAAA or from the HAAA by examing >> MIP6-Agent-Info AVP and associated HA FQDNs >> >> Ciao >> Hannes >> >> >> >> >> jouni.korhonen@teliasonera.com wrote: >> >>> Hi Alper, >>> >>> >>> >>>> -----Original Message----- >>>> From: Alper Yegin [mailto:alper.yegin@yegin.org] >>>> Sent: 17. tammikuuta 2008 12:05 >>>> To: dime@ietf.org >>>> Subject: [Dime] draft-ietf-dime-mip6-integrated-07.txt >>>> >>>> This I-D allows HA assignment by the NAS and HAAA. But how >>>> about HA assignment by VAAA? >>>> >>>> >>> A good point. The current text does not reflect this type of >>> deployment clearly enough, as the MIP6 integrated scenario >>> bootstrapping does not really define such. Local HA is within >>> ASP and the current architecture does not make explicit >>> distinction between NAS and VAAA roles when it comes to local >>> HA assigment. >>> >>> However, in my opinion the I-D does not prohibit such >>> deployment either. >>> >>> >>> >>>> In WiMAX architecture, there are three distinct networks involved: >>>> - ASN: that's where the NAS is. >>>> - VCSN: VAAA is in that network. >>>> - HCSN: HAAA is here. >>>> >>>> Is there a particular way to read this I-D such that it can >>>> support HA assignment by the VAAA? Or, can we introduce >>>> specific text towards that? >>>> >>>> >>> I would reword a bit the text in section 4.7.5 and add an >>> example under section 5 to cover situations where the HA >>> is assigned by the visited AAA. >>> >>> The rough logic for VAAA assigned HA would be the following: >>> >>> 1) NAS may or may not set the LOCAL_HOME_AGENT_ASSIGNMENT >>> capability.. it does not really matter if VAAA is in charge >>> of local HA assignment and the NAS won't do anything regarding >>> to local HA assignment anyway >>> >>> 2) VAAA overwrites the capability bits to indicate its preferences >>> to HAAA regarding to the local HA assignment >>> >>> 3) HAAA functions as normally >>> >>> 4) In the reply the VAAA adds its local HA to the reply message >>> >>> 5) NAS receives 0-n assigned HAs, out of which some may be >>> assigned by the VAAA. NAS may find the which HA is from VAAA >>> and which from HAAA by examing MIP6-Agent-Info AVP and >>> associated HA FQDNs >>> >>> Would this cover your needs? The above is within the current I-D >>> but could be expressed more clearly. >>> >>> Cheers, >>> Jouni >>> >>> >>> >>> >>> >>> >>>> Thanks. >>>> >>>> Alper >>>> >>>> >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>>> >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 24 08:00:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI1h7-0000w8-MV; Thu, 24 Jan 2008 08:00:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI1h6-0000uw-Fy for dime@ietf.org; Thu, 24 Jan 2008 08:00:36 -0500 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI1h4-0003g5-2k for dime@ietf.org; Thu, 24 Jan 2008 08:00:36 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 14:00:32 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Jan 2008 14:00:34 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30288A9D1@SEHAN021MB.tcad.telia.se> In-Reply-To: <0MKp8S-1JI0on2Swg-0004OZ@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reviews of draft-ietf-dime-mip6-integrated-07.txt Thread-Index: AcheaKp9duW2La0cQzWmPKPB0+jtTQAF4AGAAAHer/A= References: <4798557F.4030707@gmx.net> <0MKp8S-1JI0on2Swg-0004OZ@mrelay.perfora.net> From: To: , X-OriginalArrivalTime: 24 Jan 2008 13:00:32.0762 (UTC) FILETIME=[1A775DA0:01C85E89] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: dime@ietf.org Subject: [Dime] RE: Reviews of draft-ietf-dime-mip6-integrated-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Alper, > Thank you Jouni and Hannes for the responses. >=20 > In WiMAX use of RADIUS, we have dedicated attributes for both=20 > home-assigned HAs and visited-assigned HAs. I see you are=20 > making that distinction by relying on the FQDN of the=20 > assigning domain. Yes, the current ABNF allows 0-n HAs. That was mainly due some folks thought it would be important. Peeking into FQDNs is imho OK'ish approach. A mobile that is aware of roaming in general typically also knows the realms of its roaming partners. > I guess that works as well. I'm also considering how we can=20 > deal with protocol translation between RADIUS and Diameter=20 > for these payloads. Can we assume if VCSN receives a RADIUS=20 > message with the home-assigned HA IP address in it, the VAAA=20 > can generate the Diameter AVP with the right FQDN for that HA=20 > as it forwards the message towards a Diameter-only ASN? This falls more into a system design and how roaming is defined within the said system. The VAAA could e.g. inspect the contents of the User-Name or CUI attributes in the replies, learn the home realm there. Based on the realm info generate the FQDN for the HA.. but as said details such these are out of scope of IETF. Cheers, Jouni >=20 >=20 > Alper=20 >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Thursday, January 24, 2008 11:08 AM > > To: jouni.korhonen@teliasonera.com > > Cc: alper.yegin@yegin.org; dime@ietf.org; Marks, Robert > > Subject: Reviews of draft-ietf-dime-mip6-integrated-07.txt > >=20 > > Thank you Alper for the review comments with regard to the=20 > > applicability of the document to the Wimax environment. > > Thank you Robert for the feedback. > >=20 > > I like Jouni's suggestion to make the text in the draft a bit more=20 > > explicit regarding the functionality described below: > >=20 > > 1) The NAS may set the LOCAL_HOME_AGENT_ASSIGNMENT > > capability. > >=20 > > 2) A VAAA may set or overwrite the capability bits to > > indicate the preference for the visited network. > >=20 > > 3) The HAAA performs authentication and authorization (as usual) > > and returns a reply message. > >=20 > > 4) The VAAA may add its local HA to the reply message > >=20 > > 5) The NAS may receive zero or more HAs, out of which some may be > > assigned by the VAAA. The NAS is able to determine > > which HA is from the VAAA or from the HAAA by examing > > MIP6-Agent-Info AVP and associated HA FQDNs > >=20 > > Ciao > > Hannes > >=20 > >=20 > >=20 > >=20 > > jouni.korhonen@teliasonera.com wrote: > > > Hi Alper, > > > > > > > > >> -----Original Message----- > > >> From: Alper Yegin [mailto:alper.yegin@yegin.org] > > >> Sent: 17. tammikuuta 2008 12:05 > > >> To: dime@ietf.org > > >> Subject: [Dime] draft-ietf-dime-mip6-integrated-07.txt > > >> > > >> This I-D allows HA assignment by the NAS and HAAA. But=20 > how about HA=20 > > >> assignment by VAAA? > > >> > > > > > > A good point. The current text does not reflect this type of=20 > > > deployment clearly enough, as the MIP6 integrated scenario=20 > > > bootstrapping does not really define such. Local HA is within ASP=20 > > > and the current architecture does not make explicit distinction=20 > > > between NAS and VAAA roles when it comes to local HA assigment. > > > > > > However, in my opinion the I-D does not prohibit such deployment=20 > > > either. > > > > > > > > >> In WiMAX architecture, there are three distinct networks=20 > involved: > > >> - ASN: that's where the NAS is. > > >> - VCSN: VAAA is in that network. > > >> - HCSN: HAAA is here. > > >> > > >> Is there a particular way to read this I-D such that it=20 > can support=20 > > >> HA assignment by the VAAA? Or, can we introduce specific text=20 > > >> towards that? > > >> > > > > > > I would reword a bit the text in section 4.7.5 and add an example=20 > > > under section 5 to cover situations where the HA is=20 > assigned by the=20 > > > visited AAA. > > > > > > The rough logic for VAAA assigned HA would be the following: > > > > > > 1) NAS may or may not set the LOCAL_HOME_AGENT_ASSIGNMENT > > > capability.. it does not really matter if VAAA is in charge > > > of local HA assignment and the NAS won't do anything regarding > > > to local HA assignment anyway > > > > > > 2) VAAA overwrites the capability bits to indicate its preferences > > > to HAAA regarding to the local HA assignment > > > > > > 3) HAAA functions as normally > > > > > > 4) In the reply the VAAA adds its local HA to the reply message > > > > > > 5) NAS receives 0-n assigned HAs, out of which some may be > > > assigned by the VAAA. NAS may find the which HA is from VAAA > > > and which from HAAA by examing MIP6-Agent-Info AVP and > > > associated HA FQDNs > > > > > > Would this cover your needs? The above is within the=20 > current I-D but=20 > > > could be expressed more clearly. > > > > > > Cheers, > > > Jouni > > > > > > > > > > > > > > > > > >> Thanks. > > >> > > >> Alper > > >> > > >> > > >> > > >> _______________________________________________ > > >> DiME mailing list > > >> DiME@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/dime > > >> > > >> > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > >=20 >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 29 05:30:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJnj9-0001eM-Ob; Tue, 29 Jan 2008 05:30:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJnj8-0001e2-R5; Tue, 29 Jan 2008 05:30:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJnj8-0007sF-FM; Tue, 29 Jan 2008 05:30:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 5533226E4D; Tue, 29 Jan 2008 10:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JJnj8-00060B-8B; Tue, 29 Jan 2008 05:30:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 29 Jan 2008 05:30:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-qos-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Quality of Service Application Author(s) : D. Sun, et al. Filename : draft-ietf-dime-diameter-qos-04.txt Pages : 58 Date : 2008-01-29 This document describes framework, messages and procedures for the Diameter Quality of Service (QoS) application. The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation - Pull and Push are defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-diameter-qos-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-diameter-qos-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-29052928.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-diameter-qos-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-diameter-qos-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-29052928.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Wed Jan 30 18:35:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKMTB-0006kt-Fs; Wed, 30 Jan 2008 18:35:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKMT9-0006ki-C8; Wed, 30 Jan 2008 18:35:51 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKMT8-0005TM-0R; Wed, 30 Jan 2008 18:35:51 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0UNZjbj003210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Jan 2008 15:35:45 -0800 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0UNZi7p005948; Wed, 30 Jan 2008 15:35:45 -0800 (PST) Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jan 2008 15:35:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Jan 2008 15:35:41 -0800 Message-ID: In-Reply-To: <47924D28.4020903@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] WGLC for draft-ietf-mext-aaa-ha-goals-00.txt Thread-Index: Acha0DBmPBZiJjfRQwy2eXXKm2ojwQIyFmbA From: "Giaretta, Gerardo" To: "Hannes Tschofenig" X-OriginalArrivalTime: 30 Jan 2008 23:35:44.0824 (UTC) FILETIME=[D5810380:01C86398] X-Spam-Score: -4.0 (----) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: dime@ietf.org, mext@ietf.org Subject: [Dime] RE: [MEXT] WGLC for draft-ietf-mext-aaa-ha-goals-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hannes,=20 The changes you proposed are fine. I saw that you sent an email to DIME to request comments on the ciphering aspects. That is fine with me; let's see if there is any opinion there.=20 However let's remember that requirements should influence the solution and not the other way around :-) Ciao Gerardo > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Saturday, January 19, 2008 11:19 AM > To: Giaretta, Gerardo > Cc: dime@ietf.org; mext@ietf.org > Subject: Re: [MEXT] WGLC for draft-ietf-mext-aaa-ha-goals-00.txt >=20 > Hi Gerardo, >=20 > thanks for your quick response. Please find my comments inline: >=20 > ~snip~ > >> > >> > >>>> G2.11 The AAAH server MUST be able to indicate to the HA > >>>> > > whether > > > >>> the > >>> > >>> > >>>> bearer traffic for the MN needs to receive IPsec ESP > >>>> > > protection. > > > >>>> I don't understand this either. > >>>> > >>>> > >>>> > >>> The AAA may indicate if the MIPv6 tunnel should be an IP-in-IP > >>> > > tunnel or > > > >>> an ESP tunnel. > >>> > >>> > >> Hmmm. I might have missed something but Mobile IP establishes IP-in-IP > >> (or GRE tunnels) and not ESP tunnels. > >> > >> > > > > The HA and MN may configure a child SA to protect payload traffic. In > > this way the packets from HA to MN are protected using ESP. > > > > >=20 > This is a somewhat new requirement for me and we have not addressed this > aspect in our DIME documents. >=20 > The additional issue with this requirement is that one needs to have a > way to run an authorization exchange between the HA and the AAAS after > the authentication. > At the moment the authorization exchange and the authentication exchange > happen at the same time. >=20 > I will post a separate mail to the DIME list to see what implication > this has with respect to the protocol design. >=20 >=20 > >>>> G2.12 The HA MUST be able to authenticate the MN through the > >>>> > > AAAH > > > >>> in > >>> > >>> > >>>> case a pre-share key is used in IKEv2 for user > >>>> > > authentication. > > > >>>> The exact procedure is part of the solution space. > >>>> > >>>> > >>>> Why do you list this requirement? I believe it is pretty much > >>>> > > useless > > > >>>> given > >>>> that it is a consequence of the solution. I suggest to delete this > >>>> requirement. > >>>> > >>>> > >>>> > >>> I agree it is a consequence of the solution. However, I think it is > >>> > > good > > > >>> to make it clear here as RFC 5026 provides text for PSK, EAP and > >>> certificates. I don't think it is bad to have it. > >>> > >>> > >>> > >> Then, I would write make it more explicitly. Just say that RFC 5026 > >> supports different > >> authentication mechanisms (PSK, EAP and certificates) and the solution > >> specification MUST > >> specify all variants. > >> > >> > > > > This was suggested by Vijay. The point is that the HA may be able to > > fetch the PSK from the AAAH in case it does not have it. It's not only > > supporting PSK within IKEv2, rather contacting the AAAH to verify the > > PSK. > > > > > The way how IKEv2 works would not allow PSK based authentication to be > relayed to the AAA server. It does not work with legacy PSK credentials. > Hence, the only reasonable way is to request the PSK from the AAAH. >=20 > But this is fine with me. I don't see a contradiction between the > requirements text I wrote and the one envisioned by Vijay. >=20 > ~snip~ >=20 > >>>> The same > >>>> is true for requirement G4.7, which says: > >>>> > >>>> G4.7 If the MN-AAA Mobility Message Authentication Option is > >>>> > > not > > > >>>> included by the HA or the MN-AAA Mobility Message > >>>> > > Authentication > > > >>>> Option is included and the MN-AAA authentication is > >>>> > > successful, > > > >>>> the AAAH MUST send the keying material for MN-HA key to the > >>>> > > HA > > > >>> if > >>> > >>> > >>>> the HA requested for MN-HA keying material only. The AAAH > >>>> > > MUST > > > >>>> send the MN-HA key and the corresponding SPI value to the HA > >>>> > > if > > > >>>> the HA requested for MN-HA key and SPI. > >>>> > >>>> > >>>> This paragraph sounds really complex. The first sentence is pretty > >>>> > >>>> > >>> much > >>> > >>> > >>>> irrelevant for such a requirements document. Isn't the 2nd sentence > >>>> covered > >>>> by requirement in G4.3 already? > >>>> > >>>> > >>>> > >>> I agree we can remove the first sentence. The second sentence is > >>> different form G4.3, though: G4.3 is about the HA to request the > >>> > > keying > > > >>> material while G4.7 is about the AAAH sending it. Would you prefer > >>> > > merge > > > >>> the two goals? > >>> > >>> > >>> > >> I would combine it since it is a requirement for requesting a keying > >> material would (in my opinion) > >> also imply that you have a way to receive it. > >> > >> > > > > Can you please propose some text? I still don't fully understand the > > implications of the proposal. > > > > > Here is G4.7 >=20 > G4.7 If the MN-AAA Mobility Message Authentication Option is not > included by the HA or the MN-AAA Mobility Message Authentication > Option is included and the MN-AAA authentication is successful, > the AAAH MUST send the keying material for MN-HA key to the HA if > the HA requested for MN-HA keying material only. The AAAH MUST > send the MN-HA key and the corresponding SPI value to the HA if > the HA requested for MN-HA key and SPI. >=20 >=20 > Here is G4.3: >=20 > G4.3 The HA SHOULD be able to request either the keying material to > generate MN-HA key for MN-HA Mobility Message Authentication > Option or SHOULD be able to request the MN-HA key and the related > SPI values from the AAAH server. >=20 >=20 > The new requirement as a replacement of the above 2: >=20 > The AAAH MUST be able to provide a MN-HA key (or data used for > subsequent key derivation of the > MN-HA key by the HA) to the HA if requested. > Additional data, such as the SPI or lifetime parameters, are sent along > with the keying material. >=20 > ~snip~ >=20 > Ciao > Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 31 02:44:57 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKU6T-0008UB-7J; Thu, 31 Jan 2008 02:44:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKU6R-0008TV-Kn for dime@ietf.org; Thu, 31 Jan 2008 02:44:55 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JKU6P-0005Gd-Cm for dime@ietf.org; Thu, 31 Jan 2008 02:44:55 -0500 Received: (qmail invoked by alias); 31 Jan 2008 07:44:51 -0000 Received: from proxy3-nsn.nsn-inter.net (EHLO [217.115.75.231]) [217.115.75.231] by mail.gmx.net (mp006) with SMTP; 31 Jan 2008 08:44:51 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+87/J5Lpm8JyIOdhnJRMRueHsCxkNVeFCFdRQEuk 0ZizoFAX/UeSGr Message-ID: <47A17C75.80405@gmx.net> Date: Thu, 31 Jan 2008 09:44:53 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Giaretta, Gerardo" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 Cc: dime@ietf.org, mext@ietf.org Subject: [Dime] Re: [MEXT] WGLC for draft-ietf-mext-aaa-ha-goals-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Gerardo Giaretta, Gerardo wrote: > Hannes, > > The changes you proposed are fine. I saw that you sent an email to DIME > to request comments on the ciphering aspects. That is fine with me; > let's see if there is any opinion there. > So far, no response. > However let's remember that requirements should influence the solution > and not the other way around :-) > > That's correct. I just wanted to make the group aware of a requirement that I haven't seen before. Ciao Hannes > Ciao > Gerardo > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Saturday, January 19, 2008 11:19 AM >> To: Giaretta, Gerardo >> Cc: dime@ietf.org; mext@ietf.org >> Subject: Re: [MEXT] WGLC for draft-ietf-mext-aaa-ha-goals-00.txt >> >> Hi Gerardo, >> >> thanks for your quick response. Please find my comments inline: >> >> ~snip~ >> >>>> >>>>>> G2.11 The AAAH server MUST be able to indicate to the HA >>>>>> >>>>>> >>> whether >>> >>> >>>>> the >>>>> >>>>> >>>>> >>>>>> bearer traffic for the MN needs to receive IPsec ESP >>>>>> >>>>>> >>> protection. >>> >>> >>>>>> I don't understand this either. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> The AAA may indicate if the MIPv6 tunnel should be an IP-in-IP >>>>> >>>>> >>> tunnel or >>> >>> >>>>> an ESP tunnel. >>>>> >>>>> >>>>> >>>> Hmmm. I might have missed something but Mobile IP establishes >>>> > IP-in-IP > >>>> (or GRE tunnels) and not ESP tunnels. >>>> >>>> >>>> >>> The HA and MN may configure a child SA to protect payload traffic. >>> > In > >>> this way the packets from HA to MN are protected using ESP. >>> >>> >>> >> This is a somewhat new requirement for me and we have not addressed >> > this > >> aspect in our DIME documents. >> >> The additional issue with this requirement is that one needs to have a >> way to run an authorization exchange between the HA and the AAAS after >> the authentication. >> At the moment the authorization exchange and the authentication >> > exchange > >> happen at the same time. >> >> I will post a separate mail to the DIME list to see what implication >> this has with respect to the protocol design. >> >> >> >>>>>> G2.12 The HA MUST be able to authenticate the MN through the >>>>>> >>>>>> >>> AAAH >>> >>> >>>>> in >>>>> >>>>> >>>>> >>>>>> case a pre-share key is used in IKEv2 for user >>>>>> >>>>>> >>> authentication. >>> >>> >>>>>> The exact procedure is part of the solution space. >>>>>> >>>>>> >>>>>> Why do you list this requirement? I believe it is pretty much >>>>>> >>>>>> >>> useless >>> >>> >>>>>> given >>>>>> that it is a consequence of the solution. I suggest to delete >>>>>> > this > >>>>>> requirement. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I agree it is a consequence of the solution. However, I think it >>>>> > is > >>> good >>> >>> >>>>> to make it clear here as RFC 5026 provides text for PSK, EAP and >>>>> certificates. I don't think it is bad to have it. >>>>> >>>>> >>>>> >>>>> >>>> Then, I would write make it more explicitly. Just say that RFC 5026 >>>> supports different >>>> authentication mechanisms (PSK, EAP and certificates) and the >>>> > solution > >>>> specification MUST >>>> specify all variants. >>>> >>>> >>>> >>> This was suggested by Vijay. The point is that the HA may be able to >>> fetch the PSK from the AAAH in case it does not have it. It's not >>> > only > >>> supporting PSK within IKEv2, rather contacting the AAAH to verify >>> > the > >>> PSK. >>> >>> >>> >> The way how IKEv2 works would not allow PSK based authentication to be >> relayed to the AAA server. It does not work with legacy PSK >> > credentials. > >> Hence, the only reasonable way is to request the PSK from the AAAH. >> >> But this is fine with me. I don't see a contradiction between the >> requirements text I wrote and the one envisioned by Vijay. >> >> ~snip~ >> >> >>>>>> The same >>>>>> is true for requirement G4.7, which says: >>>>>> >>>>>> G4.7 If the MN-AAA Mobility Message Authentication Option is >>>>>> >>>>>> >>> not >>> >>> >>>>>> included by the HA or the MN-AAA Mobility Message >>>>>> >>>>>> >>> Authentication >>> >>> >>>>>> Option is included and the MN-AAA authentication is >>>>>> >>>>>> >>> successful, >>> >>> >>>>>> the AAAH MUST send the keying material for MN-HA key to the >>>>>> >>>>>> >>> HA >>> >>> >>>>> if >>>>> >>>>> >>>>> >>>>>> the HA requested for MN-HA keying material only. The AAAH >>>>>> >>>>>> >>> MUST >>> >>> >>>>>> send the MN-HA key and the corresponding SPI value to the >>>>>> > HA > >>> if >>> >>> >>>>>> the HA requested for MN-HA key and SPI. >>>>>> >>>>>> >>>>>> This paragraph sounds really complex. The first sentence is >>>>>> > pretty > >>>>>> >>>>> much >>>>> >>>>> >>>>> >>>>>> irrelevant for such a requirements document. Isn't the 2nd >>>>>> > sentence > >>>>>> covered >>>>>> by requirement in G4.3 already? >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I agree we can remove the first sentence. The second sentence is >>>>> different form G4.3, though: G4.3 is about the HA to request the >>>>> >>>>> >>> keying >>> >>> >>>>> material while G4.7 is about the AAAH sending it. Would you prefer >>>>> >>>>> >>> merge >>> >>> >>>>> the two goals? >>>>> >>>>> >>>>> >>>>> >>>> I would combine it since it is a requirement for requesting a >>>> > keying > >>>> material would (in my opinion) >>>> also imply that you have a way to receive it. >>>> >>>> >>>> >>> Can you please propose some text? I still don't fully understand the >>> implications of the proposal. >>> >>> >>> >> Here is G4.7 >> >> G4.7 If the MN-AAA Mobility Message Authentication Option is not >> included by the HA or the MN-AAA Mobility Message Authentication >> Option is included and the MN-AAA authentication is successful, >> the AAAH MUST send the keying material for MN-HA key to the HA >> > if > >> the HA requested for MN-HA keying material only. The AAAH MUST >> send the MN-HA key and the corresponding SPI value to the HA if >> the HA requested for MN-HA key and SPI. >> >> >> Here is G4.3: >> >> G4.3 The HA SHOULD be able to request either the keying material >> > to > >> generate MN-HA key for MN-HA Mobility Message Authentication >> Option or SHOULD be able to request the MN-HA key and the >> > related > >> SPI values from the AAAH server. >> >> >> The new requirement as a replacement of the above 2: >> >> The AAAH MUST be able to provide a MN-HA key (or data used for >> subsequent key derivation of the >> MN-HA key by the HA) to the HA if requested. >> Additional data, such as the SPI or lifetime parameters, are sent >> > along > >> with the keying material. >> >> ~snip~ >> >> Ciao >> Hannes >> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 31 02:46:14 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKU7i-00010g-MS; Thu, 31 Jan 2008 02:46:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKU7h-00010X-2d for dime@ietf.org; Thu, 31 Jan 2008 02:46:13 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JKU7g-0005ID-JE for dime@ietf.org; Thu, 31 Jan 2008 02:46:13 -0500 Received: (qmail invoked by alias); 31 Jan 2008 07:46:11 -0000 Received: from proxy3-nsn.nsn-inter.net (EHLO [217.115.75.231]) [217.115.75.231] by mail.gmx.net (mp010) with SMTP; 31 Jan 2008 08:46:11 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18HL35ZvpEHT5l3+RzKmF+NXIgKYp1jfiDs3C+mNz YW2gDRBz66YCZz Message-ID: <47A17CC6.2080506@gmx.net> Date: Thu, 31 Jan 2008 09:46:14 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dime@ietf.org Subject: Re: [Dime] NEW REQUIREMENT -- WGLC for draft-ietf-mext-aaa-ha-goals-00.txt References: <47924D1C.9080903@gmx.net> In-Reply-To: <47924D1C.9080903@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Please give me feedback on this issue! Hannes Tschofenig wrote: > Hi all, > > reading carefully through draft-ietf-mext-aaa-ha-goals-00.txt and I > noticed a new requirement, namely > > G2.11 The AAAH server MUST be able to indicate to the HA whether the > bearer traffic for the MN needs to receive IPsec ESP protection. > > To me it appears that a solution for such a requirement requires a > separate exchange between the HA and the AAAH to perform an > authorization check. > This might require modifications to draft-ietf-dime-mip6-split-06.txt > since authentication and authorization are currently done at the same > time. > > I am correctly understanding the requirement and the implications? > > Feedback appreciated. > > Ciao > Hannes > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 31 02:51:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKUCv-0007wb-DU; Thu, 31 Jan 2008 02:51:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKUCu-0007wR-Cy for dime@ietf.org; Thu, 31 Jan 2008 02:51:36 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JKUCt-0005Mc-VA for dime@ietf.org; Thu, 31 Jan 2008 02:51:36 -0500 Received: (qmail invoked by alias); 31 Jan 2008 07:51:34 -0000 Received: from proxy3-nsn.nsn-inter.net (EHLO [217.115.75.231]) [217.115.75.231] by mail.gmx.net (mp013) with SMTP; 31 Jan 2008 08:51:34 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+s0cosHaqsbS2Q7tz0zvVI7iiUcv6/I0d8gv1kW6 Sg24zpQ3C2aini Message-ID: <47A17E09.6070009@gmx.net> Date: Thu, 31 Jan 2008 09:51:37 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: narten@us.ibm.com Subject: [Dime] Feedback from the 3GPP2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org FYI, Thomas Narten, IETF Liaison to the 3GPP2, has sent the DIME chairs a mail that the 3GPP2 shows interest in two documents discussed in DIME, namely * draft-ietf-dime-mip6-integrated * draft-dondeti-dime-erp-diameter I immediately responded to Thomas to tell him that we are currently finishing the work on draft-ietf-dime-mip6-integrated and would still appreciate comments. We have just received good comments from the Wimax Forum that have been incorporated into the draft (draft submission pending but imminent). I also told him that we are currently in the phase of re-chartering and draft-dondeti-dime-erp-diameter is also being discussed as a potential DIME charter item candidate. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 31 10:12:32 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKb5c-0004C2-1g; Thu, 31 Jan 2008 10:12:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKb5b-0004Bw-DQ for dime@ietf.org; Thu, 31 Jan 2008 10:12:31 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKb5a-00061C-WA for dime@ietf.org; Thu, 31 Jan 2008 10:12:31 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m0VFCRP11521; Thu, 31 Jan 2008 15:12:28 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] NEW REQUIREMENT -- WGLC for draft-ietf-mext-aaa-ha-goals-00.txt Date: Thu, 31 Jan 2008 09:12:06 -0600 Message-ID: In-Reply-To: <47A17CC6.2080506@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] NEW REQUIREMENT -- WGLC for draft-ietf-mext-aaa-ha-goals-00.txt Thread-Index: Achj3V8tBMkbAKFjSgaY4bUe5jgJkwAPZgcg References: <47924D1C.9080903@gmx.net> <47A17CC6.2080506@gmx.net> From: "Ahmad Muhanna" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes, I am not sure why this needs to be done separately. Since the concept of doing both authentication and authorization at the same time is acceptable, I do not see any problem in applying the same on this requirement. As a requirement, I believe it is useful and should be addressed. Regards, Ahmad =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Thursday, January 31, 2008 1:46 AM > To: dime@ietf.org > Subject: Re: [Dime] NEW REQUIREMENT -- WGLC for=20 > draft-ietf-mext-aaa-ha-goals-00.txt >=20 > Please give me feedback on this issue! >=20 > Hannes Tschofenig wrote: > > Hi all, > > > > reading carefully through draft-ietf-mext-aaa-ha-goals-00.txt and I=20 > > noticed a new requirement, namely > > > > G2.11 The AAAH server MUST be able to indicate to the HA=20 > whether the > > bearer traffic for the MN needs to receive IPsec ESP=20 > protection. > > > > To me it appears that a solution for such a requirement requires a=20 > > separate exchange between the HA and the AAAH to perform an=20 > > authorization check. > > This might require modifications to=20 > draft-ietf-dime-mip6-split-06.txt=20 > > since authentication and authorization are currently done=20 > at the same=20 > > time. > > > > I am correctly understanding the requirement and the implications? > > > > Feedback appreciated. > > > > Ciao > > Hannes > > > > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 31 10:17:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKbAq-0001XC-TF; Thu, 31 Jan 2008 10:17:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKbAq-0001Wd-3D for dime@ietf.org; Thu, 31 Jan 2008 10:17:56 -0500 Received: from demumfd001.nsn-inter.net ([217.115.75.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKbAn-000816-Oc for dime@ietf.org; Thu, 31 Jan 2008 10:17:56 -0500 Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m0VFHqXG021236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2008 16:17:52 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m0VFHqoe022050; Thu, 31 Jan 2008 16:17:52 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jan 2008 16:17:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Dime] NEW REQUIREMENT --WGLC for draft-ietf-mext-aaa-ha-goals-00.txt Date: Thu, 31 Jan 2008 16:17:50 +0100 Message-ID: <5FB585F183235B42A9E70095055136FB7099CE@DEMUEXC012.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] NEW REQUIREMENT --WGLC for draft-ietf-mext-aaa-ha-goals-00.txt Thread-Index: Achj3V8tBMkbAKFjSgaY4bUe5jgJkwAPZgcgAAA/R1A= References: <47924D1C.9080903@gmx.net> <47A17CC6.2080506@gmx.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Ahmad Muhanna" , "Hannes Tschofenig" , X-OriginalArrivalTime: 31 Jan 2008 15:17:52.0079 (UTC) FILETIME=[725F9DF0:01C8641C] X-Spam-Score: -4.0 (----) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Ahmad,=20 I might have initially misread it a bit. It seems that it is sufficient = for the AAA server to indicate whether a subsequent CHILD SA exchange = should be initiated with the MN. I have read it in a way that a = susequent CHILD SA exchange would trigger an exchange with the AAA = server asking for authorization. The latter approach would require us to = change the document.=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: ext Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 > Gesendet: Donnerstag, 31. Januar 2008 17:12 > An: Hannes Tschofenig; dime@ietf.org > Betreff: RE: [Dime] NEW REQUIREMENT --WGLC for=20 > draft-ietf-mext-aaa-ha-goals-00.txt >=20 > Hi Hannes, >=20 > I am not sure why this needs to be done separately. Since the=20 > concept of > doing both authentication and authorization at the same time is > acceptable, I do not see any problem in applying the same on this > requirement. >=20 > As a requirement, I believe it is useful and should be addressed. >=20 >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > > Sent: Thursday, January 31, 2008 1:46 AM > > To: dime@ietf.org > > Subject: Re: [Dime] NEW REQUIREMENT -- WGLC for=20 > > draft-ietf-mext-aaa-ha-goals-00.txt > >=20 > > Please give me feedback on this issue! > >=20 > > Hannes Tschofenig wrote: > > > Hi all, > > > > > > reading carefully through=20 > draft-ietf-mext-aaa-ha-goals-00.txt and I=20 > > > noticed a new requirement, namely > > > > > > G2.11 The AAAH server MUST be able to indicate to the HA=20 > > whether the > > > bearer traffic for the MN needs to receive IPsec ESP=20 > > protection. > > > > > > To me it appears that a solution for such a requirement=20 > requires a=20 > > > separate exchange between the HA and the AAAH to perform an=20 > > > authorization check. > > > This might require modifications to=20 > > draft-ietf-dime-mip6-split-06.txt=20 > > > since authentication and authorization are currently done=20 > > at the same=20 > > > time. > > > > > > I am correctly understanding the requirement and the implications? > > > > > > Feedback appreciated. > > > > > > Ciao > > > Hannes > > > > > > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 31 10:37:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKbU0-0004SF-4c; Thu, 31 Jan 2008 10:37:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKbTz-0004O0-3f for dime@ietf.org; Thu, 31 Jan 2008 10:37:43 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKbTy-0007Im-6V for dime@ietf.org; Thu, 31 Jan 2008 10:37:42 -0500 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0VFbbUo019249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 31 Jan 2008 07:37:38 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0VFbbgq008770; Thu, 31 Jan 2008 07:37:37 -0800 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jan 2008 07:37:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [Dime] NEW REQUIREMENT--WGLC for draft-ietf-mext-aaa-ha-goals-00.txt Date: Thu, 31 Jan 2008 07:37:35 -0800 Message-ID: In-Reply-To: <5FB585F183235B42A9E70095055136FB7099CE@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] NEW REQUIREMENT--WGLC for draft-ietf-mext-aaa-ha-goals-00.txt Thread-Index: Achj3V8tBMkbAKFjSgaY4bUe5jgJkwAPZgcgAAA/R1AAADl0YA== From: "Giaretta, Gerardo" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Ahmad Muhanna" , "Hannes Tschofenig" , X-OriginalArrivalTime: 31 Jan 2008 15:37:37.0414 (UTC) FILETIME=[34E36260:01C8641F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes and Ahmad, I agree with Hannes interpretation of the requirement. The requirement = does not intend to point to any solution (separate message or not). = Please let me know if there is anything in the requirement that seems to = point to any solution; in that case it needs to be rephrased. >From a solution perspective, I think what is needed is just that the AAA = server sends to the HA an indication if ciphering is authorized for the = MN. This step can be done during authentication and authorization. Then = the HA may create a child SA or may wait for the MN to create it. What = is important is that the HA knows that the MN is authorized to use this = feature. Gerardo > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:hannes.tschofenig@nsn.com] > Sent: Thursday, January 31, 2008 7:18 AM > To: ext Ahmad Muhanna; Hannes Tschofenig; dime@ietf.org > Subject: AW: [Dime] NEW REQUIREMENT--WGLC for draft-ietf-mext-aaa-ha- > goals-00.txt >=20 > Hi Ahmad, >=20 > I might have initially misread it a bit. It seems that it is = sufficient > for the AAA server to indicate whether a subsequent CHILD SA exchange > should be initiated with the MN. I have read it in a way that a = susequent > CHILD SA exchange would trigger an exchange with the AAA server asking = for > authorization. The latter approach would require us to change the = document. >=20 > Ciao > Hannes >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: ext Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Gesendet: Donnerstag, 31. Januar 2008 17:12 > > An: Hannes Tschofenig; dime@ietf.org > > Betreff: RE: [Dime] NEW REQUIREMENT --WGLC for > > draft-ietf-mext-aaa-ha-goals-00.txt > > > > Hi Hannes, > > > > I am not sure why this needs to be done separately. Since the > > concept of > > doing both authentication and authorization at the same time is > > acceptable, I do not see any problem in applying the same on this > > requirement. > > > > As a requirement, I believe it is useful and should be addressed. > > > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: Thursday, January 31, 2008 1:46 AM > > > To: dime@ietf.org > > > Subject: Re: [Dime] NEW REQUIREMENT -- WGLC for > > > draft-ietf-mext-aaa-ha-goals-00.txt > > > > > > Please give me feedback on this issue! > > > > > > Hannes Tschofenig wrote: > > > > Hi all, > > > > > > > > reading carefully through > > draft-ietf-mext-aaa-ha-goals-00.txt and I > > > > noticed a new requirement, namely > > > > > > > > G2.11 The AAAH server MUST be able to indicate to the HA > > > whether the > > > > bearer traffic for the MN needs to receive IPsec ESP > > > protection. > > > > > > > > To me it appears that a solution for such a requirement > > requires a > > > > separate exchange between the HA and the AAAH to perform an > > > > authorization check. > > > > This might require modifications to > > > draft-ietf-dime-mip6-split-06.txt > > > > since authentication and authorization are currently done > > > at the same > > > > time. > > > > > > > > I am correctly understanding the requirement and the = implications? > > > > > > > > Feedback appreciated. > > > > > > > > Ciao > > > > Hannes > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 31 10:40:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKbX9-0005N6-BA; Thu, 31 Jan 2008 10:40:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKbX8-0005N0-BG for dime@ietf.org; Thu, 31 Jan 2008 10:40:58 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKbX7-0000Rz-2L for dime@ietf.org; Thu, 31 Jan 2008 10:40:57 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m0VFepP17655; Thu, 31 Jan 2008 15:40:52 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 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: [Dime] NEW REQUIREMENT--WGLC for draft-ietf-mext-aaa-ha-goals-00.txt Date: Thu, 31 Jan 2008 09:40:44 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] NEW REQUIREMENT--WGLC for draft-ietf-mext-aaa-ha-goals-00.txt Thread-Index: Achj3V8tBMkbAKFjSgaY4bUe5jgJkwAPZgcgAAA/R1AAADl0YAAAo6Aw References: <5FB585F183235B42A9E70095055136FB7099CE@DEMUEXC012.nsn-intra.net> From: "Ahmad Muhanna" To: "Giaretta, Gerardo" , "Tschofenig, Hannes (NSN - FI/Espoo)" , "Hannes Tschofenig" , X-Spam-Score: -4.0 (----) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Sounds good. Regards, Ahmad =20 > -----Original Message----- > From: Giaretta, Gerardo [mailto:gerardog@qualcomm.com]=20 > Sent: Thursday, January 31, 2008 9:38 AM > To: Tschofenig, Hannes (NSN - FI/Espoo); Muhanna, Ahmad=20 > (RICH1:2H10); Hannes Tschofenig; dime@ietf.org > Subject: RE: [Dime] NEW REQUIREMENT--WGLC for=20 > draft-ietf-mext-aaa-ha-goals-00.txt >=20 > Hi Hannes and Ahmad, >=20 > I agree with Hannes interpretation of the requirement. The=20 > requirement does not intend to point to any solution=20 > (separate message or not). Please let me know if there is=20 > anything in the requirement that seems to point to any=20 > solution; in that case it needs to be rephrased. >=20 > From a solution perspective, I think what is needed is just=20 > that the AAA server sends to the HA an indication if=20 > ciphering is authorized for the MN. This step can be done=20 > during authentication and authorization. Then the HA may=20 > create a child SA or may wait for the MN to create it. What=20 > is important is that the HA knows that the MN is authorized=20 > to use this feature. >=20 > Gerardo >=20 > > -----Original Message----- > > From: Tschofenig, Hannes (NSN - FI/Espoo)=20 > > [mailto:hannes.tschofenig@nsn.com] > > Sent: Thursday, January 31, 2008 7:18 AM > > To: ext Ahmad Muhanna; Hannes Tschofenig; dime@ietf.org > > Subject: AW: [Dime] NEW REQUIREMENT--WGLC for=20 > draft-ietf-mext-aaa-ha-=20 > > goals-00.txt > >=20 > > Hi Ahmad, > >=20 > > I might have initially misread it a bit. It seems that it is=20 > > sufficient for the AAA server to indicate whether a=20 > subsequent CHILD=20 > > SA exchange should be initiated with the MN. I have read it=20 > in a way=20 > > that a susequent CHILD SA exchange would trigger an=20 > exchange with the=20 > > AAA server asking for authorization. The latter approach=20 > would require us to change the document. > >=20 > > Ciao > > Hannes > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: ext Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > Gesendet: Donnerstag, 31. Januar 2008 17:12 > > > An: Hannes Tschofenig; dime@ietf.org > > > Betreff: RE: [Dime] NEW REQUIREMENT --WGLC for=20 > > > draft-ietf-mext-aaa-ha-goals-00.txt > > > > > > Hi Hannes, > > > > > > I am not sure why this needs to be done separately. Since the=20 > > > concept of doing both authentication and authorization at=20 > the same=20 > > > time is acceptable, I do not see any problem in applying=20 > the same on=20 > > > this requirement. > > > > > > As a requirement, I believe it is useful and should be addressed. > > > > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > Sent: Thursday, January 31, 2008 1:46 AM > > > > To: dime@ietf.org > > > > Subject: Re: [Dime] NEW REQUIREMENT -- WGLC for=20 > > > > draft-ietf-mext-aaa-ha-goals-00.txt > > > > > > > > Please give me feedback on this issue! > > > > > > > > Hannes Tschofenig wrote: > > > > > Hi all, > > > > > > > > > > reading carefully through > > > draft-ietf-mext-aaa-ha-goals-00.txt and I > > > > > noticed a new requirement, namely > > > > > > > > > > G2.11 The AAAH server MUST be able to indicate to the HA > > > > whether the > > > > > bearer traffic for the MN needs to receive IPsec ESP > > > > protection. > > > > > > > > > > To me it appears that a solution for such a requirement > > > requires a > > > > > separate exchange between the HA and the AAAH to perform an=20 > > > > > authorization check. > > > > > This might require modifications to > > > > draft-ietf-dime-mip6-split-06.txt > > > > > since authentication and authorization are currently done > > > > at the same > > > > > time. > > > > > > > > > > I am correctly understanding the requirement and the=20 > implications? > > > > > > > > > > Feedback appreciated. > > > > > > > > > > Ciao > > > > > Hannes > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 31 10:45:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKbbn-0006Ga-G3; Thu, 31 Jan 2008 10:45:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKbbm-0006GU-F5 for dime@ietf.org; Thu, 31 Jan 2008 10:45:46 -0500 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKbbl-0007VW-SN for dime@ietf.org; Thu, 31 Jan 2008 10:45:46 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 16:45:43 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 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: [Dime] NEW REQUIREMENT--WGLC for draft-ietf-mext-aaa-ha-goals-00.txt Date: Thu, 31 Jan 2008 16:45:40 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30288AB0A@SEHAN021MB.tcad.telia.se> In-Reply-To: <5FB585F183235B42A9E70095055136FB7099CE@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] NEW REQUIREMENT--WGLC for draft-ietf-mext-aaa-ha-goals-00.txt Thread-Index: Achj3V8tBMkbAKFjSgaY4bUe5jgJkwAPZgcgAAA/R1AAAEoY4A== References: <47924D1C.9080903@gmx.net> <47A17CC6.2080506@gmx.net> <5FB585F183235B42A9E70095055136FB7099CE@DEMUEXC012.nsn-intra.net> From: To: , , , X-OriginalArrivalTime: 31 Jan 2008 15:45:43.0494 (UTC) FILETIME=[569D4E60:01C86420] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, As for the signaling, we got the MIP6-Feature-Vector for such purposes. So we can address the HA-AAAH additions easily. For the rest regarding the G2.11, when the MIP6 bootstrapping takes place, IKEv2 creates implicitly the first CHILD_SA that can be used for subsequent control/user plane traffic protection. So the MIP6-Feature-Vector negotiation result would then apply to all CHILD_SA creations, whether confidentially protection is allowed in general. However, there would an issue here. We do not have a way to indicate from the HA to the UE whether it can use the first CHILD_SA for user plane protection or not.. right? Current practices e.g. in 3GPP IKEv2 usage is that creation of subsequent CHILD_SAs is a local configuration to the IKEv2 gw. JOuni > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo)=20 > [mailto:hannes.tschofenig@nsn.com]=20 > Sent: 31. tammikuuta 2008 17:18 > To: ext Ahmad Muhanna; Hannes Tschofenig; dime@ietf.org > Subject: AW: [Dime] NEW REQUIREMENT--WGLC for=20 > draft-ietf-mext-aaa-ha-goals-00.txt >=20 >=20 > Hi Ahmad,=20 >=20 > I might have initially misread it a bit. It seems that it is=20 > sufficient for the AAA server to indicate whether a=20 > subsequent CHILD SA exchange should be initiated with the MN.=20 > I have read it in a way that a susequent CHILD SA exchange=20 > would trigger an exchange with the AAA server asking for=20 > authorization. The latter approach would require us to change=20 > the document.=20 >=20 > Ciao > Hannes >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: ext Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Gesendet: Donnerstag, 31. Januar 2008 17:12 > > An: Hannes Tschofenig; dime@ietf.org > > Betreff: RE: [Dime] NEW REQUIREMENT --WGLC for=20 > > draft-ietf-mext-aaa-ha-goals-00.txt > >=20 > > Hi Hannes, > >=20 > > I am not sure why this needs to be done separately. Since=20 > the concept=20 > > of doing both authentication and authorization at the same time is=20 > > acceptable, I do not see any problem in applying the same on this=20 > > requirement. > >=20 > > As a requirement, I believe it is useful and should be addressed. > >=20 > >=20 > > Regards, > > Ahmad > > =20 > >=20 > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: Thursday, January 31, 2008 1:46 AM > > > To: dime@ietf.org > > > Subject: Re: [Dime] NEW REQUIREMENT -- WGLC for=20 > > > draft-ietf-mext-aaa-ha-goals-00.txt > > >=20 > > > Please give me feedback on this issue! > > >=20 > > > Hannes Tschofenig wrote: > > > > Hi all, > > > > > > > > reading carefully through > > draft-ietf-mext-aaa-ha-goals-00.txt and I > > > > noticed a new requirement, namely > > > > > > > > G2.11 The AAAH server MUST be able to indicate to the HA > > > whether the > > > > bearer traffic for the MN needs to receive IPsec ESP > > > protection. > > > > > > > > To me it appears that a solution for such a requirement > > requires a > > > > separate exchange between the HA and the AAAH to perform an=20 > > > > authorization check. > > > > This might require modifications to > > > draft-ietf-dime-mip6-split-06.txt > > > > since authentication and authorization are currently done > > > at the same > > > > time. > > > > > > > > I am correctly understanding the requirement and the=20 > implications? > > > > > > > > Feedback appreciated. > > > > > > > > Ciao > > > > Hannes > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > > >=20 > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 31 21:52:14 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC213A6813; Thu, 31 Jan 2008 21:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSHZSW5PE6GJ; Thu, 31 Jan 2008 21:52:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0574B3A67E4; Thu, 31 Jan 2008 21:52:14 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2126B3A67AE for ; Thu, 31 Jan 2008 21:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqQ4i-ssy1aQ for ; Thu, 31 Jan 2008 21:52:11 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id D6DAA3A67FB for ; Thu, 31 Jan 2008 21:52:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,288,1199644200"; d="scan'208,217";a="96658897" Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by ind-iport-1.cisco.com with ESMTP; 01 Feb 2008 11:23:43 +0530 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m115rg8o019138; Fri, 1 Feb 2008 11:23:42 +0530 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m115rZ1F007768; Fri, 1 Feb 2008 05:53:36 GMT Received: from xmb-blr-418.apac.cisco.com ([64.104.140.147]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Feb 2008 11:23:36 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Feb 2008 11:22:37 +0530 Message-ID: <8EB00AB9BCE95E4DBADDDB25EBCBF95D04F7F652@xmb-blr-418.apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Section 4.5: Relevance of "SHLD NOT" column Thread-Index: AchklqZTHoZtr+4EQAeU07Nt4qs+nQ== From: "Satendra Gera (satgera)" To: X-OriginalArrivalTime: 01 Feb 2008 05:53:36.0533 (UTC) FILETIME=[C94F0450:01C86496] Authentication-Results: ind-dkim-1; header.From=satgera@cisco.com; dkim=pass ( sig from cisco.com/inddkim1002 verified; ); Cc: dime@ietf.org Subject: [Dime] Section 4.5: Relevance of "SHLD NOT" column X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1148314039==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1148314039== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C86496.C8F0201B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C86496.C8F0201B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Victor/All, =20 There have been changes in section 4.5: Diameter Base Protocol AVPs between bis3-bis6 document.=20 Can you please explain =20 a) the rational behind retaining "SHLD NOT" column in the table.=20 b) use case where marking a AVP bit to "SHLD NOT" will help. AFAIR haven't seen an application marking an AVP bit as "SHLD NOT". c) what should be the behavior incase a message is received with an AVP, where a "SHLD NOT" bit is set in the header. =20 Regards, Satendra ------_=_NextPart_001_01C86496.C8F0201B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Victor/All,
 
There = have been=20 changes in section 4.5: Diameter Base Protocol=20 AVPs between bis3-bis6 document.
Can=20 you please explain
 
a)=20 the rational behind retaining "SHLD NOT" column in the table.=20
b) use case where marking a AVP bit to "SHLD NOT" will = help. AFAIR=20 haven't seen an application marking an AVP bit as "SHLD=20 NOT".
c)=20 what should be the behavior incase a message is received with an AVP, = where a=20 "SHLD NOT" bit is set in the header.
 
Regards,
Satendra
------_=_NextPart_001_01C86496.C8F0201B-- --===============1148314039== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime --===============1148314039==-- From dime-bounces@ietf.org Thu Jan 31 22:54:21 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7728F3A6840; Thu, 31 Jan 2008 22:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3yuHyyny-iA; Thu, 31 Jan 2008 22:54:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98FB3A6781; Thu, 31 Jan 2008 22:54:20 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C2BC3A67E1 for ; Thu, 31 Jan 2008 22:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFEJvTCrB16H for ; Thu, 31 Jan 2008 22:54:18 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 3651C3A6806 for ; Thu, 31 Jan 2008 22:54:17 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m116tnEO030194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Feb 2008 07:55:50 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m116tnWW013597 for ; Fri, 1 Feb 2008 07:55:49 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Feb 2008 07:55:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Feb 2008 07:55:48 +0100 Message-ID: <5FB585F183235B42A9E70095055136FB709A52@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3GPP Thread-Index: AchjWsQu1p3qYyEvQLmvyiN2/uPGqwAF8syAACz7+NAAHjZpYA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 01 Feb 2008 06:55:49.0686 (UTC) FILETIME=[7A70F560:01C8649F] Subject: [Dime] 3GPP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I also learned that the latest 3GPP SA2 TS23.402 v8.0.0+ (intermediate draft) for EPS lists the following docs also worked in Dime. [40] IETF Internet-Draft, draft-korhonen-dime-pmip6-02.txt, "Diameter Proxy Mobile IPv6: Support for Mobility Access Gateway and Local Mobility Anchor to Diameter Server Interaction", work in progress. [41] IETF Internet-Draft, draft-ietf-dime-mip6-integrated-07.txt, "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", work in progress. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 31 23:07:52 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D98D3A686C; Thu, 31 Jan 2008 23:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.492 X-Spam-Level: X-Spam-Status: No, score=-1.492 tagged_above=-999 required=5 tests=[AWL=1.107, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdzDXVDtu7pk; Thu, 31 Jan 2008 23:07:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E57A3A6812; Thu, 31 Jan 2008 23:07:51 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 889593A6854 for ; Thu, 31 Jan 2008 23:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAb6VDq8v7oM for ; Thu, 31 Jan 2008 23:07:48 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 367DC3A6812 for ; Thu, 31 Jan 2008 23:07:48 -0800 (PST) Received: (qmail invoked by alias); 01 Feb 2008 07:09:21 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp048) with SMTP; 01 Feb 2008 08:09:21 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/ZjblAtB7Z1d6I3SNiAoQfPtWEu12ornTBwn3Jx1 BFUYZO33kqr99Y Message-ID: <47A2C59F.70008@gmx.net> Date: Fri, 01 Feb 2008 09:09:19 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Giaretta, Gerardo" References: In-Reply-To: X-Y-GMX-Trusted: 0 Cc: dime@ietf.org Subject: Re: [Dime] NEW REQUIREMENT--WGLC for draft-ietf-mext-aaa-ha-goals-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Thanks for explaining the requirement better. Giaretta, Gerardo wrote: > Hi Hannes and Ahmad, > > I agree with Hannes interpretation of the requirement. The requirement do= es not intend to point to any solution (separate message or not). Please le= t me know if there is anything in the requirement that seems to point to an= y solution; in that case it needs to be rephrased. > > >From a solution perspective, I think what is needed is just that the AAA= server sends to the HA an indication if ciphering is authorized for the MN= . This step can be done during authentication and authorization. Then the H= A may create a child SA or may wait for the MN to create it. What is import= ant is that the HA knows that the MN is authorized to use this feature. > > Gerardo > > = >> -----Original Message----- >> From: Tschofenig, Hannes (NSN - FI/Espoo) >> [mailto:hannes.tschofenig@nsn.com] >> Sent: Thursday, January 31, 2008 7:18 AM >> To: ext Ahmad Muhanna; Hannes Tschofenig; dime@ietf.org >> Subject: AW: [Dime] NEW REQUIREMENT--WGLC for draft-ietf-mext-aaa-ha- >> goals-00.txt >> >> Hi Ahmad, >> >> I might have initially misread it a bit. It seems that it is sufficient >> for the AAA server to indicate whether a subsequent CHILD SA exchange >> should be initiated with the MN. I have read it in a way that a susequent >> CHILD SA exchange would trigger an exchange with the AAA server asking f= or >> authorization. The latter approach would require us to change the docume= nt. >> >> Ciao >> Hannes >> >> = >>> -----Urspr=FCngliche Nachricht----- >>> Von: ext Ahmad Muhanna [mailto:amuhanna@nortel.com] >>> Gesendet: Donnerstag, 31. Januar 2008 17:12 >>> An: Hannes Tschofenig; dime@ietf.org >>> Betreff: RE: [Dime] NEW REQUIREMENT --WGLC for >>> draft-ietf-mext-aaa-ha-goals-00.txt >>> >>> Hi Hannes, >>> >>> I am not sure why this needs to be done separately. Since the >>> concept of >>> doing both authentication and authorization at the same time is >>> acceptable, I do not see any problem in applying the same on this >>> requirement. >>> >>> As a requirement, I believe it is useful and should be addressed. >>> >>> >>> Regards, >>> Ahmad >>> >>> >>> = >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Thursday, January 31, 2008 1:46 AM >>>> To: dime@ietf.org >>>> Subject: Re: [Dime] NEW REQUIREMENT -- WGLC for >>>> draft-ietf-mext-aaa-ha-goals-00.txt >>>> >>>> Please give me feedback on this issue! >>>> >>>> Hannes Tschofenig wrote: >>>> = >>>>> Hi all, >>>>> >>>>> reading carefully through >>>>> = >>> draft-ietf-mext-aaa-ha-goals-00.txt and I >>> = >>>>> noticed a new requirement, namely >>>>> >>>>> G2.11 The AAAH server MUST be able to indicate to the HA >>>>> = >>>> whether the >>>> = >>>>> bearer traffic for the MN needs to receive IPsec ESP >>>>> = >>>> protection. >>>> = >>>>> To me it appears that a solution for such a requirement >>>>> = >>> requires a >>> = >>>>> separate exchange between the HA and the AAAH to perform an >>>>> authorization check. >>>>> This might require modifications to >>>>> = >>>> draft-ietf-dime-mip6-split-06.txt >>>> = >>>>> since authentication and authorization are currently done >>>>> = >>>> at the same >>>> = >>>>> time. >>>>> >>>>> I am correctly understanding the requirement and the implications? >>>>> >>>>> Feedback appreciated. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>> = >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>>> = >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> = >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> = _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime