From dime-bounces@ietf.org Sat Sep 01 05:25:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRPEJ-0004da-4X; Sat, 01 Sep 2007 05:25:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IROzu-0007Nn-RR for dime@ietf.org; Sat, 01 Sep 2007 05:10:31 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IROzt-0001Rq-2P for dime@ietf.org; Sat, 01 Sep 2007 05:10:30 -0400 Received: (qmail invoked by alias); 01 Sep 2007 09:10:27 -0000 Received: from p54985150.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.81.80] by mail.gmx.net (mp017) with SMTP; 01 Sep 2007 11:10:27 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX183c6JlftQ3d2V8zrZMMi6YsF7BCFCuSoFf/h8hTm zA/Dt7ixhc+Dws Message-ID: <46D92C7A.8040606@gmx.net> Date: Sat, 01 Sep 2007 11:10:18 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com Subject: Re: review of dime-mip6-split; was RE: [Dime] Meeting Minutes References: <59D7431DE2527D4CB0F1EFEDA5683ED30222C9D5@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30222C9D5@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: 1.8 (+) X-Scan-Signature: 746e7c8096e71e3815c27253c4c3edc6 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, jouni.korhonen@teliasonera.com wrote: > Hi Hannes, > > See my replies inline. > > >> Sent: 30. elokuuta 2007 12:50 >> >> Hi Jouni, >> >> thanks again for your extremely detailed review. >> >> A few more comments below: >> >> >>> Section 6.1.1 >>> >>> o For what purpose the MIP6-Feature-Vector is in DER & DEA >>> >> messages? >> >>> Its use is not explained anywhere? >>> >>> >>> >> Currently, the MIP6-Feature-Vector contains the following values: >> >> (a) MOBILITY_CAPABILITY >> (b) MIP6_INTEGRATED >> (c) LOCAL_HOME_AGENT_ASSIGNMENT >> >> Item (a) is not really required because the AAA server is >> able to learn about the Diameter client's mobility capability >> from the MIP6 App-ID. >> Item (b) is not applicable since this is not the integrated scenario. >> This leaves us with item (c). If the AAA client is not in the >> same domain as the AAA server then this could be useful. Right? >> > > Fine. This question was motivated because MIP6-Feature-Vector is > a new AVP to HA-AAA interface but the document does not really > describe anything about it. IHMO there must be some text to describe > its desired use in that interface. > > Do you agree with me that item (c) at least would be useful to communicate? A different subject is how the Diameter Mobile IPv4 MIP-Feature-Vector plays into this picture when the MIPv6 Authentication protocol is used since we said that we would want to maximize the usage of Diameter Mobile IPv4. >>> o The use of the MIP-Mobile-Node-Address in both DER & DEA messages >>> are not explained anywhere. I would expect that at least >>> >> why it is >> >>> needed in DEA would be explained. >>> >>> >> The MIP-Mobile-Node-Address allows the AAA server to provide >> the MN's HoA to be conveyed to the AAA client. >> Does this make sense to you? >> > > Yes. You should add that also to the document ;) > > OK. >>> Section 6.2 >>> >>> o this section and its subsections need a major rework.. >>> >>> o The current text only talks about using MN-AAA auth option. >>> Is there a particular reason to neglect MN-HA auth option >>> for BUs? >>> >>> >> Ideally, dime-mip6-split should be as close to RFC 4004 with >> regard to the usage of the communication between the HA and >> the AAA server. >> Hence, we should definitely make utilize MIP-MN-AAA-Auth (as >> defined in Section 7.6 of RFC 4004) as it is used in the >> AA-Mobile-Node-Request >> (AMR) message of RFC 4004. >> >> When you look at Section 6.2.1 of dime-mip6-split then you >> will find the MIP-MN-AAA-Auth AVP. >> > > The way RFC4285 calculates MN-HA and MN-AAA are different. > MN-HA is more or less local with fixed algorithms, except > that you might receive the shared-key from the AAA. On the > other hand you can let AAA do all MN-AAA calculations.. or > divide it between HA and AAA. It should be clarified what AVPs > to use and what to put into those when processing MN-HA or > MN-AAA received from the MN. > > Even if we are reusing RFC4004 AVPs we cannot assume that > it is directly clear what to do. > > This is a larger issue and I plan to address it in a separate mail. >> Hence, I believe things are in place. >> >> >>> o There should be an AVP to distinguish between MN-AAA and >>> MN-HA operations towards AAA. >>> >>> >> In what sense? What AVPs from RFC 4004 would be needed? >> > > I don't think there's one. > > Hmmm. I am not sure I understood the problem why once would need to differentiate the two. >>> o For what purpose MIP6-Feature-Vector is needed? >>> >>> >> Do you mean that we should instead use the MIP-Feature-Vector >> AVP from RFC 4004? >> > > No, I just want a line of text saying for what and how the AAA > expects to use the MIP6-Feature-Vector. We have defined few > values for integrated scenario and explained their use in that > domain. Would be nice to have the same for split scenario aswell. > It is true that it might be useful to say what values should be used and what their semantic is. In some sense that raises the question why we would like to re-use the same AVP in the first place since * some values of the MIP6-Feature-Vector as defined in the NAS<->AAA document just don't make sense in the HA<->AAA document. * other values cannot just be used without explaining the semantic. > >>> o MIP-MN-AAA-Auth AVP cannot really be used.. as it just points >>> byte ranges within the BU. We do not seem to pass the BU from >>> HA to AAA in the MRM message. >>> >>> >> This is what RFC 4004 says: >> >> 7.6. MIP-MN-AAA-Auth AVP >> >> The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains >> some ancillary data to simplify processing of the >> authentication data >> in the Mobile IPv4 Registration Request [MOBILEIP, MIPCHAL] by the >> target AAA server. Its value has the following ABNF grammar: >> >> MIP-MN-AAA-Auth ::= < AVP Header: 322 > >> { MIP-MN-AAA-SPI } >> { MIP-Auth-Input-Data-Length } >> { MIP-Authenticator-Length } >> { MIP-Authenticator-Offset } >> * [ AVP ] >> >> >> I agree with you that we cannot right away use it. >> >> I will investigate what other SDOs did, such as 3GPP2 or >> Wimax, with respect to this issue. I will come back to you on >> this one. >> > > RFC4004 passes the whole BU message in the AMR to AAA. 3GPP2 > passes only those parts of the message that are needed to > for MN-AAA authentication. 3GPP has no clue ;) And WiMAX does > its own thing. All those are deployment dependant. It might > be really hard to come up with a proper HA-AAA interface for > RFC4285 that is actually usable. > That's indeed a difficult issue. I personally do not like the way how things were design in RFC 4004 with respect to this issue. Still, RFC 4004 puts the entire Registration Request into the keyed hash calculation. I wanted to re-use RFC 4004 as much as possible I do, however, see the problems. > >>> o for MN-AAA computation the MRM is missing an AVP to carry a CoA >>> to AAA >>> >>> >> Is this missing in RFC 4004 as well or is this specific to MIPv6 >> bootstrapping? >> > > RFC4004 passes the whole BU to AAA.. so it finds the CoA etc by > parsing the data. I think this is not the right way ;) > So far we tried to be as close to RFC 4004 as possible in the believe that people would just be able to re-use most parts of their implementation (at least the part that provides the HA<->AAA interface). Now, in this particular space this is obviously not possible given that the MIPv4 Registration Request just looks different than the MIPv6 Binding Update. Now, we have can decide whether we want to follow the same design approach (in this case by passing the entire BU to the AAA server) or whether we want todo something different. In fact, there are already two different approaches (in my understanding of RFC 4721) already: Section 8 of RFC4721 says that the home agent can hash all the Mobile IP data before sending it to the HA. As an argument the size restrictions for RADIUS are provided. > If AAA does MN-AAA authentication it needs CoA and HoA to > verify the authentication data provided by the HA and MN. > > When we consider NAT traversal then I wonder whether the CoA is actually of big value. There will also be NAT traversal with IPv4/IPv6 scenarios where the MIPv6 dual stack is used. >>> o MIP-MN-to-HA-SPI & MIP-HA-to-MN-SPI are only usable for >>> MN-HA auth option that this I-D does not support at the moment >>> for Bus (btw.. I am not sure whether RFC4285 actually can have >>> different SPIs to different directions) >>> >>> >> Could you please clarify your comment regarding MIP-MN-to-HA-SPI & >> MIP-HA-to-MN-SPI? I am not sure I understood the problem. >> > > Well.. for MN-AAA authentication you would use MIP-MN-AAA-SPI (that is > part of MIP-MN-AAA-Auth grouped AVP. So if you authentication MN using > MN-AAA you don't use MIP-MN-to-HA-SPI etc, right? > I re-read all the MIPv4 RFCs yesterday and it was somewhat hard to figure out what the expect behavior was but my interpretation is that the security association between the MN and the HA is, apart from theoretical investigations, not keyed based on the SPI but the NAI is used instead. Translating this to MIPv6 the text from Section 3.1 and Section 8 of RFC 4721 is relevant. It says that a "special" SPI is used (CHAP_SPI) and a specific key derivation function is given. It seems also that the NAI is used in that particular case to select the keying material. > And the current text in the draft does not difference between > MN-HA and MN-AAA authentications. They would need slightly > different set or way of using AVPs. These should be clarified. > > >> Regarding the SPIs: I believe we should re-use RFC 4004 as much as >> possible to avoid additional implementation complexity on the >> AAA server >> side. >> In RFC 4004 two different SPIs are used. >> > > Yes.. my question in parenthesis was something more general related > to RFC4285. > > Good question. >>> o We need a generic SPI AVP.. also for MN-AAA authentication >>> >>> >> Why? >> > > Sorry, missed the MIP-MN-AAA-SPI in the MIP-MN-AAA-Auth grouped > AVP. That can be used for MN-AAA. > > >>> o for MN-HA authentication we probably need an AVP to return >>> the shared key from AAA to HA (well.. the used MIP-HA-to-MN-MSA >>> AVP could do but its use should be specified as it is a >>> grouped AVP and not all sub-AVPs are needed) >>> >>> >> I indeed thought that we could use the MIP-HA-to-MN-MSA AVP as is >> (without modifications). >> > > Within the MIP-HA-to-MN-MSA AVP we don't seem to need MIP-Algorithm-Type > as RFC4285 has a fixed one. Hmm.. maybe we could state that for the > MN-HA authentication the algorithm is always set to HMAC-SHA-1 (2) > within RFC4285 scope. > The problem with this approach is that we are now supposed to provide crypto agility for all protocols. This allows that the algorithms can be changed as part of the protocol. I wonder whether the authors of RFC 4285bis will get away with it. > >>> o MN-AAA authentication probably needs an AVP to carry the >>> timestamp from HA to AAA >>> >>> >> Why? RFC 4004 only defines one timestamp for accounting (see >> Event-Timestamp AVP). >> > > Some deployments might want to use timestamp as one parameter that > is used by the AAA to derive session keys. > > Correct. Since there is no timestamp field in Diameter Mobile IPv4 there are two possible cases: * the authors forgot to put it in there. * somehow the functionality is provided in a different way and hence an explicit timestamp AVP is not needed. I could guess that the fact that the Registration Request is essentially "piggybacked" to the AAA server the timestamp is therefore included as well. Do you agree with me? >>> o MN-AAA authentication probably needs an AVP to carry the >>> authentication data from HA to AAA >>> >>> >> Which authentication data? >> > > >From the Message Auth option.. if AAA does the MN-AAA authentication > it probably wants to have the authentication data. > Correct. > >>> o We probably need an AVP to carry the mobility data or a >>> MAC of the mobility data from HA to AAA >>> >>> >> I guess this refers to the previously mentioned >> MIP-MN-AAA-Auth AVP. Right? >> > > Not really. MIP-MN-AAA-Auth AVP does not provide way to > transfer e.g. calculated MAC mobility data calculated > HA to AAA, if HA wished to do that calculation. > > Correct. This functionality cannot be found in RFC 4004 since it was specified in RFC 4721. >>> o Use of MIP-Session-Key? I assume it is used to MN-HA calculation >>> in a BA as the shared secret. >>> >>> >> The MIP-Session-Key AVP is contained in a couple of grouped >> AVPs. It's >> semantic depends on the grouped AVP it is carried in. >> > > Probably those semantics should be explained. > > >>> o Giving explanations of AVP usage and even RFC4285 compliant >>> examples of auth option processing would be most beneficial. >>> The RFC4285 has always been somewhat foggy ;) >>> >>> >> RFC 4285 is, in my opinion, a replica of the corresponding MIPv4 >> authentication procedure (regarding the communication from >> the HA to the >> AAA server). >> > > It is close but not replica. > > I think we should post a mail to the MIPv6 list and ask the authors whether they believe that there is a difference and if so, what the differences are. >>> o A reference to draft-ietf-mip6-whyauthdataoption would be usefull >>> >>> >>> >> I don't think we need that since this is mostly a job of RFC >> 4285/RFC4285bis. >> > > Ok. > > > Ciao Hannes > Cheers, > Jouni > > > >>> I think it would be beneficial to check what e.g. 3GPP2 did >>> for their MIP6 HA-AAA interface. After all, they use RFC4285. >>> >>> >>> >> I will do that. >> >> Ciao >> Hannes >> >> >>> Cheers, >>> Jouni >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Thursday, August 16, 2007 12:59 AM >>>> To: dime@ietf.org >>>> Subject: [Dime] Meeting Minutes >>>> >>>> >>>> Please check the meeting minutes: >>>> http://www3.ietf.org/proceedings/07jul/minutes/dime.txt >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Sat Sep 01 05:40:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRPT7-0000x5-5z; Sat, 01 Sep 2007 05:40:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRPT6-0000wb-AE for dime@ietf.org; Sat, 01 Sep 2007 05:40:40 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IRPT5-0002BS-Im for dime@ietf.org; Sat, 01 Sep 2007 05:40:40 -0400 Received: (qmail invoked by alias); 01 Sep 2007 09:40:38 -0000 Received: from p54985150.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.81.80] by mail.gmx.net (mp050) with SMTP; 01 Sep 2007 11:40:38 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+1mGND7ci1cE+n0l2pV/B0O6VPhE/wWal5onR9Sc nQcgEVZnNj7yfY Message-ID: <46D9338E.6010806@gmx.net> Date: Sat, 01 Sep 2007 11:40:30 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mobile IPv6 Mailing List , 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: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Dime] Certificate Support for the MIPv6 Bootstrapping Split Scenario 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 in our attempt to complete the work on the Diameter Mobile IPv6 bootstrapping documents we encountered the following issue: http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-07.txt talks about the possibility to perform a certificate based user authentication by the home agent. That's fine. There is, however, the question what that implies for Diameter backend infrastructure usage. Did the group assume that just the authentication part will be done locally but authorization and accounting still with the AAA server? Or, was everything supposed to be done locally at the home agent without any Diameter interaction to the Diameter server? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Sep 01 05:40:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRPTB-00013F-Dz; Sat, 01 Sep 2007 05:40:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRPTA-00012e-6Y for dime@ietf.org; Sat, 01 Sep 2007 05:40:44 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IRPT9-0002Bc-Jw for dime@ietf.org; Sat, 01 Sep 2007 05:40:44 -0400 Received: (qmail invoked by alias); 01 Sep 2007 09:40:42 -0000 Received: from p54985150.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.81.80] by mail.gmx.net (mp019) with SMTP; 01 Sep 2007 11:40:42 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+swg01wbuscrugYoYsrgSc9r9p6EcgNMsZLM7fvW STDDKTVGGOJrzh Message-ID: <46D93393.5080607@gmx.net> Date: Sat, 01 Sep 2007 11:40:35 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) 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: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Dime] [Fwd: Difference between RFC4285/RFC4285bis and MIPv4 Authentication] 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, I wrote this mail to the MIPv6 list based on the recent discussion with Jouni on that subject. Ciao Hannes -------- Original Message -------- Subject: Difference between RFC4285/RFC4285bis and MIPv4 Authentication Date: Sat, 01 Sep 2007 11:30:36 +0200 From: Hannes Tschofenig To: Mobile IPv6 Mailing List CC: alpesh@cisco.com, kleung@cisco.com, mkhalil@nortel.com, haseebak@nortel.com, "Chowdhury, Kuntal" Hi Alpesh, Kent, Mohamed, Haseeb, Kuntal, Hi all, RFC 4285 specifies the MIPv6 Authentication protocol. It is currently being revised with http://www.ietf.org/internet-drafts/draft-ietf-mip6-rfc4285bis-00.txt In DIME we are working on the backend infrastructure support for the bootstrapping. Now, a question came up what the difference between RFC4285/RFC4285bis and the corresponding MIPv4 authentication procedure is. RFC4285/RFC4285bis only says: " The authentication mechanism proposed here is similar to the authentication mechanism used in Mobile IPv4 [RFC3344]. " Btw, I believe that a reference to RFC 3344 alone is insufficient given that RFC 3344 was updated by RFC 4721. Furthermore, RFC 3344 is currently being revised as well. I assume that it is a desire of RFC4285/RFC4285bis work to re-use the existing AAA server implementation as much as possible. Is this assumption correct? In DIME we would like to understand what the differences are. Could someone explain them to us? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Sep 01 10:43:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRUBj-0001Yd-Fo; Sat, 01 Sep 2007 10:43:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRUBi-0001Xl-4i for dime@ietf.org; Sat, 01 Sep 2007 10:43:02 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRUBg-0000zd-Qe for dime@ietf.org; Sat, 01 Sep 2007 10:43:02 -0400 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l81EgYxL026159; Sat, 1 Sep 2007 10:42:35 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46D97A5A.2050102@tari.toshiba.com> Date: Sat, 01 Sep 2007 10:42:34 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "Arun Santhanam, TLS-Chennai" References: <66E8AEE9980BB44CA5FCAD39EBA56AC60236FBCB@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC60236FBCB@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by toshi17.tari.toshiba.com id l81EgYxL026159 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: dime@ietf.org Subject: [Dime] Re: Reg. Diameter Path Authorization 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 Sorry for the late response. Comments line: > =85 > Similarly, the local Diameter agent, on receiving a Diameter respons= e > authorizing a session, MUST check the Route-Record AVPs to make sure > that the route traversed by the response is acceptable. At each > step, forwarding of an authorization response is considered evidence > of a willingness to take on financial risk relative to the session. > A local realm may wish to limit this exposure, for example, by > =20 > =20 > The RFC says Route-Record AVP can be =930=94 for all response message e= xcept ACA in section=20 > =9310.1. Base Protocol Command AVP Table=94=20 I think your right. There's something not clear with the diameter path=20 authorization. As I understand it, that section is trying to co-relate=20 accounting request with authorization responses. And somehow, its=20 implying the use of route record to do the co-relation without=20 specifying any semantics. My preference would be to remove the 1st=20 sentence of this paragraph and update the talbe in 10.1 so that ACA will=20 have "0" in the route record. I don't think this will break any=20 implementation since even the ABNF of ACA does not enumerate=20 route-record. A diameter node wishing to co-relation of authorization=20 responses with forwarding can still do so based on session ids and other=20 diameter application layer information. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Sep 01 10:56:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRUOS-00076d-1d; Sat, 01 Sep 2007 10:56:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRUOR-00075W-E0 for dime@ietf.org; Sat, 01 Sep 2007 10:56:11 -0400 Received: from gws04.mail.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRUOQ-0002he-Fz for dime@ietf.org; Sat, 01 Sep 2007 10:56:11 -0400 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 8B66E36000D; Sat, 1 Sep 2007 20:26:07 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws04.hcl.in (Postfix) with ESMTPid 7239E36000A; Sat, 1 Sep 2007 20:26:07 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Sep 2007 20:26:07 +0530 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: Sat, 1 Sep 2007 20:26:39 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC6023A2EC8@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reg. Diameter Path Authorization Thread-Index: AcfsplotZheVam7OTvGiK0QRJuQsxgAAdUUg References: <66E8AEE9980BB44CA5FCAD39EBA56AC60236FBCB@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <46D97A5A.2050102@tari.toshiba.com> From: "Arun Santhanam, TLS-Chennai" To: "Victor Fajardo" X-OriginalArrivalTime: 01 Sep 2007 14:56:07.0130 (UTC) FILETIME=[39C633A0:01C7ECA8] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-9.8593 TC:1F TRN:42 TV:3.6.1039(15396.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: dime@ietf.org Subject: [Dime] RE: Reg. Diameter Path Authorization 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, Thanks for the response=2E Regards -Arun -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari=2Etoshiba=2Ecom]=20 Sent: Saturday, September 01, 2007 8:13 PM To: Arun Santhanam, TLS-Chennai Cc: dime@ietf=2Eorg Subject: Re: Reg=2E Diameter Path Authorization Sorry for the late response=2E Comments line: > =2E=2E=2E > Similarly, the local Diameter agent, on receiving a Diameter response > authorizing a session, MUST check the Route-Record AVPs to make sure > that the route traversed by the response is acceptable=2E At each > step, forwarding of an authorization response is considered evidence > of a willingness to take on financial risk relative to the session=2E > A local realm may wish to limit this exposure, for example, by > =20 > =20 > The RFC says Route-Record AVP can be "0" for all response message except ACA in section=20 > "10=2E1=2E Base Protocol Command AVP Table"=20 I think your right=2E There's something not clear with the diameter path=20 authorization=2E As I understand it, that section is trying to co-relate=20 accounting request with authorization responses=2E And somehow, its=20 implying the use of route record to do the co-relation without=20 specifying any semantics=2E My preference would be to remove the 1st=20 sentence of this paragraph and update the talbe in 10=2E1 so that ACA will have "0" in the route record=2E I don't think this will break any=20 implementation since even the ABNF of ACA does not enumerate=20 route-record=2E A diameter node wishing to co-relation of authorization=20 responses with forwarding can still do so based on session ids and other diameter application layer information=2E regards, victor DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have=20 received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and=20 attachments please check them for viruses and defect=2E ---------------------------------------------------------------------------= -------------------------------------------- _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Sep 02 11:30:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRrOy-0007Ms-LO; Sun, 02 Sep 2007 11:30:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRrOy-0007Mn-Bo for dime@ietf.org; Sun, 02 Sep 2007 11:30:16 -0400 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRrOx-0001st-17 for dime@ietf.org; Sun, 02 Sep 2007 11:30:16 -0400 Received: by rv-out-0910.google.com with SMTP id l15so710250rvb for ; Sun, 02 Sep 2007 08:30:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:cc:references:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:in-reply-to:thread-index:x-mimeole; b=egfDCBxHoqGgcri71OuwvG+OcgwDsMMAyX96pp+TNqR4Z/Y0vKSRg/omF5nxzT2Slbk0ymN3X2dO4BzMZvt+iNCRQFR1ZhPnZUfTxVp2VFFrQkqG4LaYyS+wTyvTpa7QIwBx5/QOQO4sOIizDY1ESZzYXqOtjvKoOUFo/KrXw2w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:cc:references:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:in-reply-to:thread-index:x-mimeole; b=qNewcFt6nO9X65UAyR0jQHiTdkomY9K5d5Ay4/s+kO1Jqy4Yil7AmeNF3sNEJ7XOIWB17s1tbSXTch08FUoR+cRw3iI/uYH90nrJg2xINIOA9Qkr7mYh7BvFXRdas6qGTyIj+mul0pbw3u12SYG/CxGTxLjb+Jh/EjaO4/rY1I4= Received: by 10.141.87.13 with SMTP id p13mr1601873rvl.1188747014305; Sun, 02 Sep 2007 08:30:14 -0700 (PDT) Received: from Harsha ( [218.18.20.227]) by mx.google.com with ESMTPS id f34sm3686510rvb.2007.09.02.08.30.09 (version=SSLv3 cipher=RC4-MD5); Sun, 02 Sep 2007 08:30:12 -0700 (PDT) From: "Harsha" To: "'Victor Fajardo'" References: <46D3E478.3070909@gmx.net> <46D415D2.7050600@tari.toshiba.com> Subject: RE: [Dime] [Fwd: Hello,I found two errors in RFC 3588(2003)] Date: Sun, 2 Sep 2007 21:00:03 +0530 Message-ID: <001601c7ed76$255dda20$5aadfea9@Harsha> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <46D415D2.7050600@tari.toshiba.com> Thread-Index: Acfpb5CZMJLwugR7T66hzenxT95IZgEBYT5Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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, Also there is one missed event in the state machine. In WAIT_RETURNS state, the state machine there is no Action on I_RCV_NON_CEA event. In such conditions we should close the I-connection, and continue as responder by sending the CEA. Am I right? Regards, Harsha -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] Sent: Tuesday, August 28, 2007 6:02 PM To: Hannes Tschofenig Cc: dime@ietf.org; ding.xiaobo@zte.com.cn Subject: Re: [Dime] [Fwd: Hello,I found two errors in RFC 3588(2003)] Thanks. We'll fix that in the next rev. We can plan to publish 07 sometime mid sept along with a summary/history. regards, victor > Here is a message that bounced back -- > > Ding, you need to subscribe to the mailing list. > > Ciao > Hannes > > -------- Original Message -------- > Subject: Hello,I found two errors in RFC 3588(2003) > Date: Tue, 28 Aug 2007 16:21:34 +0800 > From: ding.xiaobo@zte.com.cn > To: dime@ietf.org > > > > Hello,DIME > > I found two errors in the RFC3588 Copyright (C) The Internet Society > (2003), > The first one is in page 52 : there are something wrong about AVP length: > Of session-Id AVP Header, AVP length should be 42 instead of 50; > Of session-Id AVP Header, AVP length should be 39 instead of 51; > Of recovery-Policy Header, AVP length should be 215 instead of > 223. > The second one is an inconsistency between ACA in page 121 and ACA in page > 126: > In page 121, there is no any AVP named Route-Record of the command > ACA, > but in page 126, there is 0+ AVPs named Route-Record of the > command ACA. > > That's all. Thank you！ > > Sincerely yours, > Xiaobo Ding > > > ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝===== > ZTE corporation in Nanjing, China > > Phone:+086 025 52878487 > EMail:ding.xiaobo@zte.com.cn > MSN：mirroryuri@hotmail.com > ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝====== > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > > > > _______________________________________________ > 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 Mon Sep 03 05:40:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS8Pt-0003I6-3F; Mon, 03 Sep 2007 05:40:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS8Pr-0003Ht-0K; Mon, 03 Sep 2007 05:40:19 -0400 Received: from gws04.mail.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IS8Pp-0004VK-Ta; Mon, 03 Sep 2007 05:40:18 -0400 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 7D511360039; Mon, 3 Sep 2007 15:10:14 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws04.hcl.in (Postfix) with ESMTPid 50D6A360013; Mon, 3 Sep 2007 15:10:14 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Sep 2007 15:10:12 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Sep 2007 15:10:06 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC6023A37B0@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: regrading reserved bits in Diameter header Thread-Index: AcfuDmlxdG+dpcD4QpyptB+pLmJMHA== From: "Pallavi Pethia, TLS-Chennai" To: Cc: X-OriginalArrivalTime: 03 Sep 2007 09:40:13.0223 (UTC) FILETIME=[6D310370:01C7EE0E] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-10.8596 TC:1F TRN:70 TV:3.6.1039(15396.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd Subject: [Dime] regrading reserved bits in Diameter header 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="===============0685301260==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0685301260== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EE0E.69F2B993" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7EE0E.69F2B993 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I have question in RFC 3588 'section 3=2E Diameter Header ' =2E It says, =20 r(eserved) - these flag bits are reserved for future use, and MUST be set to zero, and ignored by the receiver=2E =20 =20 Suppose the reserved are set with value 1=2E There are two ways in which receiver can respond with an answer: 1) It can ignore the reserved bits in request and respond with successful (2001 Result code)=2E 2) It can send DIAMETER_INVALID_BIT_IN_HEADER i=2Ee=2E (5013 Result code)=2E =20 =20 =20 The description of 2) is in RFC 3588 section=20 =20 7=2E1=2E5=2E Permanent Failures section of RFC 3588 is below : =20 DIAMETER_INVALID_BIT_IN_HEADER 5013 This error is returned when an unrecognized bit in the Diameter header is set to one (1)=2E =20 Please let me know in which way( 1 or 2) the receiver of request with reserved bits set should react=2E =20 Thanks, Pallavi DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have=20 received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and=20 attachments please check them for viruses and defect=2E ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C7EE0E.69F2B993 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

         I have question in RFC 3588 ‘section 3= =2E  Diameter Header ’ =2E

It says,

 

r(eserved)  - these flag bits are reserved for= future use, and

         &n= bsp;          MUST be set to zero, and ignored by the receiver= =2E

 

 

Suppose the reserved are set with value 1= =2E

There are two ways in which receiver can respond with an answer:

1)      = It can ignore the reserved bits in request and respond with successful (2001= Result code)=2E

2)      = It can send DIAMETER_INVALID_BIT_IN_HEADER i=2Ee=2E (5013 Result code)=2E

 

 

 

The description of  2) is in RFC 3588 section=

 

7=2E1=2E5=2E  Permanent Failures= section of  RFC 3588 is below :

 

DIAMETER_INVALID_BIT_IN_HEADER   &= nbsp; 5013

      This error is returned when an unrecognized bit in the= Diameter

      header is set to one (1)=2E

 

Please let me know in which way( 1 or 2) the receiver of request with reserved bits set should react=2E

 

Thanks,

Pallavi

DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E
It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have
received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and
attachments please check them for viruses and defect=2E

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C7EE0E.69F2B993-- --===============0685301260== 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 --===============0685301260==-- From dime-bounces@ietf.org Mon Sep 03 05:42:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS8S7-0005Ug-8P; Mon, 03 Sep 2007 05:42:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS8S5-0005UR-Pw for dime@ietf.org; Mon, 03 Sep 2007 05:42:37 -0400 Received: from gws04.mail.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IS8S4-0004ZT-Ls for dime@ietf.org; Mon, 03 Sep 2007 05:42:37 -0400 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 6EAE936007A for ; Mon, 3 Sep 2007 15:12:35 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws04.hcl.in (Postfix) with ESMTP id 3D52336004Dfor ; Mon, 3 Sep 2007 15:12:35 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Sep 2007 15:12:34 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Sep 2007 15:11:50 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC6023A37C4@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: regrading reserved bits in Diameter header Thread-Index: AcfuDmlxdG+dpcD4QpyptB+pLmJMHAAADLYQ From: "Pallavi Pethia, TLS-Chennai" To: X-OriginalArrivalTime: 03 Sep 2007 09:42:34.0424 (UTC) FILETIME=[C15A9380:01C7EE0E] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-12.1346 TC:01 TRN:71 TV:3.6.1039(15396.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 07e9b4af03a165a413ec6e4d37ae537b Subject: [Dime] regrading reserved bits in Diameter header 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="===============2138292184==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2138292184== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EE0E.A7954437" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7EE0E.A7954437 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I have question in RFC 3588 'section 3=2E Diameter Header ' =2E It says, =20 r(eserved) - these flag bits are reserved for future use, and MUST be set to zero, and ignored by the receiver=2E =20 =20 Suppose the reserved are set with value 1=2E There are two ways in which receiver can respond with an answer: 1) It can ignore the reserved bits in request and respond with successful (2001 Result code)=2E 2) It can send DIAMETER_INVALID_BIT_IN_HEADER i=2Ee=2E (5013 Result code)=2E =20 =20 =20 The description of 2) is in RFC 3588 section=20 =20 7=2E1=2E5=2E Permanent Failures section of RFC 3588 is below : =20 DIAMETER_INVALID_BIT_IN_HEADER 5013 This error is returned when an unrecognized bit in the Diameter header is set to one (1)=2E =20 Please let me know in which way( 1 or 2) the receiver of request with reserved bits set should react=2E =20 Thanks, Pallavi DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have=20 received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and=20 attachments please check them for viruses and defect=2E ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C7EE0E.A7954437 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

         I have question in RFC 3588 ‘section 3= =2E  Diameter Header ’ =2E

It says,

 

r(eserved)  - these flag bits are reserved for= future use, and

         &n= bsp;          MUST be set to zero, and ignored by the receiver= =2E

 

 

Suppose the reserved are set with value 1= =2E

There are two ways in which receiver can respond with an answer:

1)      = It can ignore the reserved bits in request and respond with successful (2001= Result code)=2E

2)      = It can send DIAMETER_INVALID_BIT_IN_HEADER i=2Ee=2E (5013 Result code)= =2E

 

 

 

The description of  2) is in RFC 3588 section=

 

7=2E1=2E5=2E  Permanent Failures= section of  RFC 3588 is below :

 

DIAMETER_INVALID_BIT_IN_HEADER   &= nbsp; 5013

      This error is returned when an unrecognized bit in the= Diameter

      header is set to one (1)=2E

 

Please let me know in which way( 1 or 2) the receiver of request with reserved bits set should react=2E

 

Thanks,

Pallavi

DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E
It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have
received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and
attachments please check them for viruses and defect=2E

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C7EE0E.A7954437-- --===============2138292184== 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 --===============2138292184==-- From dime-bounces@ietf.org Mon Sep 03 09:34:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISC4u-0008Pd-7e; Mon, 03 Sep 2007 09:34:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISC4s-0008PO-Tb; Mon, 03 Sep 2007 09:34:54 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISC4r-0004KQ-Ei; Mon, 03 Sep 2007 09:34:54 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l83DYnJZ025845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Sep 2007 06:34:50 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l83DYnKn002435; Mon, 3 Sep 2007 06:34:49 -0700 (PDT) Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Sep 2007 06:34:49 -0700 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] Certificate Support for the MIPv6 Bootstrapping SplitScenario Date: Mon, 3 Sep 2007 06:34:47 -0700 Message-ID: In-Reply-To: <46D9338E.6010806@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Certificate Support for the MIPv6 Bootstrapping SplitScenario Thread-Index: Acfsib0T+Hw0Rm/uRzOShFiD6aHPCABpN+3A From: "Giaretta, Gerardo" To: "Hannes Tschofenig" , "Mobile IPv6 Mailing List" , X-OriginalArrivalTime: 03 Sep 2007 13:34:49.0015 (UTC) FILETIME=[33046C70:01C7EE2F] X-Spam-Score: -4.0 (----) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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, The bootstrapping draft is not clear on this, because the AAA interactions requirements are discussed in draft-ietf-mip6-aaa-ha-goals. Unfortunately this draft is now expired but I'm working on a new version. Based on the last version there is the following goal: G2.2 The HA MUST be able to query the AAAH server to verify Mobile IPv6 service authorization for the mobile node. This goal is independent of the authentication method used. Therefore I think that the Diameter backend infrastructure should be designed in a flexible way to support the following scenarios:=20 - both authentication and authorization are performed via the AAA backend - authentication is done locally while authorization is performed by the AAA server - both authentication and authorization are performed locally Ciao Gerardo > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Saturday, September 01, 2007 11:41 AM > To: Mobile IPv6 Mailing List; dime@ietf.org > Subject: [Dime] Certificate Support for the MIPv6 Bootstrapping > SplitScenario >=20 > Hi all >=20 > in our attempt to complete the work on the Diameter Mobile IPv6 > bootstrapping documents we encountered the following issue: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- > 07.txt > talks about the possibility to perform a certificate based user > authentication by the home agent. That's fine. >=20 > There is, however, the question what that implies for Diameter backend > infrastructure usage. Did the group assume that just the authentication > part will be done locally but authorization and accounting still with > the AAA server? Or, was everything supposed to be done locally at the > home agent without any Diameter interaction to the Diameter server? >=20 > Ciao > Hannes >=20 >=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 Mon Sep 03 09:56:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISCPl-0000Ij-6W; Mon, 03 Sep 2007 09:56:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISCPj-0000GQ-I7; Mon, 03 Sep 2007 09:56:27 -0400 Received: from david.siemens.de ([192.35.17.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISCPi-0002tN-T9; Mon, 03 Sep 2007 09:56:27 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l83DuPCf001391; Mon, 3 Sep 2007 15:56:25 +0200 Received: from demuprx016.emea.nsn-intra.net (demuprx016.emea.nsn-intra.net [10.150.129.55]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id l83DuOri017144; Mon, 3 Sep 2007 15:56:24 +0200 Received: from demuexc023.nsn-intra.net ([10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id l83DuOCR013651; Mon, 3 Sep 2007 15:56:24 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Sep 2007 15:56:24 +0200 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: AW: [Dime] Certificate Support for the MIPv6 BootstrappingSplitScenario Date: Mon, 3 Sep 2007 15:56:24 +0200 Message-ID: <5FB585F183235B42A9E70095055136FB0555BA@DEMUEXC012.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Certificate Support for the MIPv6 BootstrappingSplitScenario Thread-Index: Acfsib0T+Hw0Rm/uRzOShFiD6aHPCABpN+3AAADIRoA= References: <46D9338E.6010806@gmx.net> From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" To: "ext Giaretta, Gerardo" , "Hannes Tschofenig" , "Mobile IPv6 Mailing List" , X-OriginalArrivalTime: 03 Sep 2007 13:56:24.0559 (UTC) FILETIME=[3738BFF0:01C7EE32] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Thanks for the quick response.=20 One final remark: When authentication is done at the HA via certificates you essentially need to assume that the AAA server is in the same administrative domain as the HA since otherwise you would introduce a security problem. I guess you are aware of this limitation compared to the variant where the authentication is provided to the AAA server itself.=20 Ciao Hannes > Hi Hannes, >=20 > The bootstrapping draft is not clear on this, because the AAA > interactions requirements are discussed in=20 > draft-ietf-mip6-aaa-ha-goals. >=20 > Unfortunately this draft is now expired but I'm working on a new > version. > Based on the last version there is the following goal: >=20 > G2.2 The HA MUST be able to query the AAAH server to verify Mobile > IPv6 service authorization for the mobile node. >=20 > This goal is independent of the authentication method used.=20 > Therefore I > think that the Diameter backend infrastructure should be designed in a > flexible way to support the following scenarios:=20 >=20 > - both authentication and authorization are performed via the AAA > backend > - authentication is done locally while authorization is=20 > performed by the > AAA server > - both authentication and authorization are performed locally >=20 > Ciao > Gerardo >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Saturday, September 01, 2007 11:41 AM > > To: Mobile IPv6 Mailing List; dime@ietf.org > > Subject: [Dime] Certificate Support for the MIPv6 Bootstrapping > > SplitScenario > >=20 > > Hi all > >=20 > > in our attempt to complete the work on the Diameter Mobile IPv6 > > bootstrapping documents we encountered the following issue: > >=20 > > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp > ing-split- > > 07.txt > > talks about the possibility to perform a certificate based user > > authentication by the home agent. That's fine. > >=20 > > There is, however, the question what that implies for=20 > Diameter backend > > infrastructure usage. Did the group assume that just the > authentication > > part will be done locally but authorization and accounting=20 > still with > > the AAA server? Or, was everything supposed to be done=20 > locally at the > > home agent without any Diameter interaction to the Diameter server? > >=20 > > Ciao > > Hannes > >=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 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Sep 03 10:51:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISDH6-0005A7-Ai; Mon, 03 Sep 2007 10:51:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISDH5-00057G-G5 for dime@ietf.org; Mon, 03 Sep 2007 10:51:35 -0400 Received: from gws04.hcl.in ([203.105.186.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISDH2-0005mK-Re for dime@ietf.org; Mon, 03 Sep 2007 10:51:35 -0400 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 2C2EE360072; Mon, 3 Sep 2007 20:21:30 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws04.hcl.in (Postfix) with ESMTPid 00BEA360070; Mon, 3 Sep 2007 20:21:30 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Sep 2007 20:21:29 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Sep 2007 20:22:04 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC6023DB5D0@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reg. Failed Avp in ACA Msg. Thread-Index: AcfuOGG9rvwxU/H9QNGL9JU8A1z62gAAK0+A From: "Arun Santhanam, TLS-Chennai" To: X-OriginalArrivalTime: 03 Sep 2007 14:51:29.0683 (UTC) FILETIME=[E93AA630:01C7EE39] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-12.2017 TC:1F TRN:62 TV:3.6.1039(15402.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: Subject: [Dime] RE: Reg. Failed Avp in ACA Msg. 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="===============1237880943==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1237880943== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EE39.E95CDF2B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7EE39.E95CDF2B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Victor, I was just going through ACA section in 3588-bis-06 in http://www=2Eietf=2Eorg/internet-drafts/draft-ietf-dime-rfc3588bis-06=2Etxt The following are some of my suggestions: Suggestion 1)=20 I think we can include Failed-Avp for ACA section, just as we have for rest of the command code=2E This will help to report errors of type=20 DAMETER_INVALID_AVP_VALUE, DIAMETER_MISSING_AVP =2E=2E=2E=2E& so on =20 Suggestion 2) Section 6=2E9=2E Acct-Application-Id AVP definition= says that the Avp must be present in all the Accounting Messages=20 Then we can change the present grammar from [Acct-Application-Id] to {Acct-Application-Id} for ACR and ACA command code=2E =20 =20 Thanks & Regards Arun Santhanam DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have=20 received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and=20 attachments please check them for viruses and defect=2E ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C7EE39.E95CDF2B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi Victor,
        I was=
 just going through ACA section in 3588-bis-06 in http://www=2Eietf=
=2Eorg/internet-drafts/draft-ietf-dime-rfc3588bis-06=
=2Etxt 
        &=
nbsp; The following are some of my=
 suggestions:
       =
 Suggestion 1) 
        &=
nbsp;           &nbs=
p;I think we can include Failed-Avp for ACA section, just as we have for=
 rest of the command code=2E This will help to report errors of type=
 
        &=
nbsp;           &nbs=
p;DAMETER_INVALID_AVP_VALUE,=
 DIAMETER_MISSING_AVP=
 …& so on
 
        &=
nbsp; Suggestion 2)
        &=
nbsp;           Section 6=
=2E9=2E Acct-Application-Id AVP definition says that the Avp must be=
 present in all the Accounting Messages=
 
        &=
nbsp; Then we can change the present grammar from=
 [Acct-Application-Id] to {Acct-Application-Id} for ACR and ACA command=
 code=2E

      =         <= /p>

 

Thanks & Regards

Arun Santhanam

DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E
It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have
received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and
attachments please check them for viruses and defect=2E

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C7EE39.E95CDF2B-- --===============1237880943== 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 --===============1237880943==-- From dime-bounces@ietf.org Mon Sep 03 11:19:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISDhn-0002Bo-11; Mon, 03 Sep 2007 11:19:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISDhl-0002BW-B7; Mon, 03 Sep 2007 11:19:09 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISDhj-0006Kj-T6; Mon, 03 Sep 2007 11:19:09 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l83FJ4eA015464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Sep 2007 08:19:04 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l83FJ3E5030041; Mon, 3 Sep 2007 08:19:04 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Sep 2007 08:19:03 -0700 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] Certificate Support for the MIPv6 BootstrappingSplitScenario Date: Mon, 3 Sep 2007 08:19:01 -0700 Message-ID: In-Reply-To: <5FB585F183235B42A9E70095055136FB0555BA@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Certificate Support for the MIPv6 BootstrappingSplitScenario Thread-Index: Acfsib0T+Hw0Rm/uRzOShFiD6aHPCABpN+3AAADIRoAAAuxPoA== From: "Giaretta, Gerardo" To: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" , "Hannes Tschofenig" , "Mobile IPv6 Mailing List" , X-OriginalArrivalTime: 03 Sep 2007 15:19:03.0721 (UTC) FILETIME=[C31CD190:01C7EE3D] X-Spam-Score: -4.0 (----) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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 agree with your assumption. I think that for inter-operator roaming scenarios the main solution is based on IKEv2, possibly with EAP support. PSK may be used in IKEv2 if it is dynamically derived but this is not part of the current solution.=20 Gerardo > -----Original Message----- > From: Tschofenig, Hannes (NSN - DE/Germany - MiniMD) > [mailto:hannes.tschofenig@nsn.com] > Sent: Monday, September 03, 2007 3:56 PM > To: Giaretta, Gerardo; Hannes Tschofenig; Mobile IPv6 Mailing List; > dime@ietf.org > Subject: AW: [Dime] Certificate Support for the MIPv6 > BootstrappingSplitScenario >=20 > Thanks for the quick response. >=20 > One final remark: >=20 > When authentication is done at the HA via certificates you essentially > need to assume that the AAA server is in the same administrative domain > as the HA since otherwise you would introduce a security problem. I > guess you are aware of this limitation compared to the variant where the > authentication is provided to the AAA server itself. >=20 > Ciao > Hannes >=20 >=20 > > Hi Hannes, > > > > The bootstrapping draft is not clear on this, because the AAA > > interactions requirements are discussed in > > draft-ietf-mip6-aaa-ha-goals. > > > > Unfortunately this draft is now expired but I'm working on a new > > version. > > Based on the last version there is the following goal: > > > > G2.2 The HA MUST be able to query the AAAH server to verify Mobile > > IPv6 service authorization for the mobile node. > > > > This goal is independent of the authentication method used. > > Therefore I > > think that the Diameter backend infrastructure should be designed in a > > flexible way to support the following scenarios: > > > > - both authentication and authorization are performed via the AAA > > backend > > - authentication is done locally while authorization is > > performed by the > > AAA server > > - both authentication and authorization are performed locally > > > > Ciao > > Gerardo > > > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: Saturday, September 01, 2007 11:41 AM > > > To: Mobile IPv6 Mailing List; dime@ietf.org > > > Subject: [Dime] Certificate Support for the MIPv6 Bootstrapping > > > SplitScenario > > > > > > Hi all > > > > > > in our attempt to complete the work on the Diameter Mobile IPv6 > > > bootstrapping documents we encountered the following issue: > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp > > ing-split- > > > 07.txt > > > talks about the possibility to perform a certificate based user > > > authentication by the home agent. That's fine. > > > > > > There is, however, the question what that implies for > > Diameter backend > > > infrastructure usage. Did the group assume that just the > > authentication > > > part will be done locally but authorization and accounting > > still with > > > the AAA server? Or, was everything supposed to be done > > locally at the > > > home agent without any Diameter interaction to the Diameter server? > > > > > > 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 From dime-bounces@ietf.org Mon Sep 03 16:38:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISIhA-0000zT-Ph; Mon, 03 Sep 2007 16:38:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISIh8-0000x3-Sd for dime@ietf.org; Mon, 03 Sep 2007 16:38:50 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISIh8-0005fz-3m for dime@ietf.org; Mon, 03 Sep 2007 16:38:50 -0400 Received: (qmail invoked by alias); 03 Sep 2007 20:38:48 -0000 Received: from p54985118.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.81.24] by mail.gmx.net (mp058) with SMTP; 03 Sep 2007 22:38:48 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX182YeNUl5A2vf6gUynJLpRZuYseFCSiDAx99bYZ9j 4p/3C2ZAKJ0h0+ Message-ID: <46DC70D3.7020609@gmx.net> Date: Mon, 03 Sep 2007 22:38:43 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Dime] draft-ietf-dime-mip6-split-04.txt: Proposed Next Steps 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, I read through the mobility documents and here is a suggested approach: Currently the document only talks about the usage of RFC 4877 (only EAP-based authentication) and RFC 4285. The document needs to cover certificate based authentication with the HA as well. In this mode only authorization and accounting is provided with Diameter. The document currently references RFC 4004 with regard to the AVPs. The description of the AVPs in RFC 4004 often refers to the Mobile IPv4 RFC with regard to the semantic. We should copy into the draft and modify it in order to ensure that the semantic focuses only the usage of Mobile IPv6. As Jouni recognized in his recent review there are a couple of differences between the details of the authentication mechanism used by RFC 4285 and by RFC 4004. Instead of re-using the MIP-MN-AAA-Auth AVP we need to carry the following values: * Authenticator data value from MN-AAA auth option * MAC_Mobility Data since the following computation is done: Authentication data = hash_fn(MN-AAA Shared key, MAC_Mobility Data) MAC_Mobility Data = SHA1(care-of address | home address | MH Data) * timestamp since this value may be used as input to the key derivation function. * SPI value * CoA since this value may be used as input to the key derivation function. Thoughts? Ciao Hannes PS: Thanks to Jouni for spending his time discussing these aspects with me. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Sep 03 17:03:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISJ5I-00047s-ED; Mon, 03 Sep 2007 17:03:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISJ5H-0003ym-Di for dime@ietf.org; Mon, 03 Sep 2007 17:03:47 -0400 Received: from [125.236.61.195] (helo=smtp.eservglobal.co.nz) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISJ5G-0006Bc-Kl for dime@ietf.org; Mon, 03 Sep 2007 17:03:47 -0400 Received: from [192.168.7.230] (rloader.eservglobal.co.nz [192.168.7.230]) by smtp.eservglobal.co.nz (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l83L3Wcn021503; Tue, 4 Sep 2007 09:03:32 +1200 Message-ID: <46DC76A3.2010308@eservglobal.co.nz> Date: Tue, 04 Sep 2007 09:03:31 +1200 From: Ralph Loader User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "Pallavi Pethia, TLS-Chennai" Subject: Re: [Dime] regrading reserved bits in Diameter header References: <66E8AEE9980BB44CA5FCAD39EBA56AC6023A37C4@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC6023A37C4@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4140/Tue Sep 4 05:59:33 2007 on smtp.eservglobal.co.nz X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 > r(eserved) - these flag bits are reserved for future use, and > > MUST be set to zero, and ignored by the receiver. > My reading is that the quote above is as intended, so that your option (2) is correct. DIAMETER_INVALID_BIT_IN_HEADER is then badly worded - it should be "recognized but unexpected" (e.g., P on a CER) rather than "unrecognized". Ralph. > > > > > Suppose the reserved are set with value 1. > > There are two ways in which receiver can respond with an answer: > > 1) It can ignore the reserved bits in request and respond with > successful (2001 Result code). > > 2) It can send DIAMETER_INVALID_BIT_IN_HEADER i.e. (5013 Result code). > > > > > > > > The description of 2) is in RFC 3588 section > > > > *7.1.5. Permanent Failures section of RFC 3588* is below : > > > > DIAMETER_INVALID_BIT_IN_HEADER 5013 > > This error is returned when an unrecognized bit in the Diameter > > header is set to one (1). > > > > Please let me know in which way( 1 or 2) the receiver of request with > reserved bits set should react. > > > > Thanks, > > Pallavi > > DISCLAIMER: > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of this > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ----------------------------------------------------------------------------------------------------------------------- > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Mon Sep 03 17:56:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISJuG-0005JS-4A; Mon, 03 Sep 2007 17:56:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISJuE-0005JK-OX for dime@ietf.org; Mon, 03 Sep 2007 17:56:26 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISJuD-0001C9-IN for dime@ietf.org; Mon, 03 Sep 2007 17:56:26 -0400 Received: from gwzpc (unknown[67.170.84.64]) by comcast.net (sccrmhc13) with SMTP id <2007090321561301300k70p0e>; Mon, 3 Sep 2007 21:56:24 +0000 From: "Glen Zorn" To: "'Ralph Loader'" , "'Pallavi Pethia, TLS-Chennai'" References: <66E8AEE9980BB44CA5FCAD39EBA56AC6023A37C4@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <46DC76A3.2010308@eservglobal.co.nz> In-Reply-To: <46DC76A3.2010308@eservglobal.co.nz> Subject: RE: [Dime] regrading reserved bits in Diameter header Date: Mon, 3 Sep 2007 14:55:56 -0700 Message-ID: <000b01c7ee75$3b69c400$b23d4c00$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acfubex/cl/o7ERnTHWd+x029bujbgAByrxQ Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 > r(eserved) - these flag bits are reserved for future use, and > > MUST be set to zero, and ignored by the receiver. > My reading is that the quote above is as intended, so that your option (2) is correct. DIAMETER_INVALID_BIT_IN_HEADER is then badly worded - it should be "recognized but unexpected" (e.g., P on a CER) rather than "unrecognized". [gwz] Actually, wouldn't "invalid" be better yet? ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Sep 03 20:36:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISMOd-0001Mf-Fn; Mon, 03 Sep 2007 20:35:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISMOc-0001MZ-Cp for dime@ietf.org; Mon, 03 Sep 2007 20:35:58 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISMOb-0005fd-20 for dime@ietf.org; Mon, 03 Sep 2007 20:35:58 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l840ZsI19178; Tue, 4 Sep 2007 00:35:54 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 Date: Mon, 3 Sep 2007 19:35:22 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371167EE49B@zrc2hxm2.corp.nortel.com> In-Reply-To: <46B04C06.3040002@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter Mobile IPv6: HA<->AAA Draft Reviewers Thread-Index: AcfUGqM5QlKNjhIcSb2rDc4I5V/ukAabP7Mw References: <46B04C06.3040002@gmx.net> From: "Ahmad Muhanna" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: aaff5d7f1eb2bd23c778cdb1a9c777b3 Cc: Subject: [Dime] RE: Diameter Mobile IPv6: HA<->AAA Draft Reviewers 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, My apologies for not doing this on time. I have not read the comments by Jouni or others, but please find my comments inline. I actually cut and pasted the whole (almost) draft and inserted my comments which clearly identified. Best Regards, Ahmad Muhanna ++++++++++++++++++++++++++++++++++++++++++++++++++++++ Abstract Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the Home Agent and the Diameter server of the Mobile Service Provider (MSP). This document specifies the interaction between a Mobile IP Home Agent and the Diameter server. Two different mechanisms for authentication of a MN to the HA are supported. The first method consists of performing the Internet Key Exchange v2 (IKEv2) protocol along with the Extensible Authentication Protocol (EAP) with the Diameter server, while the second method utilizes the Mobile IPv6 Authentication option, as defined in RFC 4285. For Internet Key Exchange v2 with EAP-based authentication, the Diameter Mobile IPv6 application, defined in this document, reuses the commands defined in the Diameter EAP application, while for supporting the RFC 4285-style MIPv6 Authentication Options, a new Diameter application and new command codes are defined. [Ahmad-START-1] May be the text of the last sentence needs to be fixed. It gives the impression as if there are two different MIPv6 applications defined. The new one for addressing RFC4285 authentication mechanism. [Ahmad-END-1] 1. Introduction Performing the Mobile IPv6 protocol [1], requires the Mobile Node (MN) to own a Home Address (HoA) and assignment of a Home Agent (HA) to MN. The MN needs to register its Mobile IPv6 session with the HA in order facilitate its reachability and mobility, when away from home. The registration process itself requires establishment of IPsec security associations (SA) and cryptographic material between the MN and HA. Providing the collection of home address, HA address and keying material to establish the IP SA is generaally referred to [Ahmad-START-2] replace IP with IPsec. and generaally is missspeled. [Ahmad-END-2] as the Mobile IPv6 bootstrapping problem [reference to RFC4640]. The purpose of this specification is to provide Diameter support for such bootstrapping in a split scenario [2] in a manner that satisfies the requirements defined in [13]. From an operator (mobility service provider, MSP) perspective, it is important to verify that the MN is authenticated and authorized to utilize Mobile IPv6 service and that such services are accounted for. Only when the MN is authenticated and authorized, the MSP allows the boostrapping of Mobile IPv6 parameters at the MN and HA. Thus, prior to processing the Mobile IPv6 service requests, the HA, participates in the authentication of the MN to verify the MN's identity. The HA also participates in the Mobile IPv6 authorization process involving the Diameter infrastrucure. The HA due to its role in traffic forwarding, also performs accounting for the Mobile IPv6 service provided to the MN. Mobile IPv6 specifications allow two different methods for MN authentication, one based on IKEv2 and EAP [3], and another based on the Mobile IPv6 Authentication Option [4]. The goal of this document is to specify the Diameter procedures associated with the Mobile IPv6 bootstrapping between the HA and the Diameter server for these two Mobile IP authentication approaches. For that reason the Diameter Mobile IPv6 application provides two different sets of commands. The first set of commands reuse the command already define in Diameter EAP application (though using the Diameter Mobile IPv6 Application-Id),=20 [Ahmad-START-3] Basically any node which supports the new MIPv6 Application MUST support Diameter EAP application, MIP6 Application using EAP commands, and MIPv6 Application using RFC4285 mechanism. Right? [Ahmad-END-3] while the second set of commands are new for Diameter and provide support the Mobile IPv6 Authentication Option, defined in RFC 4285. For authorization signaling and management of Mobile IPv6 session for the MN, this specification will use the existing procedures from base Diameter specification [5]. [Ahmad-START-4] This is not clear to me. May be I am missing something. Do we need further explanation and details here? When this authentication is invoked? [Ahmad-END-4] For accounting of Mobile IPv6 services provided to the MN, this specification uses the accounting application defined in [5]. 4. Overview One task of the Mobile IPv6 bootstrapping procedure is to assign an appropriate HA to the MN. Furthermore, authorization and successful delivery of Mobile IPv6 to a MN through a HA, requires the HA to act as a client to the Diameter infrastructure interconnecting it to the MSP. As a Diameter client, the HA needs to perform the following operations: Authentication: Asserting or helping in assertion of the correctness of the MN identity. As a Diameter client supporting the new Diameter Mobile IPv6 application, the HA may need to support two different types of authentication by supporting the different command sets that are required for each authentication method. Authorization: The HA must verify that the user is authorized to use the Mobile IPv6 service using the assistance of the MSP Diameter servers. This is accomplised through use of new Diameter commands specifically designed for performing Mobile IPv6 authorization decisions. This document defines these commands and requires the HA to support use of these authorization commands and to participate in this authorization signaling. [Ahmad-START-5] We discussed before that AUTHORIZATION for ROUTE OPTIMIZATION is needed. I did not see it included here?! As we discussed last time, operators do care about having control over the willingness of the MN to have route optimization. If that the case, then there should be a process to enable that kind of authorization. No? [Ahmad-END-5] Accounting: For billing purposes and capacity planning, it is required of the HA to provide accounting report to the Diameter infrastructure and thus to support the related Diameter accounting procedures. Figure 1 depicts the architecture. +---------------------------+ +-----------------+ |Visited MSP | | Home MSP/MSA | | | | | | | | | | +--------+ | | +--------+ | | |Local | Diameter | | |Home | | | |Diameter|<---------------------->|Diameter| | | |Proxy | | | |Server | | | +--------+ | | +--------+ | | ^ | | ^ | | | | | | | | | Diameter | |Diameter| | | v | | v | | +-------+ | | +-------+ | | |Home | | | |Home | | | |Agent | | | |Agent | | | +-------+ | | +-------+ | | ^ | | ^ | +-----|---------------------+ +--------|--------+ | | | | | +---------+ | | | Mobile | | +--------->| Node |<-----------+ IKEv2 or RFC 4285 +---------+ IKEv2 or RFC 4285 Figure 1: Architecture Overview [Editor's Note: A description of the relationship with the front-end protocols is needed.] 5. Protocol Description 5.1. Support for Mobile IPv6 with IKEv2 and IPsec The use of IKEv2 between the MN and the HA allows the HA to authenticate the MN. When EAP is used with IKEv2, the Diameter EAP application, as defined in [8], is re-used. AVPs specific to Mobile IPv6 bootstrapping are added to this command. Figure 2 shows the message flow involved during the authentication phase when EAP is used. Mobile Home Diameter Node Agent Server ------ ----- -------- IKE_SA_INIT (1,2) <------------------------------> HDR, SK{IDi,[CERTREQ,] [IDr,] [CP(CFG_REQUEST),] SAi2, TSi, TSr} (3) -------------------------------> DER (EAP-Response) (4) ------------------------> DEA (EAP-Request) (5) <------------------------ HDR, SK {IDr, [CERT,] AUTH, EAP } <------------------------------- HDR, SK {EAP} --------------------------------> DER (EAP-Response) ------------------------> DEA (EAP-Request) <------------------------ HDR, SK{EAP-Request} <------------------------------- HDR, SK{EAP-Response} --------------------------------> DER (EAP-Response) ------------------------> ... ... DEA (EAP-Success) <------------------------ HDR, SK{EAP-Success} <------------------------------- HDR, SK{AUTH} -------------------------------> HDR, SK {AUTH, [CP(CFG_REPLY,] SAr2, TSi, TSr } <------------------------------- Figure 2: IKEv2 Diameter EAP Message Flow The MN and the HA start the interaction with an IKE_SA_INIT exchange. In this phase cryptographic algorithms are negotiated, nonces and Diffie-Hellman parameters are exchanged. Message (3) starts the IKE_AUTH phase. This second phase authenticates the previous messages, exchanges identities and certificates and establishes the first CHILD_SA. It is used to mutually authenticate the MN (acting as an IKEv2 Initiator) and the HA (acting as an IKEv2 Responder). The identity of the user/MN is provided in the IDi field. The MN indicates its willingness to be authenticated via EAP by omitting the AUTH field in message 3 (see [9]). As part of the authentication process, the MN MAY request a Home- Address, a Home Prefix or suggests one, see [2], using a CFG_REQUEST payload in the message 3. [Ahmad-START-6] Does this sentence mean that the MN MAY request a HoA and A HNP or only one? [Ahmad-END-6] The HA extracts the IDi field from the message 3 and sends a Diameter-EAP-Request (DER) message towards the authenticating Diameter server. This message is routed to the MNs Diameter server/EAP server. The Diameter server selects the EAP method and replies with the DEA Message. Depending on the type of EAP method chosen, a number of DER and DEA messages carry the method specific exchanges between the MN and the Diameter server/EAP server. At the end of the EAP authentication phase, the Diameter server indicates the result of the authentication in the Result-Code AVP and provides the corresponding EAP packet (EAP Success or EAP Failure). The last IKEv2 message sent by the HA contains the Home Address or the Home Prefix. =20 [Ahmad-START-7] Here it is clear, that the end result is either the assignment of HoA or HNP. NOT both. May be we need to fix the sentence under comment 6. [Ahmad-END-7] =20 In the latter case, a CREATE_CHILD_SA exchange is necessary to setup IPsec SAs for Mobile IPv6 signalling. In some deployment scenario, the HA may also acts as a IKEv2 Responder for IPsec VPN access. A problem in this case is that the IKEv2 responder may not know if IK Ev2 is used for MIP6 service or for IPsec VPN access. A network operator needs to be aware of this limitation. 5.2. Support for the Mobile IPv6 Authentication Protocol Figure 3 describes the sequence of messages sent and received between the MN, the HA and the Diameter server during the registration when RFC 4285 is used. Binding Update (BU) and Binding Acknowledgement (BA) messages are used in the registration process. This exchange triggers the Diameter interaction. According to [4] the MN uses the Mobile Node Identifier Option, specifically the MN-NAI mobility option as defined in [14] to identify itself while authenticating with the HA. The MN may use the Message Identifier option for additional replay protection. =20 =20 [Ahmad-START-8] 1. Why we are calling it Message Identifier Option, Should not we refer to it as Mobility Message Replay Protection Option as per RFC4285. 2. RFC4285 DID NOT mandate the use of this option for replay protection assuming that Sequence Number is good enough for offering replay protection. I believe sequence number as per RFC3775 is lacking a complete replay protection and it relies on IPsec with IKEv2 to provide a reliable replay protection mechanism. Since RFC4285 is similar to RFC3344 of Mobile IPv4, then I would recommend mandating the use of this option for replay protection whenever RFC4285 is used as an authentication protocol. [Ahmad-END-8] The authentication option may be used by the MN to transfer authentication data when the MN and the HA are utilizing a mobility SPI. [Ahmad-START-9] This needs more details. What does the MN and the HA are utilizing a mobility SPI. Where is that SPI is coming from. i.e. Is it already configured, or do we mean the MN-AAA Authentication option reserved SPI value? Some more clarification is needed. [Ahmad-END-9] The BU initiates a MIP6-Request-Message to the Diameter server and the corresponding response is carried in a MIP6-Answer-Message. [Ahmad-START-10] Why Diameter is not part of the message name? I suggest the following naming: Diameter-MIP6-Request message and Diameter-MIP6-Answer message. [Ahmad-END-10] Mobile Home AAA Node Agent Server | | | | | | | Binding Update |MIP6-Request-Message | (a)|------------------------------------>|-------------------->| | (including MN-ID option, | | | Message ID option [optional], | | | authentication option) | | | | | | | | | Binding Acknowledgement |MIP6-Answer-Message | (b)|<------------------------------------|<--------------------| | (including MN-ID option, | (MN-HA key) | | Message ID option [optional], | | | authentication option) | | Figure 3: MIPv6 Bootstrapping using RFC 4285 [Ahmad-START-11] what are all the remaining information that is received from the Diameter Server. This only highlight MN-HA key. is that all what is returned? This Figure needs to be updated with proper naming of the authentication option and all other parameters, or a detailed explanation of these steps is required. [Ahmad-END-11] 5.3. Mobile IPv6 Session Management The Diameter server may maintain state or may be stateless. This is indicated in the Auth-Session-State AVP (or its absence). The HA MUST support the Authorization Session State Machine defined in [5]. Moreover the following 4 commands may be exchanged between the HA and the Diameter server. 5.3.1. Session-Termination-Request Command The Session-Termination-Request (STR) message [5] is sent by the HA to inform the Diameter server that an authorized session is being terminated. 5.3.2. Session-Termination-Answer Command The Session-Termination-Answer (STA) message [5] is sent by the Diameter server to acknowledge the notification that the session has been terminated. 5.3.3. Abort-Session-Request Command The Abort-Session-Request (ASR) message [5] is sent by the Diameter server to terminates the session. This fulfills one of the requirement described in [13]. 5.3.4. Abort-Session-Answer Command The Abort-Session-Answer (ASA) message [5] is sent by the Home Agent in response to an ASR message. 5.4. Accounting for Mobile IPv6 services The HA MUST be able act as a Diameter client collecting accounting records needed for service control and charging. The HA MUST support the accounting procedures (specifically the command codes mentioned below) and the Accounting Session State Machine as defined in [5]. The command codes, exchanged between the HA and Diameter server for accounting purposes, are provided in the following subsections. The Diameter application design guideline [15] defines two separate model for accounting: Split accounting model: According to this model, the accounting messages use the Diameter base accounting application ID (value of 3). Since accounting is treated as an independent application, accounting commands may be routed separately from the rest of application messages and thus the accounting messages generally end up in a central accounting server. Since Diameter Mobile IPv6 application does not define its own unique accounting commands, this is the prefered choice, since it permits use of centralized accounting for several applications. Coupled accounting model: In this model, the accounting messages will use the application ID of the Mobile IPv6 application. This means that accounting messages will be routed like any other Mobile IPv6 application messages. This requires the Diameter server in charge of Mobile IPv6 application to handle the accounting records (e.g., sends them to a proper accounting server).. As mentioned above, the prefered choice is to use the split accounting model and thus choose Diameter base accounting application ID (value of 3) for accounting messages. 5.4.1. Accounting-Request Command The Accounting-Request command [5] is sent by the HA to the Diameter server to exchange accounting information regarding the MN with the Diameter server. 5.4.2. Accounting-Answer Command The Accounting-Answer command [5] is sent by the Diameter server to the HA to acknowledge receiving an Accounting-Request. 6. Command-Code and AVP Values The following commands are defined in this section: Command-Name Abbrev. Code Reference Application ---------------------------------------------------------------------- MIP6-Request-Message MRM XXX TBD MIP6 MIP6-Answer-Message MAM XXX TBD MIP6 Figure 4: New Command Codes The following defines the command codes used by the Diameter Mobile IPv6 application: Command-Name Abbrev. Code Reference Application ---------------------------------------------------------------------- Diameter-EAP-Request DER 268 RFC 4072 EAP Diameter-EAP-Answer DEA 268 RFC 4072 EAP MIP6-Request-Message MRM XXX TBD MIP6 MIP6-Answer-Message MAM XXX TBD MIP6 Session-Termination-Request STR 275 RFC 3588 BASE Session-Termination-Answer STA 275 RFC 3588 BASE Abort-Session-Request ASR 275 RFC 3588 BASE Abort-Session-Answer ASA 275 RFC 3588 BASE Accounting-Request ACR 271 RFC 3588 BASE Accounting-Answer ACA 271 RFC 3588 BASE Figure 5: Command Codes 6.1. Command Code for EAP-based Authentication This document re-uses the Diameter EAP application commands. The following commands are used to carry MIPv6 related bootstrapping AVPs: Command-Name Abbrev. Code Reference Application ------------------------------------------------------------------ Diameter-EAP-Request DER 268 RFC 4072 EAP Diameter-EAP-Answer DEA 268 RFC 4072 EAP Figure 6: Diameter EAP command codes used for MIPv6 Bootstrapping HA to HAAA Interface 6.1.1. Diameter-EAP-Request (DER) The Diameter-EAP-Request (DER) message [8], indicated by the Command- Code field set to 268 and the 'R' bit set in the Command Flags field, is sent by the HA to the Diameter server to initiate a Mobile IPv6 service authentication and authorization procedure. The DER message format is the same as defined in [8]. The Application-ID field of the Diameter Header MUST be set to the Diameter Mobile IPv6 Application ID [TO BE ASSIGNED TO IANA]. ::=3D < Diameter Header: 268, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Request-Type } [ Destination-Host ] [ NAS-Identifier ] [ NAS-IP-Address ] [ NAS-IPv6-Address ] [ NAS-Port-Type ] [ User-Name ] { EAP-Payload } [ MIP6-Feature-Vector ] [ MIP-Mobile-Node-Address ] ... * [ AVP ] 6.1.2. Diameter-EAP-Answer (DEA) The Diameter-EAP-Answer (DEA) message defined in [8], indicated by the Command-Code field set to 268 and 'R' bit cleared in the Command Flags field, is sent in response to the Diameter-EAP-Request message (DER). If the Mobile IPv6 authentication procedure was successful then the response MAY include any set of bootstrapping AVPs. The DEA message format is the same as defined in [8]. The Application-Id field in the Diameter header MUST be set to the Diameter Mobile IPv6 Application-Id [TO BE ASSIGNED BY IANA]. ::=3D < Diameter Header: 268, PXY > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } { Origin-Host } { Origin-Realm } [ User-Name ] { EAP-Payload } [ Authorization-Lifetime ] [ MIP-Mobile-Node-Address ] [ MIP6-Feature-Vector ] ... * [ AVP ] 6.2. Command Codes for RFC 4285 Support This section defines Command-Code [5] values that MUST be supported by all Diameter implementations conforming to this specification. The following Command Codes are defined in this specification. Command-Name Abbreviation Code Section ------------------------------------------------------------------ MIP6-Request-Message MRM TBD Section 6.2.1 MIP6-Answer-Message MAM TBD Section 6.2.2 6.2.1. MIP6-Request-Message The MIP6-Request-Message (MRM), indicated by the Command-Code field set to TBD and the 'R' bit set in the Command Flags field, is sent by the HA, acting as a Diameter client, in order to request the authentication and authorization of a MN. The HA uses information found in the Binding Update to construct the following AVPs, to be included as part of the MRM: o Home Address (MIP-Mobile-Node-Address AVP) o Mobile Node NAI (User-Name AVP [5]) o MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP) [Ahmad-START-12] Should not we call it MN-AAA Message Mobility Authentication Option? Or at least reference that in an explicit text. [Ahmad-END-12] If the MN's home address is zero, the HA MUST NOT include a MIP- Mobile-Node-Address AVP. If the MN's home address is all ones, the HA MUST include a MIP- Mobile-Node-Address AVP, set to all ones. [Ahmad-START-13] As per this draft it says: " The BU initiates a MIP6-Request-Message to the Diameter server and the corresponding response is carried in a MIP6-Answer-Message. " What is in the BU as per RFC4285 which indicates to the HA which value to use inside Mobile-Node-Address AVP as listed above? [Ahmad-END-13] The message format is shown below: ::=3D < Diameter Header: XXX, REQ, PXY = > < Session-ID > { Auth-Application-Id } { User-Name } { Destination-Realm } { Origin-Host } { Origin-Realm } [ Acct-Multi-Session-Id ] [ Destination-Host ] [ Origin-State-Id ] [ NAS-Identifier ] [ NAS-IP-Address ] [ NAS-IPv6-Address ] [NAS-Port-Type] [ MIP6-Feature-Vector ] [ MIP-MN-AAA-Auth ] [ MIP-Mobile-Node-Address ] [ Authorization-Lifetime ] [ Auth-Session-State ] * [ Proxy-Info ] * [ Route-Record ] * [ AVP ] 6.2.2. MIP6-Answer-Message The MIP6-Answer-Message (MAM) message, indicated by the Command-Code field set to TBD and the 'R' bit cleared in the Command Flags field, is sent by the Diameter server in response to the MIP6-Request- Message message. The User-Name MAY be included in the MAM if it is present in the MRM. The Result-Code AVP MAY contain one of the values defined in Section 6.2.3.2, in addition to the values defined in RFC 3588 [5]. An MAM message with the Result-Code AVP set to DIAMETER_SUCCESS MUST include the MIP-Mobile-Node-Address AVP. The MIP-Home-Agent-Address AVP contains the HA assigned to the MN,=20 [Ahmad-START-14] What is the MIP-Home-Agent-Address has to do here? Is that supposed to be inside the MAM? [Ahmad-END-14] while the MIP-Mobile-Node- Address AVP contains the home address that was assigned. The message format is shown below: ::=3D < Diameter Header: XXX, PXY > < Session-Id > { Auth-Application-Id } { Result-Code } { Origin-Host } { Origin-Realm } [ Acct-Multi-Session-Id ] [ User-Name ] [ Authorization-Lifetime ] [ Auth-Session-State ] [ Error-Message ] [ Error-Reporting-Host ] [ Re-Auth-Request-Type ] [ MIP6-Feature-Vector ] [ MIP-MN-to-HA-MSA ] [ MIP-HA-to-MN-MSA ] [ MIP-MSA-Lifetime ] [ MIP-Session-Key] [ MIP-Mobile-Node-Address ] * [ MIP-Filter-Rule ] [Ahmad-START-15] Why do we need to have two different MSAs? MN-HA and HA-MN MSA? Are we using these AVP as per RFC4004? which was designed for MIPv4 Application? How the information is communicated back to the MN? What this MIP-Session-Key is used for? Is it needed here? [Ahmad-END-15] [ Origin-State-Id ] * [ Proxy-Info ] * [ AVP ] [Editor's Note: The MIP-Filter-Rule is based on IPFiltrRule, which is currently being revised. Hence, this document should refer to the updated functionality. Furthermore, the requirements document indicates that QoS parameters may need to conveyed to the HA. Hence, the revised version of the QoS-Filter-Rule / QoSFilterRule being developed with [10] has to be used.] 6.2.3. Diameter AVPs The Diameter client uses AVPs dependent on the usage of RFC 4285 [4] or RFC 4877 [3]. To provide support for RFC 4285 [4] the following AVPs defined in [11] are reused in this application: o MIP-HA-to-MN-MSA AVP, o MIP-MN-to-HA-MSA AVP, o MIP-Session-Key AVP o MIP-Algorithm-Type AVP o MIP-Replay-Mode AVP [Ahmad-START-16] What are the supported replay protection modes in MIPv6 Application? What kind of mode reference the sequence number?, for example. [Ahmad-END-16] o MIP-MN-AAA-Auth AVP o MIP-MN-AAA-SPI AVP o MIP-Auth-Input-Data-Length AVP o MIP-Authenticator-Length AVP o MIP-Authenticator-Offset AVP o MIP-MSA-Lifetime AVP o MIP-Mobile-Node-Address (with an IPv6 address) [Ahmad-START-17] I have not seen how some of these AVPS are used in Diameter MIPv6 Application which is supposedly defined in this document? Do we expect those AVPs to be used exactly as per RFC4004? If that the case, should that be specified wherever applicable in this application? [Ahmad-END-17] =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Wednesday, August 01, 2007 4:02 AM > To: dime@ietf.org > Cc: Muhanna, Ahmad (RICH1:2H10); Jouni Korhonen > Subject: Diameter Mobile IPv6: HA<->AAA Draft Reviewers >=20 > I would like to thank >=20 > * Jouni Korhonen > * Ahmad Muhanna >=20 > for their willingness to review the Diameter Mobile IPv6:=20 > HA<->AAA draft within the next 2 weeks. >=20 > Ciao > Hannes >=20 >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 04 03:38:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISSzu-0002PH-Un; Tue, 04 Sep 2007 03:38:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISSzu-0002Oc-05 for dime@ietf.org; Tue, 04 Sep 2007 03:38:54 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISSzs-0007cP-HM for dime@ietf.org; Tue, 04 Sep 2007 03:38:53 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l847cnHd004488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Sep 2007 00:38:49 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l847cmTl006615; Tue, 4 Sep 2007 00:38:49 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Sep 2007 00:38:48 -0700 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-split-04.txt: Proposed Next Steps Date: Tue, 4 Sep 2007 00:38:40 -0700 Message-ID: In-Reply-To: <46DC70D3.7020609@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] draft-ietf-dime-mip6-split-04.txt: Proposed Next Steps Thread-Index: AcfuandYu+BFMJJ8TUmf1N1DTGrZbAAW2rag From: "Giaretta, Gerardo" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 04 Sep 2007 07:38:48.0768 (UTC) FILETIME=[A1BB2400:01C7EEC6] X-Spam-Score: -4.0 (----) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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, Some comments inline... > Hi all, >=20 > I read through the mobility documents and here is a suggested approach: >=20 > Currently the document only talks about the usage of RFC 4877 (only > EAP-based authentication) and RFC 4285. The document needs to cover > certificate based authentication with the HA as well. In this mode only > authorization and accounting is provided with Diameter. > I agree. Moreover, there is another aspect that needs to be added and was pointed out also by Vijay in MIP6 mailing list. The current AAA goals draft needs to be updated in order to include the possibility for the HA to check the IKEv2 PSK provided by the MN with the AAA server.=20 This can be done either with a push method (AAA server pushing the PSK to the HA) or with a pull method (HA asking the AAA server during the IKEv2 exchange). We can discuss if we need two methods or just one of them. The goal in draft-ietf-mip6-aaa-ha-goals will not point to a specific solution but will state that the HA must be able to check the validity of a PSK. =20 > The document currently references RFC 4004 with regard to the AVPs. The > description of the AVPs in RFC 4004 often refers to the Mobile IPv4 RFC > with regard to the semantic. We should copy into the draft and modify it > in order to ensure that the semantic focuses only the usage of Mobile IPv6. >=20 Agree. ciao Gerardo > As Jouni recognized in his recent review there are a couple of > differences between the details of the authentication mechanism used by > RFC 4285 and by RFC 4004. >=20 > Instead of re-using the MIP-MN-AAA-Auth AVP we need to carry the > following values: > * Authenticator data value from MN-AAA auth option > * MAC_Mobility Data > since the following computation is done: > Authentication data =3D hash_fn(MN-AAA Shared key, MAC_Mobility Data) > MAC_Mobility Data =3D SHA1(care-of address | home address | MH Data) > * timestamp since this value may be used as input to the key derivation > function. > * SPI value > * CoA since this value may be used as input to the key derivation function. >=20 > Thoughts? >=20 > Ciao > Hannes >=20 > PS: Thanks to Jouni for spending his time discussing these aspects with me. >=20 >=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 Tue Sep 04 03:49:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IST9l-0001oy-1K; Tue, 04 Sep 2007 03:49:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IST9i-0001oi-OU for dime@ietf.org; Tue, 04 Sep 2007 03:49:02 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IST9h-0006ZK-T1 for dime@ietf.org; Tue, 04 Sep 2007 03:49:02 -0400 Received: (qmail invoked by alias); 04 Sep 2007 07:49:00 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp056) with SMTP; 04 Sep 2007 09:49:00 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/E+1huu0/E40DtJGudrVh+MLvTIvkgdupsl5pNPj Ic8ssYdfAi++Md Message-ID: <46DD0DE4.1020407@gmx.net> Date: Tue, 04 Sep 2007 09:48:52 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Giaretta, Gerardo" Subject: Re: [Dime] draft-ietf-dime-mip6-split-04.txt: Proposed Next Steps 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: 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 Gerardo, Giaretta, Gerardo wrote: > Hi Hannes, > > Some comments inline... > > >> Hi all, >> >> I read through the mobility documents and here is a suggested >> > approach: > >> Currently the document only talks about the usage of RFC 4877 (only >> EAP-based authentication) and RFC 4285. The document needs to cover >> certificate based authentication with the HA as well. In this mode >> > only > >> authorization and accounting is provided with Diameter. >> >> > > I agree. > > Moreover, there is another aspect that needs to be added and was pointed > out also by Vijay in MIP6 mailing list. The current AAA goals draft > needs to be updated in order to include the possibility for the HA to > check the IKEv2 PSK provided by the MN with the AAA server. > When you say PSK you do not mean the EAP method. Right? If so, I assume you want to put the PSK into the User-Password AVP of NASREQ? Correct? > This can be done either with a push method (AAA server pushing the PSK > to the HA) or with a pull method (HA asking the AAA server during the > IKEv2 exchange). We don't have push methods in the document. Hence, we need to go for a pull method. > We can discuss if we need two methods or just one of > them. The goal in draft-ietf-mip6-aaa-ha-goals will not point to a > specific solution but will state that the HA must be able to check the > validity of a PSK. > Ok. Thanks for raising this issue. Ciao Hannes > > >> The document currently references RFC 4004 with regard to the AVPs. >> > The > >> description of the AVPs in RFC 4004 often refers to the Mobile IPv4 >> > RFC > >> with regard to the semantic. We should copy into the draft and modify >> > it > >> in order to ensure that the semantic focuses only the usage of Mobile >> > IPv6. > > > Agree. > > ciao > Gerardo > > >> As Jouni recognized in his recent review there are a couple of >> differences between the details of the authentication mechanism used >> > by > >> RFC 4285 and by RFC 4004. >> >> Instead of re-using the MIP-MN-AAA-Auth AVP we need to carry the >> following values: >> * Authenticator data value from MN-AAA auth option >> * MAC_Mobility Data >> since the following computation is done: >> Authentication data = hash_fn(MN-AAA Shared key, MAC_Mobility Data) >> MAC_Mobility Data = SHA1(care-of address | home address | MH Data) >> * timestamp since this value may be used as input to the key >> > derivation > >> function. >> * SPI value >> * CoA since this value may be used as input to the key derivation >> > function. > >> Thoughts? >> >> Ciao >> Hannes >> >> PS: Thanks to Jouni for spending his time discussing these aspects >> > with me. > >> _______________________________________________ >> 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 Tue Sep 04 04:29:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISTn9-0001ao-3s; Tue, 04 Sep 2007 04:29:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISTn7-0001ai-PN for dime@ietf.org; Tue, 04 Sep 2007 04:29:45 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISTn6-00010J-Ad for dime@ietf.org; Tue, 04 Sep 2007 04:29:45 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 10:29:42 +0200 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-split-04.txt: Proposed Next Steps Date: Tue, 4 Sep 2007 10:29:44 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222CABB@SEHAN021MB.tcad.telia.se> In-Reply-To: <46DD0DE4.1020407@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] draft-ietf-dime-mip6-split-04.txt: Proposed Next Steps Thread-Index: AcfuyCrx3L5ZYIYfR3WgpscmfqZopAAAlMlA References: <46DD0DE4.1020407@gmx.net> From: To: , X-OriginalArrivalTime: 04 Sep 2007 08:29:42.0454 (UTC) FILETIME=[BDDEA560:01C7EECD] X-Spam-Score: -4.0 (----) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 > Sent: Tuesday, September 04, 2007 10:49 AM > > Moreover, there is another aspect that needs to be added and was=20 > > pointed out also by Vijay in MIP6 mailing list. The current=20 > AAA goals=20 > > draft needs to be updated in order to include the=20 > possibility for the=20 > > HA to check the IKEv2 PSK provided by the MN with the AAA server. > > =20 > When you say PSK you do not mean the EAP method. Right? > If so, I assume you want to put the PSK into the=20 > User-Password AVP of NASREQ? Correct? For IKEv2 you can have pre-shared keys also without EAP. That needs to be covered as well. > > This can be done either with a push method (AAA server=20 > pushing the PSK=20 > > to the HA) or with a pull method (HA asking the AAA server=20 > during the > > IKEv2 exchange). > We don't have push methods in the document. Hence, we need to=20 > go for a pull method. >=20 > > We can discuss if we need two methods or just one of them.=20 > The goal=20 > > in draft-ietf-mip6-aaa-ha-goals will not point to a=20 > specific solution=20 > > but will state that the HA must be able to check the validity of a=20 > > PSK. > > =20 > Ok. Hmm check how? Cheers, Jouni >=20 > Thanks for raising this issue. >=20 > Ciao > Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 04 04:34:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISTrF-0005yP-M7; Tue, 04 Sep 2007 04:34:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISTrE-0005yJ-46 for dime@ietf.org; Tue, 04 Sep 2007 04:34:00 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISTrD-0008Q5-Ce for dime@ietf.org; Tue, 04 Sep 2007 04:33:59 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l848XtVk008186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Sep 2007 01:33:55 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l848XsK0014448; Tue, 4 Sep 2007 01:33:55 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Sep 2007 01:33:54 -0700 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-split-04.txt: Proposed Next Steps Date: Tue, 4 Sep 2007 01:33:53 -0700 Message-ID: In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30222CABB@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] draft-ietf-dime-mip6-split-04.txt: Proposed Next Steps Thread-Index: AcfuyCrx3L5ZYIYfR3WgpscmfqZopAAAlMlAAADqLnA= From: "Giaretta, Gerardo" To: , X-OriginalArrivalTime: 04 Sep 2007 08:33:54.0693 (UTC) FILETIME=[54374350:01C7EECE] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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, > > > Moreover, there is another aspect that needs to be added and was > > > pointed out also by Vijay in MIP6 mailing list. The current > > AAA goals > > > draft needs to be updated in order to include the > > possibility for the > > > HA to check the IKEv2 PSK provided by the MN with the AAA server. > > > > > When you say PSK you do not mean the EAP method. Right? > > If so, I assume you want to put the PSK into the > > User-Password AVP of NASREQ? Correct? >=20 > For IKEv2 you can have pre-shared keys also without EAP. > That needs to be covered as well. > Yes, I was referring to the PSK without EAP. =20 > > > This can be done either with a push method (AAA server > > pushing the PSK > > > to the HA) or with a pull method (HA asking the AAA server > > during the > > > IKEv2 exchange). > > We don't have push methods in the document. Hence, we need to > > go for a pull method. > > > > > We can discuss if we need two methods or just one of them. > > The goal > > > in draft-ietf-mip6-aaa-ha-goals will not point to a > > specific solution > > > but will state that the HA must be able to check the validity of a > > > PSK. > > > > > Ok. >=20 > Hmm check how? >=20 This is part of the solution. As Hannes mentioned, so far we have only a pull method for this.=20 ciao Gerardo > Cheers, > Jouni >=20 >=20 > > > > Thanks for raising this issue. > > > > Ciao > > Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 04 08:13:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISXHM-0007li-SA; Tue, 04 Sep 2007 08:13:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISXHK-0007lO-8p for dime@ietf.org; Tue, 04 Sep 2007 08:13:10 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISXHJ-0007BS-LM for dime@ietf.org; Tue, 04 Sep 2007 08:13:10 -0400 Received: (qmail invoked by alias); 04 Sep 2007 12:13:08 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp031) with SMTP; 04 Sep 2007 14:13:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+ul8E0w3SuSyNDOHXsA/Kri7SsTk1AFJR0wl5AF2 O7c0rQNuhS5KAa Message-ID: <46DD4BCA.8090200@gmx.net> Date: Tue, 04 Sep 2007 14:12:58 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org, Mobile IPv6 Mailing List 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: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Dime] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization 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, during his review of "Diameter Mobile IPv6: HA<->AAA" Ahmad made the following comment: >>> We discussed before that AUTHORIZATION for ROUTE OPTIMIZATION is needed. I did not see it included here?! As we discussed last time, operators do care about having control over the willingness of the MN to have route optimization. If that the case, then there should be a process to enable that kind of authorization. No? <<< Does the group think that we need to provide any backend infrastructure support to enable this type of functionality? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 04 08:41:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISXiS-00061N-DH; Tue, 04 Sep 2007 08:41:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISXiR-000618-3H; Tue, 04 Sep 2007 08:41:11 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISXiQ-0007yE-Oq; Tue, 04 Sep 2007 08:41:11 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 14:41:14 +0200 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] Diameter Mobile IPv6 Bootstrapping: Authorizing RouteOptimization Date: Tue, 4 Sep 2007 14:41:06 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222CAEB@SEHAN021MB.tcad.telia.se> In-Reply-To: <46DD4BCA.8090200@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 Bootstrapping: Authorizing RouteOptimization Thread-Index: Acfu7S1o4RHDb1LuQ5WSwz9JEPE7tAAAwZ4g References: <46DD4BCA.8090200@gmx.net> From: To: , , X-OriginalArrivalTime: 04 Sep 2007 12:41:14.0584 (UTC) FILETIME=[E17AED80:01C7EEF0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 > Does the group think that we need to provide any backend=20 > infrastructure support to enable this type of functionality?=20 Yes. That could e.g. be part of the subscriber profile. Cheers, Jouni >=20 > Ciao > Hannes >=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 Sep 04 08:52:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISXtI-00079P-DI; Tue, 04 Sep 2007 08:52:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISXgh-0003i8-QK; Tue, 04 Sep 2007 08:39:23 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISXgh-0007ur-8N; Tue, 04 Sep 2007 08:39:23 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1188909561!4399700!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9751 invoked from network); 4 Sep 2007 12:39:21 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-153.messagelabs.com with SMTP; 4 Sep 2007 12:39:21 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l84CdLup021902; Tue, 4 Sep 2007 05:39:21 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l84CdK85027041; Tue, 4 Sep 2007 07:39:21 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l84CdJSh027022; Tue, 4 Sep 2007 07:39:19 -0500 (CDT) Message-ID: <46DD51F6.6000209@gmail.com> Date: Tue, 04 Sep 2007 14:39:18 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hannes Tschofenig References: <46DD4BCA.8090200@gmx.net> In-Reply-To: <46DD4BCA.8090200@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000772-0, 03/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Tue, 04 Sep 2007 08:52:22 -0400 Cc: Mobile IPv6 Mailing List , dime@ietf.org Subject: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization 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 Tschofenig wrote: > Hi all, during his review of "Diameter Mobile IPv6: HA<->AAA" Ahmad > made the following comment: >>>> > We discussed before that AUTHORIZATION for ROUTE OPTIMIZATION is > needed. I did not see it included here?! As we discussed last time, > operators do care about having control over the willingness of the MN > to have route optimization. If that the case, then there should be a > process to enable that kind of authorization. No? <<< > > Does the group think that we need to provide any backend > infrastructure support to enable this type of functionality? Which group(s)? I think RO is designed to work across the entire Internet, not limited to a AAA-controlled domain. From tests, the benefits of running RO on the MN are apparent only when the distance MN-CN is much shorter than both MN-HA and CN-HA, in terms of IP hops. In a closed system, that equation is not valid, ie, MN is close to both CN and to its HA, and the benefits of running RO are minimal, one doesn't gain much at all. So, in first place I don't see why would a MN want to run RO at all while in a AAA-controlled (closed) domain. It may very well be that MN is not interested at all to run RO to a CN outside the AAA-controlled domain, because it wouldn't gain much. Then, even if MN would want to do that, I don't see why asking the local AAA to be authorized to perform RO. Finally, are you talking about AAA backend authorizing the MN or the CN to do RO? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 04 09:54:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISYrB-0001uO-Eg; Tue, 04 Sep 2007 09:54:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISYrA-0001t0-AJ for dime@ietf.org; Tue, 04 Sep 2007 09:54:16 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ISYr8-0001v7-VG for dime@ietf.org; Tue, 04 Sep 2007 09:54:16 -0400 Received: (qmail invoked by alias); 04 Sep 2007 13:54:14 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp039) with SMTP; 04 Sep 2007 15:54:14 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18PU6UDne0P7yETJsDZVZtAg7fSe/FNkTlt8Uzo9C 3n4NrChU9lX2sf Message-ID: <46DD638A.7050509@gmx.net> Date: Tue, 04 Sep 2007 15:54:18 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu References: <46DD4BCA.8090200@gmx.net> <46DD51F6.6000209@gmail.com> In-Reply-To: <46DD51F6.6000209@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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Mobile IPv6 Mailing List , dime@ietf.org Subject: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization 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 Alex, Alexandru Petrescu wrote: > Hannes Tschofenig wrote: >> Hi all, during his review of "Diameter Mobile IPv6: HA<->AAA" Ahmad >> made the following comment: >>>>> >> We discussed before that AUTHORIZATION for ROUTE OPTIMIZATION is >> needed. I did not see it included here?! As we discussed last time, >> operators do care about having control over the willingness of the MN >> to have route optimization. If that the case, then there should be a >> process to enable that kind of authorization. No? <<< >> >> Does the group think that we need to provide any backend >> infrastructure support to enable this type of functionality? > > Which group(s)? I should have said "groups", DIME and MIP6. I should have clarified a bit more what the background of my mail was (at least how I understood it). The home operator is obviously able to prevent route optimization from happening. Whether this would be done is most likely attached to a subscriber database and could be dynamically downloaded to the Home Agent as part of the bootstrapping procedure. Ciao Hannes > > I think RO is designed to work across the entire Internet, not limited > to a AAA-controlled domain. > > From tests, the benefits of running RO on the MN are apparent only when > the distance MN-CN is much shorter than both MN-HA and CN-HA, in terms > of IP hops. > > In a closed system, that equation is not valid, ie, MN is close to both > CN and to its HA, and the benefits of running RO are minimal, one > doesn't gain much at all. > > So, in first place I don't see why would a MN want to run RO at all > while in a AAA-controlled (closed) domain. It may very well be that MN > is not interested at all to run RO to a CN outside the AAA-controlled > domain, because it wouldn't gain much. Then, even if MN would want to > do that, I don't see why asking the local AAA to be authorized to > perform RO. > > Finally, are you talking about AAA backend authorizing the MN or the CN > to do RO? > > Alex > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 04 09:57:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISYuV-0003yx-Ok; Tue, 04 Sep 2007 09:57:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISYuU-0003yi-9g; Tue, 04 Sep 2007 09:57:42 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISYuT-0001zp-1W; Tue, 04 Sep 2007 09:57:42 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l84DtPu08852; Tue, 4 Sep 2007 13:55:25 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 Date: Tue, 4 Sep 2007 08:57:36 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711686502E@zrc2hxm2.corp.nortel.com> In-Reply-To: <46DD51F6.6000209@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization Thread-Index: Acfu8KfPqS9DfApyTDCXtM0NwPletQABBCfg References: <46DD4BCA.8090200@gmx.net> <46DD51F6.6000209@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" , "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Mobile IPv6 Mailing List , dime@ietf.org Subject: [Dime] RE: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization 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 Alex, Just some background: The proposed Diameter MIPv6 Application is used to enable MIPv6 service authorization + dynamic security association allocation. As per the current application, the user is authorized for MIPv6 service without a clear indication if the user is allowed to use Route Optimization or not. Allowing the operator this flexibility makes a lot of sense. Let us remember in order for the MN to establish a RO, it needs to have at least HoTI and HoT signals transmitted via the HA which can act as the authorization enforcement point. Of course, we are talking about a network which is controlled by AAA infrastructure since the proposed application is for Diameter MIPv6.=20 Also, please see comments inline. Regards, Ahmad =20 > Subject: Re: [Mip6] Diameter Mobile IPv6 Bootstrapping:=20 > Authorizing Route Optimization >=20 > Hannes Tschofenig wrote: > > Hi all, during his review of "Diameter Mobile IPv6: HA<->AAA" Ahmad=20 > > made the following comment: > >>>>=20 > > We discussed before that AUTHORIZATION for ROUTE OPTIMIZATION is=20 > > needed. I did not see it included here?! As we discussed last time,=20 > > operators do care about having control over the willingness=20 > of the MN=20 > > to have route optimization. If that the case, then there=20 > should be a=20 > > process to enable that kind of authorization. No? <<< > >=20 > > Does the group think that we need to provide any backend=20 > > infrastructure support to enable this type of functionality? >=20 > Which group(s)? >=20 > I think RO is designed to work across the entire Internet,=20 > not limited to a AAA-controlled domain. >=20 > From tests, the benefits of running RO on the MN are=20 > apparent only when the distance MN-CN is much shorter than=20 > both MN-HA and CN-HA, in terms of IP hops. >=20 > In a closed system, that equation is not valid, ie, MN is=20 > close to both CN and to its HA, and the benefits of running=20 > RO are minimal, one doesn't gain much at all. >=20 > So, in first place I don't see why would a MN want to run RO=20 > at all while in a AAA-controlled (closed) domain. It may=20 > very well be that MN is not interested at all to run RO to a=20 > CN outside the AAA-controlled domain, because it wouldn't=20 > gain much. Then, even if MN would want to do that, I don't=20 > see why asking the local AAA to be authorized to perform RO. [Ahmad] Are you assuming that the HA is always in the visited network? Also, V-AAA does not communicate with H-AAA? I just want to understand what you meant here. Thanks. >=20 > Finally, are you talking about AAA backend authorizing the MN=20 > or the CN to do RO? [Ahmad] AAA infrastructure only can control the MN to have RO or not and hence authorization is for the MN not the CN. >=20 > Alex >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 04 10:20:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISZGU-0000dl-4r; Tue, 04 Sep 2007 10:20:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISZGT-0000dW-0A; Tue, 04 Sep 2007 10:20:25 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISZGS-0002I3-7w; Tue, 04 Sep 2007 10:20:24 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1188915622!4407263!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 4578 invoked from network); 4 Sep 2007 14:20:22 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-153.messagelabs.com with SMTP; 4 Sep 2007 14:20:22 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l84EKI7j023344; Tue, 4 Sep 2007 07:20:18 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l84EKHes004001; Tue, 4 Sep 2007 09:20:17 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l84EKFFM003964; Tue, 4 Sep 2007 09:20:16 -0500 (CDT) Message-ID: <46DD699F.3040108@gmail.com> Date: Tue, 04 Sep 2007 16:20:15 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna References: <46DD4BCA.8090200@gmx.net> <46DD51F6.6000209@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA43711686502E@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711686502E@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000772-0, 03/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: Mobile IPv6 Mailing List , dime@ietf.org Subject: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization 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 Ahmad Muhanna wrote: > Hi Alex, > > Just some background: > > The proposed Diameter MIPv6 Application is used to enable MIPv6 > service authorization + dynamic security association allocation. As > per the current application, the user is authorized for MIPv6 service > without a clear indication if the user is allowed to use Route > Optimization or not. Allowing the operator this flexibility makes a > lot of sense. Let us remember in order for the MN to establish a RO, > it needs to have at least HoTI and HoT signals transmitted via the HA > which can act as the authorization enforcement point. > > Of course, we are talking about a network which is controlled by AAA > infrastructure since the proposed application is for Diameter MIPv6. Ahmad, thank you for clarification. As you describe the operator's need it does make sense to me. There is something to it, however. If the MN, CN and HA are all in the same domain, HA and CN share IPsec keys, and if MN and HA develop keys by AAA means, then there is practically no reason for MIP6 RO to use return routability tests (the HoT/I and CoT/I) messages. I mean HoT/I and CoT/I messages are superfluous and it is possible to do RO without any security concern (eg send BU to CN through HA, all IPsec'ed). That's what I meant by MN not needing to do 3775 RO at all in a AAA-controlled infrastructure. >> Hannes Tschofenig wrote: >>> Hi all, during his review of "Diameter Mobile IPv6: HA<->AAA" >>> Ahmad made the following comment: We discussed before that >>> AUTHORIZATION for ROUTE OPTIMIZATION is needed. I did not see it >>> included here?! As we discussed last time, operators do care >>> about having control over the willingness >> of the MN >>> to have route optimization. If that the case, then there >> should be a >>> process to enable that kind of authorization. No? <<< >>> >>> Does the group think that we need to provide any backend >>> infrastructure support to enable this type of functionality? >> Which group(s)? >> >> I think RO is designed to work across the entire Internet, not >> limited to a AAA-controlled domain. >> >> From tests, the benefits of running RO on the MN are apparent only >> when the distance MN-CN is much shorter than both MN-HA and CN-HA, >> in terms of IP hops. >> >> In a closed system, that equation is not valid, ie, MN is close to >> both CN and to its HA, and the benefits of running RO are minimal, >> one doesn't gain much at all. >> >> So, in first place I don't see why would a MN want to run RO at all >> while in a AAA-controlled (closed) domain. It may very well be >> that MN is not interested at all to run RO to a CN outside the >> AAA-controlled domain, because it wouldn't gain much. Then, even >> if MN would want to do that, I don't see why asking the local AAA >> to be authorized to perform RO. > > [Ahmad] Are you assuming that the HA is always in the visited > network? Right, I did. > Also, V-AAA does not communicate with H-AAA? I just want to > understand what you meant here. Thanks. Right... Anyways I don't see AAA to scale anywhere to the size of the Internet. If AAA is used in one closed system (or two WiMax-like ASN+CSN systems) then I think there's little need for RO. Probably, I mean probably because depends on so many other factors, if MN attaches to ASN and its H-AAA is in the CSN, and MN is outside both CSN and ASN, but much closer to ASN than to CSN, then MN may gain something by doing RO to it. This necessity depends so much on the deployment scenario and placement of different networks. >> Finally, are you talking about AAA backend authorizing the MN or >> the CN to do RO? > > [Ahmad] AAA infrastructure only can control the MN to have RO or not > and hence authorization is for the MN not the CN. I'd like to identify first whether MN needs to do RO or not, and only then look at whether it needs to be authorized or not. For your description, do you think that when MN attaches to a WiMax network's ASN and talks to an arbitrary CN on the Internet - will the MN-CN normal traffic go all the way to CSN first? Alex ASN: Access Service Network CSN: Connectivity Service Network ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 04 10:25:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISZKw-0004UW-BD; Tue, 04 Sep 2007 10:25:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISZKu-0004N0-Ul for dime@ietf.org; Tue, 04 Sep 2007 10:25:01 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISZKr-0002Tf-OU for dime@ietf.org; Tue, 04 Sep 2007 10:25:00 -0400 Received: (qmail invoked by alias); 04 Sep 2007 14:24:56 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp032) with SMTP; 04 Sep 2007 16:24:56 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/HP61R97vHd9hJpwCrc99ZW6qeGg44vFBZ3tZB4Q PHsZ5CzrwDEkh9 Message-ID: <46DD6ABA.5060104@gmx.net> Date: Tue, 04 Sep 2007 16:24:58 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna References: <46B04C06.3040002@gmx.net> <6FC4416DDE56C44DA0AEE67BC7CA4371167EE49B@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371167EE49B@zrc2hxm2.corp.nortel.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: dce614827510b4050294eeec86a3642d Cc: dime@ietf.org Subject: [Dime] Re: Diameter Mobile IPv6: HA<->AAA Draft Reviewers 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, thanks for your review. Please find a few comments below: Ahmad Muhanna wrote: > Hi Hannes, > > My apologies for not doing this on time. I have not read the comments by > Jouni or others, but please find my comments inline. I actually cut and > pasted the whole (almost) draft and inserted my comments which clearly > identified. > > Best Regards, > Ahmad Muhanna > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > Abstract > > Mobile IPv6 deployments may want to bootstrap their operations > dynamically based on an interaction between the Home Agent and the > Diameter server of the Mobile Service Provider (MSP). This document > specifies the interaction between a Mobile IP Home Agent and the > Diameter server. Two different mechanisms for authentication of a MN > to the HA are supported. The first method consists of performing the > Internet Key Exchange v2 (IKEv2) protocol along with the Extensible > Authentication Protocol (EAP) with the Diameter server, while the > second method utilizes the Mobile IPv6 Authentication option, as > defined in RFC 4285. For Internet Key Exchange v2 with EAP-based > authentication, the Diameter Mobile IPv6 application, defined in this > document, reuses the commands defined in the Diameter EAP > application, while for supporting the RFC 4285-style MIPv6 > Authentication Options, a new Diameter application and new command > codes are defined. > > [Ahmad-START-1] > May be the text of the last sentence needs to be fixed. It gives the > impression as if there are two different MIPv6 applications defined. The > new one for addressing RFC4285 authentication mechanism. > > [Ahmad-END-1] > Ok. > > 1. Introduction > > Performing the Mobile IPv6 protocol [1], requires the Mobile Node > (MN) to own a Home Address (HoA) and assignment of a Home Agent (HA) > to MN. The MN needs to register its Mobile IPv6 session with the HA > in order facilitate its reachability and mobility, when away from > home. The registration process itself requires establishment of > IPsec security associations (SA) and cryptographic material between > the MN and HA. Providing the collection of home address, HA address > and keying material to establish the IP SA is generaally referred to > > [Ahmad-START-2] > replace IP with IPsec. and generaally is missspeled. > > [Ahmad-END-2] > Ok. > as the Mobile IPv6 bootstrapping problem [reference to RFC4640]. The > purpose of this specification is to provide Diameter support for such > bootstrapping in a split scenario [2] in a manner that satisfies the > requirements defined in [13]. > > From an operator (mobility service provider, MSP) perspective, it is > important to verify that the MN is authenticated and authorized to > utilize Mobile IPv6 service and that such services are accounted for. > Only when the MN is authenticated and authorized, the MSP allows the > boostrapping of Mobile IPv6 parameters at the MN and HA. Thus, prior > to processing the Mobile IPv6 service requests, the HA, participates > in the authentication of the MN to verify the MN's identity. The HA > also participates in the Mobile IPv6 authorization process involving > the Diameter infrastrucure. The HA due to its role in traffic > forwarding, also performs accounting for the Mobile IPv6 service > provided to the MN. > > Mobile IPv6 specifications allow two different methods for MN > authentication, one based on IKEv2 and EAP [3], and another based on > the Mobile IPv6 Authentication Option [4]. The goal of this document > is to specify the Diameter procedures associated with the Mobile IPv6 > bootstrapping between the HA and the Diameter server for these two > Mobile IP authentication approaches. > > For that reason the Diameter Mobile IPv6 application provides two > different sets of commands. The first set of commands reuse the > command already define in Diameter EAP application (though using the > Diameter Mobile IPv6 Application-Id), > > [Ahmad-START-3] > Basically any node which supports the new MIPv6 Application MUST support > Diameter EAP application, MIP6 Application using EAP commands, and MIPv6 > Application using RFC4285 mechanism. Right? > > [Ahmad-END-3] > You need to differentiate between the different entities. Let us do that for a second: * Requirements for the AAA Server If the AAA server has to serve clients that use various different forms of authentication then the AAA server needs to support all mechanisms provided in the document. * Requirements for the Home Agent If the Home Agent expects only messages that are authenticated in a particular fashion then it only needs to support the respective subset of the document. Does this make sense? > while the second set of > commands are new for Diameter and provide support the Mobile IPv6 > Authentication Option, defined in RFC 4285. > > For authorization signaling and management of Mobile IPv6 session for > the MN, this specification will use the existing procedures from base > Diameter specification [5]. > > [Ahmad-START-4] > This is not clear to me. May be I am missing something. Do we need > further explanation and details here? > When this authentication is invoked? > > [Ahmad-END-4] > I guess it would not hurt to replace this sentence since the text about authorization and session management is later in the text anyway. > For accounting of Mobile IPv6 services provided to the MN, this > specification uses the accounting application defined in [5]. > > > 4. Overview > > One task of the Mobile IPv6 bootstrapping procedure is to assign an > appropriate HA to the MN. Furthermore, authorization and successful > delivery of Mobile IPv6 to a MN through a HA, requires the HA to act > as a client to the Diameter infrastructure interconnecting it to the > MSP. As a Diameter client, the HA needs to perform the following > operations: > > Authentication: Asserting or helping in assertion of the correctness > of the MN identity. As a Diameter client supporting the new > Diameter Mobile IPv6 application, the HA may need to support two > different types of authentication by supporting the different > command sets that are required for each authentication method. > > Authorization: The HA must verify that the user is authorized to use > the Mobile IPv6 service using the assistance of the MSP Diameter > servers. This is accomplised through use of new Diameter commands > specifically designed for performing Mobile IPv6 authorization > decisions. This document defines these commands and requires the > HA to support use of these authorization commands and to > participate in this authorization signaling. > > [Ahmad-START-5] > > We discussed before that AUTHORIZATION for ROUTE OPTIMIZATION is needed. > I did not see it included here?! As we discussed last time, operators do > care about having control over the willingness of the MN to have route > optimization. If that the case, then there should be a process to enable > that kind of authorization. No? > > [Ahmad-END-5] > Hmmm. Let me send a mail to the group specifically about this issue. > Accounting: For billing purposes and capacity planning, it is > required of the HA to provide accounting report to the Diameter > infrastructure and thus to support the related Diameter accounting > procedures. > > > Figure 1 depicts the architecture. > > > +---------------------------+ +-----------------+ > |Visited MSP | | Home MSP/MSA | > | | | | > | | | | > | +--------+ | | +--------+ | > | |Local | Diameter | | |Home | | > | |Diameter|<---------------------->|Diameter| | > | |Proxy | | | |Server | | > | +--------+ | | +--------+ | > | ^ | | ^ | > | | | | | | > | | Diameter | |Diameter| | > | v | | v | > | +-------+ | | +-------+ | > | |Home | | | |Home | | > | |Agent | | | |Agent | | > | +-------+ | | +-------+ | > | ^ | | ^ | > +-----|---------------------+ +--------|--------+ > | | > | | > | +---------+ | > | | Mobile | | > +--------->| Node |<-----------+ > IKEv2 or RFC 4285 +---------+ IKEv2 or RFC 4285 > > Figure 1: Architecture Overview > > [Editor's Note: A description of the relationship with the front-end > protocols is needed.] > > > 5. Protocol Description > > 5.1. Support for Mobile IPv6 with IKEv2 and IPsec > > The use of IKEv2 between the MN and the HA allows the HA to > authenticate the MN. When EAP is used with IKEv2, the Diameter EAP > application, as defined in [8], is re-used. AVPs specific to Mobile > IPv6 bootstrapping are added to this command. > > Figure 2 shows the message flow involved during the authentication > phase when EAP is used. > > > Mobile Home Diameter > Node Agent Server > ------ ----- -------- > IKE_SA_INIT (1,2) > <------------------------------> > > HDR, SK{IDi,[CERTREQ,] [IDr,] > [CP(CFG_REQUEST),] > SAi2, TSi, TSr} (3) > -------------------------------> > DER (EAP-Response) (4) > ------------------------> > DEA (EAP-Request) (5) > <------------------------ > HDR, SK {IDr, [CERT,] AUTH, > EAP } > <------------------------------- > HDR, SK {EAP} > --------------------------------> > DER (EAP-Response) > ------------------------> > DEA (EAP-Request) > <------------------------ > HDR, SK{EAP-Request} > <------------------------------- > HDR, SK{EAP-Response} > --------------------------------> > DER (EAP-Response) > ------------------------> > ... ... > > DEA (EAP-Success) > <------------------------ > HDR, SK{EAP-Success} > <------------------------------- > HDR, SK{AUTH} > -------------------------------> > HDR, SK {AUTH, [CP(CFG_REPLY,] SAr2, TSi, TSr } > <------------------------------- > > Figure 2: IKEv2 Diameter EAP Message Flow > > The MN and the HA start the interaction with an IKE_SA_INIT exchange. > In this phase cryptographic algorithms are negotiated, nonces and > Diffie-Hellman parameters are exchanged. Message (3) starts the > IKE_AUTH phase. This second phase authenticates the previous > messages, exchanges identities and certificates and establishes the > first CHILD_SA. It is used to mutually authenticate the MN (acting > as an IKEv2 Initiator) and the HA (acting as an IKEv2 Responder). > The identity of the user/MN is provided in the IDi field. The MN > indicates its willingness to be authenticated via EAP by omitting the > AUTH field in message 3 (see [9]). > > As part of the authentication process, the MN MAY request a Home- > Address, a Home Prefix or suggests one, see [2], using a CFG_REQUEST > payload in the message 3. > > [Ahmad-START-6] > Does this sentence mean that the MN MAY request a HoA and A HNP or only > one? > > [Ahmad-END-6] > I replaced the sentence with a "may" rather than a "MAY" since this is anyway out-side the scope of this document. This is the front-end story. > The HA extracts the IDi field from the message 3 and sends a > Diameter-EAP-Request (DER) message towards the authenticating > Diameter server. > > This message is routed to the MNs Diameter server/EAP server. The > Diameter server selects the EAP method and replies with the DEA > Message. Depending on the type of EAP method chosen, a number of DER > and DEA messages carry the method specific exchanges between the MN > and the Diameter server/EAP server. > > At the end of the EAP authentication phase, the Diameter server > indicates the result of the authentication in the Result-Code AVP and > provides the corresponding EAP packet (EAP Success or EAP Failure). > The last IKEv2 message sent by the HA contains the Home Address or > the Home Prefix. > > [Ahmad-START-7] > Here it is clear, that the end result is either the assignment of HoA or > HNP. NOT both. May be we need to fix the sentence under comment 6. > > [Ahmad-END-7] > I believe we should reduce this text to a minimum since this text talks about the content of this document: http://www.ietf.org/rfc/rfc4877.txt To answer your question: I believe both can be configured; not either or. > > In the latter case, a CREATE_CHILD_SA exchange is > necessary to setup IPsec SAs for Mobile IPv6 signalling. > > In some deployment scenario, the HA may also acts as a IKEv2 > Responder for IPsec VPN access. A problem in this case is that the > IKEv2 responder may not know if IK Ev2 is used for MIP6 service or > for IPsec VPN access. A network operator needs to be aware of this > limitation. > > 5.2. Support for the Mobile IPv6 Authentication Protocol > > Figure 3 describes the sequence of messages sent and received between > the MN, the HA and the Diameter server during the registration when > RFC 4285 is used. Binding Update (BU) and Binding Acknowledgement > (BA) messages are used in the registration process. This exchange > triggers the Diameter interaction. > > According to [4] the MN uses the Mobile Node Identifier Option, > specifically the MN-NAI mobility option as defined in [14] to > identify itself while authenticating with the HA. > > The MN may use the Message Identifier option for additional replay > protection. > > [Ahmad-START-8] > 1. Why we are calling it Message Identifier Option, Should not we refer > to it as Mobility Message Replay Protection Option as per RFC4285. > I naively copied it from http://tools.ietf.org/html/draft-ietf-mip6-rfc4285bis-00 in the expectation that the figure there would be correct. I was wrong :-) > 2. RFC4285 DID NOT mandate the use of this option for replay protection > assuming that Sequence Number is good enough for offering replay > protection. I believe sequence number as per RFC3775 is lacking a > complete replay protection and it relies on IPsec with IKEv2 to provide > a reliable replay protection mechanism. Since RFC4285 is similar to > RFC3344 of Mobile IPv4, then I would recommend mandating the use of this > option for replay protection whenever RFC4285 is used as an > authentication protocol. > I agree with you since there is a piece missing compared to the MIPv4 solution when sequence numbers are used, namely the resynchronization part. > [Ahmad-END-8] > > The authentication option may be used by the MN to > transfer authentication data when the MN and the HA are utilizing a > mobility SPI. > > > [Ahmad-START-9] > This needs more details. What does the MN and the HA are utilizing a > mobility SPI. Where is that SPI is coming from. i.e. Is it already > configured, or do we mean the MN-AAA Authentication option reserved SPI > value? > > Some more clarification is needed. > [Ahmad-END-9] > I deleted this sentence. Problem solved. > The BU initiates a MIP6-Request-Message to the Diameter server and > the corresponding response is carried in a MIP6-Answer-Message. > > [Ahmad-START-10] > Why Diameter is not part of the message name? I suggest the following > naming: > Diameter-MIP6-Request message and Diameter-MIP6-Answer message. > > [Ahmad-END-10] > There is no required to put Diameter into the name of a Command. We can, however, do it. It just makes the name longer. > Mobile Home AAA > Node Agent Server > | | | > | | | > | Binding Update |MIP6-Request-Message | > (a)|------------------------------------>|-------------------->| > | (including MN-ID option, | | > | Message ID option [optional], | | > | authentication option) | | > | | | > | | | > | Binding Acknowledgement |MIP6-Answer-Message | > (b)|<------------------------------------|<--------------------| > | (including MN-ID option, | (MN-HA key) | > | Message ID option [optional], | | > | authentication option) | | > > Figure 3: MIPv6 Bootstrapping using RFC 4285 > > [Ahmad-START-11] > what are all the remaining information that is received from the > Diameter Server. This only highlight MN-HA key. is that all what is > returned? > There is much more returned. We just didn't want to overload the figure since there are a number of AVPs that need to be exchanged. > This Figure needs to be updated with proper naming of the authentication > option and all other parameters, or a detailed explanation of these > steps is required. > Done. Please also do it in the revision of the Authentication Protocol draft. > [Ahmad-END-11] > > 5.3. Mobile IPv6 Session Management > > The Diameter server may maintain state or may be stateless. This is > indicated in the Auth-Session-State AVP (or its absence). The HA > MUST support the Authorization Session State Machine defined in [5]. > Moreover the following 4 commands may be exchanged between the HA and > the Diameter server. > > 5.3.1. Session-Termination-Request Command > > The Session-Termination-Request (STR) message [5] is sent by the HA > to inform the Diameter server that an authorized session is being > terminated. > > > 5.3.2. Session-Termination-Answer Command > > The Session-Termination-Answer (STA) message [5] is sent by the > Diameter server to acknowledge the notification that the session has > been terminated. > > 5.3.3. Abort-Session-Request Command > > The Abort-Session-Request (ASR) message [5] is sent by the Diameter > server to terminates the session. This fulfills one of the > requirement described in [13]. > > 5.3.4. Abort-Session-Answer Command > > The Abort-Session-Answer (ASA) message [5] is sent by the Home Agent > in response to an ASR message. > > 5.4. Accounting for Mobile IPv6 services > > The HA MUST be able act as a Diameter client collecting accounting > records needed for service control and charging. The HA MUST support > the accounting procedures (specifically the command codes mentioned > below) and the Accounting Session State Machine as defined in [5]. > The command codes, exchanged between the HA and Diameter server for > accounting purposes, are provided in the following subsections. > > The Diameter application design guideline [15] defines two separate > model for accounting: > > Split accounting model: > > According to this model, the accounting messages use the Diameter > base accounting application ID (value of 3). Since accounting is > treated as an independent application, accounting commands may be > routed separately from the rest of application messages and thus > the accounting messages generally end up in a central accounting > server. Since Diameter Mobile IPv6 application does not define > its own unique accounting commands, this is the prefered choice, > since it permits use of centralized accounting for several > applications. > > Coupled accounting model: > > In this model, the accounting messages will use the application ID > of the Mobile IPv6 application. This means that accounting > messages will be routed like any other Mobile IPv6 application > messages. This requires the Diameter server in charge of Mobile > IPv6 application to handle the accounting records (e.g., sends > them to a proper accounting server).. > > As mentioned above, the prefered choice is to use the split > accounting model and thus choose Diameter base accounting application > ID (value of 3) for accounting messages. > > 5.4.1. Accounting-Request Command > > The Accounting-Request command [5] is sent by the HA to the Diameter > server to exchange accounting information regarding the MN with the > Diameter server. > > 5.4.2. Accounting-Answer Command > > The Accounting-Answer command [5] is sent by the Diameter server to > the HA to acknowledge receiving an Accounting-Request. > > > 6. Command-Code and AVP Values > > The following commands are defined in this section: > > > Command-Name Abbrev. Code Reference Application > ---------------------------------------------------------------------- > MIP6-Request-Message MRM XXX TBD MIP6 > MIP6-Answer-Message MAM XXX TBD MIP6 > > Figure 4: New Command Codes > > The following defines the command codes used by the Diameter Mobile > IPv6 application: > > > Command-Name Abbrev. Code Reference Application > ---------------------------------------------------------------------- > Diameter-EAP-Request DER 268 RFC 4072 EAP > Diameter-EAP-Answer DEA 268 RFC 4072 EAP > MIP6-Request-Message MRM XXX TBD MIP6 > MIP6-Answer-Message MAM XXX TBD MIP6 > Session-Termination-Request STR 275 RFC 3588 BASE > Session-Termination-Answer STA 275 RFC 3588 BASE > Abort-Session-Request ASR 275 RFC 3588 BASE > Abort-Session-Answer ASA 275 RFC 3588 BASE > Accounting-Request ACR 271 RFC 3588 BASE > Accounting-Answer ACA 271 RFC 3588 BASE > > > Figure 5: Command Codes > > 6.1. Command Code for EAP-based Authentication > > This document re-uses the Diameter EAP application commands. The > following commands are used to carry MIPv6 related bootstrapping > AVPs: > > > Command-Name Abbrev. Code Reference Application > ------------------------------------------------------------------ > Diameter-EAP-Request DER 268 RFC 4072 EAP > Diameter-EAP-Answer DEA 268 RFC 4072 EAP > > Figure 6: Diameter EAP command codes used for MIPv6 Bootstrapping HA > to HAAA Interface > > 6.1.1. Diameter-EAP-Request (DER) > > The Diameter-EAP-Request (DER) message [8], indicated by the Command- > Code field set to 268 and the 'R' bit set in the Command Flags field, > is sent by the HA to the Diameter server to initiate a Mobile IPv6 > service authentication and authorization procedure. The DER message > format is the same as defined in [8]. The Application-ID field of > the Diameter Header MUST be set to the Diameter Mobile IPv6 > Application ID [TO BE ASSIGNED TO IANA]. > > > ::= < Diameter Header: 268, REQ, PXY > > < Session-Id > > { Auth-Application-Id } > { Origin-Host } > { Origin-Realm } > { Destination-Realm } > { Auth-Request-Type } > [ Destination-Host ] > [ NAS-Identifier ] > [ NAS-IP-Address ] > [ NAS-IPv6-Address ] > [ NAS-Port-Type ] > [ User-Name ] > { EAP-Payload } > > [ MIP6-Feature-Vector ] > [ MIP-Mobile-Node-Address ] > > ... > * [ AVP ] > > 6.1.2. Diameter-EAP-Answer (DEA) > > The Diameter-EAP-Answer (DEA) message defined in [8], indicated by > the Command-Code field set to 268 and 'R' bit cleared in the Command > Flags field, is sent in response to the Diameter-EAP-Request message > (DER). If the Mobile IPv6 authentication procedure was successful > then the response MAY include any set of bootstrapping AVPs. > > The DEA message format is the same as defined in [8]. The > Application-Id field in the Diameter header MUST be set to the > Diameter Mobile IPv6 Application-Id [TO BE ASSIGNED BY IANA]. > > > ::= < Diameter Header: 268, PXY > > < Session-Id > > { Auth-Application-Id } > { Auth-Request-Type } > { Result-Code } > { Origin-Host } > { Origin-Realm } > > [ User-Name ] > { EAP-Payload } > [ Authorization-Lifetime ] > > [ MIP-Mobile-Node-Address ] > [ MIP6-Feature-Vector ] > > ... > * [ AVP ] > > 6.2. Command Codes for RFC 4285 Support > > This section defines Command-Code [5] values that MUST be supported > by all Diameter implementations conforming to this specification. > The following Command Codes are defined in this specification. > > > Command-Name Abbreviation Code Section > ------------------------------------------------------------------ > MIP6-Request-Message MRM TBD Section 6.2.1 > MIP6-Answer-Message MAM TBD Section 6.2.2 > > 6.2.1. MIP6-Request-Message > > The MIP6-Request-Message (MRM), indicated by the Command-Code field > set to TBD and the 'R' bit set in the Command Flags field, is sent by > the HA, acting as a Diameter client, in order to request the > authentication and authorization of a MN. The HA uses information > found in the Binding Update to construct the following AVPs, to be > included as part of the MRM: > > o Home Address (MIP-Mobile-Node-Address AVP) > > o Mobile Node NAI (User-Name AVP [5]) > > o MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP) > > [Ahmad-START-12] > Should not we call it MN-AAA Message Mobility Authentication Option? Or > at least reference that in an explicit text. > > [Ahmad-END-12] > As I indicated in my mail to the group about the next steps we need to change the content of this AVP and hence it would be much better to replace it entirely. It will obviously get a new name as well. > If the MN's home address is zero, the HA MUST NOT include a MIP- > Mobile-Node-Address AVP. > > If the MN's home address is all ones, the HA MUST include a MIP- > Mobile-Node-Address AVP, set to all ones. > > > [Ahmad-START-13] > > As per this draft it says: > " The BU initiates a MIP6-Request-Message to the Diameter server and > the corresponding response is carried in a MIP6-Answer-Message. > " > > What is in the BU as per RFC4285 which indicates to the HA which value > to use inside Mobile-Node-Address AVP as listed above? > > [Ahmad-END-13] > Good point. I think this aspect is undefined, if I recall it correctly. > > > The message format is shown below: > > > ::= < Diameter Header: XXX, REQ, PXY > > < Session-ID > > { Auth-Application-Id } > { User-Name } > { Destination-Realm } > { Origin-Host } > { Origin-Realm } > [ Acct-Multi-Session-Id ] > [ Destination-Host ] > [ Origin-State-Id ] > [ NAS-Identifier ] > [ NAS-IP-Address ] > [ NAS-IPv6-Address ] > [NAS-Port-Type] > > [ MIP6-Feature-Vector ] > [ MIP-MN-AAA-Auth ] > [ MIP-Mobile-Node-Address ] > > [ Authorization-Lifetime ] > [ Auth-Session-State ] > * [ Proxy-Info ] > * [ Route-Record ] > * [ AVP ] > > 6.2.2. MIP6-Answer-Message > > The MIP6-Answer-Message (MAM) message, indicated by the Command-Code > field set to TBD and the 'R' bit cleared in the Command Flags field, > is sent by the Diameter server in response to the MIP6-Request- > Message message. The User-Name MAY be included in the MAM if it is > present in the MRM. The Result-Code AVP MAY contain one of the > values defined in Section 6.2.3.2, in addition to the values defined > in RFC 3588 [5]. > > An MAM message with the Result-Code AVP set to DIAMETER_SUCCESS MUST > include the MIP-Mobile-Node-Address AVP. The MIP-Home-Agent-Address > > AVP contains the HA assigned to the MN, > > [Ahmad-START-14] > > What is the MIP-Home-Agent-Address has to do here? Is that supposed to > be inside the MAM? > > [Ahmad-END-14] > I deleted this sentence since the HA is not distributed in the MAM given that the MN has to interact with the Home Agent in the first place. > while the MIP-Mobile-Node- > Address AVP contains the home address that was assigned. > > The message format is shown below: > > > ::= < Diameter Header: XXX, PXY > > < Session-Id > > { Auth-Application-Id } > { Result-Code } > { Origin-Host } > { Origin-Realm } > [ Acct-Multi-Session-Id ] > [ User-Name ] > [ Authorization-Lifetime ] > [ Auth-Session-State ] > [ Error-Message ] > [ Error-Reporting-Host ] > [ Re-Auth-Request-Type ] > > [ MIP6-Feature-Vector ] > [ MIP-MN-to-HA-MSA ] > [ MIP-HA-to-MN-MSA ] > [ MIP-MSA-Lifetime ] > [ MIP-Session-Key] > [ MIP-Mobile-Node-Address ] > * [ MIP-Filter-Rule ] > > [Ahmad-START-15] > Why do we need to have two different MSAs? MN-HA and HA-MN MSA? > Are we using these AVP as per RFC4004? which was designed for MIPv4 > Application? > Yes. We re-use these AVPs and these guys just used two different AVPs. > How the information is communicated back to the MN? > The key is not transported -- a key derivation technique is used. > What this MIP-Session-Key is used for? Is it needed here? > > [Ahmad-END-15] > > > [ Origin-State-Id ] > * [ Proxy-Info ] > * [ AVP ] > > [Editor's Note: The MIP-Filter-Rule is based on IPFiltrRule, which is > currently being revised. Hence, this document should refer to the > updated functionality. Furthermore, the requirements document > indicates that QoS parameters may need to conveyed to the HA. Hence, > the revised version of the QoS-Filter-Rule / QoSFilterRule being > developed with [10] has to be used.] > > 6.2.3. Diameter AVPs > > The Diameter client uses AVPs dependent on the usage of RFC 4285 [4] > or RFC 4877 [3]. > > To provide support for RFC 4285 [4] the following AVPs defined in > [11] are reused in this application: > > o MIP-HA-to-MN-MSA AVP, > o MIP-MN-to-HA-MSA AVP, > o MIP-Session-Key AVP > o MIP-Algorithm-Type AVP > o MIP-Replay-Mode AVP > > [Ahmad-START-16] > > What are the supported replay protection modes in MIPv6 Application? > What kind of mode reference the sequence number?, for example. > > [Ahmad-END-16] > To me it seems that the timestamp based replay protection technique is the only one that can be used at the moment. But there is a chance that people come up with something new in the future. > o MIP-MN-AAA-Auth AVP > o MIP-MN-AAA-SPI AVP > o MIP-Auth-Input-Data-Length AVP > o MIP-Authenticator-Length AVP > o MIP-Authenticator-Offset AVP > o MIP-MSA-Lifetime AVP > o MIP-Mobile-Node-Address (with an IPv6 address) > > [Ahmad-START-17] > > I have not seen how some of these AVPS are used in Diameter MIPv6 > Application which is supposedly defined in this document? > > Do we expect those AVPs to be used exactly as per RFC4004? If that the > case, should that be specified wherever applicable in this application? > > [Ahmad-END-17] > These AVPs are extracted from RFC 4004. I suggested to copy the corresponding text from RFC 4004 (with a few modifications where necessary). Ciao Hannes > > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Wednesday, August 01, 2007 4:02 AM >> To: dime@ietf.org >> Cc: Muhanna, Ahmad (RICH1:2H10); Jouni Korhonen >> Subject: Diameter Mobile IPv6: HA<->AAA Draft Reviewers >> >> I would like to thank >> >> * Jouni Korhonen >> * Ahmad Muhanna >> >> for their willingness to review the Diameter Mobile IPv6: >> HA<->AAA draft within the next 2 weeks. >> >> Ciao >> Hannes >> >> >> >> _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 04 11:01:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISZu1-0004DG-DU; Tue, 04 Sep 2007 11:01:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISZtz-0004Ce-NE for dime@ietf.org; Tue, 04 Sep 2007 11:01:15 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISZty-0003nN-GK for dime@ietf.org; Tue, 04 Sep 2007 11:01:15 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l84F1B615627; Tue, 4 Sep 2007 15:01:11 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 Date: Tue, 4 Sep 2007 10:01:08 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371168652B9@zrc2hxm2.corp.nortel.com> In-Reply-To: <46DD6ABA.5060104@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter Mobile IPv6: HA<->AAA Draft Reviewers Thread-Index: Acfu/2YwAv6dXtKBSn+1F3t+QDL/DwAAq5kg References: <46B04C06.3040002@gmx.net> <6FC4416DDE56C44DA0AEE67BC7CA4371167EE49B@zrc2hxm2.corp.nortel.com> <46DD6ABA.5060104@gmx.net> From: "Ahmad Muhanna" To: "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: dime@ietf.org Subject: [Dime] RE: Diameter Mobile IPv6: HA<->AAA Draft Reviewers 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 =20 Thanks Hannes, Minor comments inline. Regards, Ahmad > > > > [Ahmad-START-3] > > Basically any node which supports the new MIPv6 Application MUST=20 > > support Diameter EAP application, MIP6 Application using=20 > EAP commands,=20 > > and MIPv6 Application using RFC4285 mechanism. Right? > > > > [Ahmad-END-3] > > =20 > You need to differentiate between the different entities. Let=20 > us do that for a second: >=20 > * Requirements for the AAA Server >=20 > If the AAA server has to serve clients that use various=20 > different forms of authentication then the AAA server needs=20 > to support all mechanisms provided in the document. >=20 > * Requirements for the Home Agent >=20 > If the Home Agent expects only messages that are=20 > authenticated in a particular fashion then it only needs to=20 > support the respective subset of the document. >=20 >=20 > Does this make sense? {Ahmad] I agree. I should have identified which entity I am talking about, I meant the AAA server.=20 But probably it is a good idea to capture some text in the draft. >=20 > > while the second set of > > commands are new for Diameter and provide support the Mobile IPv6 > > Authentication Option, defined in RFC 4285. > > > > For authorization signaling and management of Mobile=20 > IPv6 session for > > the MN, this specification will use the existing=20 > procedures from base > > Diameter specification [5]. > > > > [Ahmad-START-4] > > This is not clear to me. May be I am missing something. Do we need=20 > > further explanation and details here? > > When this authentication is invoked? > > > > [Ahmad-END-4] > > =20 > I guess it would not hurt to replace this sentence since the=20 > text about authorization and session management is later in=20 > the text anyway. >=20 >=20 > > For accounting of Mobile IPv6 services provided to the MN, this > > specification uses the accounting application defined in [5]. > > > > > > > > [Ahmad-END-5] > > =20 >=20 > Hmmm. Let me send a mail to the group specifically about this issue. [Ahmad] Thanks! > > > > As part of the authentication process, the MN MAY request a Home- > > Address, a Home Prefix or suggests one, see [2], using a=20 > CFG_REQUEST > > payload in the message 3. > > > > [Ahmad-START-6] > > Does this sentence mean that the MN MAY request a HoA and A=20 > HNP or only > > one? > > > > [Ahmad-END-6] > > =20 > I replaced the sentence with a "may" rather than a "MAY"=20 > since this is=20 > anyway out-side the scope of this document. This is the=20 > front-end story. [Ahmad] Ok. > > > > > > [Ahmad-START-9] > > This needs more details. What does the MN and the HA are utilizing a > > mobility SPI. Where is that SPI is coming from. i.e. Is it already > > configured, or do we mean the MN-AAA Authentication option=20 > reserved SPI > > value? > > > > Some more clarification is needed. > > [Ahmad-END-9] > > =20 >=20 > I deleted this sentence. Problem solved. [Ahmad] Ok. > > > > [Ahmad-START-15] > > Why do we need to have two different MSAs? MN-HA and HA-MN MSA? > > Are we using these AVP as per RFC4004? which was designed for MIPv4 > > Application? > > =20 > Yes. We re-use these AVPs and these guys just used two different AVPs. >=20 > > How the information is communicated back to the MN? > > =20 > The key is not transported -- a key derivation technique is used. >=20 [Ahmad] Is that derivation already defined any where? Also, what about the SPI values, are they also derived? > > What this MIP-Session-Key is used for? Is it needed here? > > > > [Ahmad-END-15] > > > > > > [ Origin-State-Id ] > > * [ Proxy-Info ] > > * [ AVP ] > > > > [Editor's Note: The MIP-Filter-Rule is based on=20 > IPFiltrRule, which is > > currently being revised. Hence, this document should=20 > refer to the > > updated functionality. Furthermore, the requirements document > > indicates that QoS parameters may need to conveyed to=20 > the HA. Hence, > > the revised version of the QoS-Filter-Rule / QoSFilterRule being > > developed with [10] has to be used.] > > > > 6.2.3. Diameter AVPs > > > > The Diameter client uses AVPs dependent on the usage of=20 > RFC 4285 [4] > > or RFC 4877 [3]. > > > > To provide support for RFC 4285 [4] the following AVPs defined in > > [11] are reused in this application: > > > > o MIP-HA-to-MN-MSA AVP, > > o MIP-MN-to-HA-MSA AVP, > > o MIP-Session-Key AVP > > o MIP-Algorithm-Type AVP > > o MIP-Replay-Mode AVP > > > > [Ahmad-START-16] > > > > What are the supported replay protection modes in MIPv6 Application? > > What kind of mode reference the sequence number?, for example. > > > > [Ahmad-END-16] > > =20 >=20 > To me it seems that the timestamp based replay protection=20 > technique is=20 > the only one that can be used at the moment. But there is a=20 > chance that=20 > people come up with something new in the future. [Ahmad] If that the case, let us make sure that we define that too.=20 I am sure this is pending approval of comments on MIP6 rgarding RFC4285bis. >=20 > Ciao > Hannes >=20 > > =20 > > > > =20 > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > >> Sent: Wednesday, August 01, 2007 4:02 AM > >> To: dime@ietf.org > >> Cc: Muhanna, Ahmad (RICH1:2H10); Jouni Korhonen > >> Subject: Diameter Mobile IPv6: HA<->AAA Draft Reviewers > >> > >> I would like to thank > >> > >> * Jouni Korhonen > >> * Ahmad Muhanna > >> > >> for their willingness to review the Diameter Mobile IPv6:=20 > >> HA<->AAA draft within the next 2 weeks. > >> > >> Ciao > >> Hannes > >> > >> > >> > >> =20 >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 04 11:17:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISa9y-0005Gl-AI; Tue, 04 Sep 2007 11:17:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISa9x-0005CG-Hs for dime@ietf.org; Tue, 04 Sep 2007 11:17:45 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISa9w-0003yR-NW for dime@ietf.org; Tue, 04 Sep 2007 11:17:45 -0400 Received: (qmail invoked by alias); 04 Sep 2007 15:17:43 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp036) with SMTP; 04 Sep 2007 17:17:43 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19Jj+MVIj9JCznh3/8qUll5rolqGnINZ8O4i7wBN1 nNPWilagJbf/nQ Message-ID: <46DD770D.7020105@gmx.net> Date: Tue, 04 Sep 2007 17:17:33 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna References: <46B04C06.3040002@gmx.net> <6FC4416DDE56C44DA0AEE67BC7CA4371167EE49B@zrc2hxm2.corp.nortel.com> <46DD6ABA.5060104@gmx.net> <6FC4416DDE56C44DA0AEE67BC7CA4371168652B9@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371168652B9@zrc2hxm2.corp.nortel.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: e1b0e72ff1bbd457ceef31828f216a86 Cc: dime@ietf.org Subject: [Dime] Re: Diameter Mobile IPv6: HA<->AAA Draft Reviewers 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, > > >>> [Ahmad-START-15] >>> Why do we need to have two different MSAs? MN-HA and HA-MN MSA? >>> Are we using these AVP as per RFC4004? which was designed for MIPv4 >>> Application? >>> >>> >> Yes. We re-use these AVPs and these guys just used two different AVPs. >> >> >>> How the information is communicated back to the MN? >>> >>> >> The key is not transported -- a key derivation technique is used. >> >> > > [Ahmad] > Is that derivation already defined any where? > A couple of SDOs did some work on it. The key derivation to some extend depends on the available credentials that are being used in a particular environment. > Also, what about the SPI values, are they also derived? > There are two SPIs: For the inbound direction at the HA side the HA or the AAA server needs to pick it. -- they don't need to be derived. > >>> What this MIP-Session-Key is used for? Is it needed here? >>> >>> [Ahmad-END-15] >>> >>> >>> [ Origin-State-Id ] >>> * [ Proxy-Info ] >>> * [ AVP ] >>> >>> [Editor's Note: The MIP-Filter-Rule is based on >>> >> IPFiltrRule, which is >> >>> currently being revised. Hence, this document should >>> >> refer to the >> >>> updated functionality. Furthermore, the requirements document >>> indicates that QoS parameters may need to conveyed to >>> >> the HA. Hence, >> >>> the revised version of the QoS-Filter-Rule / QoSFilterRule being >>> developed with [10] has to be used.] >>> >>> 6.2.3. Diameter AVPs >>> >>> The Diameter client uses AVPs dependent on the usage of >>> >> RFC 4285 [4] >> >>> or RFC 4877 [3]. >>> >>> To provide support for RFC 4285 [4] the following AVPs defined in >>> [11] are reused in this application: >>> >>> o MIP-HA-to-MN-MSA AVP, >>> o MIP-MN-to-HA-MSA AVP, >>> o MIP-Session-Key AVP >>> o MIP-Algorithm-Type AVP >>> o MIP-Replay-Mode AVP >>> >>> [Ahmad-START-16] >>> >>> What are the supported replay protection modes in MIPv6 Application? >>> What kind of mode reference the sequence number?, for example. >>> >>> [Ahmad-END-16] >>> >>> >> To me it seems that the timestamp based replay protection >> technique is >> the only one that can be used at the moment. But there is a >> chance that >> people come up with something new in the future. >> > > [Ahmad] > If that the case, let us make sure that we define that too. > I am sure this is pending approval of comments on MIP6 rgarding > RFC4285bis. > RFC 4285 already specifies this timestamp but the backend infrastructure need to carry it as well. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 04 11:37:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISaT9-0004JX-MI; Tue, 04 Sep 2007 11:37:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISaT8-0004JR-IO for dime@ietf.org; Tue, 04 Sep 2007 11:37:34 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISaT8-0004bb-6G for dime@ietf.org; Tue, 04 Sep 2007 11:37:34 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l84FZIu06571; Tue, 4 Sep 2007 15:35:18 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 Date: Tue, 4 Sep 2007 10:37:28 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116865489@zrc2hxm2.corp.nortel.com> In-Reply-To: <46DD770D.7020105@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter Mobile IPv6: HA<->AAA Draft Reviewers Thread-Index: AcfvBr+5Z9laJTRWSqaoP6RxzVjHxAAAB4AQ References: <46B04C06.3040002@gmx.net> <6FC4416DDE56C44DA0AEE67BC7CA4371167EE49B@zrc2hxm2.corp.nortel.com> <46DD6ABA.5060104@gmx.net> <6FC4416DDE56C44DA0AEE67BC7CA4371168652B9@zrc2hxm2.corp.nortel.com> <46DD770D.7020105@gmx.net> From: "Ahmad Muhanna" To: "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: dime@ietf.org Subject: [Dime] RE: Diameter Mobile IPv6: HA<->AAA Draft Reviewers 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, > > > > [Ahmad] > > Is that derivation already defined any where? > > =20 > A couple of SDOs did some work on it. The key derivation to=20 > some extend depends on the available credentials that are=20 > being used in a particular environment. > > Also, what about the SPI values, are they also derived? > > =20 > There are two SPIs: For the inbound direction at the HA side=20 > the HA or the AAA server needs to pick it. -- they don't=20 > need to be derived. [Ahmad] What about the MN side? In other words, How these SPIs are communicated back to the MN? >=20 > > =20 > >>> What this MIP-Session-Key is used for? Is it needed here? > >>> > >>> [Ahmad-END-15] > >> =20 > > > > [Ahmad] > > If that the case, let us make sure that we define that too.=20 > > I am sure this is pending approval of comments on MIP6 rgarding=20 > > RFC4285bis. > > =20 > RFC 4285 already specifies this timestamp but the backend=20 > infrastructure need to carry it as well. >=20 > Ciao > Hannes >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 04 12:00:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISapS-0005cm-Ia; Tue, 04 Sep 2007 12:00:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISapI-0005OI-Ag; Tue, 04 Sep 2007 12:00:28 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISapH-0005Sd-3A; Tue, 04 Sep 2007 12:00:28 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l84G0O622489; Tue, 4 Sep 2007 16:00:24 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 Date: Tue, 4 Sep 2007 11:00:18 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116865561@zrc2hxm2.corp.nortel.com> In-Reply-To: <46DD699F.3040108@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization Thread-Index: Acfu/r9GxvW1LaKDQ9mWY311vE+5dAADLEPw References: <46DD4BCA.8090200@gmx.net> <46DD51F6.6000209@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA43711686502E@zrc2hxm2.corp.nortel.com> <46DD699F.3040108@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Mobile IPv6 Mailing List , dime@ietf.org Subject: [Dime] RE: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization 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 Alex, Please see comments inline. Regards, Ahmad =20 >=20 > >> Finally, are you talking about AAA backend authorizing the=20 > MN or the=20 > >> CN to do RO? > >=20 > > [Ahmad] AAA infrastructure only can control the MN to have=20 > RO or not=20 > > and hence authorization is for the MN not the CN. >=20 > I'd like to identify first whether MN needs to do RO or not,=20 > and only then look at whether it needs to be authorized or not. >=20 > For your description, do you think that when MN attaches to a=20 > WiMax network's ASN and talks to an arbitrary CN on the=20 > Internet - will the MN-CN normal traffic go all the way to CSN first? [Ahmad] It depends. I assume we are talking about Client MIPv6 here.=20 In case the MN uses the HoA as a source IP address, I believe the traffic will go to the node which defends the HoA address; right? Now, if the MN can use its CoA as a source IP address, then traffic is not necessarily sent to the entity which defends the HoA, i.e. arbitrary CN in your case. I guess allowing the Home Network the option to force user traffic through the home network, IMO, makes a good business case and a flexibility for the operator to use for offering different service models.=20 I believe I am going beyond the technicality of the issue here; I hope I am correct.:-) =20 >=20 > Alex > ASN: Access Service Network > CSN: Connectivity Service Network >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 04 12:19:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISb7f-0006bl-23; Tue, 04 Sep 2007 12:19:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISb7d-0006Zk-DG; Tue, 04 Sep 2007 12:19:25 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ISb7c-0005yU-4b; Tue, 04 Sep 2007 12:19:25 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-128.messagelabs.com!1188922762!17152439!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 4984 invoked from network); 4 Sep 2007 16:19:23 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-128.messagelabs.com with SMTP; 4 Sep 2007 16:19:23 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l84GJM9w004275; Tue, 4 Sep 2007 09:19:22 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l84GJM5h021128; Tue, 4 Sep 2007 11:19:22 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l84GJJel021076; Tue, 4 Sep 2007 11:19:19 -0500 (CDT) Message-ID: <46DD8586.80201@gmail.com> Date: Tue, 04 Sep 2007 18:19:18 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna References: <46DD4BCA.8090200@gmx.net> <46DD51F6.6000209@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA43711686502E@zrc2hxm2.corp.nortel.com> <46DD699F.3040108@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116865561@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116865561@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000772-0, 03/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Mobile IPv6 Mailing List , dime@ietf.org Subject: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization 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 Ahmad Muhanna wrote: > Hi Alex, Please see comments inline. > > Regards, Ahmad > >>>> Finally, are you talking about AAA backend authorizing the >> MN or the >>>> CN to do RO? >>> [Ahmad] AAA infrastructure only can control the MN to have >> RO or not >>> and hence authorization is for the MN not the CN. >> I'd like to identify first whether MN needs to do RO or not, and >> only then look at whether it needs to be authorized or not. >> >> For your description, do you think that when MN attaches to a WiMax >> network's ASN and talks to an arbitrary CN on the Internet - will >> the MN-CN normal traffic go all the way to CSN first? > > [Ahmad] It depends. I assume we are talking about Client MIPv6 here. > In case the MN uses the HoA as a source IP address, I believe the > traffic will go to the node which defends the HoA address; right? I believe so... I think the entity defending that address is HA in CSN. > Now, if the MN can use its CoA as a source IP address, then traffic > is not necessarily sent to the entity which defends the HoA, i.e. > arbitrary CN in your case. Right, and in that case MN doesn't need RO at all (because CN doesn't use MN's HoA to talk to MN). > I guess allowing the Home Network the option to force user traffic > through the home network, IMO, makes a good business case and a > flexibility for the operator to use for offering different service > models. I believe I am going beyond the technicality of the issue > here; I hope I am correct.:-) That's what I'm not sure I understand: I'm not sure I understand the technicality of the mechanism: does the MN _need_ at all to run MIP6 RO HoT/I CoT/I when it uses a CoA instead of HoA... If it's realized that MN needs to do RO then obviously a mechanism for AAA to authorize RO service is necessary, IMHO. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 04 14:40:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdK5-0002zR-1i; Tue, 04 Sep 2007 14:40:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISd5p-0006Pk-60; Tue, 04 Sep 2007 14:25:41 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISd5n-0008Lc-NG; Tue, 04 Sep 2007 14:25:41 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l84IOpt5023920; Tue, 4 Sep 2007 21:25:36 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 21:25:14 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 13:25:11 -0500 Received: from 172.19.244.158 ([172.19.244.158]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Sep 2007 18:25:11 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 04 Sep 2007 13:25:37 -0500 From: Basavaraj Patil To: ext Hannes Tschofenig , , Mobile IPv6 Mailing List Message-ID: Thread-Topic: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization Thread-Index: AcfvIP09O9VE0FsUEdyuUQARJNUNiA== In-Reply-To: <46DD4BCA.8090200@gmx.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Sep 2007 18:25:11.0404 (UTC) FILETIME=[EDFBC2C0:01C7EF20] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Tue, 04 Sep 2007 14:40:24 -0400 Cc: Subject: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization 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 do not believe that the use of Route Optimization has to be authorized for an MN. If the MN is capable of RO and initiates RO signaling, there is no need for it to be authorized to do so. The concern mentioned below is that operators prefer to be in control of an MN. Since the HA is involved in the RO signaling, it can prevent the MN from establishing route-optimized sessions with CNs. -Raj On 9/4/07 7:12 AM, "ext Hannes Tschofenig" wrote: > Hi all, > > during his review of "Diameter Mobile IPv6: HA<->AAA" Ahmad made the following > comment: > >>>> > We discussed before that AUTHORIZATION for ROUTE OPTIMIZATION is needed. > I did not see it included here?! As we discussed last time, operators do > care about having control over the willingness of the MN to have route > optimization. If that the case, then there should be a process to enable > that kind of authorization. No? > <<< > > Does the group think that we need to provide any backend infrastructure > support to enable this type of functionality? > > Ciao > Hannes > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 04 14:40:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdK5-0002zV-6q; Tue, 04 Sep 2007 14:40:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISd98-0002sj-5m; Tue, 04 Sep 2007 14:29:06 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISd96-0008NK-UX; Tue, 04 Sep 2007 14:29:06 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l84ISqkB028084; Tue, 4 Sep 2007 21:28:57 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 21:28:52 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 13:28:44 -0500 Received: from 172.19.244.158 ([172.19.244.158]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Sep 2007 18:28:44 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 04 Sep 2007 13:29:10 -0500 From: Basavaraj Patil To: ext Ahmad Muhanna , Alexandru Petrescu , Hannes Tschofenig Message-ID: Thread-Topic: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization Thread-Index: Acfu8KfPqS9DfApyTDCXtM0NwPletQABBCfgAAsw8Tg= In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711686502E@zrc2hxm2.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Sep 2007 18:28:44.0292 (UTC) FILETIME=[6CDFE440:01C7EF21] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 X-Mailman-Approved-At: Tue, 04 Sep 2007 14:40:24 -0400 Cc: Mobile IPv6 Mailing List , dime@ietf.org Subject: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization 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, I am skeptical about the need for an MN being authorized to use an inherent feature of MIP6. It makes no sense for an MN to be authorized depending on the network that it is attached to whether it is able to use RO with CNs. -Raj On 9/4/07 8:57 AM, "ext Ahmad Muhanna" wrote: > Hi Alex, > > Just some background: > > The proposed Diameter MIPv6 Application is used to enable MIPv6 service > authorization + dynamic security association allocation. As per the > current application, the user is authorized for MIPv6 service without a > clear indication if the user is allowed to use Route Optimization or > not. Allowing the operator this flexibility makes a lot of sense. Let us > remember in order for the MN to establish a RO, it needs to have at > least HoTI and HoT signals transmitted via the HA which can act as the > authorization enforcement point. > > Of course, we are talking about a network which is controlled by AAA > infrastructure since the proposed application is for Diameter MIPv6. > > Also, please see comments inline. > > Regards, > Ahmad > > >> Subject: Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: >> Authorizing Route Optimization >> >> Hannes Tschofenig wrote: >>> Hi all, during his review of "Diameter Mobile IPv6: HA<->AAA" Ahmad >>> made the following comment: >>>>>> >>> We discussed before that AUTHORIZATION for ROUTE OPTIMIZATION is >>> needed. I did not see it included here?! As we discussed last time, >>> operators do care about having control over the willingness >> of the MN >>> to have route optimization. If that the case, then there >> should be a >>> process to enable that kind of authorization. No? <<< >>> >>> Does the group think that we need to provide any backend >>> infrastructure support to enable this type of functionality? >> >> Which group(s)? >> >> I think RO is designed to work across the entire Internet, >> not limited to a AAA-controlled domain. >> >> From tests, the benefits of running RO on the MN are >> apparent only when the distance MN-CN is much shorter than >> both MN-HA and CN-HA, in terms of IP hops. >> >> In a closed system, that equation is not valid, ie, MN is >> close to both CN and to its HA, and the benefits of running >> RO are minimal, one doesn't gain much at all. >> >> So, in first place I don't see why would a MN want to run RO >> at all while in a AAA-controlled (closed) domain. It may >> very well be that MN is not interested at all to run RO to a >> CN outside the AAA-controlled domain, because it wouldn't >> gain much. Then, even if MN would want to do that, I don't >> see why asking the local AAA to be authorized to perform RO. > > [Ahmad] > Are you assuming that the HA is always in the visited network? Also, > V-AAA does not communicate with H-AAA? > I just want to understand what you meant here. > Thanks. > >> >> Finally, are you talking about AAA backend authorizing the MN >> or the CN to do RO? > > [Ahmad] > AAA infrastructure only can control the MN to have RO or not and hence > authorization is for the MN not the CN. >> >> Alex >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 04 14:50:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdTz-00046l-8h; Tue, 04 Sep 2007 14:50:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdTw-00046I-ID; Tue, 04 Sep 2007 14:50:36 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISdTv-0000Jn-B9; Tue, 04 Sep 2007 14:50:36 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l84ImJu15812; Tue, 4 Sep 2007 18:48:20 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 Date: Tue, 4 Sep 2007 13:50:30 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116865AF0@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization Thread-Index: AcfvIP09O9VE0FsUEdyuUQARJNUNiAAALESA References: <46DD4BCA.8090200@gmx.net> From: "Ahmad Muhanna" To: "Basavaraj Patil" , "ext Hannes Tschofenig" , , "Mobile IPv6 Mailing List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Subject: [Dime] RE: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization 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 Raj, Please see comment inline. Regards, Ahmad =20 > Subject: Re: [Mip6] Diameter Mobile IPv6 Bootstrapping:=20 > Authorizing Route Optimization=20 >=20 > Hi Hannes, >=20 > I do not believe that the use of Route Optimization has to be=20 > authorized for an MN. If the MN is capable of RO and=20 > initiates RO signaling, there is no need for it to be=20 > authorized to do so. >=20 > The concern mentioned below is that operators prefer to be in=20 > control of an MN. Since the HA is involved in the RO=20 > signaling, it can prevent the MN from establishing=20 > route-optimized sessions with CNs. [Ahmad] MN may, by default, is authorized for RO as part of MIPv6 authorization. On the other hand, some other operators may deny RO by default too. However, an optional AVP to be returned in the MAM could make a big difference and make the solution much more flexible and cleaner and applicable on a per-user. As far as I know, at least one of the SDO's has have some discussion on disallowing RO by default. In summary, we either have a default authorization as part of MIPv6 for all users or RO is NOT authorized by default for all users. That is probably not the best choice. I believe we need to propose a solution which is flexible and operator can choose one of the extremes or a per-user authorization based on the operator service model. All what is needed here is an extra optional AVP. Do you think that is not worth it? On the other hand, if HA is used to block the HoIT/HoT messages, communicating that behavior to the HA can be based on a global policy, a per domain, or per-user. But, since HA is going to H-AAA anyway why do not we make that dynamic and supported as part of the Diameter MIPv6 Application. Best Regards, Ahmad >=20 > -Raj >=20 >=20 > On 9/4/07 7:12 AM, "ext Hannes Tschofenig" > wrote: >=20 > > Hi all, > >=20 > > during his review of "Diameter Mobile IPv6: HA<->AAA" Ahmad=20 > made the=20 > > following > > comment:=20 > >=20 > >>>>=20 > > We discussed before that AUTHORIZATION for ROUTE=20 > OPTIMIZATION is needed. > > I did not see it included here?! As we discussed last time,=20 > operators=20 > > do care about having control over the willingness of the MN to have=20 > > route optimization. If that the case, then there should be=20 > a process=20 > > to enable that kind of authorization. No? > > <<< > >=20 > > Does the group think that we need to provide any backend=20 > > infrastructure support to enable this type of functionality? > >=20 > > Ciao > > Hannes > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 04 15:34:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISeAT-0002Rc-TA; Tue, 04 Sep 2007 15:34:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISeAS-0002RL-7o for dime@ietf.org; Tue, 04 Sep 2007 15:34:32 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ISeAQ-0002Fn-MP for dime@ietf.org; Tue, 04 Sep 2007 15:34:32 -0400 Received: (qmail invoked by alias); 04 Sep 2007 19:34:29 -0000 Received: from p549846DC.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.70.220] by mail.gmx.net (mp029) with SMTP; 04 Sep 2007 21:34:29 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18bMilWqJMbmpoQhnXk9JOKnMHbAndzgTp+Nj7lAz 4VHQtRMzPamDKd Message-ID: <46DDB33C.10007@gmx.net> Date: Tue, 04 Sep 2007 21:34:20 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Basavaraj Patil 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: 2086112c730e13d5955355df27e3074b Cc: Mobile IPv6 Mailing List , dime@ietf.org Subject: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization 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 Raj, you raise a good point. There is no doubt that a network operator can prevent all end hosts from using the RO procedure. The main question therefore is whether the RO procedure has to enabled / disabled on a per user basis. Ciao Hannes Basavaraj Patil wrote: > Hi Ahmad, > > I am skeptical about the need for an MN being authorized to use an inherent > feature of MIP6. It makes no sense for an MN to be authorized depending on > the network that it is attached to whether it is able to use RO with CNs. > > -Raj > > > On 9/4/07 8:57 AM, "ext Ahmad Muhanna" wrote: > > >> Hi Alex, >> >> Just some background: >> >> The proposed Diameter MIPv6 Application is used to enable MIPv6 service >> authorization + dynamic security association allocation. As per the >> current application, the user is authorized for MIPv6 service without a >> clear indication if the user is allowed to use Route Optimization or >> not. Allowing the operator this flexibility makes a lot of sense. Let us >> remember in order for the MN to establish a RO, it needs to have at >> least HoTI and HoT signals transmitted via the HA which can act as the >> authorization enforcement point. >> >> Of course, we are talking about a network which is controlled by AAA >> infrastructure since the proposed application is for Diameter MIPv6. >> >> Also, please see comments inline. >> >> Regards, >> Ahmad >> >> >> >>> Subject: Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: >>> Authorizing Route Optimization >>> >>> Hannes Tschofenig wrote: >>> >>>> Hi all, during his review of "Diameter Mobile IPv6: HA<->AAA" Ahmad >>>> made the following comment: >>>> >>>> We discussed before that AUTHORIZATION for ROUTE OPTIMIZATION is >>>> needed. I did not see it included here?! As we discussed last time, >>>> operators do care about having control over the willingness >>>> >>> of the MN >>> >>>> to have route optimization. If that the case, then there >>>> >>> should be a >>> >>>> process to enable that kind of authorization. No? <<< >>>> >>>> Does the group think that we need to provide any backend >>>> infrastructure support to enable this type of functionality? >>>> >>> Which group(s)? >>> >>> I think RO is designed to work across the entire Internet, >>> not limited to a AAA-controlled domain. >>> >>> From tests, the benefits of running RO on the MN are >>> apparent only when the distance MN-CN is much shorter than >>> both MN-HA and CN-HA, in terms of IP hops. >>> >>> In a closed system, that equation is not valid, ie, MN is >>> close to both CN and to its HA, and the benefits of running >>> RO are minimal, one doesn't gain much at all. >>> >>> So, in first place I don't see why would a MN want to run RO >>> at all while in a AAA-controlled (closed) domain. It may >>> very well be that MN is not interested at all to run RO to a >>> CN outside the AAA-controlled domain, because it wouldn't >>> gain much. Then, even if MN would want to do that, I don't >>> see why asking the local AAA to be authorized to perform RO. >>> >> [Ahmad] >> Are you assuming that the HA is always in the visited network? Also, >> V-AAA does not communicate with H-AAA? >> I just want to understand what you meant here. >> Thanks. >> >> >>> Finally, are you talking about AAA backend authorizing the MN >>> or the CN to do RO? >>> >> [Ahmad] >> AAA infrastructure only can control the MN to have RO or not and hence >> authorization is for the MN not the CN. >> >>> Alex >>> >>> ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security System. >>> For more information please visit >>> http://www.messagelabs.com/email >>> ______________________________________________________________________ >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >>> >>> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 04 15:54:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISeU5-0006sy-P4; Tue, 04 Sep 2007 15:54:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISeU4-0006sX-35; Tue, 04 Sep 2007 15:54:48 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISeU2-00030q-Jd; Tue, 04 Sep 2007 15:54:48 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l84Js2mm031146; Tue, 4 Sep 2007 22:54:43 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 22:54:30 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 14:54:28 -0500 Received: from 172.19.244.158 ([172.19.244.158]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Sep 2007 19:54:28 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 04 Sep 2007 14:54:54 -0500 From: Basavaraj Patil To: ext Ahmad Muhanna , ext Hannes Tschofenig , , Mobile IPv6 Mailing List Message-ID: Thread-Topic: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization Thread-Index: AcfvIP09O9VE0FsUEdyuUQARJNUNiAAALESAAALx/b8= In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116865AF0@zrc2hxm2.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Sep 2007 19:54:28.0871 (UTC) FILETIME=[67485970:01C7EF2D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: Subject: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization 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, Comments inline: On 9/4/07 1:50 PM, "ext Ahmad Muhanna" wrote: > Hi Raj, > Please see comment inline. > > Regards, > Ahmad > > >> Subject: Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: >> Authorizing Route Optimization >> >> Hi Hannes, >> >> I do not believe that the use of Route Optimization has to be >> authorized for an MN. If the MN is capable of RO and >> initiates RO signaling, there is no need for it to be >> authorized to do so. >> >> The concern mentioned below is that operators prefer to be in >> control of an MN. Since the HA is involved in the RO >> signaling, it can prevent the MN from establishing >> route-optimized sessions with CNs. > > [Ahmad] > MN may, by default, is authorized for RO as part of MIPv6 authorization. > On the other hand, some other operators may deny RO by default too. Raj> Not sure what you mean by "other operators" above... Are you implying that the visited network that the MN is attached to does not permit the MN from using RO? Fundamentally, what is the reasoning for preventing route-optimization. I think there has not been any discussion about why RO should be blocked and in what specific scenarios. > However, an optional AVP to be returned in the MAM could make a big > difference and make the solution much more flexible and cleaner and > applicable on a per-user. As far as I know, at least one of the SDO's > has have some discussion on disallowing RO by default. Raj> I think the HA can even today is capable of denying RO on a per-MN granularity. I am just wondering what is the point of indicating to the MN whether RO is permitted or not. There has not been enough experience with RO and its implications. When is RO triggered by an MN for example? IMO it makes no sense to build blocking mechanisms for a feature that we do not have yet have better understanding. And what is the point of denying RO. The MN can just as well use the CoA and communicate directly with the CN. Session continuity does not exist in such a case. But if the point of the operator was to ensure that all traffic flows through the HA, that is already defeated via the CoA. > > In summary, we either have a default authorization as part of MIPv6 for > all users or RO is NOT authorized by default for all users. Raj> Whether RO can be achieved depends if the CN has the capability to support RO as well. I don't see any benefit in having additional control of a MIP6 feature. An MN may be able to perform RO with some CNs and not with others. With this policy that you are proposing, does the indication to the MN cause it to not do RO? And are you proposing policing that the MN does not do RO via the HA? I just don't see good reasons for blocking RO at all. I think this paranoia of maintaining control over a user by ensuring that all traffic flows via an HA is not really justifiable. > That is > probably not the best choice. I believe we need to propose a solution > which is flexible and operator can choose one of the extremes or a > per-user authorization based on the operator service model. > > All what is needed here is an extra optional AVP. Do you think that is > not worth it? Raj> It is not the question of whether it is just an extra AVP or a bit. I think the premise of requiring authorization for RO is invalid (at least IMO). -Raj > > On the other hand, if HA is used to block the HoIT/HoT messages, > communicating that behavior to the HA can be based on a global policy, a > per domain, or per-user. But, since HA is going to H-AAA anyway why do > not we make that dynamic and supported as part of the Diameter MIPv6 > Application. > > Best Regards, > Ahmad > >> >> -Raj >> >> >> On 9/4/07 7:12 AM, "ext Hannes Tschofenig" >> wrote: >> >>> Hi all, >>> >>> during his review of "Diameter Mobile IPv6: HA<->AAA" Ahmad >> made the >>> following >>> comment: >>> >>>>>> >>> We discussed before that AUTHORIZATION for ROUTE >> OPTIMIZATION is needed. >>> I did not see it included here?! As we discussed last time, >> operators >>> do care about having control over the willingness of the MN to have >>> route optimization. If that the case, then there should be >> a process >>> to enable that kind of authorization. No? >>> <<< >>> >>> Does the group think that we need to provide any backend >>> infrastructure support to enable this type of functionality? >>> >>> Ciao >>> Hannes >>> >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 04 15:55:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISeUm-00074t-Lc; Tue, 04 Sep 2007 15:55:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISeUk-00074V-OZ for dime@ietf.org; Tue, 04 Sep 2007 15:55:30 -0400 Received: from web84108.mail.mud.yahoo.com ([68.142.206.195]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISeUj-000370-Hp for dime@ietf.org; Tue, 04 Sep 2007 15:55:30 -0400 Received: (qmail 39620 invoked by uid 60001); 4 Sep 2007 19:55:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=pebjkfoltrgOaugBaQ99unIY9YicMNm1ntg9XzfEpXiqChCJ8FYdqT6fdYrtTTHEdWCUPp41Qxd1e6MgUWM33EDToGfswYMHuuawiSpvvbWeE/7SgizYFq7cRLAtcLm+H6fGoIOwD2wBpbQzRMzGa/am9vkKPQmBX2rIIf22OPI=; X-YMail-OSG: Yg6NuRYVM1mlCQKbntuzxVyt2M00ktZvSBl_hCMS6sPapseCiVn3E2z1ST3YCB_41ZkiLySCDzCP0zNInFrcpysV4aHAqJsgi3zbhqXl0utlOPD72po8OuDQeA-- Received: from [206.16.17.212] by web84108.mail.mud.yahoo.com via HTTP; Tue, 04 Sep 2007 12:55:28 PDT X-Mailer: YahooMailRC/651.48 YahooMailWebService/0.7.134 Date: Tue, 4 Sep 2007 12:55:28 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization To: Hannes Tschofenig MIME-Version: 1.0 Message-ID: <883834.39489.qm@web84108.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: Mobile IPv6 Mailing List , dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1783412853==" Errors-To: dime-bounces@ietf.org --===============1783412853== Content-Type: multipart/alternative; boundary="0-1619741852-1188935728=:39489" --0-1619741852-1188935728=:39489 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I like Jouni's idea of making RO authorization part of the subscriber profi= le. I think such a thing fits better into the (AAA) managed network model. = Defining an AVP probably is not necessary.=0A=0ARegards,=0A=0ABehcet=0A=0A-= ---- Original Message ----=0AFrom: Hannes Tschofenig =0ATo: Basavaraj Patil =0ACc: Mobile IPv6 Mai= ling List ; dime@ietf.org=0ASent: Tuesday, September 4, 2007= 2:34:20 PM=0ASubject: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping= : Authorizing Route Optimization=0A=0AHi Raj,=0A=0Ayou raise a good point. = There is no doubt that a network operator can =0Aprevent all end hosts from= using the RO procedure.=0A=0AThe main question therefore is whether the RO= procedure has to enabled / =0Adisabled on a per user basis.=0A=0ACiao=0AHa= nnes=0A=0ABasavaraj Patil wrote:=0A> Hi Ahmad,=0A>=0A> I am skeptical about= the need for an MN being authorized to use an inherent=0A> feature of MIP6= . It makes no sense for an MN to be authorized depending on=0A> the network= that it is attached to whether it is able to use RO with CNs.=0A>=0A> -Raj= =0A>=0A>=0A> On 9/4/07 8:57 AM, "ext Ahmad Muhanna" w= rote:=0A>=0A> =0A>> Hi Alex,=0A>>=0A>> Just some background:=0A>>=0A>> Th= e proposed Diameter MIPv6 Application is used to enable MIPv6 service=0A>> = authorization + dynamic security association allocation. As per the=0A>> cu= rrent application, the user is authorized for MIPv6 service without a=0A>> = clear indication if the user is allowed to use Route Optimization or=0A>> n= ot. Allowing the operator this flexibility makes a lot of sense. Let us=0A>= > remember in order for the MN to establish a RO, it needs to have at=0A>> = least HoTI and HoT signals transmitted via the HA which can act as the=0A>>= authorization enforcement point.=0A>>=0A>> Of course, we are talking about= a network which is controlled by AAA=0A>> infrastructure since the propose= d application is for Diameter MIPv6.=0A>>=0A>> Also, please see comments in= line.=0A>>=0A>> Regards,=0A>> Ahmad=0A>> =0A>>=0A>> =0A>>> Subject: Re= : [Mip6] Diameter Mobile IPv6 Bootstrapping:=0A>>> Authorizing Route Optimi= zation=0A>>>=0A>>> Hannes Tschofenig wrote:=0A>>> =0A>>>> Hi all, dur= ing his review of "Diameter Mobile IPv6: HA<->AAA" Ahmad=0A>>>> made the fo= llowing comment:=0A>>>> =0A>>>> We discussed before that AUTHORIZAT= ION for ROUTE OPTIMIZATION is=0A>>>> needed. I did not see it included here= ?! As we discussed last time,=0A>>>> operators do care about having control= over the willingness=0A>>>> =0A>>> of the MN =0A>>> =0A>>>> = to have route optimization. If that the case, then there=0A>>>> =0A= >>> should be a =0A>>> =0A>>>> process to enable that kind of authori= zation. No? <<<=0A>>>>=0A>>>> Does the group think that we need to provide = any backend=0A>>>> infrastructure support to enable this type of functional= ity?=0A>>>> =0A>>> Which group(s)?=0A>>>=0A>>> I think RO is design= ed to work across the entire Internet,=0A>>> not limited to a AAA-controlle= d domain.=0A>>>=0A>>> From tests, the benefits of running RO on the MN are= =0A>>> apparent only when the distance MN-CN is much shorter than=0A>>> bot= h MN-HA and CN-HA, in terms of IP hops.=0A>>>=0A>>> In a closed system, tha= t equation is not valid, ie, MN is=0A>>> close to both CN and to its HA, an= d the benefits of running=0A>>> RO are minimal, one doesn't gain much at al= l.=0A>>>=0A>>> So, in first place I don't see why would a MN want to run RO= =0A>>> at all while in a AAA-controlled (closed) domain. It may=0A>>> very= well be that MN is not interested at all to run RO to a=0A>>> CN outside t= he AAA-controlled domain, because it wouldn't=0A>>> gain much. Then, even = if MN would want to do that, I don't=0A>>> see why asking the local AAA to = be authorized to perform RO.=0A>>> =0A>> [Ahmad]=0A>> Are you assumin= g that the HA is always in the visited network? Also,=0A>> V-AAA does not c= ommunicate with H-AAA?=0A>> I just want to understand what you meant here.= =0A>> Thanks.=0A>>=0A>> =0A>>> Finally, are you talking about AAA backe= nd authorizing the MN=0A>>> or the CN to do RO?=0A>>> =0A>> [Ahmad]= =0A>> AAA infrastructure only can control the MN to have RO or not and henc= e=0A>> authorization is for the MN not the CN.=0A>> =0A>>> Alex=0A>>>= =0A>>> ____________________________________________________________________= __=0A>>> This email has been scanned by the MessageLabs Email Security Syst= em.=0A>>> For more information please visit=0A>>> http://www.messagelabs.co= m/email=0A>>> _____________________________________________________________= _________=0A>>>=0A>>> _______________________________________________=0A>>>= Mip6 mailing list=0A>>> Mip6@ietf.org=0A>>> https://www1.ietf.org/mailman/= listinfo/mip6=0A>>>=0A>>> =0A>> _____________________________________= __________=0A>> Mip6 mailing list=0A>> Mip6@ietf.org=0A>> https://www1.ietf= .org/mailman/listinfo/mip6=0A>> =0A=0A=0A______________________________= _________________=0ADiME mailing list=0ADiME@ietf.org=0Ahttps://www1.ietf.o= rg/mailman/listinfo/dime=0A=0A=0A=0A=0A --0-1619741852-1188935728=:39489 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
I like Jouni's idea of making RO authorization part of= the subscriber profile. I think such a thing fits better into the (AAA) ma= naged network model. Defining an AVP probably is not necessary.

Rega= rds,

Behcet

----- Original Message ----
From: Hann= es Tschofenig <Hannes.Tschofenig@gmx.net>
To: Basavaraj Patil <= basavaraj.patil@nsn.com>
Cc: Mobile IPv6 Mailing List <mip6@ietf.o= rg>; dime@ietf.org
Sent: Tuesday, September 4, 2007 2:34:20 PM
Sub= ject: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Rou= te Optimization

Hi Raj,

you raise a good point. There is no doubt that a network operator can
prevent all end hosts from using = the RO procedure.

The main question therefore is whether the RO proc= edure has to enabled /
disabled on a per user basis.

Ciao
Han= nes

Basavaraj Patil wrote:
> Hi Ahmad,
>
> I am sk= eptical about the need for an MN being authorized to use an inherent
>= ; feature of MIP6. It makes no sense for an MN to be authorized depending o= n
> the network that it is attached to whether it is able to use RO w= ith CNs.
>
> -Raj
>
>
> On 9/4/07 8:57 AM, "e= xt Ahmad Muhanna" <amuhanna@nortel.com> wrote:
>
> &= nbsp;
>> Hi Alex,
>>
>> Just some background:>>
>> The proposed Diameter MIPv6 Application is used to e= nable MIPv6 service
>> authorization + dynamic security associatio= n allocation. As per the
>> current application, the user is authorized for MIPv6 service without a
>> clear indication if = the user is allowed to use Route Optimization or
>> not. Allowing = the operator this flexibility makes a lot of sense. Let us
>> reme= mber in order for the MN to establish a RO, it needs to have at
>>= least HoTI and HoT signals transmitted via the HA which can act as the
= >> authorization enforcement point.
>>
>> Of course= , we are talking about a network which is controlled by AAA
>> inf= rastructure since the proposed application is for Diameter MIPv6.
>&g= t;
>> Also, please see comments inline.
>>
>> Re= gards,
>> Ahmad
>>  
>>
>>&nb= sp;   
>>> Subject: Re: [Mip6] Diameter Mobile = IPv6 Bootstrapping:
>>> Authorizing Route Optimization
>&= gt;>
>>> Hannes Tschofenig wrote:
>>>      
>>>= ;> Hi all, during his review of "Diameter Mobile IPv6: HA<->AAA" A= hmad
>>>> made the following comment:
>>>>&nb= sp;       
>>>> We discu= ssed before that AUTHORIZATION for ROUTE OPTIMIZATION is
>>>>= ; needed. I did not see it included here?! As we discussed last time,
&g= t;>>> operators do care about having control over the willingness<= br>>>>>        
>= ;>> of the MN
>>>       >>>> to have route optimization. If that the case, then there=
>>>>        
&g= t;>> should be a
>>>      =
>>>> process to enable that kind of authorization. No? <<<
>>>>
>>>> Does the group th= ink that we need to provide any backend
>>>> infrastructure = support to enable this type of functionality?
>>>> &nbs= p;      
>>> Which group(s)?
= >>>
>>> I think RO is designed to work across the enti= re Internet,
>>> not limited to a AAA-controlled domain.
>= ;>>
>>>  From tests, the benefits of running RO= on the MN are
>>> apparent only when the distance MN-CN is muc= h shorter than
>>> both MN-HA and CN-HA, in terms of IP hops.>>>
>>> In a closed system, that equation is not val= id, ie, MN is
>>> close to both CN and to its HA, and the benef= its of running
>>> RO are minimal, one doesn't gain much at all= .
>>>
>>> So, in first place I don't see why would a MN want to run RO
>>> at all while in a AAA-controlled= (closed) domain.  It may
>>> very well be that MN is= not interested at all to run RO to a
>>> CN outside the AAA-co= ntrolled domain, because it wouldn't
>>> gain much.  = Then, even if MN would want to do that, I don't
>>> see why ask= ing the local AAA to be authorized to perform RO.
>>> &nbs= p;    
>> [Ahmad]
>> Are you assumin= g that the HA is always in the visited network? Also,
>> V-AAA doe= s not communicate with H-AAA?
>> I just want to understand what yo= u meant here.
>> Thanks.
>>
>>   =  
>>> Finally, are you talking about AAA backend authoriz= ing the MN
>>> or the CN to do RO?
>>>  &= nbsp;   
>> [Ahmad]
>> AAA infrastructure only can control the MN to have RO or not and hence
>= > authorization is for the MN not the CN.
>>   &= nbsp;
>>> Alex
>>>
>>> _______________= _______________________________________________________
>>> Thi= s email has been scanned by the MessageLabs Email Security System.
>&= gt;> For more information please visit
>>> http://www.messagelabs.com/em= ail
>>> ___________________________________________________= ___________________
>>>
>>> _______________________= ________________________
>>> Mip6 mailing list
>>> = Mip6@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/mip6
>>>
>>>      
>> _______________________________________________
>> M= ip6 mailing list
>> Mip6@ietf.org
>> https://www1.ietf.org= /mailman/listinfo/mip6
>>    


= _______________________________________________
DiME mailing list
DiM= E@ietf.org
https://www1.ietf.org/mailman/listinfo/dime

--0-1619741852-1188935728=:39489-- --===============1783412853== 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 --===============1783412853==-- From dime-bounces@ietf.org Tue Sep 04 17:08:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISfdX-0002VF-Pb; Tue, 04 Sep 2007 17:08:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISfdW-0002Un-WE; Tue, 04 Sep 2007 17:08:39 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISfdV-0005DD-Of; Tue, 04 Sep 2007 17:08:38 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l84L8YX19498; Tue, 4 Sep 2007 21:08:35 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 Date: Tue, 4 Sep 2007 16:08:32 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371168AEA44@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization Thread-Index: AcfvIP09O9VE0FsUEdyuUQARJNUNiAAALESAAALx/b8AAUl0QA== References: <6FC4416DDE56C44DA0AEE67BC7CA437116865AF0@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Basavaraj Patil" , "ext Hannes Tschofenig" , , "Mobile IPv6 Mailing List" X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: Subject: [Dime] RE: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization 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 Raj, Please see comments inline. Regards, Ahmad =20 > > =20 > >=20 > >> Subject: Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: > >> Authorizing Route Optimization > >>=20 > >> Hi Hannes, > >>=20 > >> I do not believe that the use of Route Optimization has to be=20 > >> authorized for an MN. If the MN is capable of RO and initiates RO=20 > >> signaling, there is no need for it to be authorized to do so. > >>=20 > >> The concern mentioned below is that operators prefer to be=20 > in control=20 > >> of an MN. Since the HA is involved in the RO signaling, it can=20 > >> prevent the MN from establishing route-optimized sessions with CNs. > >=20 > > [Ahmad] > > MN may, by default, is authorized for RO as part of MIPv6=20 > authorization. > > On the other hand, some other operators may deny RO by default too. >=20 > Raj> Not sure what you mean by "other operators" above... Are you=20 > Raj> implying > that the visited network that the MN is attached to does not=20 > permit the MN from using RO? > Fundamentally, what is the reasoning for preventing=20 > route-optimization. I think there has not been any discussion=20 > about why RO should be blocked and in what specific scenarios. >=20 > > However, an optional AVP to be returned in the MAM could make a big=20 > > difference and make the solution much more flexible and cleaner and=20 > > applicable on a per-user. As far as I know, at least one of=20 > the SDO's=20 > > has have some discussion on disallowing RO by default. >=20 > Raj> I think the HA can even today is capable of denying RO=20 > on a per-MN > granularity.=20 [Ahmad] Yes. Of course that is part of HA capabilities. However, the point is: how the HA decides which user RO to block. > I am just wondering what is the point of=20 > indicating to the MN whether RO is permitted or not. > There has not been enough experience with RO and its=20 > implications. When is RO triggered by an MN for example? IMO=20 > it makes no sense to build blocking mechanisms for a feature=20 > that we do not have yet have better understanding. [Ahmad] There are two points here and let me address both together. 1. Hmm, you are raising a good point here on how to indicate that to the MN. I guess indicating that to the MN could be optional, however, the HA will enforce this policy on a per-user basis without any statically configured information. i.e. during MIPv6 authorization. Freebee:-) BTW: Since some people may not like the idea of another AVP, this can be as simple as a bit in the MIPv6-Feature-Vector, which, as per Diameter MIP6 application, is included in all Requests and Answers messages! 2. I agree there have not been a lot of discussion on RO authorization/blocking but let us think of it in a different way. What about if we say that a home network is interested in getting some users traffic pass through its home network all the time. For whatever reason. They may be able to negotiate a better roaming deal!:-) >=20 > And what is the point of denying RO. The MN can just as well=20 > use the CoA and communicate directly with the CN. Session=20 > continuity does not exist in such a case. But if the point of=20 > the operator was to ensure that all traffic flows through the=20 > HA, that is already defeated via the CoA. [Ahmad] But let us take what RFC3775 says in this regard. A CN is not supposed to trust a MN unless it is able to verify that the MN is addressable at the claimed HoA and CoA. Now, if CN does not behave, that in itself a violation of RFC3775 and a risk the CN is taking and should consider seriously. Right? Here RFC3775 text: " 5.2.5. Return Routability Procedure The Return Routability Procedure enables the correspondent node to obtain some reasonable assurance that the mobile node is in fact addressable at its claimed care-of address as well as at its home address. Only with this assurance is the correspondent node able to accept Binding Updates from the mobile node which would then instruct the correspondent node to direct that mobile node's data traffic to its claimed care-of address. " >=20 > >=20 > > In summary, we either have a default authorization as part of MIPv6=20 > > for all users or RO is NOT authorized by default for all users. >=20 > Raj> Whether RO can be achieved depends if the CN has the=20 > capability to > support RO as well. I don't see any benefit in having=20 > additional control of a MIP6 feature. An MN may be able to=20 > perform RO with some CNs and not with others. With this=20 > policy that you are proposing, does the indication to the MN=20 > cause it to not do RO? And are you proposing policing that=20 > the MN does not do RO via the HA? I just don't see good=20 > reasons for blocking RO at all. [Ahmad] I see your point, but as far as blocking RO all together, I guess I heard people talking about it before! > I think this paranoia of maintaining control over a user by=20 > ensuring that all traffic flows via an HA is not really justifiable. [Ahmad] May be it is; if those marketing guys find a way to make money out of it. You never know:-) However, if people think that it is not a good idea despite all simplicity proposed here, "just adding a bit in MIP6-Feature-Vector", then that is how things is decided here anyway. My recollection, if I still remember correctly, there was some support for this long time ago after the Nov. 2006 IETF meeting, I guess. >=20 > > That is > > probably not the best choice. I believe we need to propose=20 > a solution=20 > > which is flexible and operator can choose one of the extremes or a=20 > > per-user authorization based on the operator service model. > >=20 > > All what is needed here is an extra optional AVP. Do you=20 > think that is=20 > > not worth it? >=20 > Raj> It is not the question of whether it is just an extra=20 > AVP or a bit.=20 > Raj> I > think the premise of requiring authorization for RO is=20 > invalid (at least IMO). >=20 > -Raj >=20 > >=20 > > On the other hand, if HA is used to block the HoIT/HoT messages,=20 > > communicating that behavior to the HA can be based on a=20 > global policy,=20 > > a per domain, or per-user. But, since HA is going to H-AAA=20 > anyway why=20 > > do not we make that dynamic and supported as part of the Diameter=20 > > MIPv6 Application. > >=20 > > Best Regards, > > Ahmad > >=20 > >>=20 > >> -Raj > >>=20 > >>=20 > >> On 9/4/07 7:12 AM, "ext Hannes Tschofenig"=20 > >> > >> wrote: > >>=20 > >>> Hi all, > >>>=20 > >>> during his review of "Diameter Mobile IPv6: HA<->AAA" Ahmad > >> made the > >>> following > >>> comment:=20 > >>>=20 > >>>>>>=20 > >>> We discussed before that AUTHORIZATION for ROUTE > >> OPTIMIZATION is needed. > >>> I did not see it included here?! As we discussed last time, > >> operators > >>> do care about having control over the willingness of the=20 > MN to have=20 > >>> route optimization. If that the case, then there should be > >> a process > >>> to enable that kind of authorization. No? > >>> <<< > >>>=20 > >>> Does the group think that we need to provide any backend=20 > >>> infrastructure support to enable this type of functionality? > >>>=20 > >>> Ciao > >>> Hannes > >>>=20 > >>>=20 > >>> _______________________________________________ > >>> Mip6 mailing list > >>> Mip6@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mip6 > >>=20 > >>=20 > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > >>=20 >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 05 00:18:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISmLU-0007IJ-8U; Wed, 05 Sep 2007 00:18:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISmLT-0007D0-0d; Wed, 05 Sep 2007 00:18:27 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISmLS-0006xZ-KH; Wed, 05 Sep 2007 00:18:26 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l854INq05974; Wed, 5 Sep 2007 04:18:23 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 Date: Tue, 4 Sep 2007 23:18:21 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371168AEE32@zrc2hxm2.corp.nortel.com> In-Reply-To: <46DD8586.80201@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization Thread-Index: AcfvD1882LtkEndtSYqP0voVVs+UzAAYvBOw References: <46DD4BCA.8090200@gmx.net> <46DD51F6.6000209@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA43711686502E@zrc2hxm2.corp.nortel.com> <46DD699F.3040108@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116865561@zrc2hxm2.corp.nortel.com> <46DD8586.80201@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Mobile IPv6 Mailing List , dime@ietf.org Subject: [Dime] RE: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization 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 > Right, and in that case MN doesn't need RO at all (because CN=20 > doesn't use MN's HoA to talk to MN). >=20 > > I guess allowing the Home Network the option to force user traffic=20 > > through the home network, IMO, makes a good business case and a=20 > > flexibility for the operator to use for offering different service=20 > > models. I believe I am going beyond the technicality of the issue=20 > > here; I hope I am correct.:-) >=20 > That's what I'm not sure I understand: I'm not sure I=20 > understand the technicality of the mechanism: does the MN=20 > _need_ at all to run MIP6 RO HoT/I CoT/I when it uses a CoA=20 > instead of HoA... [Ahmad] Hi Alex, To be honest, it is really confusing:-( It seems to me that one opinion argues that we need to support Mobile IPv6 including RO and we should not kill it before it is even deployed by skinning off the RO from MIPv6; which I strongly agree. However, when it is pointed out that as per RFC3775 the CN is supposed to make sure that the MN is addressable at the HoA and CoA before even trusting this MN, another opinion says, as you just mentioned above:-), the CoA is just another IP address. Which absolutely fine. However, we MUST not pick and choose. Either we support RFC3775 as a whole or just let us deploy what is meaningful. As far as I remember, I heard that some SDO's do not want to support RO at least one year back. >=20 > If it's realized that MN needs to do RO then obviously a=20 > mechanism for AAA to authorize RO service is necessary, IMHO. [Ahmad] Agreed! >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 05 00:28:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISmV3-0002PS-Uw; Wed, 05 Sep 2007 00:28:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISmV2-0002Os-S2; Wed, 05 Sep 2007 00:28:20 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISmV1-0006NN-Iu; Wed, 05 Sep 2007 00:28:20 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l854SGl12933; Wed, 5 Sep 2007 04:28:16 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 Date: Tue, 4 Sep 2007 23:28:12 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371168AEE3A@zrc2hxm2.corp.nortel.com> In-Reply-To: <46DE05F5.1090809@hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization Thread-Index: AcfvW+ztVgFbS41ISSKmOd5PZ+ZPIgAGC+pA References: <6FC4416DDE56C44DA0AEE67BC7CA437116865AF0@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA4371168AEA44@zrc2hxm2.corp.nortel.com> <46DE05F5.1090809@hp.com> From: "Ahmad Muhanna" To: "Brian Haley" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Mobile IPv6 Mailing List , dime@ietf.org Subject: [Dime] RE: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization 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 > >=20 > > [Ahmad] > > But let us take what RFC3775 says in this regard. A CN is=20 > not supposed=20 > > to trust a MN unless it is able to verify that the MN is=20 > addressable=20 > > at the claimed HoA and CoA. Now, if CN does not behave,=20 > that in itself=20 > > a violation of RFC3775 and a risk the CN is taking and=20 > should consider=20 > > seriously. Right? >=20 > To the other end it's just an address, not a CoA - direct=20 > communication without mobility support. [Ahmad] Why the MN needs to ask for MIPv6 then. It could negotiate Simple IPv6 and that is perfectly fine. >=20 > I agree with Raj and see no purpose to not authorizing RO. =20 > Do we really want to cripple Mipv6 before it even gets deployed? [Ahmad] Hi Brian, Not at all, I am not proposing to cripple MIPv6 before it even gets deployed, I am just asking that we need to comply with RFC3775 which is the basis of MIPv6. If we start the process of pick and choose, then I am afraid we are contributing to the crippling of MIPv6. As I said, CN is not supposed to trust a MN until it is able to verify that the MN is addressable at both addresses and that address is referred to in RFC3775 as the CoA. If we disagree with RFC3775, then we probably need to change it. IMHO. >=20 > -Brian >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 05 02:32:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISoQa-0001GT-SB; Wed, 05 Sep 2007 02:31:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISoQZ-0001GH-Cv; Wed, 05 Sep 2007 02:31:51 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISoQY-0001eL-Dv; Wed, 05 Sep 2007 02:31:51 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.168]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Sep 2007 08:31:48 +0200 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] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: AuthorizingRoute Optimization Date: Wed, 5 Sep 2007 08:31:47 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222CB19@SEHAN021MB.tcad.telia.se> In-Reply-To: <883834.39489.qm@web84108.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: AuthorizingRoute Optimization Thread-Index: AcfvLZM1TzYF91xdQ86chLyf0jhgrAAVlaqg References: <883834.39489.qm@web84108.mail.mud.yahoo.com> From: To: , X-OriginalArrivalTime: 05 Sep 2007 06:31:48.0674 (UTC) FILETIME=[6FFB3A20:01C7EF86] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: mip6@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 =20 Hmm.. lets clarify what my "yes" was supposed to mean. An operator needs to have a way to indicate to a HA per subscriber basis whether a RO procedure is enabled / disabled (in the HA). This information can be conveyed e.g. in the current dime-split draft using the MIP6-Feature-Vector AVP. IMO this is more a policy decision than an authorization. Cheers, Jouni =20 ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Tuesday, September 04, 2007 10:55 PM To: Hannes Tschofenig Cc: Mobile IPv6 Mailing List; dime@ietf.org Subject: Re: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: AuthorizingRoute Optimization =09 =09 I like Jouni's idea of making RO authorization part of the subscriber profile. I think such a thing fits better into the (AAA) managed network model. Defining an AVP probably is not necessary. =09 Regards, =09 Behcet =09 =09 ----- Original Message ---- From: Hannes Tschofenig To: Basavaraj Patil Cc: Mobile IPv6 Mailing List ; dime@ietf.org Sent: Tuesday, September 4, 2007 2:34:20 PM Subject: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization =09 =09 Hi Raj, =09 you raise a good point. There is no doubt that a network operator can=20 prevent all end hosts from using the RO procedure. =09 The main question therefore is whether the RO procedure has to enabled /=20 disabled on a per user basis. =09 Ciao Hannes =09 Basavaraj Patil wrote: > Hi Ahmad, > > I am skeptical about the need for an MN being authorized to use an inherent > feature of MIP6. It makes no sense for an MN to be authorized depending on > the network that it is attached to whether it is able to use RO with CNs. > > -Raj > > > On 9/4/07 8:57 AM, "ext Ahmad Muhanna" wrote: > > =20 >> Hi Alex, >> >> Just some background: >> >> The proposed Diameter MIPv6 Application is used to enable MIPv6 service >> authorization + dynamic security association allocation. As per the >> current application, the user is authorized for MIPv6 service without a >> clear indication if the user is allowed to use Route Optimization or >> not. Allowing the operator this flexibility makes a lot of sense. Let us >> remember in order for the MN to establish a RO, it needs to have at >> least HoTI and HoT signals transmitted via the HA which can act as the >> authorization enforcement point. >> >> Of course, we are talking about a network which is controlled by AAA >> infrastructure since the proposed application is for Diameter MIPv6. >> >> Also, please see comments inline. >> >> Regards, >> Ahmad >> =20 >> >> =20 >>> Subject: Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: >>> Authorizing Route Optimization >>> >>> Hannes Tschofenig wrote: >>> =20 >>>> Hi all, during his review of "Diameter Mobile IPv6: HA<->AAA" Ahmad >>>> made the following comment: >>>> =20 >>>> We discussed before that AUTHORIZATION for ROUTE OPTIMIZATION is >>>> needed. I did not see it included here?! As we discussed last time, >>>> operators do care about having control over the willingness >>>> =20 >>> of the MN=20 >>> =20 >>>> to have route optimization. If that the case, then there >>>> =20 >>> should be a=20 >>> =20 >>>> process to enable that kind of authorization. No? <<< >>>> >>>> Does the group think that we need to provide any backend >>>> infrastructure support to enable this type of functionality? >>>> =20 >>> Which group(s)? >>> >>> I think RO is designed to work across the entire Internet, >>> not limited to a AAA-controlled domain. >>> >>> From tests, the benefits of running RO on the MN are >>> apparent only when the distance MN-CN is much shorter than >>> both MN-HA and CN-HA, in terms of IP hops. >>> >>> In a closed system, that equation is not valid, ie, MN is >>> close to both CN and to its HA, and the benefits of running >>> RO are minimal, one doesn't gain much at all. >>> >>> So, in first place I don't see why would a MN want to run RO >>> at all while in a AAA-controlled (closed) domain. It may >>> very well be that MN is not interested at all to run RO to a >>> CN outside the AAA-controlled domain, because it wouldn't >>> gain much. Then, even if MN would want to do that, I don't >>> see why asking the local AAA to be authorized to perform RO. >>> =20 >> [Ahmad] >> Are you assuming that the HA is always in the visited network? Also, >> V-AAA does not communicate with H-AAA? >> I just want to understand what you meant here. >> Thanks. >> >> =20 >>> Finally, are you talking about AAA backend authorizing the MN >>> or the CN to do RO? >>> =20 >> [Ahmad] >> AAA infrastructure only can control the MN to have RO or not and hence >> authorization is for the MN not the CN. >> =20 >>> Alex >>> >>> ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security System. >>> For more information please visit >>> http://www.messagelabs.com/email >>> ______________________________________________________________________ >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >>> >>> =20 >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> =20 =09 =09 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime =09 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 05 07:34:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISt9A-0002as-95; Wed, 05 Sep 2007 07:34:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISt99-0002ak-4I; Wed, 05 Sep 2007 07:34:11 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISt98-0002CN-JR; Wed, 05 Sep 2007 07:34:11 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1188992049!19866594!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 21681 invoked from network); 5 Sep 2007 11:34:09 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-128.messagelabs.com with SMTP; 5 Sep 2007 11:34:09 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l85BY8nQ024976; Wed, 5 Sep 2007 04:34:09 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l85BY8RR020359; Wed, 5 Sep 2007 06:34:08 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l85BY64O020334; Wed, 5 Sep 2007 06:34:06 -0500 (CDT) Message-ID: <46DE942D.9010606@gmail.com> Date: Wed, 05 Sep 2007 13:34:05 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna References: <46DD4BCA.8090200@gmx.net> <46DD51F6.6000209@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA43711686502E@zrc2hxm2.corp.nortel.com> <46DD699F.3040108@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116865561@zrc2hxm2.corp.nortel.com> <46DD8586.80201@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA4371168AEE32@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371168AEE32@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000772-3, 04/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Mobile IPv6 Mailing List , dime@ietf.org Subject: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization 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 Ahmad Muhanna wrote: >> Right, and in that case MN doesn't need RO at all (because CN >> doesn't use MN's HoA to talk to MN). >> >>> I guess allowing the Home Network the option to force user >>> traffic through the home network, IMO, makes a good business case >>> and a flexibility for the operator to use for offering different >>> service models. I believe I am going beyond the technicality of >>> the issue here; I hope I am correct.:-) >> That's what I'm not sure I understand: I'm not sure I understand >> the technicality of the mechanism: does the MN _need_ at all to run >> MIP6 RO HoT/I CoT/I when it uses a CoA instead of HoA... > > [Ahmad] Hi Alex, > > To be honest, it is really confusing:-( It seems to me that one > opinion argues that we need to support Mobile IPv6 including RO and > we should not kill it before it is even deployed by skinning off the > RO from MIPv6; which I strongly agree. However, when it is pointed > out that as per RFC3775 the CN is supposed to make sure that the MN > is addressable at the HoA and CoA before even trusting this MN, > another opinion says, as you just mentioned above:-), the CoA is just > another IP address. Which absolutely fine. However, we MUST not pick > and choose. Either we support RFC3775 as a whole or just let us > deploy what is meaningful. As far as I remember, I heard that some > SDO's do not want to support RO at least one year back. It would be interesting to learn from these SDOs how exactly would they like to not support RO: -by not implementing RO software in their HA? -by IP filtering rules at HA? (drop HoT/I)? -by advertising lack-RO in their advertisements to MN? -by AAA means? Alex >> If it's realized that MN needs to do RO then obviously a mechanism >> for AAA to authorize RO service is necessary, IMHO. > > [Ahmad] Agreed! > >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 05 11:54:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISxD2-0005Iw-Kx; Wed, 05 Sep 2007 11:54:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISxD1-0005IR-Dn; Wed, 05 Sep 2007 11:54:27 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISxCz-00075t-VC; Wed, 05 Sep 2007 11:54:27 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.168]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Sep 2007 17:54:24 +0200 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, 5 Sep 2007 17:54:23 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222CB4E@SEHAN021MB.tcad.telia.se> In-Reply-To: <46DEBC3D.6030604@hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing RouteOptimization Thread-Index: AcfvyJxa6CXTMUV7Q1uTmNVccNkm4QACeYDw References: <6FC4416DDE56C44DA0AEE67BC7CA437116865AF0@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA4371168AEA44@zrc2hxm2.corp.nortel.com><46DE05F5.1090809@hp.com><6FC4416DDE56C44DA0AEE67BC7CA4371168AEE3A@zrc2hxm2.corp.nortel.com> <46DEBC3D.6030604@hp.com> From: To: , X-OriginalArrivalTime: 05 Sep 2007 15:54:24.0575 (UTC) FILETIME=[0810F4F0:01C7EFD5] X-Spam-Score: -4.0 (----) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mip6@ietf.org, dime@ietf.org Subject: [Dime] RE: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing RouteOptimization 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 Brian, > > [Ahmad] > > Why the MN needs to ask for MIPv6 then. It could negotiate=20 > Simple IPv6=20 > > and that is perfectly fine. >=20 > I think you mis-understood me, I wasn't talking about using=20 > MIPv6. A MN can use the IPv6 address it's configured on the=20 > remote link for communicating with local nodes (eg DNS)=20 > without using any MIPv6 functionality. It should=20 > reverse-tunnel the rest. But if we start restricting RO,=20 > people will start getting creative with their implementations=20 > and work around it, and none of those will be inter-operable. A MN needs to be prepared for failing return routability test anyway.. there might be an evil firewall in between than causes the RO to fail. So if the MN does not know whether the HA or some other intermediate node failed the RO, there is not much point of trying to do clever things in the MN. Having said this I think there is no need to explicitly tell the MN whether HA does some policy based decision on RO. The MN will learn it eventually.. > Jouni's latest email clarified what he meant, but I still=20 > don't agree an HA RO knob should exist, that's just my opinion. Unfortunately I think operators will do it in any case. They are creative on that ;) And sometimes also forced by regulation. Doing such policy decision in a HA is more logical place than trying to do that in a cluster of firewalls. Cheers, Jouni >=20 > -Brian >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 05 13:03:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISyHP-00028H-1w; Wed, 05 Sep 2007 13:03:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISyHO-00027k-8B for dime@ietf.org; Wed, 05 Sep 2007 13:03:02 -0400 Received: from web84111.mail.mud.yahoo.com ([68.142.206.198]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISyHM-0002mx-N0 for dime@ietf.org; Wed, 05 Sep 2007 13:03:02 -0400 Received: (qmail 39525 invoked by uid 60001); 5 Sep 2007 17:03:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=gnm++P1bGIwE184dFs4j1TM3eAsRn0i34TJ67JoV2uz15AydXcX/QXn22012dO6vsio6MQQwjKi4Z0kto0h3qgxXnpTTaVAUniaP2kZM917kx4kSKHT9Km3EHCjt84v9/D8PmuvJobin/PA/s72GDNXCQz2iz7rXNttTmjVfewk=; X-YMail-OSG: tIfDOVsVM1kTYnwCptiMl1u.bjXgztDv0TJpsvVp73a3BYXGC3T9RGjXpB8wItxcT4sQUXXLY00ndHPrJ6C4HzHQ_p1ONAANZIK9o3j2fEQA6KOsIAeTvgKynA-- Received: from [206.16.17.212] by web84111.mail.mud.yahoo.com via HTTP; Wed, 05 Sep 2007 10:03:00 PDT X-Mailer: YahooMailRC/651.48 YahooMailWebService/0.7.134 Date: Wed, 5 Sep 2007 10:03:00 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: AuthorizingRoute Optimization To: jouni.korhonen@teliasonera.com, dime@ietf.org MIME-Version: 1.0 Message-ID: <219961.39234.qm@web84111.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Cc: mip6@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1034762685==" Errors-To: dime-bounces@ietf.org --===============1034762685== Content-Type: multipart/alternative; boundary="0-1494209095-1189011780=:39234" --0-1494209095-1189011780=:39234 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable How about this?=0ARO authorization is part of the subscriber profile and us= ing HA-AAA interface and MIP6-Feature-Vector AVP, this is communicated to H= A. =0A=0AMN is free to attempt RO as Raj wants. HA would block HoTI if MN i= s not authorized.=0A=0AMy suggestion would be to enable RO as much as possi= ble.=0A=0ARegards,=0A=0ABehcet=0A=0A----- Original Message ----=0AFrom: "jo= uni.korhonen@teliasonera.com" =0ATo: Hannes= .Tschofenig@gmx.net; dime@ietf.org=0ACc: mip6@ietf.org; sarikaya@ieee.org= =0ASent: Wednesday, September 5, 2007 1:31:47 AM=0ASubject: RE: [Dime] Re: = [Mip6] Diameter Mobile IPv6 Bootstrapping: AuthorizingRoute Optimization=0A= =0A =0A=0AHmm.. lets clarify what my "yes" was supposed to mean. An operato= r=0Aneeds to have a way to indicate to a HA per subscriber basis whether=0A= a RO procedure is enabled / disabled (in the HA). This information=0Acan be= conveyed e.g. in the current dime-split draft using the=0AMIP6-Feature-Vec= tor AVP. IMO this is more a policy decision than an=0Aauthorization.=0A=0AC= heers,=0A Jouni=0A =0A=0A=0A________________________________=0A=0A Fr= om: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] =0A Sent: Tuesday,= September 04, 2007 10:55 PM=0A To: Hannes Tschofenig=0A Cc: Mobile I= Pv6 Mailing List; dime@ietf.org=0A Subject: Re: [Dime] Re: [Mip6] Diamet= er Mobile IPv6=0ABootstrapping: AuthorizingRoute Optimization=0A =0A = =0A I like Jouni's idea of making RO authorization part of the=0Asubscri= ber profile. I think such a thing fits better into the (AAA)=0Amanaged netw= ork model. Defining an AVP probably is not necessary.=0A =0A Regards,= =0A =0A Behcet=0A =0A =0A ----- Original Message ----=0A = From: Hannes Tschofenig =0A To: Basavaraj Pat= il =0A Cc: Mobile IPv6 Mailing List ; dime@ietf.org=0A Sent: Tuesday, September 4, 2007 2:34:20 PM=0A = Subject: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping:=0AAuthorizi= ng Route Optimization=0A =0A =0A Hi Raj,=0A =0A you raise a = good point. There is no doubt that a network=0Aoperator can =0A prevent = all end hosts from using the RO procedure.=0A =0A The main question t= herefore is whether the RO procedure has to=0Aenabled / =0A disabled on = a per user basis.=0A =0A Ciao=0A Hannes=0A =0A Basavaraj Pat= il wrote:=0A > Hi Ahmad,=0A >=0A > I am skeptical about the need f= or an MN being authorized to=0Ause an inherent=0A > feature of MIP6. It = makes no sense for an MN to be authorized=0Adepending on=0A > the networ= k that it is attached to whether it is able to use=0ARO with CNs.=0A >= =0A > -Raj=0A >=0A >=0A > On 9/4/07 8:57 AM, "ext Ahmad Muhanna= " =0Awrote:=0A >=0A > =0A >> Hi Alex,=0A = >>=0A >> Just some background:=0A >>=0A >> The proposed Diameter = MIPv6 Application is used to enable=0AMIPv6 service=0A >> authorization = + dynamic security association allocation. As=0Aper the=0A >> current ap= plication, the user is authorized for MIPv6 service=0Awithout a=0A >> cl= ear indication if the user is allowed to use Route=0AOptimization or=0A = >> not. Allowing the operator this flexibility makes a lot of=0Asense. Let = us=0A >> remember in order for the MN to establish a RO, it needs to=0Ah= ave at=0A >> least HoTI and HoT signals transmitted via the HA which can= =0Aact as the=0A >> authorization enforcement point.=0A >>=0A >> O= f course, we are talking about a network which is controlled=0Aby AAA=0A = >> infrastructure since the proposed application is for Diameter=0AMIPv6.= =0A >>=0A >> Also, please see comments inline.=0A >>=0A >> Rega= rds,=0A >> Ahmad=0A >> =0A >>=0A >> =0A >>> Subject: Re= : [Mip6] Diameter Mobile IPv6 Bootstrapping:=0A >>> Authorizing Route Op= timization=0A >>>=0A >>> Hannes Tschofenig wrote:=0A >>> =0A= >>>> Hi all, during his review of "Diameter Mobile IPv6:=0AHA<->AAA" Ah= mad=0A >>>> made the following comment:=0A >>>> =0A >>>> W= e discussed before that AUTHORIZATION for ROUTE=0AOPTIMIZATION is=0A >>>= > needed. I did not see it included here?! As we discussed=0Alast time,=0A = >>>> operators do care about having control over the willingness=0A >= >>> =0A >>> of the MN =0A >>> =0A >>>> to have route= optimization. If that the case, then there=0A >>>> =0A >>> s= hould be a =0A >>> =0A >>>> process to enable that kind of auth= orization. No? <<<=0A >>>>=0A >>>> Does the group think that we need = to provide any backend=0A >>>> infrastructure support to enable this typ= e of=0Afunctionality?=0A >>>> =0A >>> Which group(s)?=0A >= >>=0A >>> I think RO is designed to work across the entire Internet,=0A = >>> not limited to a AAA-controlled domain.=0A >>>=0A >>> From te= sts, the benefits of running RO on the MN are=0A >>> apparent only when = the distance MN-CN is much shorter than=0A >>> both MN-HA and CN-HA, in = terms of IP hops.=0A >>>=0A >>> In a closed system, that equation is = not valid, ie, MN is=0A >>> close to both CN and to its HA, and the bene= fits of running=0A >>> RO are minimal, one doesn't gain much at all.=0A = >>>=0A >>> So, in first place I don't see why would a MN want to run = RO=0A >>> at all while in a AAA-controlled (closed) domain. It may=0A = >>> very well be that MN is not interested at all to run RO to a=0A >>= > CN outside the AAA-controlled domain, because it wouldn't=0A >>> gain = much. Then, even if MN would want to do that, I don't=0A >>> see why as= king the local AAA to be authorized to perform RO.=0A >>> =0A >= > [Ahmad]=0A >> Are you assuming that the HA is always in the visited=0A= network? Also,=0A >> V-AAA does not communicate with H-AAA?=0A >> I j= ust want to understand what you meant here.=0A >> Thanks.=0A >>=0A = >> =0A >>> Finally, are you talking about AAA backend authorizing t= he=0AMN=0A >>> or the CN to do RO?=0A >>> =0A >> [Ahmad]=0A = >> AAA infrastructure only can control the MN to have RO or not=0Aand he= nce=0A >> authorization is for the MN not the CN.=0A >> =0A >>= > Alex=0A >>>=0A >>>=0A______________________________________________= ________________________=0A >>> This email has been scanned by the Messa= geLabs Email=0ASecurity System.=0A >>> For more information please visit= =0A >>> http://www.messagelabs.com/email=0A >>>=0A___________________= ___________________________________________________=0A >>>=0A >>> ___= ____________________________________________=0A >>> Mip6 mailing list=0A= >>> Mip6@ietf.org=0A >>> https://www1.ietf.org/mailman/listinfo/mip6= =0A >>>=0A >>> =0A >> ______________________________________= _________=0A >> Mip6 mailing list=0A >> Mip6@ietf.org=0A >> https:= //www1.ietf.org/mailman/listinfo/mip6=0A >> =0A =0A =0A ___= ____________________________________________=0A DiME mailing list=0A = DiME@ietf.org=0A https://www1.ietf.org/mailman/listinfo/dime=0A =0A= =0A=0A=0A=0A=0A=0A --0-1494209095-1189011780=:39234 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
How about this?
RO authorization is part of the sub= scriber profile and using HA-AAA interface and MIP6-Feature-Vector AVP, thi= s is communicated to HA.

MN is free to attempt RO as Raj wants. HA = would block HoTI if MN is not authorized.

My suggestion would be to = enable RO as much as possible.

Regards,

Behcet

----- Original Message ----
From: "jouni.korhonen@teliasonera.com" <= jouni.korhonen@teliasonera.com>
To: Hannes.Tschofenig@gmx.net; dime@i= etf.org
Cc: mip6@ietf.org; sarikaya@ieee.org
Sent: Wednesday, Septemb= er 5, 2007 1:31:47 AM
Subject: RE: [Dime] Re: [Mip6] Diameter Mobile IPv= 6 Bootstrapping: AuthorizingRoute Optimization



Hmm.. le= ts clarify what my "yes" was supposed to mean. An operator
needs to have= a way to indicate to a HA per subscriber basis whether
a RO procedure i= s enabled / disabled (in the HA). This information
can be conveyed e.g. = in the current dime-split draft using the
MIP6-Feature-Vector AVP. IMO t= his is more a policy decision than an
authorization.

Cheers,
&= nbsp;   Jouni



______________________________= __

    From: Behcet Sarikaya [mailto:behcetsarik= aya@yahoo.com]
    Sent: Tuesday, September 04, 200= 7 10:55 PM
    To: Hannes Tschofenig
  =   Cc: Mobile IPv6 Mailing List; dime@ietf.org
  &nbs= p; Subject: Re: [Dime] Re: [Mip6] Diameter Mobile IPv6
Bootstrappin= g: AuthorizingRoute Optimization
    
    
&n= bsp;   I like Jouni's idea of making RO authorization part o= f the
subscriber profile. I think such a thing fits better into the (AAA= )
managed network model. Defining an AVP probably is not necessary.
&= nbsp;   
    Regards,
  =   
    Behcet
    <= br>    
    ----- Original Messa= ge ----
    From: Hannes Tschofenig <Hannes.Tscho= fenig@gmx.net>
    To: Basavaraj Patil <basava= raj.patil@nsn.com>
    Cc: Mobile IPv6 Mailing Li= st <mip6@ietf.org>; dime@ietf.org
    Sent: Tu= esday, September 4, 2007 2:34:20 PM
    Subject: [Di= me] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping:
Authorizing Route Optimization
    
    =
    Hi Raj,
    
 &n= bsp;  you raise a good point. There is no doubt that a networkoperator can
    prevent all end hosts from using = the RO procedure.
    
    Th= e main question therefore is whether the RO procedure has to
enabled / <= br>    disabled on a per user basis.
  &nb= sp; 
    Ciao
    Hannes=
    
    Basavaraj Patil wro= te:
    > Hi Ahmad,
    &g= t;
    > I am skeptical about the need for an MN = being authorized to
use an inherent
    > feat= ure of MIP6. It makes no sense for an MN to be authorized
depending on
    > the network tha= t it is attached to whether it is able to use
RO with CNs.
 &nbs= p;  >
    > -Raj
  &nbs= p; >
    >
    >= ; On 9/4/07 8:57 AM, "ext Ahmad Muhanna" <amuhanna@nortel.com>
wro= te:
    >
    > &n= bsp;
    >> Hi Alex,
   &nb= sp;>>
    >> Just some background:
&n= bsp;   >>
    >> The prop= osed Diameter MIPv6 Application is used to enable
MIPv6 service
 = ;   >> authorization + dynamic security association al= location. As
per the
    >> current applica= tion, the user is authorized for MIPv6 service
without a
    >> clear indication if the user is allo= wed to use Route
Optimization or
    >> not= . Allowing the operator this flexibility makes a lot of
sense. Let us    >> remember in order for the MN to establish= a RO, it needs to
have at
    >> least HoT= I and HoT signals transmitted via the HA which can
act as the
 &= nbsp;  >> authorization enforcement point.
  &= nbsp; >>
    >> Of course, we are t= alking about a network which is controlled
by AAA
   &= nbsp;>> infrastructure since the proposed application is for Diameter=
MIPv6.
    >>
    &= gt;> Also, please see comments inline.
    >&g= t;
    >> Regards,
    >> Ahmad
   &n= bsp;>>  
    >>
  = ;  >>    
    &= gt;>> Subject: Re: [Mip6] Diameter Mobile IPv6 Bootstrapping:
&nbs= p;   >>> Authorizing Route Optimization
 &n= bsp;  >>>
    >>> Hannes= Tschofenig wrote:
    >>>   = ;   
    >>>> Hi all, du= ring his review of "Diameter Mobile IPv6:
HA<->AAA" Ahmad
 = ;   >>>> made the following comment:
 &n= bsp;  >>>>       &= nbsp;
    >>>> We discussed before that= AUTHORIZATION for ROUTE
OPTIMIZATION is
    >>>> needed. I did not see it in= cluded here?! As we discussed
last time,
    >= >>> operators do care about having control over the willingness    >>>>     &nbs= p;  
    >>> of the MN
 = ;   >>>      
&nb= sp;   >>>> to have route optimization. If that t= he case, then there
    >>>>  =       
    >>&g= t; should be a
    >>>   &n= bsp;  
    >>>> process to en= able that kind of authorization. No? <<<
   &nbs= p;>>>>
    >>>> Does the group think that we need to provide any backend
   &= nbsp;>>>> infrastructure support to enable this type of
func= tionality?
    >>>>   &nb= sp;    
    >>> Which = group(s)?
    >>>
   &nbs= p;>>> I think RO is designed to work across the entire Internet,    >>> not limited to a AAA-controlled doma= in.
    >>>
    >= >>  From tests, the benefits of running RO on the MN are    >>> apparent only when the distance MN-CN= is much shorter than
    >>> both MN-HA an= d CN-HA, in terms of IP hops.
    >>>
&n= bsp;   >>> In a closed system, that equation is not valid, ie, MN is
    >>> close to b= oth CN and to its HA, and the benefits of running
   &nbs= p;>>> RO are minimal, one doesn't gain much at all.
  = ;  >>>
    >>> So, in fi= rst place I don't see why would a MN want to run RO
   &n= bsp;>>> at all while in a AAA-controlled (closed) domain. &nb= sp;It may
    >>> very well be that MN is n= ot interested at all to run RO to a
    >>>= CN outside the AAA-controlled domain, because it wouldn't
  &= nbsp; >>> gain much.  Then, even if MN would want t= o do that, I don't
    >>> see why asking t= he local AAA to be authorized to perform RO.
    >= ;>>      
    >> [Ahmad]
    &g= t;> Are you assuming that the HA is always in the visited
network? Al= so,
    >> V-AAA does not communicate with H-A= AA?
    >> I just want to understand what you = meant here.
    >> Thanks.
  &nbs= p; >>
    >>    = ;
    >>> Finally, are you talking about A= AA backend authorizing the
MN
    >>> or= the CN to do RO?
    >>>   =    
    >> [Ahmad]
 &n= bsp;  >> AAA infrastructure only can control the MN to have= RO or not
and hence
    >> authorization i= s for the MN not the CN.
    >>    
 =    >>> Alex
    >>>=
    >>>
_______________________________= _______________________________________
    >>= > This email has been scanned by the MessageLabs Email
Security Syste= m.
    >>> For more information please visi= t
    >>> http://www.messagelabs.com/email
 = ;   >>>
________________________________________= ______________________________
    >>>
&= nbsp;   >>> _______________________________________= ________
    >>> Mip6 mailing list
 = ;   >>> Mip6@ietf.org
    >>> https://www1.ietf.org= /mailman/listinfo/mip6
    >>>
 = ;   >>>      
&nb= sp;   >> _____________________________________________= __
    >> Mip6 mailing list
  &nb= sp; >> Mip6@ietf.org
    >> https://= www1.ietf.org/mailman/listinfo/mip6
    >>=     
    
   =  
    _________________________________________= ______
    DiME mailing list
   &n= bsp;DiME@ietf.org
    https://www1.ietf.org= /mailman/listinfo/dime
    



--0-1494209095-1189011780=:39234-- --===============1034762685== 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 --===============1034762685==-- From dime-bounces@ietf.org Wed Sep 05 15:43:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT0mS-0006IH-UY; Wed, 05 Sep 2007 15:43:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT0mQ-00067V-LB; Wed, 05 Sep 2007 15:43:14 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IT0mP-0007ki-42; Wed, 05 Sep 2007 15:43:14 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l85JKux18643; Wed, 5 Sep 2007 19:20:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: AuthorizingRoute Optimization Date: Wed, 5 Sep 2007 14:23:06 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116904FE3@zrc2hxm2.corp.nortel.com> In-Reply-To: <219961.39234.qm@web84111.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: AuthorizingRoute Optimization Thread-Index: Acfv3qemm0CBinkSQDabcYsSvWShqgAE1cGQ References: <219961.39234.qm@web84111.mail.mud.yahoo.com> From: "Ahmad Muhanna" To: "Behcet Sarikaya" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: fbb024a763f81fc20bcc0df70457576f Cc: mip6@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: , Content-Type: multipart/mixed; boundary="===============0446644430==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0446644430== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EFF2.306D945E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7EFF2.306D945E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Behcet, This is a good suggestion and it is absolutely fine with me. Regards,=20 Ahmad=20 =20 ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Wednesday, September 05, 2007 12:03 PM To: jouni.korhonen@teliasonera.com; dime@ietf.org Cc: mip6@ietf.org Subject: Re: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: AuthorizingRoute Optimization =09 =09 How about this? RO authorization is part of the subscriber profile and using HA-AAA interface and MIP6-Feature-Vector AVP, this is communicated to HA.=20 =09 MN is free to attempt RO as Raj wants. HA would block HoTI if MN is not authorized. =09 My suggestion would be to enable RO as much as possible. =09 Regards, =09 Behcet =09 =09 ----- Original Message ---- From: "jouni.korhonen@teliasonera.com" To: Hannes.Tschofenig@gmx.net; dime@ietf.org Cc: mip6@ietf.org; sarikaya@ieee.org Sent: Wednesday, September 5, 2007 1:31:47 AM Subject: RE: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: AuthorizingRoute Optimization =09 =09 Hmm.. lets clarify what my "yes" was supposed to mean. An operator needs to have a way to indicate to a HA per subscriber basis whether a RO procedure is enabled / disabled (in the HA). This information can be conveyed e.g. in the current dime-split draft using the MIP6-Feature-Vector AVP. IMO this is more a policy decision than an authorization. =09 Cheers, Jouni =09 =09 =09 ________________________________ =09 From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Tuesday, September 04, 2007 10:55 PM To: Hannes Tschofenig Cc: Mobile IPv6 Mailing List; dime@ietf.org Subject: Re: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: AuthorizingRoute Optimization =20 =20 I like Jouni's idea of making RO authorization part of the subscriber profile. I think such a thing fits better into the (AAA) managed network model. Defining an AVP probably is not necessary. =20 Regards, =20 Behcet =20 =20 ----- Original Message ---- From: Hannes Tschofenig To: Basavaraj Patil Cc: Mobile IPv6 Mailing List ; dime@ietf.org Sent: Tuesday, September 4, 2007 2:34:20 PM Subject: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization =20 =20 Hi Raj, =20 you raise a good point. There is no doubt that a network operator can=20 prevent all end hosts from using the RO procedure. =20 The main question therefore is whether the RO procedure has to enabled /=20 disabled on a per user basis. =20 Ciao Hannes =20 Basavaraj Patil wrote: > Hi Ahmad, > > I am skeptical about the need for an MN being authorized to use an inherent > feature of MIP6. It makes no sense for an MN to be authorized depending on > the network that it is attached to whether it is able to use RO with CNs. > > -Raj > > > On 9/4/07 8:57 AM, "ext Ahmad Muhanna" wrote: > > =20 >> Hi Alex, >> >> Just some background: >> >> The proposed Diameter MIPv6 Application is used to enable MIPv6 service >> authorization + dynamic security association allocation. As per the >> current application, the user is authorized for MIPv6 service without a >> clear indication if the user is allowed to use Route Optimization or >> not. Allowing the operator this flexibility makes a lot of sense. Let us >> remember in order for the MN to establish a RO, it needs to have at >> least HoTI and HoT signals transmitted via the HA which can act as the >> authorization enforcement point. >> >> Of course, we are talking about a network which is controlled by AAA >> infrastructure since the proposed application is for Diameter MIPv6. >> >> Also, please see comments inline. >> >> Regards, >> Ahmad >> =20 >> >> =20 >>> Subject: Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: >>> Authorizing Route Optimization >>> >>> Hannes Tschofenig wrote: >>> =20 >>>> Hi all, during his review of "Diameter Mobile IPv6: HA<->AAA" Ahmad >>>> made the following comment: >>>> =20 >>>> We discussed before that AUTHORIZATION for ROUTE OPTIMIZATION is >>>> needed. I did not see it included here?! As we discussed last time, >>>> operators do care about having control over the willingness >>>> =20 >>> of the MN=20 >>> =20 >>>> to have route optimization. If that the case, then there >>>> =20 >>> should be a=20 >>> =20 >>>> process to enable that kind of authorization. No? <<< >>>> >>>> Does the group think that we need to provide any backend >>>> infrastructure support to enable this type of functionality? >>>> =20 >>> Which group(s)? >>> >>> I think RO is designed to work across the entire Internet, >>> not limited to a AAA-controlled domain. >>> >>> From tests, the benefits of running RO on the MN are >>> apparent only when the distance MN-CN is much shorter than >>> both MN-HA and CN-HA, in terms of IP hops. >>> >>> In a closed system, that equation is not valid, ie, MN is >>> close to both CN and to its HA, and the benefits of running >>> RO are minimal, one doesn't gain much at all. >>> >>> So, in first place I don't see why would a MN want to run RO >>> at all while in a AAA-controlled (closed) domain. It may >>> very well be that MN is not interested at all to run RO to a >>> CN outside the AAA-controlled domain, because it wouldn't >>> gain much. Then, even if MN would want to do that, I don't >>> see why asking the local AAA to be authorized to perform RO. >>> =20 >> [Ahmad] >> Are you assuming that the HA is always in the visited network? Also, >> V-AAA does not communicate with H-AAA? >> I just want to understand what you meant here. >> Thanks. >> >> =20 >>> Finally, are you talking about AAA backend authorizing the MN >>> or the CN to do RO? >>> =20 >> [Ahmad] >> AAA infrastructure only can control the MN to have RO or not and hence >> authorization is for the MN not the CN. >> =20 >>> Alex >>> >>> =09 ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security System. >>> For more information please visit >>> http://www.messagelabs.com/email >>> =09 ______________________________________________________________________ >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >>> >>> =20 >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> =20 =20 =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime =20 =09 =09 =09 ------_=_NextPart_001_01C7EFF2.306D945E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks Behcet,
This is a good suggestion and it is absolutely = fine with=20 me.

Regards, =
Ahmad

 

From: Behcet Sarikaya=20 [mailto:behcetsarikaya@yahoo.com]
Sent: Wednesday, = September 05,=20 2007 12:03 PM
To: jouni.korhonen@teliasonera.com;=20 dime@ietf.org
Cc: mip6@ietf.org
Subject: Re: = [Dime] Re:=20 [Mip6] Diameter Mobile IPv6 Bootstrapping: AuthorizingRoute=20 Optimization

How=20 about this?
RO authorization is part of the subscriber profile and = using=20 HA-AAA interface and MIP6-Feature-Vector AVP, this is communicated to = HA.=20

MN is free to attempt RO as Raj wants. HA would block HoTI if = MN is=20 not authorized.

My suggestion would be to enable RO as much as=20 possible.

Regards,

Behcet

-----=20 Original Message ----
From: "jouni.korhonen@teliasonera.com"=20 <jouni.korhonen@teliasonera.com>
To: = Hannes.Tschofenig@gmx.net;=20 dime@ietf.org
Cc: mip6@ietf.org; sarikaya@ieee.org
Sent: = Wednesday,=20 September 5, 2007 1:31:47 AM
Subject: RE: [Dime] Re: [Mip6] = Diameter Mobile=20 IPv6 Bootstrapping: AuthorizingRoute Optimization



Hmm.. lets clarify what my "yes" was supposed to mean. An = operator
needs to have a way to indicate to a HA per subscriber = basis=20 whether
a RO procedure is enabled / disabled (in the HA). This=20 information
can be conveyed e.g. in the current dime-split draft = using=20 the
MIP6-Feature-Vector AVP. IMO this is more a policy decision = than=20 = an
authorization.

Cheers,
    Jouni
<= BR>

________________________________

   &nbs= p;From:=20 Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20
    Sent: Tuesday, September 04, 2007 10:55=20 PM
    To: Hannes=20 Tschofenig
    Cc: Mobile IPv6 Mailing List;=20 dime@ietf.org
    Subject: Re: [Dime] Re: = [Mip6]=20 Diameter Mobile IPv6
Bootstrapping: AuthorizingRoute=20 = Optimization
    
    
&= nbsp;   I=20 like Jouni's idea of making RO authorization part of the
subscriber = profile. I think such a thing fits better into the (AAA)
managed = network=20 model. Defining an AVP probably is not=20 = necessary.
    
    Regards= ,
    
    Behcet
 =    
    
    = ;-----=20 Original Message ----
    From: Hannes = Tschofenig=20 <Hannes.Tschofenig@gmx.net>
    To: = Basavaraj=20 Patil <basavaraj.patil@nsn.com>
    Cc: = Mobile=20 IPv6 Mailing List <mip6@ietf.org>;=20 dime@ietf.org
    Sent: Tuesday, September 4, = 2007=20 2:34:20 PM
    Subject: [Dime] Re: [Mip6] = Diameter=20 Mobile IPv6 Bootstrapping:
Authorizing Route=20 = Optimization
    
    
&= nbsp;   Hi=20 Raj,
    
    you raise = a good=20 point. There is no doubt that a network
operator can=20
    prevent all end hosts from using the RO=20 procedure.
    
    The = main=20 question therefore is whether the RO procedure has to
enabled /=20
    disabled on a per user=20 = basis.
    
    Ciao
&nb= sp;   Hannes
    
  &n= bsp; Basavaraj=20 Patil wrote:
    > Hi=20 Ahmad,
    >
    > = I am=20 skeptical about the need for an MN being authorized to
use an=20 inherent
    > feature of MIP6. It makes no = sense=20 for an MN to be authorized
depending = on
    > the=20 network that it is attached to whether it is able to use
RO with=20 CNs.
    >
    >=20 = -Raj
    >
    >
&= nbsp;   >=20 On 9/4/07 8:57 AM, "ext Ahmad Muhanna"=20 = <amuhanna@nortel.com>
wrote:
    >
=     >  =20
    >> Hi=20 = Alex,
    >>
    >= >=20 Just some=20 = background:
    >>
   &nbs= p;>>=20 The proposed Diameter MIPv6 Application is used to enable
MIPv6=20 service
    >> authorization + dynamic = security=20 association allocation. As
per = the
    >>=20 current application, the user is authorized for MIPv6 = service
without=20 a
    >> clear indication if the user is = allowed=20 to use Route
Optimization or
    >> = not.=20 Allowing the operator this flexibility makes a lot of
sense. Let=20 us
    >> remember in order for the MN to = establish a RO, it needs to
have = at
    >>=20 least HoTI and HoT signals transmitted via the HA which can
act as=20 the
    >> authorization enforcement=20 = point.
    >>
    >= ;>=20 Of course, we are talking about a network which is controlled
by=20 AAA
    >> infrastructure since the = proposed=20 application is for=20 = Diameter
MIPv6.
    >>
  &nb= sp; >>=20 Also, please see comments=20 = inline.
    >>
    &g= t;>=20 Regards,
    >>=20 = Ahmad
    >>  
  &nbs= p; >>
    >>   &nb= sp;=20
    >>> Subject: Re: [Mip6] Diameter = Mobile=20 IPv6 Bootstrapping:
    >>> = Authorizing Route=20 = Optimization
    >>>
   = ; >>>=20 Hannes Tschofenig=20 = wrote:
    >>>    &nb= sp; =20
    >>>> Hi all, during his review = of=20 "Diameter Mobile IPv6:
HA<->AAA"=20 Ahmad
    >>>> made the following=20 = comment:
    >>>>   &nb= sp;    =20
    >>>> We discussed before that=20 AUTHORIZATION for ROUTE
OPTIMIZATION=20 is
    >>>> needed. I did not see = it=20 included here?! As we discussed
last=20 time,
    >>>> operators do care = about=20 having control over the=20 = willingness
    >>>>   =      =20
    >>> of the MN=20 =
    >>>     &nb= sp;=20
    >>>> to have route = optimization. If=20 that the case, then=20 = there
    >>>>    =     =20
    >>> should be a=20 =
    >>>     &nb= sp;=20
    >>>> process to enable that = kind of=20 authorization. No?=20 = <<<
    >>>>
  &= nbsp; >>>>=20 Does the group think that we need to provide any=20 backend
    >>>> infrastructure = support to=20 enable this type=20 = of
functionality?
    >>>> &nb= sp;      =20
    >>> Which=20 = group(s)?
    >>>
   &n= bsp;>>>=20 I think RO is designed to work across the entire=20 Internet,
    >>> not limited to a=20 AAA-controlled=20 = domain.
    >>>
   &nbs= p;>>>  From=20 tests, the benefits of running RO on the MN=20 are
    >>> apparent only when the = distance=20 MN-CN is much shorter than
    >>> = both MN-HA=20 and CN-HA, in terms of IP=20 = hops.
    >>>
    = >>>=20 In a closed system, that equation is not valid, ie, MN=20 is
    >>> close to both CN and to its = HA, and=20 the benefits of running
    >>> RO are = minimal, one doesn't gain much at=20 = all.
    >>>
    &= gt;>>=20 So, in first place I don't see why would a MN want to run=20 RO
    >>> at all while in a = AAA-controlled=20 (closed) domain.  It = may
    >>>=20 very well be that MN is not interested at all to run RO to=20 a
    >>> CN outside the = AAA-controlled=20 domain, because it wouldn't
    >>> = gain=20 much.  Then, even if MN would want to do that, I=20 don't
    >>> see why asking the local = AAA to=20 be authorized to perform=20 = RO.
    >>>     =  =20
    >>=20 [Ahmad]
    >> Are you assuming that the = HA is=20 always in the visited
network? = Also,
    >>=20 V-AAA does not communicate with = H-AAA?
    >> I=20 just want to understand what you meant=20 here.
    >>=20 = Thanks.
    >>
    &g= t;>    =20
    >>> Finally, are you talking = about AAA=20 backend authorizing the
MN
    >>> = or the=20 CN to do=20 = RO?
    >>>     =  =20
    >>=20 [Ahmad]
    >> AAA infrastructure only = can=20 control the MN to have RO or not
and=20 hence
    >> authorization is for the MN = not the=20 CN.
    >>    =20
    >>>=20 = Alex
    >>>
    &= gt;>>
__________________________________________________________= ____________
    >>>=20 This email has been scanned by the MessageLabs Email
Security=20 System.
    >>> For more information = please=20 visit
    >>> http://www.messagelabs.com/email
   = ; >>>
__________________________________________________= ____________________
    >>>
 &nb= sp;  >>>=20 = _______________________________________________
   &nbs= p;>>>=20 Mip6 mailing list
    >>>=20 Mip6@ietf.org
    >>> https://www1.ietf.org/mailman/listinfo/mip6
 =    >>>
    >>>&nb= sp;     =20
    >>=20 = _______________________________________________
   &nbs= p;>>=20 Mip6 mailing list
    >>=20 Mip6@ietf.org
    >> https://www1.ietf.org/mailman/listinfo/mip6
 =    >>    =20 =
    
    
  &= nbsp; _______________________________________________
  = ;  DiME=20 mailing=20 = list
    DiME@ietf.org
    = https://www1.ietf.org/mailman/listinfo/dime
 =    



------_=_NextPart_001_01C7EFF2.306D945E-- --===============0446644430== 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 --===============0446644430==-- From dime-bounces@ietf.org Wed Sep 05 17:02:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT20f-0000Jq-Aq; Wed, 05 Sep 2007 17:02:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT20d-0000JZ-Ht; Wed, 05 Sep 2007 17:01:59 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IT20c-0002xS-Uj; Wed, 05 Sep 2007 17:01:59 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l85L1RC4016309; Thu, 6 Sep 2007 00:01:52 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 00:01:42 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Sep 2007 16:01:40 -0500 Received: from 172.19.244.149 ([172.19.244.149]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 5 Sep 2007 21:01:40 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 05 Sep 2007 16:02:07 -0500 From: Basavaraj Patil To: "ext mip6-bounces@ietf.org" , , Message-ID: Thread-Topic: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing RouteOptimization Thread-Index: AcfvyJxa6CXTMUV7Q1uTmNVccNkm4QACeYDwAAtgixM= In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30222CB4E@SEHAN021MB.tcad.telia.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Sep 2007 21:01:40.0451 (UTC) FILETIME=[F4B46330:01C7EFFF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: mip6@ietf.org, dime@ietf.org Subject: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing RouteOptimization 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, I agree with your comments about the many reasons why RO may fail (firewalls, CN being incapable, HA policy etc.). So I do not think there is any need to specify the RO authorization knob for MIP6. And I do agree that operators will do all sorts of creative things to prevent RO (if that is what they want). But there is no reason for it to specified. -Raj On 9/5/07 10:54 AM, "ext mip6-bounces@ietf.org" wrote: > Hi Brian, > >>> [Ahmad] >>> Why the MN needs to ask for MIPv6 then. It could negotiate >> Simple IPv6 >>> and that is perfectly fine. >> >> I think you mis-understood me, I wasn't talking about using >> MIPv6. A MN can use the IPv6 address it's configured on the >> remote link for communicating with local nodes (eg DNS) >> without using any MIPv6 functionality. It should >> reverse-tunnel the rest. But if we start restricting RO, >> people will start getting creative with their implementations >> and work around it, and none of those will be inter-operable. > > A MN needs to be prepared for failing return routability test > anyway.. there might be an evil firewall in between than causes > the RO to fail. So if the MN does not know whether the HA or > some other intermediate node failed the RO, there is not much > point of trying to do clever things in the MN. Having said this > I think there is no need to explicitly tell the MN whether HA > does some policy based decision on RO. The MN will learn it > eventually.. > >> Jouni's latest email clarified what he meant, but I still >> don't agree an HA RO knob should exist, that's just my opinion. > > Unfortunately I think operators will do it in any case. They > are creative on that ;) And sometimes also forced by regulation. > Doing such policy decision in a HA is more logical place than > trying to do that in a cluster of firewalls. > > > Cheers, > Jouni > >> >> -Brian >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 06 04:08:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITCPn-0004VE-JX; Thu, 06 Sep 2007 04:08:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITC7u-0003Pw-JA; Thu, 06 Sep 2007 03:50:10 -0400 Received: from smail5.alcatel.fr ([64.208.49.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITC7t-0006qZ-3P; Thu, 06 Sep 2007 03:50:10 -0400 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l867n61I001738; Thu, 6 Sep 2007 09:49:06 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 6 Sep 2007 09:49:38 +0200 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 Date: Thu, 6 Sep 2007 09:49:00 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A5013999E6@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Diameter Mobile IPv6 Bootstrapping: AuthorizingRouteOptimization Thread-Index: AcfvyJxa6CXTMUV7Q1uTmNVccNkm4QACeYDwAAtgixMAFc7bAA== From: "DE JUAN HUARTE FEDERICO" To: "Basavaraj Patil" , , X-OriginalArrivalTime: 06 Sep 2007 07:49:38.0165 (UTC) FILETIME=[79A0C250:01C7F05A] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 X-Mailman-Approved-At: Thu, 06 Sep 2007 04:08:38 -0400 Cc: mip6@ietf.org, dime@ietf.org, mip6-bounces@ietf.org Subject: [Dime] RE: [Mip6] Diameter Mobile IPv6 Bootstrapping: AuthorizingRouteOptimization 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, for what is worth, my opinion is that given that it is aknowledged that = network administrators may want to disallow/block RO, this should be = reason enough to specify it What is the harm of notifying "RO not supported" to the MN? I see a difference between: 1- RO does not work because network topology or other reasons 2- RO does not work because of administrative decision The first case is (arguably) an error condition and should be = (potentially) corrected The second case is a desired behaviour There seem to be already mechanisms to block RO (are they documented?), = but what's the MN experience in these conditions? I assume that the MN just experiences a timeout. In a typical = implementation this would lead to a retry and eventually to consider = this as an error condition The implementation in the MN can be cleaner when there's a proper = notification of RO not supported Regards federico -----Message d'origine----- De : Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 Envoy=E9 : mercredi 5 septembre 2007 23:02 =C0 : ext mip6-bounces@ietf.org; brian.haley@hp.com; amuhanna@nortel.com Cc : mip6@ietf.org; dime@ietf.org Objet : Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: = AuthorizingRouteOptimization Hi Jouni, I agree with your comments about the many reasons why RO may fail = (firewalls, CN being incapable, HA policy etc.). So I do not think there is any need to specify the RO authorization knob = for MIP6. And I do agree that operators will do all sorts of creative things to = prevent RO (if that is what they want). But there is no reason for it to = specified. -Raj On 9/5/07 10:54 AM, "ext mip6-bounces@ietf.org" wrote: > Hi Brian, >=20 >>> [Ahmad] >>> Why the MN needs to ask for MIPv6 then. It could negotiate >> Simple IPv6 >>> and that is perfectly fine. >>=20 >> I think you mis-understood me, I wasn't talking about using MIPv6. A = >> MN can use the IPv6 address it's configured on the remote link for=20 >> communicating with local nodes (eg DNS) without using any MIPv6=20 >> functionality. It should reverse-tunnel the rest. But if we start=20 >> restricting RO, people will start getting creative with their=20 >> implementations and work around it, and none of those will be=20 >> inter-operable. >=20 > A MN needs to be prepared for failing return routability test anyway.. = > there might be an evil firewall in between than causes the RO to fail. = > So if the MN does not know whether the HA or some other intermediate=20 > node failed the RO, there is not much point of trying to do clever=20 > things in the MN. Having said this I think there is no need to=20 > explicitly tell the MN whether HA does some policy based decision on=20 > RO. The MN will learn it eventually.. >=20 >> Jouni's latest email clarified what he meant, but I still don't agree = >> an HA RO knob should exist, that's just my opinion. >=20 > Unfortunately I think operators will do it in any case. They are=20 > creative on that ;) And sometimes also forced by regulation. > Doing such policy decision in a HA is more logical place than trying=20 > to do that in a cluster of firewalls. >=20 >=20 > Cheers, > Jouni >=20 >>=20 >> -Brian >>=20 >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >>=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 06 04:17:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITCYn-0005qP-HY; Thu, 06 Sep 2007 04:17:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITCYl-0005py-Io; Thu, 06 Sep 2007 04:17:55 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITCYk-00021L-Pq; Thu, 06 Sep 2007 04:17:55 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 10:17:53 +0200 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 Date: Thu, 6 Sep 2007 10:17:52 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222CB86@SEHAN021MB.tcad.telia.se> In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A5013999E6@FRVELSMBS12.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Diameter Mobile IPv6 Bootstrapping:AuthorizingRouteOptimization Thread-Index: AcfvyJxa6CXTMUV7Q1uTmNVccNkm4QACeYDwAAtgixMAFc7bAAABOAwQ References: <319D54578EAC3147BA8CC78DAB5467A5013999E6@FRVELSMBS12.ad2.ad.alcatel.com> From: To: , , , X-OriginalArrivalTime: 06 Sep 2007 08:17:53.0081 (UTC) FILETIME=[6BE06A90:01C7F05E] X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: mip6@ietf.org, dime@ietf.org, mip6-bounces@ietf.org Subject: [Dime] RE: [Mip6] Diameter Mobile IPv6 Bootstrapping:AuthorizingRouteOptimization 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 federico, > Sent: Thursday, September 06, 2007 10:49 AM > I see a difference between: > 1- RO does not work because network topology or other reasons > 2- RO does not work because of administrative decision The=20 > first case is (arguably) an error condition and should be=20 > (potentially) corrected The second case is a desired behaviour Even if the MN knew something about administrative decision, it still must prepare for failing RO. Even if the mobility service provider allows RO others between the MN and a CN may block RO. > There seem to be already mechanisms to block RO (are they=20 > documented?), but what's the MN experience in these conditions? > I assume that the MN just experiences a timeout. In a typical=20 RO times out and the MN "falls back" to reverse tunneled mode. No need for anything more advanced. RO is just an optimization. Note that the MN has connectivity all the time so it is not really an error case if RO fails. > implementation this would lead to a retry and eventually to=20 > consider this as an error condition The implementation in the=20 > MN can be cleaner when there's a proper notification of RO=20 > not supported I don't think there is a need for suck notification.=20 Cheers, Jouni >=20 > Regards >=20 > federico >=20 > -----Message d'origine----- > De : Basavaraj Patil [mailto:basavaraj.patil@nsn.com] Envoy=E9=20 > : mercredi 5 septembre 2007 23:02 =C0 : ext=20 > mip6-bounces@ietf.org; brian.haley@hp.com;=20 > amuhanna@nortel.com Cc : mip6@ietf.org; dime@ietf.org Objet :=20 > Re: [Mip6] Diameter Mobile IPv6 Bootstrapping:=20 > AuthorizingRouteOptimization >=20 >=20 > Hi Jouni, >=20 > I agree with your comments about the many reasons why RO may=20 > fail (firewalls, CN being incapable, HA policy etc.). >=20 > So I do not think there is any need to specify the RO=20 > authorization knob for MIP6. >=20 > And I do agree that operators will do all sorts of creative=20 > things to prevent RO (if that is what they want). But there=20 > is no reason for it to specified. >=20 > -Raj >=20 >=20 > On 9/5/07 10:54 AM, "ext mip6-bounces@ietf.org"=20 > > wrote: >=20 > > Hi Brian, > >=20 > >>> [Ahmad] > >>> Why the MN needs to ask for MIPv6 then. It could negotiate > >> Simple IPv6 > >>> and that is perfectly fine. > >>=20 > >> I think you mis-understood me, I wasn't talking about=20 > using MIPv6. A=20 > >> MN can use the IPv6 address it's configured on the remote link for=20 > >> communicating with local nodes (eg DNS) without using any MIPv6=20 > >> functionality. It should reverse-tunnel the rest. But if=20 > we start=20 > >> restricting RO, people will start getting creative with their=20 > >> implementations and work around it, and none of those will be=20 > >> inter-operable. > >=20 > > A MN needs to be prepared for failing return routability=20 > test anyway..=20 > > there might be an evil firewall in between than causes the=20 > RO to fail.=20 > > So if the MN does not know whether the HA or some other=20 > intermediate=20 > > node failed the RO, there is not much point of trying to do clever=20 > > things in the MN. Having said this I think there is no need to=20 > > explicitly tell the MN whether HA does some policy based=20 > decision on=20 > > RO. The MN will learn it eventually.. > >=20 > >> Jouni's latest email clarified what he meant, but I still=20 > don't agree=20 > >> an HA RO knob should exist, that's just my opinion. > >=20 > > Unfortunately I think operators will do it in any case. They are=20 > > creative on that ;) And sometimes also forced by regulation. > > Doing such policy decision in a HA is more logical place=20 > than trying=20 > > to do that in a cluster of firewalls. > >=20 > >=20 > > Cheers, > > Jouni > >=20 > >>=20 > >> -Brian > >>=20 > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > >>=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 06 04:20:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITCax-0006cK-Fk; Thu, 06 Sep 2007 04:20:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITCav-0006bB-36; Thu, 06 Sep 2007 04:20:09 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITCat-0007cJ-K6; Thu, 06 Sep 2007 04:20:09 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 10:20:02 +0200 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] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing RouteOptimization Date: Thu, 6 Sep 2007 10:20:00 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222CB87@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing RouteOptimization Thread-Index: AcfvyJxa6CXTMUV7Q1uTmNVccNkm4QACeYDwAAtgixMAERAKMA== References: <59D7431DE2527D4CB0F1EFEDA5683ED30222CB4E@SEHAN021MB.tcad.telia.se> From: To: , , , X-OriginalArrivalTime: 06 Sep 2007 08:20:02.0031 (UTC) FILETIME=[B8BC9FF0:01C7F05E] X-Spam-Score: -4.0 (----) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: mip6@ietf.org, 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 Raj, "no reason for it to specified" will just lead to so many times seen creativeness on AAA interfaces in other SDOs. I don't think that will benefit anyone.. at least those who end up deploying these backend AAA systems. Cheers, Jouni > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Thursday, September 06, 2007 12:02 AM > To: ext mip6-bounces@ietf.org; brian.haley@hp.com; amuhanna@nortel.com > Cc: mip6@ietf.org; dime@ietf.org > Subject: [Dime] Re: [Mip6] Diameter Mobile IPv6=20 > Bootstrapping: Authorizing RouteOptimization >=20 >=20 >=20 > Hi Jouni, >=20 > I agree with your comments about the many reasons why RO may=20 > fail (firewalls, CN being incapable, HA policy etc.). >=20 > So I do not think there is any need to specify the RO=20 > authorization knob for MIP6. >=20 > And I do agree that operators will do all sorts of creative=20 > things to prevent RO (if that is what they want). But there=20 > is no reason for it to specified. >=20 > -Raj >=20 >=20 > On 9/5/07 10:54 AM, "ext mip6-bounces@ietf.org"=20 > > wrote: >=20 > > Hi Brian, > >=20 > >>> [Ahmad] > >>> Why the MN needs to ask for MIPv6 then. It could negotiate > >> Simple IPv6 > >>> and that is perfectly fine. > >>=20 > >> I think you mis-understood me, I wasn't talking about=20 > using MIPv6. A=20 > >> MN can use the IPv6 address it's configured on the remote link for=20 > >> communicating with local nodes (eg DNS) without using any MIPv6=20 > >> functionality. It should reverse-tunnel the rest. But if=20 > we start=20 > >> restricting RO, people will start getting creative with their=20 > >> implementations and work around it, and none of those will be=20 > >> inter-operable. > >=20 > > A MN needs to be prepared for failing return routability=20 > test anyway..=20 > > there might be an evil firewall in between than causes the=20 > RO to fail.=20 > > So if the MN does not know whether the HA or some other=20 > intermediate=20 > > node failed the RO, there is not much point of trying to do clever=20 > > things in the MN. Having said this I think there is no need to=20 > > explicitly tell the MN whether HA does some policy based=20 > decision on=20 > > RO. The MN will learn it eventually.. > >=20 > >> Jouni's latest email clarified what he meant, but I still=20 > don't agree=20 > >> an HA RO knob should exist, that's just my opinion. > >=20 > > Unfortunately I think operators will do it in any case. They are=20 > > creative on that ;) And sometimes also forced by regulation. > > Doing such policy decision in a HA is more logical place=20 > than trying=20 > > to do that in a cluster of firewalls. > >=20 > >=20 > > Cheers, > > Jouni > >=20 > >>=20 > >> -Brian > >>=20 > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > >>=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=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 Sep 06 08:49:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITGnZ-0001Ji-UQ; Thu, 06 Sep 2007 08:49:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITGnY-0001A7-Mz; Thu, 06 Sep 2007 08:49:28 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITGnX-0000h3-V1; Thu, 06 Sep 2007 08:49:28 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l86CnL603606; Thu, 6 Sep 2007 12:49:21 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 Date: Thu, 6 Sep 2007 07:49:18 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371169059DC@zrc2hxm2.corp.nortel.com> In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A5013999E6@FRVELSMBS12.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Diameter Mobile IPv6 Bootstrapping: AuthorizingRouteOptimization Thread-Index: AcfvyJxa6CXTMUV7Q1uTmNVccNkm4QACeYDwAAtgixMAFc7bAAALE6UA References: <319D54578EAC3147BA8CC78DAB5467A5013999E6@FRVELSMBS12.ad2.ad.alcatel.com> From: "Ahmad Muhanna" To: "DE JUAN HUARTE FEDERICO" , "Basavaraj Patil" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: mip6@ietf.org, dime@ietf.org, mip6-bounces@ietf.org Subject: [Dime] RE: [Mip6] Diameter Mobile IPv6 Bootstrapping: AuthorizingRouteOptimization 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 Federico, Excellent! & I fully Agree!=20 Regards, Ahmad =20 > -----Original Message----- > From: DE JUAN HUARTE FEDERICO=20 > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr]=20 > Sent: Thursday, September 06, 2007 2:49 AM > To: Basavaraj Patil; brian.haley@hp.com; Muhanna, Ahmad (RICH1:2H10) > Cc: mip6@ietf.org; dime@ietf.org; mip6-bounces@ietf.org > Subject: RE: [Mip6] Diameter Mobile IPv6 Bootstrapping:=20 > AuthorizingRouteOptimization >=20 > Hi, >=20 > for what is worth, my opinion is that given that it is=20 > aknowledged that network administrators may want to=20 > disallow/block RO, this should be reason enough to specify it=20 > What is the harm of notifying "RO not supported" to the MN? >=20 > I see a difference between: > 1- RO does not work because network topology or other reasons > 2- RO does not work because of administrative decision The=20 > first case is (arguably) an error condition and should be=20 > (potentially) corrected The second case is a desired behaviour >=20 > There seem to be already mechanisms to block RO (are they=20 > documented?), but what's the MN experience in these conditions? > I assume that the MN just experiences a timeout. In a typical=20 > implementation this would lead to a retry and eventually to=20 > consider this as an error condition The implementation in the=20 > MN can be cleaner when there's a proper notification of RO=20 > not supported >=20 > Regards >=20 > federico >=20 > -----Message d'origine----- > De : Basavaraj Patil [mailto:basavaraj.patil@nsn.com] Envoy=E9=20 > : mercredi 5 septembre 2007 23:02 =C0 : ext=20 > mip6-bounces@ietf.org; brian.haley@hp.com;=20 > amuhanna@nortel.com Cc : mip6@ietf.org; dime@ietf.org Objet :=20 > Re: [Mip6] Diameter Mobile IPv6 Bootstrapping:=20 > AuthorizingRouteOptimization >=20 >=20 > Hi Jouni, >=20 > I agree with your comments about the many reasons why RO may=20 > fail (firewalls, CN being incapable, HA policy etc.). >=20 > So I do not think there is any need to specify the RO=20 > authorization knob for MIP6. >=20 > And I do agree that operators will do all sorts of creative=20 > things to prevent RO (if that is what they want). But there=20 > is no reason for it to specified. >=20 > -Raj >=20 >=20 > On 9/5/07 10:54 AM, "ext mip6-bounces@ietf.org"=20 > > wrote: >=20 > > Hi Brian, > >=20 > >>> [Ahmad] > >>> Why the MN needs to ask for MIPv6 then. It could negotiate > >> Simple IPv6 > >>> and that is perfectly fine. > >>=20 > >> I think you mis-understood me, I wasn't talking about=20 > using MIPv6. A=20 > >> MN can use the IPv6 address it's configured on the remote link for=20 > >> communicating with local nodes (eg DNS) without using any MIPv6=20 > >> functionality. It should reverse-tunnel the rest. But if=20 > we start=20 > >> restricting RO, people will start getting creative with their=20 > >> implementations and work around it, and none of those will be=20 > >> inter-operable. > >=20 > > A MN needs to be prepared for failing return routability=20 > test anyway..=20 > > there might be an evil firewall in between than causes the=20 > RO to fail.=20 > > So if the MN does not know whether the HA or some other=20 > intermediate=20 > > node failed the RO, there is not much point of trying to do clever=20 > > things in the MN. Having said this I think there is no need to=20 > > explicitly tell the MN whether HA does some policy based=20 > decision on=20 > > RO. The MN will learn it eventually.. > >=20 > >> Jouni's latest email clarified what he meant, but I still=20 > don't agree=20 > >> an HA RO knob should exist, that's just my opinion. > >=20 > > Unfortunately I think operators will do it in any case. They are=20 > > creative on that ;) And sometimes also forced by regulation. > > Doing such policy decision in a HA is more logical place=20 > than trying=20 > > to do that in a cluster of firewalls. > >=20 > >=20 > > Cheers, > > Jouni > >=20 > >>=20 > >> -Brian > >>=20 > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > >>=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 06 08:58:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITGwU-00033A-WB; Thu, 06 Sep 2007 08:58:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITGwT-00031e-CC; Thu, 06 Sep 2007 08:58:41 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITGwR-0005zd-D4; Thu, 06 Sep 2007 08:58:41 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l86CwW604995; Thu, 6 Sep 2007 12:58:33 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 Date: Thu, 6 Sep 2007 07:58:29 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116905A01@zrc2hxm2.corp.nortel.com> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30222CB86@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Diameter Mobile IPv6 Bootstrapping:AuthorizingRouteOptimization Thread-Index: AcfvyJxa6CXTMUV7Q1uTmNVccNkm4QACeYDwAAtgixMAFc7bAAABOAwQAAocYuA= References: <319D54578EAC3147BA8CC78DAB5467A5013999E6@FRVELSMBS12.ad2.ad.alcatel.com> <59D7431DE2527D4CB0F1EFEDA5683ED30222CB86@SEHAN021MB.tcad.telia.se> From: "Ahmad Muhanna" To: , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: mip6@ietf.org, dime@ietf.org, mip6-bounces@ietf.org Subject: [Dime] RE: [Mip6] Diameter Mobile IPv6 Bootstrapping:AuthorizingRouteOptimization 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, Actually after the nice description by Federico, I am thinking why not = informing the MN. If we mimic MIPv4, for example, I remember there is a = code of value "I think it is 1", which means successful registration BUT = Simultaneous Binding is not allowed. Can we say that after the HA receives the AAA indication about RO, would = returning a code such like this one to let the MN know that Registration = is successful, however, RO is not Allowed; is possible? For backward compatibility, for example, code 0 still can be used to = mean that Registration is successful and RO is Allowed, as it is now. It is actually amazing and I never though that it could be as simple and = harmless as it is now. One bit in MIP6-Feature-Victor between the HA and AAA and another status = code between the HA and MN. All-in-All less than 2 lines. My 2 cents. Regards, Ahmad =20 > -----Original Message----- > From: jouni.korhonen@teliasonera.com=20 > [mailto:jouni.korhonen@teliasonera.com]=20 > Sent: Thursday, September 06, 2007 3:18 AM > To: Federico.De_Juan_Huarte@alcatel-lucent.fr;=20 > basavaraj.patil@nsn.com; brian.haley@hp.com; Muhanna, Ahmad=20 > (RICH1:2H10) > Cc: mip6@ietf.org; dime@ietf.org; mip6-bounces@ietf.org > Subject: RE: [Mip6] Diameter Mobile IPv6=20 > Bootstrapping:AuthorizingRouteOptimization >=20 > Hi federico, >=20 > > Sent: Thursday, September 06, 2007 10:49 AM >=20 > > I see a difference between: > > 1- RO does not work because network topology or other reasons > > 2- RO does not work because of administrative decision The first=20 > > case is (arguably) an error condition and should be > > (potentially) corrected The second case is a desired behaviour >=20 > Even if the MN knew something about administrative decision,=20 > it still must prepare for failing RO. Even if the mobility=20 > service provider allows RO others between the MN and a CN may=20 > block RO. >=20 > > There seem to be already mechanisms to block RO (are they=20 > > documented?), but what's the MN experience in these conditions? > > I assume that the MN just experiences a timeout. In a typical >=20 > RO times out and the MN "falls back" to reverse tunneled mode. > No need for anything more advanced. RO is just an optimization. > Note that the MN has connectivity all the time so it is not=20 > really an error case if RO fails. >=20 > > implementation this would lead to a retry and eventually to=20 > consider=20 > > this as an error condition The implementation in the MN can=20 > be cleaner=20 > > when there's a proper notification of RO not supported >=20 > I don't think there is a need for suck notification.=20 >=20 > Cheers, > Jouni >=20 >=20 > >=20 > > Regards > >=20 > > federico > >=20 > > -----Message d'origine----- > > De : Basavaraj Patil [mailto:basavaraj.patil@nsn.com] Envoy=E9 > > : mercredi 5 septembre 2007 23:02 =C0 : ext mip6-bounces@ietf.org;=20 > > brian.haley@hp.com; amuhanna@nortel.com Cc : mip6@ietf.org;=20 > > dime@ietf.org Objet : > > Re: [Mip6] Diameter Mobile IPv6 Bootstrapping:=20 > > AuthorizingRouteOptimization > >=20 > >=20 > > Hi Jouni, > >=20 > > I agree with your comments about the many reasons why RO may fail=20 > > (firewalls, CN being incapable, HA policy etc.). > >=20 > > So I do not think there is any need to specify the RO authorization=20 > > knob for MIP6. > >=20 > > And I do agree that operators will do all sorts of creative=20 > things to=20 > > prevent RO (if that is what they want). But there is no=20 > reason for it=20 > > to specified. > >=20 > > -Raj > >=20 > >=20 > > On 9/5/07 10:54 AM, "ext mip6-bounces@ietf.org"=20 > > > > wrote: > >=20 > > > Hi Brian, > > >=20 > > >>> [Ahmad] > > >>> Why the MN needs to ask for MIPv6 then. It could negotiate > > >> Simple IPv6 > > >>> and that is perfectly fine. > > >>=20 > > >> I think you mis-understood me, I wasn't talking about > > using MIPv6. A > > >> MN can use the IPv6 address it's configured on the=20 > remote link for=20 > > >> communicating with local nodes (eg DNS) without using any MIPv6=20 > > >> functionality. It should reverse-tunnel the rest. But if > > we start > > >> restricting RO, people will start getting creative with their=20 > > >> implementations and work around it, and none of those will be=20 > > >> inter-operable. > > >=20 > > > A MN needs to be prepared for failing return routability > > test anyway..=20 > > > there might be an evil firewall in between than causes the > > RO to fail.=20 > > > So if the MN does not know whether the HA or some other > > intermediate > > > node failed the RO, there is not much point of trying to=20 > do clever=20 > > > things in the MN. Having said this I think there is no need to=20 > > > explicitly tell the MN whether HA does some policy based > > decision on > > > RO. The MN will learn it eventually.. > > >=20 > > >> Jouni's latest email clarified what he meant, but I still > > don't agree > > >> an HA RO knob should exist, that's just my opinion. > > >=20 > > > Unfortunately I think operators will do it in any case. They are=20 > > > creative on that ;) And sometimes also forced by regulation. > > > Doing such policy decision in a HA is more logical place > > than trying > > > to do that in a cluster of firewalls. > > >=20 > > >=20 > > > Cheers, > > > Jouni > > >=20 > > >>=20 > > >> -Brian > > >>=20 > > >> _______________________________________________ > > >> Mip6 mailing list > > >> Mip6@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/mip6 > > >>=20 > > >=20 > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 06 21:18:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITSUL-0003AH-Ao; Thu, 06 Sep 2007 21:18:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITSUK-0002tk-1N for dime@ietf.org; Thu, 06 Sep 2007 21:18:24 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITSUJ-00062o-9N for dime@ietf.org; Thu, 06 Sep 2007 21:18:23 -0400 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l871IDYQ047933; Thu, 6 Sep 2007 21:18:14 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46E0A6D5.2020402@tari.toshiba.com> Date: Thu, 06 Sep 2007 21:18:13 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "Arun Santhanam, TLS-Chennai" References: <66E8AEE9980BB44CA5FCAD39EBA56AC6023DB5D0@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC6023DB5D0@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by toshi17.tari.toshiba.com id l871IDYQ047933 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: dime@ietf.org Subject: [Dime] Re: Reg. Failed Avp in ACA Msg. 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 Arun, Sorry for the late reply. > I think we can include Failed-Avp for ACA section,= just as we have for rest of the command code. This will help to report e= rrors of type=20 > DAMETER_INVALID_AVP_VALUE, DIAMETER_MISSING_AVP =85= & so on We should add optional Error-Message and Failed-AVP to ACA. > =20 > Suggestion 2) > Section 6.9. Acct-Application-Id AVP definition say= s that the Avp must be present in all the Accounting Messages=20 > Then we can change the present grammar from [Acct-Application= -Id] to {Acct-Application-Id} for ACR and ACA command code. I'm guessing that this AVP is optional because it is present either as=20 part of the Vendor-Specific-Application-Id or a 'standalone' AVP. And=20 only one of them can be present at a time. (See 9.7.1). regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 07 00:38:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITVba-0003XP-3h; Fri, 07 Sep 2007 00:38:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITVbZ-0003XG-4C for dime@ietf.org; Fri, 07 Sep 2007 00:38:05 -0400 Received: from gws04.hcl.in ([203.105.186.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITVbY-0001fW-8F for dime@ietf.org; Fri, 07 Sep 2007 00:38:05 -0400 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 86D3C3600C3; Fri, 7 Sep 2007 10:08:01 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws04.hcl.in (Postfix) with ESMTPid 701EA36009A; Fri, 7 Sep 2007 10:08:01 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 10:08:00 +0530 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, 7 Sep 2007 10:08:16 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC602459C85@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reg. Failed Avp in ACA Msg. Thread-Index: Acfw7PwE38lAkVJhQs6F0N7erh37VgAG9cqQ References: <66E8AEE9980BB44CA5FCAD39EBA56AC6023DB5D0@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <46E0A6D5.2020402@tari.toshiba.com> From: "Arun Santhanam, TLS-Chennai" To: "Victor Fajardo" X-OriginalArrivalTime: 07 Sep 2007 04:38:00.0921 (UTC) FILETIME=[DF264C90:01C7F108] X-imss-version: 2.048 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-13.1501 TC:1F TRN:27 TV:3.6.1039(15408.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: dime@ietf.org Subject: [Dime] RE: Reg. Failed Avp in ACA Msg. 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, Thanks for the response=2E Regards -Arun -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari=2Etoshiba=2Ecom]=20 Sent: Friday, September 07, 2007 6:48 AM To: Arun Santhanam, TLS-Chennai Cc: dime@ietf=2Eorg Subject: Re: Reg=2E Failed Avp in ACA Msg=2E Hi Arun, Sorry for the late reply=2E > I think we can include Failed-Avp for ACA section, just as we have for rest of the command code=2E This will help to report errors of type=20 > DAMETER_INVALID_AVP_VALUE, DIAMETER_MISSING_AVP =2E=2E=2E=2E& so on We should add optional Error-Message and Failed-AVP to ACA=2E > =20 > Suggestion 2) > Section 6=2E9=2E Acct-Application-Id AVP definition says that the Avp must be present in all the Accounting Messages=20 > Then we can change the present grammar from [Acct-Application-Id] to {Acct-Application-Id} for ACR and ACA command code=2E I'm guessing that this AVP is optional because it is present either as=20 part of the Vendor-Specific-Application-Id or a 'standalone' AVP=2E And=20 only one of them can be present at a time=2E (See 9=2E7=2E1)=2E regards, victor DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have=20 received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and=20 attachments please check them for viruses and defect=2E ---------------------------------------------------------------------------= -------------------------------------------- _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 07 09:15:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdgT-0000id-7l; Fri, 07 Sep 2007 09:15:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdgR-0000ck-UI for dime@ietf.org; Fri, 07 Sep 2007 09:15:39 -0400 Received: from gws03.mail.hcl.in ([203.105.186.19] helo=gws03.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITdgP-0000Gs-MT for dime@ietf.org; Fri, 07 Sep 2007 09:15:39 -0400 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 531C937C0B3; Fri, 7 Sep 2007 18:45:35 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws03.hcl.in (Postfix) with ESMTPid 3AF7637C0A5; Fri, 7 Sep 2007 18:45:35 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 18:45:34 +0530 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, 7 Sep 2007 18:46:15 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC60248A1BA@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reg. Failed Avp in ACA Msg. Thread-Index: Acfw7PwE38lAkVJhQs6F0N7erh37VgAXQ4uw References: <66E8AEE9980BB44CA5FCAD39EBA56AC6023DB5D0@CHN-HCLT-EVS02.HCLT.CO RP.HCL.IN> <46E0A6D5.2020402@tari.toshiba.com> From: "Arun Santhanam, TLS-Chennai" To: X-OriginalArrivalTime: 07 Sep 2007 13:15:34.0841 (UTC) FILETIME=[2CBA7290:01C7F151] X-imss-version: 2.048 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-7.6108 TC:1F TRN:34 TV:3.6.1039(15408.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Subject: [Dime] RE: Reg. Failed Avp in ACA Msg. 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, The following are some of my suggestion w=2Er=2Et to the draft http://www=2Eietf=2Eorg/internet-drafts/draft-ietf-dime-rfc3588bis-06=2Etxt Suggestion 3) Redirect-Host can be added to the ACA message inclusion of this will really help the accounting messages to flow through redirect agents=2E Since the relay and redirect are Protocol Transparent they will be supporting Accounting and all other Diameter Applications=2E=20 (Let me know your suggestion) Suggestion 4) Section "10=2E2=2E Accounting AVP Table" I find that Error-Reporting-Host is having "0+" for ACA message =2EI think It should be "0-1" (Correct me if I'm wrong)=2E Thx -Arun -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari=2Etoshiba=2Ecom]=20 Sent: Friday, September 07, 2007 6:48 AM To: Arun Santhanam, TLS-Chennai Cc: dime@ietf=2Eorg Subject: Re: Reg=2E Failed Avp in ACA Msg=2E Hi Arun, Sorry for the late reply=2E > I think we can include Failed-Avp for ACA section, just as we have for rest of the command code=2E This will help to report errors of type=20 > DAMETER_INVALID_AVP_VALUE, DIAMETER_MISSING_AVP =2E=2E=2E=2E& so on We should add optional Error-Message and Failed-AVP to ACA=2E > =20 > Suggestion 2) > Section 6=2E9=2E Acct-Application-Id AVP definition says that the Avp must be present in all the Accounting Messages=20 > Then we can change the present grammar from [Acct-Application-Id] to {Acct-Application-Id} for ACR and ACA command code=2E I'm guessing that this AVP is optional because it is present either as=20 part of the Vendor-Specific-Application-Id or a 'standalone' AVP=2E And=20 only one of them can be present at a time=2E (See 9=2E7=2E1)=2E regards, victor DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and=20 attachments please check them for viruses and defect=2E ---------------------------------------------------------------------------= -------------------------------------------- _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Sep 09 14:56:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IURx5-00080L-1Z; Sun, 09 Sep 2007 14:56:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IURx3-0007xy-WD for dime@ietf.org; Sun, 09 Sep 2007 14:56:10 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IURx2-0002Bc-N6 for dime@ietf.org; Sun, 09 Sep 2007 14:56:09 -0400 Received: (qmail invoked by alias); 09 Sep 2007 18:56:06 -0000 Received: from p549866A8.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.102.168] by mail.gmx.net (mp040) with SMTP; 09 Sep 2007 20:56:06 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19iYOkF3RBihO7LHpkNG9eSvLgf+PZwoVDO+W/GXV 8LPcCsmxZ4lsPj Message-ID: <46E441BD.3020708@gmx.net> Date: Sun, 09 Sep 2007 20:55:57 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org Subject: Re: [Dime] [Fwd: Request for review of "AAA Framework for Multicasting"] References: <46C8A642.2040102@gmx.net> In-Reply-To: <46C8A642.2040102@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: a4a24b484706be629f915bfb1a3e4771 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, I have also reviewed http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework-04.txt Summary: The document does not only outline a model of AAA interworking but describes a model for service access that happens to be distributed using multicast. The model envisions that the user would interact with an NSP who then interacts with a content provider. The model is a bit questionable and I doubt it is inline with other work that is taking place in this field. Before addressing the AAA part the entire model needs to be clarified and described in a good way. The current document does not really provide indication (a) about what would be needed from RADIUS and/or Diameter and (b) it does not consider state-of-the-art (my opinion) Furthermore, the document has too many pages and does not contain a lot of relevant content. A couple of comments below: * There are many editorial issues. I strongly suggest to use XML2RFC. * Abstract: "... and to invoice such customers in a reliable and efficient manner. " Hmmm. I guess that invoicing is largely outside the scope of IETF work. I am also not sure what reliable and efficient could mean in this context. * Section 2.1 Terminology I suggest to replace most of the terms with references to existing documents. * Section 4.1 Framework " The CP hopes to collect accounting information related to the access of their content. " Why would the CP "HOPE"? The content provider can decide what is wants to charge the user. " The CP may choose to authenticate and authorize NSPs which are eligible to provide users access to its contents. " The CP does not really authenticate or authorize NSPs. It has IP connectivity and obviously need to have a business contract for doing that. Additionally, I am curious why you use plural here (NSPs). " When the CP cannot (e.g. error or resource issues) or decides not (e.g. policy issues) to deliver content, the CP is responsible for notifying the NSP of the reason. It is up to the NSP how to relay or translate the messages to the user. " I doubt that the NSP cares. Why doesn't the CP send the message to the user right away. The user has interacted with the CP in the first place. In fact, I find Figure 1 strange since it shows that the user interacts indirectly with the CP rather than directly. There is something wrong. (Btw, the figure has no caption.) " The NSP is responsible for managing its network resources. The NSP may perform admission control. It is also responsible for relaying the AAA messages from the CP whether the user is eligible to receive content (authentication by proxy), " Hmm. Why does the NSP relay AAA messages when the user interacts with the CP? " In certain cases the CP and NSP may have a contractual relationship in which the NSP is authorized to make the content authorization decision based on mutually predetermined criteria: in such cases the NSP- AAA may also make the content authorization decision without querying the CP-AAA. When the NSP cannot or decides not to multicast to users, the NSP may notify the users of the reason. It is recommended that the NSP notify eligible users of the reason for not multicasting content when it is due network or content unavailability, for example. The NSP may choose not to notify ineligible users of the reason for any case. " From a AAA point of view it does not really matter whether the NSP and the CP have a contract. I don't understand why the NSP will make the content authorization decision. What authorization decision would that be? The story that the NSP would notify the user about any content related issues seems really strange to me. * Section 4.2 " The actual mapping rules for NSPs and CPs to map user IDs with the IDs in other provider domains is a matter for the providers. A solution should provide an API between the providers to flexibly support various mapping methods. " Why would one want to map identities? * Section 4.3 Accounting " Standardization of the logs or messages to share content usage information is important to support a single NSP sharing accounting information with multiple CPs or a single CP receiving from multiple NSPs. " You envision that NSPs would send accounting information to the CP. Just to understand you correctly did you have something like http://tools.ietf.org/wg/nsis/draft-dressler-nsis-metering-nslp-05.txt Imagine the following case that there are multiple networks between the CP and the end host. Would each intermediate domain send accounting records to the CP? * Section 5.1 Basic Connection Model " First a user that requests content sends an Access request to an NSP which then forwards it on to the appropriate CP for Authentication and Authorization purposes. " Why would a user send an "requst" to an NSP when it wants to get access to, for example, a video? Figure 2 looks like something obtained from an ITU-T doc. In the IETF you typically do not speak about interfaces but rather about protocols. " multicast AAA server " What is this? " ... access policy is downloaded to the NAS (conditional access policy control function.) " What policies do you want to download? Figure 3: The entire discussion about Resource and Admission Control System (RACS) is most likely irrelevant for the AAA interaction. Are you referring to work outside the IETF or to the Diameter QoS work? http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-01.txt Ciao Hannes Hannes Tschofenig wrote: > During the IETF#69 meeting I have also asked for reviewers. Two > persons offered help: > * Jouni Korhonen > * Tina Tsou > > Their review is still pending! > > -------- Original Message -------- > Subject: Request for review of "AAA Framework for Multicasting" > Date: Sat, 18 Aug 2007 14:49:00 -0700 > From: Bernard Aboba > To: radiusext@ops.ietf.org > > > > A request for review has been received relating to the document "AAA > Framework for Multicasting" which is under development within the > MBONED WG. The document is available for inspection here: > http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework-04.txt > > > The Request for Review will last until September 5, 2007. Please post > your comments on this document to the RADEXT WG mailing list, CC:'ing > the document authors. > > Information on the review request was previously posted to the RADEXT > WG mailing list: > http://ops.ietf.org/lists/radiusext/2007/msg00528.html > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > > _______________________________________________ > 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 Mon Sep 10 02:00:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUcJh-0007Xu-7D; Mon, 10 Sep 2007 02:00:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUcJf-0007Xm-Bn for dime@ietf.org; Mon, 10 Sep 2007 02:00:11 -0400 Received: from gws03.hcl.in ([203.105.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUcJb-0001in-B7 for dime@ietf.org; Mon, 10 Sep 2007 02:00:11 -0400 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 736CD37C197; Mon, 10 Sep 2007 11:30:03 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws03.hcl.in (Postfix) with ESMTPid 6678A37C194; Mon, 10 Sep 2007 11:30:03 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 11:30:03 +0530 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, 10 Sep 2007 11:30:00 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC60248A7EB@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some more Suggestions in 3588-bis-06!! Thread-Index: Acfw7PwE38lAkVJhQs6F0N7erh37VgAXQ4uwAIlfR+A= From: "Arun Santhanam, TLS-Chennai" To: X-OriginalArrivalTime: 10 Sep 2007 06:00:03.0050 (UTC) FILETIME=[D434D4A0:01C7F36F] X-imss-version: 2.048 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-0.2755 TC:1F TRN:34 TV:3.6.1039(15410.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Subject: [Dime] Some more Suggestions in 3588-bis-06!! 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, The following are some of my suggestion w=2Er=2Et to the draft http://www=2Eietf=2Eorg/internet-drafts/draft-ietf-dime-rfc3588bis-06=2Etxt Suggestion 3) Redirect-Host can be added to the ACA message inclusion of this will really help the accounting messages to flow through redirect agents=2E Since the relay and redirect are Protocol Transparent they will be supporting Accounting and all other Diameter Applications=2E=20 (Let me know your suggestion) Suggestion 4) Section "10=2E2=2E Accounting AVP Table" I find that Error-Reporting-Host is having "0+" for ACA message =2EI think It should be "0-1" (Correct me if I'm wrong)=2E Thx -Arun -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari=2Etoshiba=2Ecom]=20 Sent: Friday, September 07, 2007 6:48 AM To: Arun Santhanam, TLS-Chennai Cc: dime@ietf=2Eorg Subject: Re: Reg=2E Failed Avp in ACA Msg=2E Hi Arun, Sorry for the late reply=2E > I think we can include Failed-Avp for ACA section, just as we have for rest of the command code=2E This will help to report errors of type=20 > DAMETER_INVALID_AVP_VALUE, DIAMETER_MISSING_AVP =2E=2E=2E=2E=2E& so on We should add optional Error-Message and Failed-AVP to ACA=2E > =20 > Suggestion 2) > Section 6=2E9=2E Acct-Application-Id AVP definition says that the Avp must be present in all the Accounting Messages=20 > Then we can change the present grammar from [Acct-Application-Id] to {Acct-Application-Id} for ACR and ACA command code=2E I'm guessing that this AVP is optional because it is present either as=20 part of the Vendor-Specific-Application-Id or a 'standalone' AVP=2E And=20 only one of them can be present at a time=2E (See 9=2E7=2E1)=2E regards, victor DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and=20 attachments please check them for viruses and defect=2E ---------------------------------------------------------------------------= -------------------------------------------- _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Sep 10 08:31:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUiQG-00077l-05; Mon, 10 Sep 2007 08:31:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUiQD-00075y-Sn for dime@ietf.org; Mon, 10 Sep 2007 08:31:21 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUiQC-0003Vf-PE for dime@ietf.org; Mon, 10 Sep 2007 08:31:21 -0400 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 l8ACUkag065371; Mon, 10 Sep 2007 08:30:50 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46E538F6.4010900@tari.toshiba.com> Date: Mon, 10 Sep 2007 08:30:46 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "Arun Santhanam, TLS-Chennai" References: <66E8AEE9980BB44CA5FCAD39EBA56AC60248A7EB@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC60248A7EB@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: dime@ietf.org Subject: [Dime] Re: Some more Suggestions in 3588-bis-06!! 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 Arun, > Suggestion 3) Redirect-Host can be added to the ACA message > inclusion of this will really help the accounting messages to flow > through redirect agents. Since the relay and redirect are Protocol > Transparent they will be supporting Accounting and all other Diameter > Applications. > (Let me know your suggestion) > I don't think we need to update ACA for this. Redirected answers follow the ABNF in 7.2. Secondly, sec 6.1.8 already describes when how to do redirection. > Suggestion 4) Section "10.2. Accounting AVP Table" I find that > Error-Reporting-Host is having "0+" for ACA message .I think It should > be "0-1" (Correct me if I'm wrong). > Ok. -- victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Sep 10 09:55:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUjjQ-0002uZ-2o; Mon, 10 Sep 2007 09:55:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUjjP-0002td-7y for dime@ietf.org; Mon, 10 Sep 2007 09:55:15 -0400 Received: from gws04.mail.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUjjO-0006st-0Z for dime@ietf.org; Mon, 10 Sep 2007 09:55:15 -0400 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 92BC4360065; Mon, 10 Sep 2007 19:25:11 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws04.hcl.in (Postfix) with ESMTPid 73F51360027; Mon, 10 Sep 2007 19:25:11 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 19:25:11 +0530 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, 10 Sep 2007 19:25:56 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC6024BCE6B@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some more Suggestions in 3588-bis-06!! Thread-Index: AcfzpnbSXtUmeOMSQ7aUVp39NVvcEgAAr1egAAFcI9AAAL5rMA== References: <66E8AEE9980BB44CA5FCAD39EBA56AC60248A7EB@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <46E538F6.4010900@tari.toshiba.com> From: "Arun Santhanam, TLS-Chennai" To: "Victor Fajardo" X-OriginalArrivalTime: 10 Sep 2007 13:55:11.0129 (UTC) FILETIME=[34587890:01C7F3B2] X-imss-version: 2.048 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-10.0027 TC:1F TRN:53 TV:3.6.1039(15416.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: dime@ietf.org Subject: [Dime] RE: Some more Suggestions in 3588-bis-06!! 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 agree with your point regarding the processing of the Redirected Answer Message but as per the section=20 " 6=2E1=2E8=2E Redirecting requests When a redirect agent receives a request whose routing entry is set to REDIRECT, it MUST reply with an answer message with the 'E' bit set, while maintaining the Hop-by-Hop Identifier in the header, and include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION=2E Each of the servers associated with the routing entry are added in separate Redirect-Host AVP=2E" When the Answer "E" bit is set then it will not confirm to the normal answer message instead it will confirm to "E" bit Grammar =20 "7=2E2=2E Error Bit The 'E' (Error Bit) in the Diameter header is set when the request caused a protocol-related error (see Section 7=2E1=2E3)=2E A message= with the 'E' bit MUST NOT be sent as a response to an answer message=2E Note that a message with the 'E' bit set is still subjected to the processing rules defined in Section 6=2E2=2E When set, the answer message will not conform to the ABNF specification for the command, and will instead conform to the following ABNF:" =20 If this is the case then we need to include the redirect host in "E" bit response message which is currently missing in "E" bit response message * [ Redirect-Host ] [ Redirect-Host-Usage ] [ Redirect-Max-Cache-Time ]=20 Existing Grammar for "E" bit response Message ::=3D < Diameter Header: code, ERR [PXY] > 0*1< Session-Id > { Origin-Host } { Origin-Realm } { Result-Code } [ Origin-State-Id ] [ Error-Message ] [ Error-Reporting-Host ] [ Failed-AVP ] * [ Proxy-Info ] * [ AVP ] Please let me know you suggestion on this issue=2E If the above statement is correct then we don't require having Redirect-Host Avp's in STA RAA ASA=2E Please let me know your suggestion=2E Thx -Arun -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari=2Etoshiba=2Ecom]=20 Sent: Monday, September 10, 2007 6:01 PM To: Arun Santhanam, TLS-Chennai Cc: dime@ietf=2Eorg Subject: Re: Some more Suggestions in 3588-bis-06!! Hi Arun, > Suggestion 3) Redirect-Host can be added to the ACA message > inclusion of this will really help the accounting messages to flow > through redirect agents=2E Since the relay and redirect are Protocol > Transparent they will be supporting Accounting and all other Diameter > Applications=2E=20 > (Let me know your suggestion) > =20 I don't think we need to update ACA for this=2E Redirected answers follow=20 the ABNF in 7=2E2=2E Secondly, sec 6=2E1=2E8 already describes when how to= do=20 redirection=2E > Suggestion 4) Section "10=2E2=2E Accounting AVP Table" I find that > Error-Reporting-Host is having "0+" for ACA message =2EI think It should > be "0-1" (Correct me if I'm wrong)=2E > =20 Ok=2E -- victor DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have=20 received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and=20 attachments please check them for viruses and defect=2E ---------------------------------------------------------------------------= -------------------------------------------- _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Sep 10 10:09:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUjwq-00012G-T2; Mon, 10 Sep 2007 10:09:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUjwp-00011z-GO for dime@ietf.org; Mon, 10 Sep 2007 10:09:07 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUjwp-0006bT-8J for dime@ietf.org; Mon, 10 Sep 2007 10:09:07 -0400 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 l8AE8eBl065793; Mon, 10 Sep 2007 10:08:40 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46E54FE8.3080805@tari.toshiba.com> Date: Mon, 10 Sep 2007 10:08:40 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "Arun Santhanam, TLS-Chennai" References: <66E8AEE9980BB44CA5FCAD39EBA56AC60248A7EB@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <46E538F6.4010900@tari.toshiba.com> <66E8AEE9980BB44CA5FCAD39EBA56AC6024BCE6B@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC6024BCE6B@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: dime@ietf.org Subject: [Dime] Re: Some more Suggestions in 3588-bis-06!! 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 Arun, > > If this is the case then we need to include the redirect host in "E" bit > response message which is currently missing in "E" bit response message > * [ Redirect-Host ] > [ Redirect-Host-Usage ] > [ Redirect-Max-Cache-Time ] > > Existing Grammar for "E" bit response Message > > ::= < Diameter Header: code, ERR [PXY] > > 0*1< Session-Id > > { Origin-Host } > { Origin-Realm } > { Result-Code } > [ Origin-State-Id ] > [ Error-Message ] > [ Error-Reporting-Host ] > [ Failed-AVP ] > * [ Proxy-Info ] > * [ AVP ] > Sure. > Please let me know you suggestion on this issue. > > If the above statement is correct then we don't require having > Redirect-Host Avp's in STA RAA ASA. > I was looking at this a while ago and I was'nt exactly sure why these AVPs where there in the first place. Sec 6.1.8 and 7.2 should be enough. Unless there are some semantics defined, I think these AVPs should be removed from these messages as well. I don't see any backward compatibility issue if these AVPs are removed. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Sep 10 14:15:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUnmt-00030G-36; Mon, 10 Sep 2007 14:15:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUnmo-0002yq-Ny; Mon, 10 Sep 2007 14:15:02 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUnmo-0006xe-BL; Mon, 10 Sep 2007 14:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 3A2182AC3F; Mon, 10 Sep 2007 18:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IUnmn-00061C-VL; Mon, 10 Sep 2007 14:15:01 -0400 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, 10 Sep 2007 14:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-rfc3588bis-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 --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-07.txt Pages : 158 Date : 2007-9-10 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-07.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-07.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-07.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: <2007-9-10131120.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-rfc3588bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-10131120.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 Mon Sep 10 15:24:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUos7-00027G-4B; Mon, 10 Sep 2007 15:24:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUos5-0001xx-JK for dime@ietf.org; Mon, 10 Sep 2007 15:24:33 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUos4-0001Gn-AS for dime@ietf.org; Mon, 10 Sep 2007 15:24:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Sep 2007 15:27:02 -0400 Message-ID: From: "Mark Jones" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Dime] [3588-bis] Auth/Acct-Application-Id redundant? 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 Section 6.8 of the 3588-bis-06 draft states that the "Auth-Application-Id MUST also be present in all Authentication and/or Authorization messages that are defined in a separate Diameter specification and have an Application ID assigned." A similar statement appears in section 6.9 for the Acct-Application-Id. However, the application ID is already present in the message header and sections 6.8/6.9 state that "the value of the Auth/Acct-Application-Id AVP MUST match the application id present in the diameter message header except when used in a CER or CEA messages". I understand the usage of these AVPs in CER/CEA but what is the reason for their mandatory (and apparently redundant) inclusion in the other message types? The draft also has statements about command routing based on these fields but why would one ever dig them out of the message body when an identical value appears in the header? I looked back through the DIME mailing list archive and it appears that the previous threads sought to clarify the content of these AVPs rather than question their mandatory presence.=20 I'd like to see this cleaned up in the bis because the current text results in IETF commands that can not be re-used in vendor-specific applications without ABNF conflicts. I will provide cleanup text for the bis if the list agrees that this is worthwhile. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Sep 10 15:40:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUp7Y-0000qt-5S; Mon, 10 Sep 2007 15:40:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUp7W-0000n3-5A for dime@ietf.org; Mon, 10 Sep 2007 15:40:30 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUp7V-0001hh-1o for dime@ietf.org; Mon, 10 Sep 2007 15:40:30 -0400 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 l8AJe5Ir067503; Mon, 10 Sep 2007 15:40:05 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46E59D95.6060306@tari.toshiba.com> Date: Mon, 10 Sep 2007 15:40:05 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] [3588-bis] Auth/Acct-Application-Id redundant? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Mark, > Section 6.8 of the 3588-bis-06 draft states that the > "Auth-Application-Id MUST also be present in all Authentication and/or > Authorization messages that are defined in a separate Diameter > specification and have an Application ID assigned." A similar statement > appears in section 6.9 for the Acct-Application-Id. > > However, the application ID is already present in the message header and > sections 6.8/6.9 state that "the value of the Auth/Acct-Application-Id > AVP MUST match the application id present in the diameter message header > except when used in a CER or CEA messages". > > I understand the usage of these AVPs in CER/CEA but what is the reason > for their mandatory (and apparently redundant) inclusion in the other > message types? The draft also has statements about command routing > based on these fields but why would one ever dig them out of the message > body when an identical value appears in the header? > > I looked back through the DIME mailing list archive and it appears that > the previous threads sought to clarify the content of these AVPs rather > than question their mandatory presence. > You may also want to take a look at http://www.tschofenig.priv.at:8080/diameter-interop/issue13 which discusses this issue and what resolution we currently came up with. > I'd like to see this cleaned up in the bis because the current text > results in IETF commands that can not be re-used in vendor-specific > applications without ABNF conflicts. I will provide cleanup text for the > bis if the list agrees that this is worthwhile. > What conflicts ? I suggest we should be very careful with this issue. Changing the rules/semantics on application id (especially in the header) is very dramatic at this stage of the game. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 11 03:32:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV0EQ-0001bs-0U; Tue, 11 Sep 2007 03:32:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV0EP-0001a6-3x for dime@ietf.org; Tue, 11 Sep 2007 03:32:21 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IV0EO-0003Rr-Kb for dime@ietf.org; Tue, 11 Sep 2007 03:32:21 -0400 Received: (qmail invoked by alias); 11 Sep 2007 07:32:19 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp044) with SMTP; 11 Sep 2007 09:32:19 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18ZqtkTfswZ1hezUKGj/59i/3gPncuDBanpmSMnil 7E69SZXbzIBeKu Message-ID: <46E64481.3010407@gmx.net> Date: Tue, 11 Sep 2007 09:32:17 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Victor Fajardo , xiayangsong@huawei.com Subject: Re: [Dime] Diameter QoS Attributes Reviewers References: <46B04AA6.1020400@gmx.net> In-Reply-To: <46B04AA6.1020400@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: e5ba305d0e64821bf3d8bc5d3bb07228 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 Frank, Hi Victor, at the Chicago IETF meeting you have volunteered to review the Diameter QoS draft. I don't recall that I have seen your reviews. Could you please post your review asap? Ciao Hannes Hannes Tschofenig wrote: > I would like to thank > > * Victor Fajardo > * Frank Xia > > for their willingness to review the Diameter QoS Attributes draft > within the next 2 weeks. > > 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 Tue Sep 11 03:33:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV0FH-0002Zl-Aj; Tue, 11 Sep 2007 03:33:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV0FG-0002Zg-DH for dime@ietf.org; Tue, 11 Sep 2007 03:33:14 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IV0FF-0003Sd-Tt for dime@ietf.org; Tue, 11 Sep 2007 03:33:14 -0400 Received: (qmail invoked by alias); 11 Sep 2007 07:33:13 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp040) with SMTP; 11 Sep 2007 09:33:13 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+f3BIRrJqf8Ndk8FkOrAAMmKiwaA5P/U8WI+6KxU SSHmKu86LiuM8h Message-ID: <46E644B6.70902@gmx.net> Date: Tue, 11 Sep 2007 09:33:10 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "David B. Nelson" , Tolga Asveren , Victor Fajardo Subject: Re: [Dime] Diameter QoS Draft Reviewers References: <46B04A34.3040706@gmx.net> In-Reply-To: <46B04A34.3040706@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: e5ba305d0e64821bf3d8bc5d3bb07228 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 David, Hi Tolga, Hi Victor, at the Chicago IETF meeting you have volunteered to review the Diameter QoS draft. I don't recall that I have seen your reviews. Could you please post your review asap? Ciao Hannes Hannes Tschofenig wrote: > I would like to thank > > * Tolga Asveren > * Victor Fajardo > * David B. Nelson > > for their willingness to review the Diameter QoS draft within the next > 2 weeks. > > 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 Tue Sep 11 03:33:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV0Fq-0003OE-6b; Tue, 11 Sep 2007 03:33:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV0Fo-0003O9-An for dime@ietf.org; Tue, 11 Sep 2007 03:33:48 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IV0Fn-0003TD-Lt for dime@ietf.org; Tue, 11 Sep 2007 03:33:48 -0400 Received: (qmail invoked by alias); 11 Sep 2007 07:33:46 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp029) with SMTP; 11 Sep 2007 09:33:46 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/UtB46Ae7UgAGc0hbtw73J3HfDyFBmXLbDrf+nsG Rd7yO4uuSrMe0j Message-ID: <46E644D8.10302@gmx.net> Date: Tue, 11 Sep 2007 09:33:44 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ulf Bodin , aland@nitros9.org Subject: Re: [Dime] Diameter Design Guidelines Draft Reviewers References: <46B04B7E.4040404@gmx.net> In-Reply-To: <46B04B7E.4040404@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 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 Alan, Hi Ulf, at the Chicago IETF meeting you have volunteered to review the Diameter Design Guidelines draft I haven't seen your review of it yet. Could you post it asap? Ciao Hannes PS: Thanks to Wolfgang for doing the review. Hannes Tschofenig wrote: > I would like to thank > > * Wolfgang Steigerwald > * Ulf Bodin > * Alan DeKok > > for their willingness to review the Diameter Design Guidelines draft > within the next 2 weeks. > > 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 Tue Sep 11 04:46:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV1OV-0006PS-37; Tue, 11 Sep 2007 04:46:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV16O-0004W4-PM for dime@ietf.org; Tue, 11 Sep 2007 04:28:08 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV16N-0004kL-Ik for dime@ietf.org; Tue, 11 Sep 2007 04:28:08 -0400 Received: from [10.0.1.38] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id 0F61DA7083; Tue, 11 Sep 2007 01:27:57 -0700 (PDT) Message-ID: <46E65186.1090803@nitros9.org> Date: Tue, 11 Sep 2007 10:27:50 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Dime] Diameter Design Guidelines Draft Reviewers References: <46B04B7E.4040404@gmx.net> <46E644D8.10302@gmx.net> In-Reply-To: <46E644D8.10302@gmx.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 X-Mailman-Approved-At: Tue, 11 Sep 2007 04:46:49 -0400 Cc: Ulf Bodin , 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 Hannes Tschofenig wrote: > I haven't seen your review of it yet. > Could you post it asap? From the -02 draft: Section 4.1.1: o Can the new functionality be fulfilled by creating a new application independent from the existing applications ? ... I would expect that the answer to that question is *always* "yes". The issue appears to be one of redundancy in functionality. i.e. two applications can be independent, and have significant redundancy. The goal here appears to be maximizing reuse by minimizing redundancy. o Care should be taken to avoid a liberal method of importing many commands that results in a monolithic and hard to manage application which supports many different functionality. ... That sentence is a little long and could be clarified by splitting it into shorter pieces. Nit: at the top of page 7, the paragraphs are not separated by whitespace. ..., messages for different applications providing service to the same user may end up in different servers would then need to be co-related. ... Is that supposed to be "correlated"? Section 4.2: So design considerations have been outline to ease the decision making process. ... Using "So" to start a sentence is not recommended. Also "outline" is missing a "d", to match the tense of the previous verb. Nit: The bullet points in 4.2.1 aren't separated by whitespace. The rules are strict in the case where the AVPs to be added is mandatory. A mandatory cannot be ... "A mandatory ..." what? The sentence needs a subject. I suggest adding "AVP" after "mandatory". [1] states that doing so would require the definition of a new application. ... I suggest adding a point to a specific section of the reference. e.g. "Section X.Y of [1] states..." This makes it easier to find the text in the reference, and also makes the sentence easier to parse. This comment applies to multiple references to [1] in the text, which are not further qualified to section or subsection. If one or more of the above conditions are true, the AVP is consider mandatory. ... Maybe "... the AVP MUST be made mandatory". I don't know what it means to have an AVP "considered" mandatory. It's a nice consideration to have, but what does it mean for the application designer? These questions are not comprehensive in any way but in all cases the semantics of the application must change to justify the use of mandatory AVPs. ... That text doesn't inspire confidence. Non-comprehensive guidelines leave a lot of room for interpretation by application designers. I suggest saying that there are more considerations which can apply, which are application-specific, and not enumerated here. That phrasing makes it a little clearer that the application designer should take great care in marking AVP's mandatory or not. However, care should also be taken when opting for optional AVPs ... Nit: Suggest "... when using optional AVPs". It's awkard to use the same work multiple times. e.g. "We opted to opt-in to the optional options." Some of the issues associated with using optional AVPs are: ... Given the text following the bullet points, I suggest re-phrasing the bullet points as a checklist of things to look for. Section 4.3: This section deals with even more granularity than Section 4.1 and Section 4.2. ... Granularity of what? Maybe "deals with AVP rules in even more granularity..." Section 6.4: o For general AAA applications, Diameter requires more message exchanges for the same set of services compared to RADIUS. Therefore, application designers should consider scalability issues during the design process. ... Are there specific guidelines that can be followed? o Application design should be agnostic to any Diameter topology. ... I would say "should not be dependent on any Diameter topology". That phrasing seems a little more forceful. There should be more spacing between the following bullet points. I also have a number of non-substantive comments on phrasing and consistency, but they are not included here. Alan DeKok. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 11 07:52:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV4IU-0007Kl-8e; Tue, 11 Sep 2007 07:52:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV4IT-0007KZ-DU for dime@ietf.org; Tue, 11 Sep 2007 07:52:49 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV4IS-0001iF-W8 for dime@ietf.org; Tue, 11 Sep 2007 07:52:49 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id l8BBqk9i016503; Tue, 11 Sep 2007 07:52:46 -0400 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] Diameter QoS Draft Reviewers Date: Tue, 11 Sep 2007 07:52:46 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188216@sonusmail04.sonusnet.com> In-Reply-To: <46E644B6.70902@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Draft Reviewers Thread-Index: Acf0RgbfJ/cgFGCXSiyK2RRzhae70QAI+viw References: <46B04A34.3040706@gmx.net> <46E644B6.70902@gmx.net> From: "Asveren, Tolga" To: "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 Hannes, I sent my review at 05/08/2007 and also had a follow-up discussion with Pete (I guess all during your vacation ;-) ). I think there are a few pending issues left but IMHO these can be best discussed once we have the next version of the document (which I am really looking forward to). Thanks, Tolga=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, September 11, 2007 3:33 AM > To: David B. Nelson; Tolga Asveren; Victor Fajardo > Cc: dime@ietf.org > Subject: Re: [Dime] Diameter QoS Draft Reviewers >=20 > Hi David, > Hi Tolga, > Hi Victor, >=20 > at the Chicago IETF meeting you have volunteered to review the Diameter > QoS draft. > I don't recall that I have seen your reviews. >=20 > Could you please post your review asap? >=20 > Ciao > Hannes >=20 > Hannes Tschofenig wrote: > > I would like to thank > > > > * Tolga Asveren > > * Victor Fajardo > > * David B. Nelson > > > > for their willingness to review the Diameter QoS draft within the next > > 2 weeks. > > > > 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 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 11 07:57:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV4Mi-00010b-OU; Tue, 11 Sep 2007 07:57:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV4Mh-00010T-Bs for dime@ietf.org; Tue, 11 Sep 2007 07:57:11 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IV4Mf-0000FU-RS for dime@ietf.org; Tue, 11 Sep 2007 07:57:11 -0400 Received: (qmail invoked by alias); 11 Sep 2007 11:57:08 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp018) with SMTP; 11 Sep 2007 13:57:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18ncmJmgyon0sV4iebTHqVJsA5UUluJUqbPwQ8prO 8P93El+tPbolVV Message-ID: <46E68293.8080501@gmx.net> Date: Tue, 11 Sep 2007 13:57:07 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [Dime] Diameter QoS Draft Reviewers References: <46B04A34.3040706@gmx.net> <46E644B6.70902@gmx.net> <033458F56EC2A64E8D2D7B759FA3E7E7188216@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188216@sonusmail04.sonusnet.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: 4b800b1eab964a31702fa68f1ff0e955 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 Tolga, thanks. I missed that one. Ciao Hannes Asveren, Tolga wrote: > Hi Hannes, > > I sent my review at 05/08/2007 and also had a follow-up discussion with > Pete (I guess all during your vacation ;-) ). I think there are a few > pending issues left but IMHO these can be best discussed once we have > the next version of the document (which I am really looking forward to). > > Thanks, > Tolga > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Tuesday, September 11, 2007 3:33 AM >> To: David B. Nelson; Tolga Asveren; Victor Fajardo >> Cc: dime@ietf.org >> Subject: Re: [Dime] Diameter QoS Draft Reviewers >> >> Hi David, >> Hi Tolga, >> Hi Victor, >> >> at the Chicago IETF meeting you have volunteered to review the >> > Diameter > >> QoS draft. >> I don't recall that I have seen your reviews. >> >> Could you please post your review asap? >> >> Ciao >> Hannes >> >> Hannes Tschofenig wrote: >> >>> I would like to thank >>> >>> * Tolga Asveren >>> * Victor Fajardo >>> * David B. Nelson >>> >>> for their willingness to review the Diameter QoS draft within the >>> > next > >>> 2 weeks. >>> >>> 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 From dime-bounces@ietf.org Tue Sep 11 09:05:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV5Qa-0005dX-F8; Tue, 11 Sep 2007 09:05:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV5Gq-0005pm-Mr; Tue, 11 Sep 2007 08:55:12 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV5Go-0001mq-KB; Tue, 11 Sep 2007 08:55:12 -0400 X-IronPort-AV: E=Sophos;i="4.20,237,1186351200"; d="scan'208,217";a="152814497" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 Sep 2007 14:55:10 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8BCt9Xd030892; Tue, 11 Sep 2007 14:55:09 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8BCt7EP005718; Tue, 11 Sep 2007 12:55:09 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 14:55:04 +0200 Received: from [144.254.53.188] ([144.254.53.188]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 14:55:03 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) To: dime@ietf.org Message-Id: <8CA3470D-D813-4184-9F09-66766FA33ED1@cisco.com> From: Francois Le Faucheur Date: Tue, 11 Sep 2007 14:54:58 +0200 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Sep 2007 12:55:03.0751 (UTC) FILETIME=[F8980570:01C7F472] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=27139; t=1189515309; x=1190379309; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20 |Subject:=20dime-diameter-qos-01=20handling=20of=20QoS=20Signaling=20Prox ies |Sender:=20; bh=OeLTVLZqVgCF7d7nN0YFds368VDwdjhyu4C2UlzvEV0=; b=qx7+m9GPiW45h76ynmkQKmgG+t0r7/pUZbULNnvm69Bbxt+/abmgqLtcsiW2JirdWjMyJMNd hZnVie9ErdWMczU6Ez5Qroamby8ZG0t5LMCmhJk1HYL4EDbKPIX6Jhfg; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -2.2 (--) X-Scan-Signature: 6e8a3b85ef670172081194f0b0f68e6f X-Mailman-Approved-At: Tue, 11 Sep 2007 09:05:14 -0400 Cc: Le Faucheur Francois , tsvwg tsvwg Subject: [Dime] dime-diameter-qos-01 handling of QoS Signaling Proxies 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="===============0813743411==" Errors-To: dime-bounces@ietf.org --===============0813743411== Content-Type: multipart/alternative; boundary=Apple-Mail-8-754701087 --Apple-Mail-8-754701087 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello, 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). draft-ietf-tsvwg-rsvp-proxy-approaches discusses RSVP Sender Proxy and RSVP Receiver Proxy. NSIS has defined similar NSIS signaling proxy entities. 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). Just for illustration, *A* could perhaps look something like this: 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--....----| | | | |=====================Data Flow==============....===>| | | | +- - - - - ACR - - - - - >| | |(START,QoS-Resources,Cost| | |CC-Time,Acc-Multisess-id)| | | +--------+--------------+ | | | Report for successful | | | | QoS reservation | | | |Update of reserved QoS | | | | resources | | | +--------+--------------+ | |< - - - - ACA - - - - - -+ | | | Just for illustration, *B* could perhaps look something like this: 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----+ | | | | |=====================Data Flow==============....===>| | | | +- - - - - ACR - - - - - >| | |(START,QoS-Resources,Cost| | |CC-Time,Acc-Multisess-id)| | | +--------+--------------+ | | | Report for successful | | | | QoS reservation | | | |Update of reserved QoS | | | | resources | | | +--------+--------------+ | |< - - - - ACA - - - - - -+ | | | 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) Would the DIME WG be willing to address these QOS reservation proxy scenarios in dime-diameter-qos? Thank you FRancois --Apple-Mail-8-754701087 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hello,

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=A0the actual sender) or terminated by a = Signaling Receiver Proxy (on behalf of=A0the actual = receiver).

draft-ietf-tsvwg-rsvp-proxy-approaches discusses RSVP = Sender Proxy and RSVP Receiver Proxy. NSIS has defined similar NSIS = signaling proxy entities.

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=A0would 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=A0Authorization Request from a NE, ability for the AAA=A0Authorizing = 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).

Just for illustration, *A* = could perhaps look something like this:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = Authorizing
=A0 =A0=A0 End-Host=A0 =A0 =A0 =A0=A0 Network Element=A0 = =A0 =A0 =A0 =A0 =A0=A0 Entity
=A0=A0 requesting QoS=A0 =A0 = =A0 ( Diameter=A0 =A0 =A0 =A0 =A0 =A0 =A0 ( = Diameter
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 QoS = Client)=A0 =A0 =A0 =A0 =A0 =A0=A0 QoS Server)
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0=A0 |
=A0=A0 =A0=A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = +--------+--------------+
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 = Authorize new flow=A0 =A0|
=A0=A0 =A0=A0 =A0|=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0=A0= =A0....=A0 =A0 =A0=A0 =A0=A0 =A0|
=A0=A0 =A0=A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Sig Sender Proxy needed|
=A0=A0 =A0=A0 =A0|=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = +--------+--------------+
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |< - - - - XXX - - - - - = -+
=A0=A0= =A0=A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | =A0 = =A0(...Sender-Proxy) =A0 =A0|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0=A0 +-------+---------+
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0=A0 |Install QoS state|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0=A0 |=A0 =A0 =A0=A0 +=A0 =A0 =A0 =A0=A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0=A0 | Initiate QoS =A0 =A0|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0=A0 | Reservation=A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 QoS = Responder
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = Node
=A0= =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0=A0 +-------+---------+=A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 = +----------QoS-Reserve---....--->|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |<---------QoS-Response--....----|
=A0=A0 =A0=A0 =A0|=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0=A0 |=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>|
=A0 =A0 =A0=A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 +- - - - - ACR - - - - - = >|
=A0= =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |(START,QoS-Resources,Cost|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 = |CC-Time,Acc-Multisess-id)|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = +--------+--------------+
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Report for = successful |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0=A0 QoS reservation=A0 =A0=A0 = |
=A0 = =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |Update of reserved QoS |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 = resources=A0 =A0 =A0 =A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = +--------+--------------+
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |< - - - - ACA - - - - - = -+
=A0 = =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |



Just for illustration, *B* = could perhaps look something like this:

=A0 =A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0= =A0Authorizing
=A0 =A0=A0 End-Host=A0 =A0 =A0 =A0=A0 Network Element=A0 = =A0 =A0 =A0 =A0 =A0=A0 Entity
=A0=A0 requesting QoS=A0 =A0 = =A0 ( Diameter=A0 =A0 =A0 =A0 =A0 =A0 =A0 ( = Diameter
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 QoS = Client)=A0 =A0 =A0 =A0 =A0 =A0=A0 QoS Server)
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0=A0 |
=A0 =A0 =A0=A0 +---QoS-Reserve---->|=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 +- - - - - QAR - - - - - = >|
=A0= =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |(QoS-Resources,Cost,=A0 =A0=A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0=A0 = QoS-Auth-Data,User-ID)|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = +--------+--------------+
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 = Authorize request=A0 =A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0=A0 = =A0=A0 ...=A0 =A0 =A0=A0 =A0=A0 =A0|
=A0=A0 =A0=A0 =A0|=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Sig = Receiver Proxy needed|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = +--------+--------------+
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |< - - - - YYY - - - - - = -+
=A0 = =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |(Result-Code,CC-Time,Cost|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |... Receiver-Proxy)|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0=A0 +-------+---------+
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0=A0 |Install QoS state|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0=A0 |=A0 =A0 =A0=A0 +=A0 =A0 =A0 =A0=A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0=A0 | Authz. session=A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0=A0 | /Authz-time,=A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 QoS = Responder
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0=A0 |=A0 = CC-Time,Cost/=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = Node
=A0= =A0 =A0=A0 =A0|=A0 =A0 =A0 =A0 =A0=A0 |+ Receiver Proxy | =A0 =A0=A0 =A0=A0= =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0|
=A0=A0 =A0=A0 =A0|=A0 =A0 =A0 = =A0 =A0=A0 +-------+---------+=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = |
=A0 = =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 +=A0 =A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0|
=A0= =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0|
=A0 =A0 =A0=A0 = |<--QoS-Response----+=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = |
=A0 = =A0 =A0=A0 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Data Flow=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D....=3D=3D=3D>|
=A0 =A0 = =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 +- - - - - ACR - - - - - = >|
=A0= =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |(START,QoS-Resources,Cost|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 = |CC-Time,Acc-Multisess-id)|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = +--------+--------------+
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Report for = successful |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0=A0 QoS reservation=A0 =A0=A0 = |
=A0 = =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |Update of reserved QoS |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 = resources=A0 =A0 =A0 =A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = +--------+--------------+
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |< - - - - ACA - - - - - = -+
=A0 = =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |


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=A0the=A0network. 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.=A0It 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=A0Category 1 and = 2)

Would the DIME WG be willing = to address these QOS reservation proxy scenarios in = dime-diameter-qos?

Thank = you
FRancois

= --Apple-Mail-8-754701087-- --===============0813743411== 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 --===============0813743411==-- From dime-bounces@ietf.org Tue Sep 11 09:40:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV5yl-0005Mf-FH; Tue, 11 Sep 2007 09:40:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV5yj-0005MZ-TT for dime@ietf.org; Tue, 11 Sep 2007 09:40:33 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV5yi-0002zX-MD for dime@ietf.org; Tue, 11 Sep 2007 09:40:33 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id l8BDeRwL027407; Tue, 11 Sep 2007 09:40:27 -0400 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] dime-diameter-qos-01 handling of QoS Signaling Proxies Date: Tue, 11 Sep 2007 09:40:26 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E718821A@sonusmail04.sonusnet.com> In-Reply-To: <8CA3470D-D813-4184-9F09-66766FA33ED1@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] dime-diameter-qos-01 handling of QoS Signaling Proxies Thread-Index: Acf0dGwAONSut4hcRPiy8FvjRXHQZQAA7yJg References: <8CA3470D-D813-4184-9F09-66766FA33ED1@cisco.com> From: "Asveren, Tolga" To: "Francois Le Faucheur" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 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 To me this makes sense; it overcomes the practical issue most endpoints = not having support for e2e signaling. Actually, I guess this approach = can be used to reserve resources in any segment of the path, i.e. not = necessarily the whole path except the endpoints. B doesn't look to me like "Push" at all but this is a detail for now. IMHO Diameter QoS Application should have support for that type of use. Thanks, Tolga ________________________________________ 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 Hello, 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=A0the actual sender) or terminated by a Signaling Receiver Proxy (on = behalf of=A0the actual receiver). draft-ietf-tsvwg-rsvp-proxy-approaches discusses RSVP Sender Proxy and = RSVP Receiver Proxy. NSIS has defined similar NSIS signaling proxy = entities. 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=A0would 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=A0Authorization Request from a NE, ability for = the AAA=A0Authorizing 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). Just for illustration, *A* could perhaps look something like this: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0=A0 Authorizing =A0 =A0=A0 End-Host=A0 =A0 =A0 =A0=A0 Network Element=A0 =A0 =A0 =A0 =A0 = =A0=A0 Entity =A0=A0 requesting QoS=A0 =A0 =A0 ( Diameter=A0 =A0 =A0 =A0 =A0 =A0 =A0 ( = Diameter =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 QoS Client)=A0 =A0 =A0 = =A0 =A0 =A0=A0 QoS Server) =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | =A0=A0 =A0=A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 +--------+--------------+ =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |=A0 Authorize new flow=A0 =A0| =A0=A0 =A0=A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0=A0 =A0....=A0 =A0 =A0=A0 =A0=A0 =A0| =A0=A0 =A0=A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 | Sig Sender Proxy needed| =A0=A0 =A0=A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 +--------+--------------+ =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |< - - - - XXX - = - - - - -+ =A0=A0 =A0=A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | =A0 = =A0(...Sender-Proxy) =A0 =A0| =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0=A0 +-------+---------+ =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0=A0 |Install QoS state| =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0=A0 +=A0 =A0 =A0 = =A0=A0 | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0=A0 | Initiate QoS =A0 =A0| =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0=A0 | Reservation=A0 =A0 =A0|=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 QoS Responder =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Node =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0=A0 +-------+---------+=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = +----------QoS-Reserve---....--->| =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |<---------QoS-Response--....----| =A0=A0 =A0=A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0=A0 = |=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>| =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 +- - - - - ACR - = - - - - >| =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |(START,QoS-Resources,Cost| =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |CC-Time,Acc-Multisess-id)| =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +--------+--------------+ =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 | Report for successful | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |=A0=A0 QoS reservation=A0 =A0=A0 | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |Update of reserved QoS | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |=A0 =A0 =A0 resources=A0 =A0 =A0 =A0 | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +--------+--------------+ =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |< - - - - ACA - = - - - - -+ =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | Just for illustration, *B* could perhaps look something like this: =A0 =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0Authorizing =A0 =A0=A0 End-Host=A0 =A0 =A0 =A0=A0 Network Element=A0 =A0 =A0 =A0 =A0 = =A0=A0 Entity =A0=A0 requesting QoS=A0 =A0 =A0 ( Diameter=A0 =A0 =A0 =A0 =A0 =A0 =A0 ( = Diameter =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 QoS Client)=A0 =A0 =A0 = =A0 =A0 =A0=A0 QoS Server) =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | =A0 =A0 =A0=A0 +---QoS-Reserve---->|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0=A0 | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 +- - - - - QAR - = - - - - >| =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |(QoS-Resources,Cost,=A0 =A0=A0 | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0=A0 = QoS-Auth-Data,User-ID)| =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +--------+--------------+ =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |=A0 Authorize request=A0 =A0 | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 | =A0 =A0=A0 =A0=A0 ...=A0 =A0 =A0=A0 =A0=A0 =A0| =A0=A0 =A0=A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 | Sig Receiver Proxy needed| =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +--------+--------------+ =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |< - - - - YYY - = - - - - -+ =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |(Result-Code,CC-Time,Cost| =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |... = Receiver-Proxy)| =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0=A0 +-------+---------+ =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0=A0 |Install QoS state| =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0=A0 +=A0 =A0 =A0 = =A0=A0 | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0=A0 | Authz. session=A0 | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0=A0 | /Authz-time,=A0 =A0 |=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 QoS Responder =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0=A0 |=A0 CC-Time,Cost/=A0 |=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Node =A0=A0 =A0=A0 =A0|=A0 =A0 =A0 =A0 =A0=A0 |+ Receiver Proxy | =A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0| =A0=A0 =A0=A0 =A0|=A0 =A0 =A0 =A0 =A0=A0 +-------+---------+=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 +=A0 =A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0| =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0| =A0 =A0 =A0=A0 |<--QoS-Response----+=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0=A0 = |=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>| =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 +- - - - - ACR - = - - - - >| =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |(START,QoS-Resources,Cost| =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |CC-Time,Acc-Multisess-id)| =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +--------+--------------+ =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 | Report for successful | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |=A0=A0 QoS reservation=A0 =A0=A0 | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |Update of reserved QoS | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |=A0 =A0 =A0 resources=A0 =A0 =A0 =A0 | =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +--------+--------------+ =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |< - - - - ACA - = - - - - -+ =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | 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=A0the=A0network. 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.=A0It 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=A0Category 1 and 2) Would the DIME WG be willing to address these QOS reservation proxy = scenarios in dime-diameter-qos? Thank you FRancois _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 11 10:57:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV7B3-0005gG-BY; Tue, 11 Sep 2007 10:57:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV7B2-0005fN-HC for dime@ietf.org; Tue, 11 Sep 2007 10:57:20 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV7B1-0007AD-Vc for dime@ietf.org; Tue, 11 Sep 2007 10:57:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Issue 13: Duplication of application ID in header and avps Date: Tue, 11 Sep 2007 10:59:51 -0400 Message-ID: In-Reply-To: <46E59D95.6060306@tari.toshiba.com> References: <46E59D95.6060306@tari.toshiba.com> From: "Mark Jones" To: "Victor Fajardo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 >=20 > You may also want to take a look at=20 > http://www.tschofenig.priv.at:8080/diameter-interop/issue13 which=20 > discusses=20 > this issue and what resolution we currently came up with. >=20 Thanks for the URL, Victor. I have updated the subject of this email to refer to the original issue. I've reviewed the issue comments and I'm in agreement with Jan Nordqvist's analysis (posted 2006-09-07.13:22:13). The Auth/Acct-Application-ID AVPs are redundant except in CER/CEA commands and should not be mandatory for all new commands. As Jan suggests, we can eliminate a lot of confusion by redefining these AVPs as optional outside CER/CEA messages. > > I'd like to see this cleaned up in the bis because the current text > > results in IETF commands that can not be re-used in vendor-specific > > applications without ABNF conflicts. I will provide cleanup=20 > text for the > > bis if the list agrees that this is worthwhile. > > =20 >=20 > What conflicts ? I suggest we should be very careful with this issue.=20 The conflict comes when a vendor designing a new application finds an IETF-defined command that is a candidate for reuse. When the vendor reuses the command, the application id in the command header will be the vendor-specific application id assigned to the vendor's new application. The IETF-defined command contains the required Auth-Application-Id AVP and 3588-bis states that the Auth-Application-Id AVP value MUST match the header so it will also contain the vendor-specific application id. However, the grouped Vendor-Specific-Application-Id AVP is used to advertise a vendor-specific application and not the Auth-Application-Id AVP. The vendor can't use the Vendor-Specific-Application-Id AVP instead of the Auth-Application-Id AVP because the resulting command would not comply with the original command ABNF. > Changing the rules/semantics on application id (especially in the=20 > header) is very dramatic at this stage of the game. >=20 I agree we should be cautious. However, by relaxing the "MUST be present" requirement to a "MAY be present", we free new applications from this obligation to create redundancy without breaking existing applications that have already included the AVPs in their ABNF. I think the changes to the bis are relatively minor. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 11 17:23:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVDCU-00083i-B5; Tue, 11 Sep 2007 17:23:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVDCS-00083d-Bs for dime@ietf.org; Tue, 11 Sep 2007 17:23:12 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVDCR-0007ZK-VR for dime@ietf.org; Tue, 11 Sep 2007 17:23:12 -0400 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 l8BLMMHr073579; Tue, 11 Sep 2007 17:22:23 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46E70713.7040904@tari.toshiba.com> Date: Tue, 11 Sep 2007 17:22:27 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] Issue 13: Duplication of application ID in header and avps References: <46E59D95.6060306@tari.toshiba.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Mark Jones wrote: > I've reviewed the issue comments and I'm in agreement with Jan > Nordqvist's analysis (posted 2006-09-07.13:22:13). The > Auth/Acct-Application-ID AVPs are redundant except in CER/CEA commands > and should not be mandatory for all new commands. As Jan suggests, we > can eliminate a lot of confusion by redefining these AVPs as optional > outside CER/CEA messages. > For new commands this maybe possible but I do not suggest redefining these AVPs for existing commands. You can easily create backward compatibility issues if we modify any existing comm > The conflict comes when a vendor designing a new application finds an > IETF-defined command that is a candidate for reuse. When the vendor > reuses the command, the application id in the command header will be the > vendor-specific application id assigned to the vendor's new application. > The IETF-defined command contains the required Auth-Application-Id AVP > and 3588-bis states that the Auth-Application-Id AVP value MUST match > the header so it will also contain the vendor-specific application id. > Mmmm ... maybe I missed something but I specifically remember that the solution for clarifying the original issue was that only one of the auth, acct or vendor app id MUST be present in the message and MUST match the app id in the header (6.1.1). Perhaps allowing more that one app id AVP in the message causes more confusion .... > However, the grouped Vendor-Specific-Application-Id AVP is used to > advertise a vendor-specific application and not the Auth-Application-Id > AVP. The vendor can't use the Vendor-Specific-Application-Id AVP instead > of the Auth-Application-Id AVP because the resulting command would not > comply with the original command ABNF. > > > > I agree we should be cautious. However, by relaxing the "MUST be > present" requirement to a "MAY be present", we free new applications > from this obligation to create redundancy without breaking existing > applications that have already included the AVPs in their ABNF. I think > the changes to the bis are relatively minor. > It may not be as minor. If a very recent implementation decides that it will follow the "MAY" specification and therefore possibly not include these AVPs the way the older implementation does then obviously there will be backward compatibility problems. I'm not sure I totally understand the problem you mentioned but my suggestion would be to use the rules in 6.1.1 to keep things simple. If a new application where to inherit from an older app, they can easily apply for a new vendor app id and use that scheme instead of having more than one app id indicator present in the message. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 12 05:42:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVOjg-00077Y-U3; Wed, 12 Sep 2007 05:42:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVOjg-00077T-Hv for dime@ietf.org; Wed, 12 Sep 2007 05:42:16 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVOjf-0002Lz-25 for dime@ietf.org; Wed, 12 Sep 2007 05:42:16 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8C9g0H7021540 for ; Wed, 12 Sep 2007 12:42:13 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 12:41:59 +0300 Received: from esebe107.NOE.Nokia.com ([172.21.143.89]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 12:41:59 +0300 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] Issue 13: Duplication of application ID in header and avps Date: Wed, 12 Sep 2007 12:41:35 +0300 Message-ID: <165947868C470B4889510CCB51416F6D0292BFDA@esebe107.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Issue 13: Duplication of application ID in header and avps Thread-Index: Acf0hDCUL16ns/5MTzaQzT0gVlfmAgAm+yng References: <46E59D95.6060306@tari.toshiba.com> From: To: X-OriginalArrivalTime: 12 Sep 2007 09:41:59.0078 (UTC) FILETIME=[2A00F460:01C7F521] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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, > The vendor can't use the Vendor-Specific-Application-Id AVP > instead of the Auth-Application-Id AVP because the resulting > command would not comply with the original command ABNF.=20 Perhaps it would be useful allow that "original" command ABNF can be modified if the application-id changes. Command-code and application-id should be used together to identify the applicable command ABNF. Best Regards, Mikko >-----Original Message----- >From: ext Mark Jones [mailto:mark.jones@bridgewatersystems.com]=20 >Sent: 11 September, 2007 18:00 >To: Victor Fajardo >Cc: dime@ietf.org >Subject: RE: [Dime] Issue 13: Duplication of application ID in=20 >header and avps > > >>=20 >> You may also want to take a look at=20 >> http://www.tschofenig.priv.at:8080/diameter-interop/issue13 which=20 >> discusses=20 >> this issue and what resolution we currently came up with. >>=20 > >Thanks for the URL, Victor. I have updated the subject of this email to >refer to the original issue. > >I've reviewed the issue comments and I'm in agreement with Jan >Nordqvist's analysis (posted 2006-09-07.13:22:13). The >Auth/Acct-Application-ID AVPs are redundant except in CER/CEA commands >and should not be mandatory for all new commands. As Jan suggests, we >can eliminate a lot of confusion by redefining these AVPs as optional >outside CER/CEA messages. > >> > I'd like to see this cleaned up in the bis because the current text >> > results in IETF commands that can not be re-used in vendor-specific >> > applications without ABNF conflicts. I will provide cleanup=20 >> text for the >> > bis if the list agrees that this is worthwhile. >> > =20 >>=20 >> What conflicts ? I suggest we should be very careful with=20 >this issue.=20 > >The conflict comes when a vendor designing a new application finds an >IETF-defined command that is a candidate for reuse. When the vendor >reuses the command, the application id in the command header=20 >will be the >vendor-specific application id assigned to the vendor's new=20 >application. >The IETF-defined command contains the required Auth-Application-Id AVP >and 3588-bis states that the Auth-Application-Id AVP value MUST match >the header so it will also contain the vendor-specific application id. >However, the grouped Vendor-Specific-Application-Id AVP is used to >advertise a vendor-specific application and not the Auth-Application-Id >AVP. The vendor can't use the Vendor-Specific-Application-Id=20 >AVP instead >of the Auth-Application-Id AVP because the resulting command would not >comply with the original command ABNF. > >> Changing the rules/semantics on application id (especially in the=20 >> header) is very dramatic at this stage of the game. >>=20 > >I agree we should be cautious. However, by relaxing the "MUST be >present" requirement to a "MAY be present", we free new applications >from this obligation to create redundancy without breaking existing >applications that have already included the AVPs in their ABNF. I think >the changes to the bis are relatively minor. > >Regards >Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 12 09:43:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVSVX-00055L-Mu; Wed, 12 Sep 2007 09:43:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVSVW-00052b-Id for dime@ietf.org; Wed, 12 Sep 2007 09:43:54 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVSVW-0003yW-5r for dime@ietf.org; Wed, 12 Sep 2007 09:43:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Issue 13: Duplication of application ID in header and avps Date: Wed, 12 Sep 2007 09:46:27 -0400 Message-ID: In-Reply-To: <165947868C470B4889510CCB51416F6D0292BFDA@esebe107.NOE.Nokia.com> References: <46E59D95.6060306@tari.toshiba.com> <165947868C470B4889510CCB51416F6D0292BFDA@esebe107.NOE.Nokia.com> From: "Mark Jones" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 > Perhaps it would be useful allow that "original" command ABNF > can be modified if the application-id changes. >=20 Mikko, I'd rather we address the root cause than risk creating additional confusion with these types of exceptions in 3588-bis. For conflicts in existing commands, I think we can document the preferred workaround in the Design Guidelines draft but lets not propagate the issue into new commands. I am not suggesting that we redefine the application id AVPs or remove them from existing commands. I am proposing that we relax the rule that they MUST appear in every new command ABNF. > Command-code and application-id should be used together > to identify the applicable command ABNF. >=20 Agreed and since both are in the command header there is no need to duplicate application ids in the message body. All the Diameter implementations I'm aware of are using the header fields to locate the command ABNF. I don't see any advantage to digging the application id out of AVPs in the message body rather using the one in the command header. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 12 09:47:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVSZ6-0002cS-4O; Wed, 12 Sep 2007 09:47:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVSZ4-0002cF-E2 for dime@ietf.org; Wed, 12 Sep 2007 09:47:34 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVSZ3-0007OH-8f for dime@ietf.org; Wed, 12 Sep 2007 09:47:34 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id l8CDlWoD021200; Wed, 12 Sep 2007 09:47:32 -0400 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] Issue 13: Duplication of application ID in header and avps Date: Wed, 12 Sep 2007 09:47:32 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188220@sonusmail04.sonusnet.com> In-Reply-To: <165947868C470B4889510CCB51416F6D0292BFDA@esebe107.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Issue 13: Duplication of application ID in header and avps Thread-Index: Acf0hDCUL16ns/5MTzaQzT0gVlfmAgAm+yngAAjHYIA= References: <46E59D95.6060306@tari.toshiba.com> <165947868C470B4889510CCB51416F6D0292BFDA@esebe107.NOE.Nokia.com> From: "Asveren, Tolga" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 Mikko, [..snip..] >=20 > Command-code and application-id should be used together > to identify the applicable command ABNF. [TOLGA]My understanding is that this is against what we currently have. Each command is the same for all applications and if there is a need to add mandatory AVPs etc... one needs to create a new command. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 12 16:40:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVZ0u-0004BT-TD; Wed, 12 Sep 2007 16:40:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVZ0u-00040A-3R for dime@ietf.org; Wed, 12 Sep 2007 16:40:44 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVZ0t-0007Kb-Jf for dime@ietf.org; Wed, 12 Sep 2007 16:40:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Issue 13: Duplication of application ID in header and avps Date: Wed, 12 Sep 2007 16:42:53 -0400 Message-ID: In-Reply-To: References: <46E59D95.6060306@tari.toshiba.com><165947868C470B4889510CCB51416F6D0292BFDA@esebe107.NOE.Nokia.com> From: "Mark Jones" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 Now that 3588-bis requires the application id AVP value to match the id in the diameter message header (except CER/CEA), I propose a cleanup of the following sections (in 3588bis-07) to avoid any confusion around request routing: 1st Change: Remove the following text from Section 6.1:=20 Request messages that may be forwarded by Diameter agents (proxies, redirects or relays) MUST also contain an Acct- Application-Id AVP, an Auth-Application-Id AVP or a Vendor- Specific-Application-Id AVP. 2nd Change: Remove the following bullet from Section 6.1.1: o an Acct-Application-Id AVP, an Auth-Application-Id or a Vendor-Specific-Application-Id AVP must be included=20 if the request is proxiable. The application id present in one of these relevant AVPs must match the application id present in the diameter message header. 3rd Change: Remove the following text from section 6.1.6: It MAY also rely on the application identification AVPs=20 Auth-Application-Id, Acct-Application-Id or Vendor-Specific- Application-Id instead of the application id in the message header as a secondary measure. I'm also proposing the following changes which relax the requirement to include an application id AVP in every new command. This does not impact existing commands or backwards compatibility. 4th Change: Update text in section 6.8: The Auth-Application-Id AVP (AVP Code 258) is of type=20 Unsigned32 and is used in CER or CEA messages in order to=20 advertise support of the Authentication and Authorization=20 portion of an application (see Section 2.4). If present=20 in a message other than CER/CEA, the value of the Auth- Application-Id AVP MUST match the application id present in the diameter message header. 5th Change: Update text in section 6.9: The Acct-Application-Id AVP (AVP Code 259) is of type Unsigned32 and is used in CER or CEA messages in order to advertise support of the Accounting portion of an=20 application (see Section 2.4). If present in a message other than CER/CEA, the value of the Acct-Application-Id=20 AVP MUST match the application id present in the diameter message header. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 12 18:06:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVaMI-0007BD-LT; Wed, 12 Sep 2007 18:06:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVaMG-0007B7-UT for dime@ietf.org; Wed, 12 Sep 2007 18:06:52 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVaMF-0002n6-QM for dime@ietf.org; Wed, 12 Sep 2007 18:06:52 -0400 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 l8CM6UaA079981; Wed, 12 Sep 2007 18:06:30 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46E862F0.9050509@tari.toshiba.com> Date: Wed, 12 Sep 2007 18:06:40 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] Issue 13: Duplication of application ID in header and avps References: <46E59D95.6060306@tari.toshiba.com><165947868C470B4889510CCB51416F6D0292BFDA@esebe107.NOE.Nokia.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Mark, I'm ok with the changes. If anybody else have some additional comments on the text pls provide them ASAP. regards, victor > Now that 3588-bis requires the application id AVP value to match the id > in the diameter message header (except CER/CEA), I propose a cleanup of > the following sections (in 3588bis-07) to avoid any confusion around > request routing: > > 1st Change: Remove the following text from Section 6.1: > > Request messages that may be forwarded by Diameter agents > (proxies, redirects or relays) MUST also contain an Acct- > Application-Id AVP, an Auth-Application-Id AVP or a Vendor- > Specific-Application-Id AVP. > > 2nd Change: Remove the following bullet from Section 6.1.1: > > o an Acct-Application-Id AVP, an Auth-Application-Id or > a Vendor-Specific-Application-Id AVP must be included > if the request is proxiable. The application id present > in one of these relevant AVPs must match the application > id present in the diameter message header. > > 3rd Change: Remove the following text from section 6.1.6: > > It MAY also rely on the application identification AVPs > Auth-Application-Id, Acct-Application-Id or Vendor-Specific- > Application-Id instead of the application id in the message > header as a secondary measure. > > I'm also proposing the following changes which relax the requirement to > include an application id AVP in every new command. This does not impact > existing commands or backwards compatibility. > > 4th Change: Update text in section 6.8: > > The Auth-Application-Id AVP (AVP Code 258) is of type > Unsigned32 and is used in CER or CEA messages in order to > advertise support of the Authentication and Authorization > portion of an application (see Section 2.4). If present > in a message other than CER/CEA, the value of the Auth- > Application-Id AVP MUST match the application id present > in the diameter message header. > > 5th Change: Update text in section 6.9: > > The Acct-Application-Id AVP (AVP Code 259) is of type > Unsigned32 and is used in CER or CEA messages in order to > advertise support of the Accounting portion of an > application (see Section 2.4). If present in a message > other than CER/CEA, the value of the Acct-Application-Id > AVP MUST match the application id present in the diameter > message header. > > Regards > Mark > > _______________________________________________ > 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 Sep 12 18:59:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVbAt-0005fp-BN; Wed, 12 Sep 2007 18:59:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVbAr-0005ff-OS for dime@ietf.org; Wed, 12 Sep 2007 18:59:09 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVbAp-0003eQ-Qw for dime@ietf.org; Wed, 12 Sep 2007 18:59:09 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JOA00BLT2HLU7@szxga03-in.huawei.com> for dime@ietf.org; Thu, 13 Sep 2007 06:58:33 +0800 (CST) Received: from ny3104051930 ([10.124.12.88]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JOA004QG2HGUV@szxga03-in.huawei.com> for dime@ietf.org; Thu, 13 Sep 2007 06:58:33 +0800 (CST) Date: Wed, 12 Sep 2007 18:00:56 -0500 From: Frank Xia Subject: Re: [Dime] Diameter QoS Attributes Reviewers To: Hannes Tschofenig , Victor Fajardo Message-id: <006a01c7f590$c89a4e40$580c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <46B04AA6.1020400@gmx.net> <46E64481.3010407@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 All Quick comments. 1)Reference error. In section 3.1. Command Codes , "Diameter NASREQ [RFC4072] and Diameter EAP [RFC4005] application commands" It should be Diameter NASREQ [RFC4005] and Diameter EAP [RFC4072] application commands 2) QoS-Flow-State. is it possible to add directional information? when a service is symmetrice(such as , sip call), the two direction flows have the same QoS parameters. If bi-directional flow is defined, only one copy of QoS parameters is necessary to be downloaded from AAA server. BR Frank ----- Original Message ----- From: "Hannes Tschofenig" To: "Victor Fajardo" ; Cc: Sent: Tuesday, September 11, 2007 2:32 AM Subject: Re: [Dime] Diameter QoS Attributes Reviewers > Hi Frank, > Hi Victor, > > at the Chicago IETF meeting you have volunteered to review the Diameter > QoS draft. > I don't recall that I have seen your reviews. > > Could you please post your review asap? > > Ciao > Hannes > > Hannes Tschofenig wrote: > > I would like to thank > > > > * Victor Fajardo > > * Frank Xia > > > > for their willingness to review the Diameter QoS Attributes draft > > within the next 2 weeks. > > > > 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 Sep 13 02:02:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVhmd-0002wx-0z; Thu, 13 Sep 2007 02:02:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVhmb-0002wo-Dd for dime@ietf.org; Thu, 13 Sep 2007 02:02:33 -0400 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVhmZ-0003rq-OU for dime@ietf.org; Thu, 13 Sep 2007 02:02:33 -0400 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l8D62NPt093661; Thu, 13 Sep 2007 08:02:23 +0200 (CEST) (envelope-from Ulf.Bodin@operax.com) 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] Diameter Design Guidelines Draft Reviewers Date: Thu, 13 Sep 2007 08:02:22 +0200 Message-ID: <33656995C5C5094A983DE84DA649A92401B78725@lulex02.ad.operax.com> In-Reply-To: <46E644D8.10302@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Design Guidelines Draft Reviewers Thread-Index: Acf0Y+fBVPQ6toXXRzeaio3s5i9J1QBZ3mCw References: <46B04B7E.4040404@gmx.net> <46E644D8.10302@gmx.net> From: "Ulf Bodin" To: "Hannes Tschofenig" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Thu, 13 Sep 2007 08:02:23 +0200 (CEST) X-Spam-Status: No, score=-152.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST,USER_IN_WHITELIST autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/4263/Thu Sep 13 06:45:30 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Hannes,=20 I sended my review the 13:th of Auguest and got some comments from Victor which I aswered the day after.=20 BR Ulf=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: den 11 september 2007 09:34 To: Ulf Bodin; aland@nitros9.org Cc: dime@ietf.org Subject: Re: [Dime] Diameter Design Guidelines Draft Reviewers Hi Alan, Hi Ulf, at the Chicago IETF meeting you have volunteered to review the Diameter Design Guidelines draft I haven't seen your review of it yet. Could you post it asap? Ciao Hannes PS: Thanks to Wolfgang for doing the review. Hannes Tschofenig wrote: > I would like to thank > > * Wolfgang Steigerwald > * Ulf Bodin > * Alan DeKok > > for their willingness to review the Diameter Design Guidelines draft=20 > within the next 2 weeks. > > 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 From dime-bounces@ietf.org Thu Sep 13 04:01:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVjdD-00065A-74; Thu, 13 Sep 2007 04:00:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVjdB-00064w-HY for dime@ietf.org; Thu, 13 Sep 2007 04:00:57 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVjdA-0006GB-UA for dime@ietf.org; Thu, 13 Sep 2007 04:00:57 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 10:00:55 +0200 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] WGLC: Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction Date: Thu, 13 Sep 2007 10:00:53 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222CDAA@SEHAN021MB.tcad.telia.se> In-Reply-To: <46D1D2D1.9060808@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WGLC: Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction Thread-Index: AcfoFmeyOYcavfGZTWSVUPTpK6TcAwNxOOZg References: <46D1D2D1.9060808@gmx.net> From: To: , X-OriginalArrivalTime: 13 Sep 2007 08:00:55.0200 (UTC) FILETIME=[36105A00:01C7F5DC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Few minor comments: o Should we reserve a small range from MIP6-Feature-Vector for experimental use? For example upper 8 bits. o I would like to relax the 'MUST' in 4.7.1 where is says "When the MIP6-Agent-Info AVP is present in a message, it MUST contain either a MIP-Home-Agent-Address AVP or a MIP-Home-Agent-Host AVP, but not both." Imho SHOULD is enough. The use of must makes these nasty in message dependencies between AVPs Cheers, Jouni > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Sunday, August 26, 2007 10:22 PM > To: dime@ietf.org > Cc: mip6@ietf.org > Subject: [Dime] WGLC: Diameter Mobile IPv6: Support for=20 > Network Access Server to Diameter Server Interaction >=20 >=20 > Hi all, >=20 > this message marks the issuance of a working group last call=20 > (WGLC) on DIME's Internet Draft entitled "Diameter Mobile=20 > IPv6: Support for Network Access Server to Diameter Server=20 > Interaction"=20 > (draft-ietf-dime-mip6-integrated-05.txt). You may view this=20 > document at=20 > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integ > rated-05.txt >=20 > Please post comments and questions to the DIME mailing list=20 > no later than 9 September 2007. >=20 > Ciao > Hannes & Dave >=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 Sep 13 06:16:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVlkn-0000CZ-5o; Thu, 13 Sep 2007 06:16:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVlkj-00007R-RY; Thu, 13 Sep 2007 06:16:53 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVlki-0000XV-Ov; Thu, 13 Sep 2007 06:16:53 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id l8DAGlUv021626; Thu, 13 Sep 2007 19:16:47 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id l8DAGo100045; Thu, 13 Sep 2007 19:16:50 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id l8DAGn315899; Thu, 13 Sep 2007 19:16:49 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.75]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 18:15:54 +0800 Message-ID: <46E90DD3.6070601@sg.panasonic.com> Date: Thu, 13 Sep 2007 18:15:47 +0800 From: Hong Cheng User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Francois Le Faucheur References: <8CA3470D-D813-4184-9F09-66766FA33ED1@cisco.com> In-Reply-To: <8CA3470D-D813-4184-9F09-66766FA33ED1@cisco.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Sep 2007 10:15:54.0783 (UTC) FILETIME=[11CAA2F0:01C7F5EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: dime@ietf.org, tsvwg tsvwg Subject: [Dime] Re: [Tsvwg] dime-diameter-qos-01 handling of QoS Signaling Proxies 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 Francois, I think this is a very important topic to be addressed by the DIME group. For your scenarios *B*, it seems quite reasonable and with some minor changes to the current messages it should work. However, for the scenario *A*, it seems there is a requirement for the Authorizing Entity to locate the NE that is on the data path (and possibly nearest to the sender?). I feel that there may be some more work required here. Maybe some sort of discovery mechanism is necessary (if we do not assume the Authorizing Entity has the network topology information). cheers Cheng Hong Francois Le Faucheur wrote: > Hello, > > 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). > > draft-ietf-tsvwg-rsvp-proxy-approaches discusses RSVP Sender Proxy and > RSVP Receiver Proxy. NSIS has defined similar NSIS signaling proxy entities. > > 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). > > Just for illustration, *A* could perhaps look something like this: > > 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--....----| > | | | > |=====================Data Flow==============....===>| > | | > | +- - - - - ACR - - - - - >| > | |(START,QoS-Resources,Cost| > | |CC-Time,Acc-Multisess-id)| > | | +--------+--------------+ > | | | Report for successful | > | | | QoS reservation | > | | |Update of reserved QoS | > | | | resources | > | | +--------+--------------+ > | |< - - - - ACA - - - - - -+ > | | | > > > > Just for illustration, *B* could perhaps look something like this: > > 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----+ | > | | | > |=====================Data Flow==============....===>| > | | > | +- - - - - ACR - - - - - >| > | |(START,QoS-Resources,Cost| > | |CC-Time,Acc-Multisess-id)| > | | +--------+--------------+ > | | | Report for successful | > | | | QoS reservation | > | | |Update of reserved QoS | > | | | resources | > | | +--------+--------------+ > | |< - - - - ACA - - - - - -+ > | | | > > > 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) > > Would the DIME WG be willing to address these QOS reservation proxy > scenarios in dime-diameter-qos? > > Thank you > > FRancois > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 13 07:51:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnEP-0002l1-CB; Thu, 13 Sep 2007 07:51:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnEN-0002k5-Ia; Thu, 13 Sep 2007 07:51:35 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVnEM-0002Hu-O3; Thu, 13 Sep 2007 07:51:35 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id l8DBpTQ1031398; Thu, 13 Sep 2007 07:51:29 -0400 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] Re: [Tsvwg] dime-diameter-qos-01 handling of QoS SignalingProxies Date: Thu, 13 Sep 2007 07:51:29 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188239@sonusmail04.sonusnet.com> In-Reply-To: <46E90DD3.6070601@sg.panasonic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: [Tsvwg] dime-diameter-qos-01 handling of QoS SignalingProxies Thread-Index: Acf17z2JIgvg/CIYRzuDc39a5uAWbQADAwYg References: <8CA3470D-D813-4184-9F09-66766FA33ED1@cisco.com> <46E90DD3.6070601@sg.panasonic.com> From: "Asveren, Tolga" To: "Hong Cheng" , "Francois Le Faucheur" X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 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: , Errors-To: dime-bounces@ietf.org Hi Cheng Hong, > -----Original Message----- > From: Hong Cheng [mailto:hong.cheng@sg.panasonic.com] > Sent: Thursday, September 13, 2007 6:16 AM > To: Francois Le Faucheur > Cc: dime@ietf.org; tsvwg tsvwg > Subject: [Dime] Re: [Tsvwg] dime-diameter-qos-01 handling of QoS > SignalingProxies >=20 > Hi Francois, >=20 > I think this is a very important topic to be addressed by the DIME group. >=20 > For your scenarios *B*, it seems quite reasonable and with some minor > changes to the current messages it should work. >=20 > However, for the scenario *A*, it seems there is a requirement for the > Authorizing Entity to locate the NE that is on the data path (and > possibly nearest to the sender?). I feel that there may be some more > work required here. Maybe some sort of discovery mechanism is necessary > (if we do not assume the Authorizing Entity has the network topology > information). [TOLGA]Diameter itself provides relaying/proxying capability. These can be utilized to forward messages to entities, which perform some type of discovery. OTOH, I am not sure whether the discovery mechanism itself needs to be specified by the Diameter QoS Application (OTOH, it may be useful that we at least think whether discovery mechanism needs to be standardized and if so where) >=20 > cheers >=20 > Cheng Hong >=20 >=20 >=20 >=20 > Francois Le Faucheur wrote: > > Hello, > > > > 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). > > > > draft-ietf-tsvwg-rsvp-proxy-approaches discusses RSVP Sender Proxy and > > RSVP Receiver Proxy. NSIS has defined similar NSIS signaling proxy > entities. > > > > 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). > > > > Just for illustration, *A* could perhaps look something like this: > > > > 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 - - - - - -+ > > | | | > > > > > > > > Just for illustration, *B* could perhaps look something like this: > > > > 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 - - - - - -+ > > | | | > > > > > > 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) > > > > Would the DIME WG be willing to address these QOS reservation proxy > > scenarios in dime-diameter-qos? > > > > Thank you > > > > FRancois > > >=20 >=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 Sep 13 08:14:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVna9-0003qS-NR; Thu, 13 Sep 2007 08:14:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVna8-0003pY-3l; Thu, 13 Sep 2007 08:14:04 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVna7-0003F9-2E; Thu, 13 Sep 2007 08:14:04 -0400 X-IronPort-AV: E=Sophos;i="4.20,249,1186351200"; d="scan'208";a="153043682" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Sep 2007 14:13:48 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8DCDlF8014531; Thu, 13 Sep 2007 14:13:47 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8DCDbEN009571; Thu, 13 Sep 2007 12:13:37 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 14:13:37 +0200 Received: from [144.254.53.188] ([144.254.53.188]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 14:13:37 +0200 In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188239@sonusmail04.sonusnet.com> References: <8CA3470D-D813-4184-9F09-66766FA33ED1@cisco.com> <46E90DD3.6070601@sg.panasonic.com> <033458F56EC2A64E8D2D7B759FA3E7E7188239@sonusmail04.sonusnet.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Subject: Re: [Dime] Re: [Tsvwg] dime-diameter-qos-01 handling of QoS SignalingProxies Date: Thu, 13 Sep 2007 14:13:29 +0200 To: "Asveren, Tolga" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Sep 2007 12:13:37.0208 (UTC) FILETIME=[83532B80:01C7F5FF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9478; t=1189685627; x=1190549627; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[Dime]=20Re=3A=20[Tsvwg]=20dime-diameter-qos-01=20han dling=20of=20QoS=20SignalingProxies |Sender:=20; bh=Lx9RosucHI0leXIRfavhp/G1nX/LT2kn2QlX2uyP92Q=; b=Cm1yFqYJm6Iw+lYAo9NDU1BNd4D9kuvYXkhpYxhl+oPdasPKZUBZ+s3dOsUDdDB9bQ2nHAYa X5fTNp1LfOWstqHqdtp3z5R+JRQrPb5Xip6t4ttP/F81NI312qV52bcA; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 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: , Errors-To: dime-bounces@ietf.org Hello Tolga, Cheng, On 13 Sep 2007, at 13:51, Asveren, Tolga wrote: > Hi Cheng Hong, > >> -----Original Message----- >> From: Hong Cheng [mailto:hong.cheng@sg.panasonic.com] >> Sent: Thursday, September 13, 2007 6:16 AM >> To: Francois Le Faucheur >> Cc: dime@ietf.org; tsvwg tsvwg >> Subject: [Dime] Re: [Tsvwg] dime-diameter-qos-01 handling of QoS >> SignalingProxies >> >> Hi Francois, >> >> I think this is a very important topic to be addressed by the DIME > group. >> >> For your scenarios *B*, it seems quite reasonable and with some minor >> changes to the current messages it should work. >> >> However, for the scenario *A*, it seems there is a requirement for >> the >> Authorizing Entity to locate the NE that is on the data path (and >> possibly nearest to the sender?). I feel that there may be some more >> work required here. Maybe some sort of discovery mechanism is > necessary >> (if we do not assume the Authorizing Entity has the network topology >> information). > [TOLGA]Diameter itself provides relaying/proxying capability. These > can > be utilized to forward messages to entities, which perform some > type of > discovery. OTOH, I am not sure whether the discovery mechanism itself > needs to be specified by the Diameter QoS Application (OTOH, it may be > useful that we at least think whether discovery mechanism needs to be > standardized and if so where) Right. I would picture that the Diameter QoS Application spec would (i) briefly bring up the requirement for Authorizing Entity to locate NE and (ii) mention the sort of solutions to that problem such as configuration for some environments and dynamic discovery for some others. But I would assume actual discovery mechanisms to be defined outside this document. Cheers Francois >> >> cheers >> >> Cheng Hong >> >> >> >> >> Francois Le Faucheur wrote: >>> Hello, >>> >>> 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). >>> >>> draft-ietf-tsvwg-rsvp-proxy-approaches discusses RSVP Sender Proxy > and >>> RSVP Receiver Proxy. NSIS has defined similar NSIS signaling proxy >> entities. >>> >>> 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). >>> >>> Just for illustration, *A* could perhaps look something like this: >>> >>> 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--....----| >>> | | | >>> |=====================Data Flow==============....===>| >>> | | >>> | +- - - - - ACR - - - - - >| >>> | |(START,QoS-Resources,Cost| >>> | |CC-Time,Acc-Multisess-id)| >>> | | > +--------+--------------+ >>> | | | Report for successful > | >>> | | | QoS reservation > | >>> | | |Update of reserved QoS > | >>> | | | resources > | >>> | | > +--------+--------------+ >>> | |< - - - - ACA - - - - - -+ >>> | | | >>> >>> >>> >>> Just for illustration, *B* could perhaps look something like this: >>> >>> 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----+ | >>> | | | >>> |=====================Data Flow==============....===>| >>> | | >>> | +- - - - - ACR - - - - - >| >>> | |(START,QoS-Resources,Cost| >>> | |CC-Time,Acc-Multisess-id)| >>> | | > +--------+--------------+ >>> | | | Report for successful > | >>> | | | QoS reservation > | >>> | | |Update of reserved QoS > | >>> | | | resources > | >>> | | > +--------+--------------+ >>> | |< - - - - ACA - - - - - -+ >>> | | | >>> >>> >>> 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) >>> >>> Would the DIME WG be willing to address these QOS reservation proxy >>> scenarios in dime-diameter-qos? >>> >>> Thank you >>> >>> FRancois >>> >> >> >> _______________________________________________ >> 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 Sep 13 08:52:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVoB0-0002ws-MI; Thu, 13 Sep 2007 08:52:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVoAz-0002pY-LE for dime@ietf.org; Thu, 13 Sep 2007 08:52:09 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IVoAy-0004Z9-Jp for dime@ietf.org; Thu, 13 Sep 2007 08:52:09 -0400 Received: (qmail invoked by alias); 13 Sep 2007 12:52:05 -0000 Received: from ip-90-186-10-19.web.vodafone.de (EHLO [90.186.10.19]) [90.186.10.19] by mail.gmx.net (mp020) with SMTP; 13 Sep 2007 14:52:05 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18TmocimMATLu1TcyCkHJGqtiFMEMmw/GaiQgvYnW ycHjwLM8mPw5/c Message-ID: <46E93273.2010201@gmx.net> Date: Thu, 13 Sep 2007 14:52:03 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Francois Le Faucheur References: <8CA3470D-D813-4184-9F09-66766FA33ED1@cisco.com> In-Reply-To: <8CA3470D-D813-4184-9F09-66766FA33ED1@cisco.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: 3fbd9b434023f8abfcb1532abaec7a21 Cc: dime@ietf.org, tsvwg tsvwg Subject: [Dime] Re: [Tsvwg] dime-diameter-qos-01 handling of QoS Signaling Proxies 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 Francois, Francois Le Faucheur wrote: > Hello, > > 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. Not really. The document also works when you do the reservations only on one side. > 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). I certainly agree. > > draft-ietf-tsvwg-rsvp-proxy-approaches discusses RSVP Sender Proxy and > RSVP Receiver Proxy. NSIS has defined similar NSIS signaling proxy > entities. > > > 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). > > Just for illustration, *A* could perhaps look something like this: > > 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--....----| > | | | > |=====================Data Flow==============....===>| > | | > | +- - - - - ACR - - - - - >| > | |(START,QoS-Resources,Cost| > | |CC-Time,Acc-Multisess-id)| > | | +--------+--------------+ > | | | Report for successful | > | | | QoS reservation | > | | |Update of reserved QoS | > | | | resources | > | | +--------+--------------+ > | |< - - - - ACA - - - - - -+ > | | | > > > > Just for illustration, *B* could perhaps look something like this: > > 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----+ | > | | | > |=====================Data Flow==============....===>| > | | > | +- - - - - ACR - - - - - >| > | |(START,QoS-Resources,Cost| > | |CC-Time,Acc-Multisess-id)| > | | +--------+--------------+ > | | | Report for successful | > | | | QoS reservation | > | | |Update of reserved QoS | > | | | resources | > | | +--------+--------------+ > | |< - - - - ACA - - - - - -+ > | | | > > > 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) > It is true that B can use push and pull scenarios whereby a pull mode might be preferred. > Would the DIME WG be willing to address these QOS reservation proxy > scenarios in dime-diameter-qos? We certainly intended to capture these scenario. It, however, seems that the current document does not make this too explicit. We will have to add text to describe these type of scenarios. Thanks for the review. > > > Thank you > > FRancois Ciao Hannes > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 13 09:03:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVoLv-0003H9-BN; Thu, 13 Sep 2007 09:03:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVoLu-0003Go-Sq for dime@ietf.org; Thu, 13 Sep 2007 09:03:26 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IVoLt-0004wA-MS for dime@ietf.org; Thu, 13 Sep 2007 09:03:26 -0400 Received: (qmail invoked by alias); 13 Sep 2007 13:03:23 -0000 Received: from ip-90-186-10-19.web.vodafone.de (EHLO [90.186.10.19]) [90.186.10.19] by mail.gmx.net (mp030) with SMTP; 13 Sep 2007 15:03:23 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18VL8JV9ocVe2EZ7IpyCCyi47AZJYRfYSvcT5lSAo B0+G3Vnt54Xtb8 Message-ID: <46E93515.2040101@gmx.net> Date: Thu, 13 Sep 2007 15:03:17 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hong Cheng References: <8CA3470D-D813-4184-9F09-66766FA33ED1@cisco.com> <46E90DD3.6070601@sg.panasonic.com> In-Reply-To: <46E90DD3.6070601@sg.panasonic.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: 21be852dc93f0971708678c18d38c096 Cc: dime@ietf.org, tsvwg tsvwg Subject: [Dime] Re: [Tsvwg] dime-diameter-qos-01 handling of QoS Signaling Proxies 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 In previous discussions we indicated that we will not discuss the topic of NE discovery for the push mode. In the pull mode this problem obviously does not appear. Ciao Hannes Hong Cheng wrote: > Hi Francois, > > I think this is a very important topic to be addressed by the DIME group. > > For your scenarios *B*, it seems quite reasonable and with some minor > changes to the current messages it should work. > > However, for the scenario *A*, it seems there is a requirement for the > Authorizing Entity to locate the NE that is on the data path (and > possibly nearest to the sender?). I feel that there may be some more > work required here. Maybe some sort of discovery mechanism is necessary > (if we do not assume the Authorizing Entity has the network topology > information). > > cheers > > Cheng Hong > > > > > Francois Le Faucheur wrote: > >> Hello, >> >> 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). >> >> draft-ietf-tsvwg-rsvp-proxy-approaches discusses RSVP Sender Proxy and >> RSVP Receiver Proxy. NSIS has defined similar NSIS signaling proxy entities. >> >> 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). >> >> Just for illustration, *A* could perhaps look something like this: >> >> 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--....----| >> | | | >> |=====================Data Flow==============....===>| >> | | >> | +- - - - - ACR - - - - - >| >> | |(START,QoS-Resources,Cost| >> | |CC-Time,Acc-Multisess-id)| >> | | +--------+--------------+ >> | | | Report for successful | >> | | | QoS reservation | >> | | |Update of reserved QoS | >> | | | resources | >> | | +--------+--------------+ >> | |< - - - - ACA - - - - - -+ >> | | | >> >> >> >> Just for illustration, *B* could perhaps look something like this: >> >> 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----+ | >> | | | >> |=====================Data Flow==============....===>| >> | | >> | +- - - - - ACR - - - - - >| >> | |(START,QoS-Resources,Cost| >> | |CC-Time,Acc-Multisess-id)| >> | | +--------+--------------+ >> | | | Report for successful | >> | | | QoS reservation | >> | | |Update of reserved QoS | >> | | | resources | >> | | +--------+--------------+ >> | |< - - - - ACA - - - - - -+ >> | | | >> >> >> 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) >> >> Would the DIME WG be willing to address these QOS reservation proxy >> scenarios in dime-diameter-qos? >> >> Thank you >> >> FRancois >> >> > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 13 21:51:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW0L9-0007dl-Hu; Thu, 13 Sep 2007 21:51:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW0L6-0007UR-FT; Thu, 13 Sep 2007 21:51:24 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IW0L5-0002xw-6W; Thu, 13 Sep 2007 21:51:24 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id l8E1pHpA023965; Fri, 14 Sep 2007 10:51:17 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id l8E1pH415787; Fri, 14 Sep 2007 10:51:17 +0900 (JST) Received: from pslexc01.psl.local ([127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id l8E1pFe07882; Fri, 14 Sep 2007 10:51:15 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.75]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 09:50:21 +0800 Message-ID: <46E9E8EB.3010808@sg.panasonic.com> Date: Fri, 14 Sep 2007 09:50:35 +0800 From: Hong Cheng User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Francois Le Faucheur IMAP Subject: Re: [Dime] Re: [Tsvwg] dime-diameter-qos-01 handling of QoS SignalingProxies References: <8CA3470D-D813-4184-9F09-66766FA33ED1@cisco.com> <46E90DD3.6070601@sg.panasonic.com> <033458F56EC2A64E8D2D7B759FA3E7E7188239@sonusmail04.sonusnet.com> In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Sep 2007 01:50:21.0002 (UTC) FILETIME=[9BDCBAA0:01C7F671] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e 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: , Errors-To: dime-bounces@ietf.org Hi Tolga, Francois and all, In Francois's scenario *A*, the NE is the proxy for the signaling application (but not a Diameter Proxy). It is actually the Diameter client. Therefore, I am not sure if the existing Diamter proxy/relaying discovery procedure is sufficient. Another challenge is that the Authorizing Entity may not be on the data path, but it needs to locate an NE on the actual data path (as required by RSVP or NSIS). Does it have the sufficient information to do so? As mentioned in your emails, I guess at least we need to take a look at these requirements and think about the possible solutions. As for where to document it, we could decide when we are clearer about it. cheers Cheng Hong Francois Le Faucheur IMAP wrote: > Hello Tolga, Cheng, > > On 13 Sep 2007, at 13:51, Asveren, Tolga wrote: > >> Hi Cheng Hong, >> >>> -----Original Message----- >>> From: Hong Cheng [mailto:hong.cheng@sg.panasonic.com] >>> Sent: Thursday, September 13, 2007 6:16 AM >>> To: Francois Le Faucheur >>> Cc: dime@ietf.org; tsvwg tsvwg >>> Subject: [Dime] Re: [Tsvwg] dime-diameter-qos-01 handling of QoS >>> SignalingProxies >>> >>> Hi Francois, >>> >>> I think this is a very important topic to be addressed by the DIME >> group. >>> >>> For your scenarios *B*, it seems quite reasonable and with some minor >>> changes to the current messages it should work. >>> >>> However, for the scenario *A*, it seems there is a requirement for the >>> Authorizing Entity to locate the NE that is on the data path (and >>> possibly nearest to the sender?). I feel that there may be some more >>> work required here. Maybe some sort of discovery mechanism is >> necessary >>> (if we do not assume the Authorizing Entity has the network topology >>> information). >> [TOLGA]Diameter itself provides relaying/proxying capability. These can >> be utilized to forward messages to entities, which perform some type of >> discovery. OTOH, I am not sure whether the discovery mechanism itself >> needs to be specified by the Diameter QoS Application (OTOH, it may be >> useful that we at least think whether discovery mechanism needs to be >> standardized and if so where) > > Right. I would picture that the Diameter QoS Application spec would (i) > briefly bring up the requirement for Authorizing Entity to locate NE and > (ii) mention the sort of solutions to that problem such as configuration > for some environments and dynamic discovery for some others. But I would > assume actual discovery mechanisms to be defined outside this document. > > Cheers > > Francois > > >>> >>> cheers >>> >>> Cheng Hong >>> >>> >>> >>> >>> Francois Le Faucheur wrote: >>>> Hello, >>>> >>>> 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). >>>> >>>> draft-ietf-tsvwg-rsvp-proxy-approaches discusses RSVP Sender Proxy >> and >>>> RSVP Receiver Proxy. NSIS has defined similar NSIS signaling proxy >>> entities. >>>> >>>> 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). >>>> >>>> Just for illustration, *A* could perhaps look something like this: >>>> >>>> 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--....----| >>>> | | | >>>> |=====================Data Flow==============....===>| >>>> | | >>>> | +- - - - - ACR - - - - - >| >>>> | |(START,QoS-Resources,Cost| >>>> | |CC-Time,Acc-Multisess-id)| >>>> | | >> +--------+--------------+ >>>> | | | Report for successful >> | >>>> | | | QoS reservation >> | >>>> | | |Update of reserved QoS >> | >>>> | | | resources >> | >>>> | | >> +--------+--------------+ >>>> | |< - - - - ACA - - - - - -+ >>>> | | | >>>> >>>> >>>> >>>> Just for illustration, *B* could perhaps look something like this: >>>> >>>> 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----+ | >>>> | | | >>>> |=====================Data Flow==============....===>| >>>> | | >>>> | +- - - - - ACR - - - - - >| >>>> | |(START,QoS-Resources,Cost| >>>> | |CC-Time,Acc-Multisess-id)| >>>> | | >> +--------+--------------+ >>>> | | | Report for successful >> | >>>> | | | QoS reservation >> | >>>> | | |Update of reserved QoS >> | >>>> | | | resources >> | >>>> | | >> +--------+--------------+ >>>> | |< - - - - ACA - - - - - -+ >>>> | | | >>>> >>>> >>>> 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) >>>> >>>> Would the DIME WG be willing to address these QOS reservation proxy >>>> scenarios in dime-diameter-qos? >>>> >>>> Thank you >>>> >>>> FRancois >>>> >>> >>> >>> _______________________________________________ >>> 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 Sep 13 21:56:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW0Ph-0006bK-Cf; Thu, 13 Sep 2007 21:56:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW0Pg-0006az-AH; Thu, 13 Sep 2007 21:56:08 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IW0Pe-0005WE-Bq; Thu, 13 Sep 2007 21:56:08 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id l8E1txgT011578; Fri, 14 Sep 2007 10:55:59 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id l8E1txw05571; Fri, 14 Sep 2007 10:55:59 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id l8E1tx303952; Fri, 14 Sep 2007 10:55:59 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.75]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 09:55:03 +0800 Message-ID: <46E9EA06.5080702@sg.panasonic.com> Date: Fri, 14 Sep 2007 09:55:18 +0800 From: Hong Cheng User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Hannes Tschofenig References: <8CA3470D-D813-4184-9F09-66766FA33ED1@cisco.com> <46E90DD3.6070601@sg.panasonic.com> <46E93515.2040101@gmx.net> In-Reply-To: <46E93515.2040101@gmx.net> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Sep 2007 01:55:03.0674 (UTC) FILETIME=[44590DA0:01C7F672] X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: dime@ietf.org, tsvwg tsvwg Subject: [Dime] Re: [Tsvwg] dime-diameter-qos-01 handling of QoS Signaling Proxies 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, Maybe in the previous discussions there is no requirements identified for the discovery. However, as Francois proposal is about some new (signaling proxy) scenarios, it may have different requirements and lead to different conclusions (as discussed in other mails of this thread). Maybe we could do a bit analysis on it first? cheers Cheng Hong Hannes Tschofenig wrote: > In previous discussions we indicated that we will not discuss the topic > of NE discovery for the push mode. In the pull mode this problem > obviously does not appear. > > Ciao > Hannes > > Hong Cheng wrote: >> Hi Francois, >> >> I think this is a very important topic to be addressed by the DIME group. >> >> For your scenarios *B*, it seems quite reasonable and with some minor >> changes to the current messages it should work. >> >> However, for the scenario *A*, it seems there is a requirement for the >> Authorizing Entity to locate the NE that is on the data path (and >> possibly nearest to the sender?). I feel that there may be some more >> work required here. Maybe some sort of discovery mechanism is necessary >> (if we do not assume the Authorizing Entity has the network topology >> information). >> >> cheers >> >> Cheng Hong >> >> >> >> >> Francois Le Faucheur wrote: >> >>> Hello, >>> >>> 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). >>> >>> draft-ietf-tsvwg-rsvp-proxy-approaches discusses RSVP Sender Proxy and >>> RSVP Receiver Proxy. NSIS has defined similar NSIS signaling proxy >>> entities. >>> >>> 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). >>> >>> Just for illustration, *A* could perhaps look something like this: >>> >>> 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--....----| >>> | | | >>> |=====================Data Flow==============....===>| >>> | | >>> | +- - - - - ACR - - - - - >| >>> | |(START,QoS-Resources,Cost| >>> | |CC-Time,Acc-Multisess-id)| >>> | | +--------+--------------+ >>> | | | Report for successful | >>> | | | QoS reservation | >>> | | |Update of reserved QoS | >>> | | | resources | >>> | | +--------+--------------+ >>> | |< - - - - ACA - - - - - -+ >>> | | | >>> >>> >>> >>> Just for illustration, *B* could perhaps look something like this: >>> >>> 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----+ | >>> | | | >>> |=====================Data Flow==============....===>| >>> | | >>> | +- - - - - ACR - - - - - >| >>> | |(START,QoS-Resources,Cost| >>> | |CC-Time,Acc-Multisess-id)| >>> | | +--------+--------------+ >>> | | | Report for successful | >>> | | | QoS reservation | >>> | | |Update of reserved QoS | >>> | | | resources | >>> | | +--------+--------------+ >>> | |< - - - - ACA - - - - - -+ >>> | | | >>> >>> >>> 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) >>> >>> Would the DIME WG be willing to address these QOS reservation proxy >>> scenarios in dime-diameter-qos? >>> >>> Thank you >>> >>> FRancois >>> >>> >> >> >> > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 14 07:51:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW9hV-0001pB-T7; Fri, 14 Sep 2007 07:51:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW9hT-0001jf-Bd; Fri, 14 Sep 2007 07:51:07 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IW9hS-0002kX-25; Fri, 14 Sep 2007 07:51:07 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id l8EBowdD024942; Fri, 14 Sep 2007 07:50:58 -0400 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] Re: [Tsvwg] dime-diameter-qos-01 handling of QoS SignalingProxies Date: Fri, 14 Sep 2007 07:50:58 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188245@sonusmail04.sonusnet.com> In-Reply-To: <46E9E8EB.3010808@sg.panasonic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: [Tsvwg] dime-diameter-qos-01 handling of QoS SignalingProxies Thread-Index: Acf2ccPHWTE/fGe6Q5uIkv58A2184QAUxjsQ References: <8CA3470D-D813-4184-9F09-66766FA33ED1@cisco.com> <46E90DD3.6070601@sg.panasonic.com> <033458F56EC2A64E8D2D7B759FA3E7E7188239@sonusmail04.sonusnet.com> <46E9E8EB.3010808@sg.panasonic.com> From: "Asveren, Tolga" To: "Hong Cheng" , "Francois Le Faucheur IMAP" X-Spam-Score: 0.0 (/) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 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: , Errors-To: dime-bounces@ietf.org Hi Cheng Hong, > -----Original Message----- > From: Hong Cheng [mailto:hong.cheng@sg.panasonic.com] > Sent: Thursday, September 13, 2007 9:51 PM > To: Francois Le Faucheur IMAP > Cc: Asveren, Tolga; dime@ietf.org; tsvwg tsvwg > Subject: Re: [Dime] Re: [Tsvwg] dime-diameter-qos-01 handling of QoS > SignalingProxies >=20 > Hi Tolga, Francois and all, >=20 > In Francois's scenario *A*, the NE is the proxy for the signaling > application (but not a Diameter Proxy). It is actually the Diameter > client. Therefore, I am not sure if the existing Diamter proxy/relaying > discovery procedure is sufficient. [TOLGA]When I refer to utilizing the services of a Diameter Relay Agent/Proxy, what I meant is that the message can be sent to such an entity which can perform the discovery by some other means and forward it to the appropriate next Diameter hop. AFAICS in terms of Diameter functionality there is nothing extraordinary here. >=20 > Another challenge is that the Authorizing Entity may not be on the data > path, but it needs to locate an NE on the actual data path (as required > by RSVP or NSIS). Does it have the sufficient information to do so? [TOLGA]The same challenge may be there for any push-model scenario. This needs to be handled by the discovery procedure. >=20 > As mentioned in your emails, I guess at least we need to take a look at > these requirements and think about the possible solutions. As for where > to document it, we could decide when we are clearer about it. [TOLGA]The problem needs to be handled but I am not sure where the best place to do so is.=20 >=20 > cheers >=20 > Cheng Hong >=20 >=20 >=20 >=20 > Francois Le Faucheur IMAP wrote: > > Hello Tolga, Cheng, > > > > On 13 Sep 2007, at 13:51, Asveren, Tolga wrote: > > > >> Hi Cheng Hong, > >> > >>> -----Original Message----- > >>> From: Hong Cheng [mailto:hong.cheng@sg.panasonic.com] > >>> Sent: Thursday, September 13, 2007 6:16 AM > >>> To: Francois Le Faucheur > >>> Cc: dime@ietf.org; tsvwg tsvwg > >>> Subject: [Dime] Re: [Tsvwg] dime-diameter-qos-01 handling of QoS > >>> SignalingProxies > >>> > >>> Hi Francois, > >>> > >>> I think this is a very important topic to be addressed by the DIME > >> group. > >>> > >>> For your scenarios *B*, it seems quite reasonable and with some minor > >>> changes to the current messages it should work. > >>> > >>> However, for the scenario *A*, it seems there is a requirement for the > >>> Authorizing Entity to locate the NE that is on the data path (and > >>> possibly nearest to the sender?). I feel that there may be some more > >>> work required here. Maybe some sort of discovery mechanism is > >> necessary > >>> (if we do not assume the Authorizing Entity has the network topology > >>> information). > >> [TOLGA]Diameter itself provides relaying/proxying capability. These can > >> be utilized to forward messages to entities, which perform some type of > >> discovery. OTOH, I am not sure whether the discovery mechanism itself > >> needs to be specified by the Diameter QoS Application (OTOH, it may be > >> useful that we at least think whether discovery mechanism needs to be > >> standardized and if so where) > > > > Right. I would picture that the Diameter QoS Application spec would (i) > > briefly bring up the requirement for Authorizing Entity to locate NE and > > (ii) mention the sort of solutions to that problem such as configuration > > for some environments and dynamic discovery for some others. But I would > > assume actual discovery mechanisms to be defined outside this document. > > > > Cheers > > > > Francois > > > > > >>> > >>> cheers > >>> > >>> Cheng Hong > >>> > >>> > >>> > >>> > >>> Francois Le Faucheur wrote: > >>>> Hello, > >>>> > >>>> 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). > >>>> > >>>> draft-ietf-tsvwg-rsvp-proxy-approaches discusses RSVP Sender Proxy > >> and > >>>> RSVP Receiver Proxy. NSIS has defined similar NSIS signaling proxy > >>> entities. > >>>> > >>>> 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). > >>>> > >>>> Just for illustration, *A* could perhaps look something like this: > >>>> > >>>> 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 - - - - - -+ > >>>> | | | > >>>> > >>>> > >>>> > >>>> Just for illustration, *B* could perhaps look something like this: > >>>> > >>>> 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 - - - - - -+ > >>>> | | | > >>>> > >>>> > >>>> 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) > >>>> > >>>> Would the DIME WG be willing to address these QOS reservation proxy > >>>> scenarios in dime-diameter-qos? > >>>> > >>>> Thank you > >>>> > >>>> FRancois > >>>> > >>> > >>> > >>> _______________________________________________ > >>> 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 Fri Sep 14 15:44:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWH5R-0003lh-3Q; Fri, 14 Sep 2007 15:44:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWH5Q-0003gM-1U for dime@ietf.org; Fri, 14 Sep 2007 15:44:20 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWH5O-0000Sk-Oq for dime@ietf.org; Fri, 14 Sep 2007 15:44:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Sep 2007 15:46:40 -0400 Message-ID: From: "Mark Jones" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Dime] Design Guideline on Command reuse and Application-Id 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 When 3GPP reused NASREQ commands in the Gx application (TS 29.212), a question arose about which application id should populate the Auth-Application-Id AVP. Gx is a vendor-specific application (3GPP is the 'vendor') so it was initially thought that the Vendor-Specific-Application-Id AVP should be used instead of Auth-Application-Id. However, the Auth-Application-Id AVP is a required AVP in the NASREQ commands so the AVP could not be replaced without abandoning the command reuse. 3GPP decided to populate the Auth-Application-Id AVP with the Gx application id. I think it would be useful for the Design Guidelines draft to capture this scenario and suggest the following paragraph be added to section 5.3 (Use of Application-Id in a Message): "For historical reasons, some IETF applications specify commands that require application id AVPs (Auth-Application-Id or Acct-Application-Id) in the message body. When designing vendor-specific applications which reuse these IETF commands, designers should specify that the application id contained in these AVPs is that assigned to the vendor-specific application and not the original IETF application." Any concerns? Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 18 08:22:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXc4b-0004n6-MK; Tue, 18 Sep 2007 08:21:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXc4Z-0004mu-TU for dime@ietf.org; Tue, 18 Sep 2007 08:20:59 -0400 Received: from mail51.messagelabs.com ([216.82.244.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IXc4T-0005dJ-Nr for dime@ietf.org; Tue, 18 Sep 2007 08:20:59 -0400 X-VirusChecked: Checked X-Env-Sender: Sitansu.Swain@lntinfotech.com X-Msg-Ref: server-23.tower-51.messagelabs.com!1190118012!33559539!17 X-StarScan-Version: 5.5.12.14.2; banners=lntinfotech.com,-,- X-Originating-IP: [202.80.57.66] Received: (qmail 25215 invoked from network); 18 Sep 2007 12:20:30 -0000 Received: from unknown (HELO VASHIOUT.lntinfotech.com) (202.80.57.66) by server-23.tower-51.messagelabs.com with SMTP; 18 Sep 2007 12:20:30 -0000 Received: from vashi.lntinfotech.com ([172.17.25.8]) by VASHIOUT.lntinfotech.com (Lotus Domino Release 6.5.4) with ESMTP id 2007091817471047-18600 ; Tue, 18 Sep 2007 17:47:10 +0530 To: dime@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Sitansu Swain Date: Tue, 18 Sep 2007 17:50:59 +0530 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 09/18/2007 05:51:21 PM, Serialize complete at 09/18/2007 05:51:21 PM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 09/18/2007 05:47:10 PM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 09/18/2007 05:50:28 PM, Serialize complete at 09/18/2007 05:50:28 PM X-Spam-Score: -4.0 (----) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [Dime] Clarification required on Peer and Realm-Based Routing Table 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="===============0200384937==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0200384937== Content-Type: multipart/alternative; boundary="=_alternative 0043EB816525735A_=" This is a multipart message in MIME format. --=_alternative 0043EB816525735A_= Content-Type: text/plain; charset="US-ASCII" Hi All, My doubts are in following.. 1)in 2.6 it is written that "The Diameter Peer Table is used in message forwarding, and referenced by the Realm Routing Table" .Does is mean that both the tables are manually configured in all Peers in a Diameter Implementation? 2)In The Realm-Based Routing Table as per the Local Action filed the Incoming messages will FORWARD/RELAY/PROXY..etcHow it is possible for an incoming message?Is there any AVP required for the selection process or it is determined from Realm Name? Thanks & Regards, Sitansu Sekhar Swain Software Engineer POSDATA ODC Communication & Embedded Systems SBU L & T Infotech Limited Vashi Mobile : +919892844710 Ph : 02255945629 The information contained in this email has been classified as: [ ] L&T Infotech General Business [x] L&T Infotech Internal Use [ ] L&T Infotech Confidential [ ] L&T Infotech Proprietary This email may contain confidential or privileged information for the intended recipient(s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. From dime-bounces@ietf.org Tue Sep 18 08:22:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXc4b-0004n6-MK; Tue, 18 Sep 2007 08:21:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXc4Z-0004mu-TU for dime@ietf.org; Tue, 18 Sep 2007 08:20:59 -0400 Received: from mail51.messagelabs.com ([216.82.244.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IXc4T-0005dJ-Nr for dime@ietf.org; Tue, 18 Sep 2007 08:20:59 -0400 X-VirusChecked: Checked X-Env-Sender: Sitansu.Swain@lntinfotech.com X-Msg-Ref: server-23.tower-51.messagelabs.com!1190118012!33559539!17 X-StarScan-Version: 5.5.12.14.2; banners=lntinfotech.com,-,- X-Originating-IP: [202.80.57.66] Received: (qmail 25215 invoked from network); 18 Sep 2007 12:20:30 -0000 Received: from unknown (HELO VASHIOUT.lntinfotech.com) (202.80.57.66) by server-23.tower-51.messagelabs.com with SMTP; 18 Sep 2007 12:20:30 -0000 Received: from vashi.lntinfotech.com ([172.17.25.8]) by VASHIOUT.lntinfotech.com (Lotus Domino Release 6.5.4) with ESMTP id 2007091817471047-18600 ; Tue, 18 Sep 2007 17:47:10 +0530 To: dime@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Sitansu Swain Date: Tue, 18 Sep 2007 17:50:59 +0530 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 09/18/2007 05:51:21 PM, Serialize complete at 09/18/2007 05:51:21 PM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 09/18/2007 05:47:10 PM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 09/18/2007 05:50:28 PM, Serialize complete at 09/18/2007 05:50:28 PM X-Spam-Score: -4.0 (----) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [Dime] Clarification required on Peer and Realm-Based Routing Table 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="===============0200384937==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0200384937== Content-Type: multipart/alternative; boundary="=_alternative 0043EB816525735A_=" This is a multipart message in MIME format. --=_alternative 0043EB816525735A_= Content-Type: text/plain; charset="US-ASCII" Hi All, My doubts are in following.. 1)in 2.6 it is written that "The Diameter Peer Table is used in message forwarding, and referenced by the Realm Routing Table" .Does is mean that both the tables are manually configured in all Peers in a Diameter Implementation? 2)In The Realm-Based Routing Table as per the Local Action filed the Incoming messages will FORWARD/RELAY/PROXY..etcHow it is possible for an incoming message?Is there any AVP required for the selection process or it is determined from Realm Name? Thanks & Regards, Sitansu Sekhar Swain Software Engineer POSDATA ODC Communication & Embedded Systems SBU L & T Infotech Limited Vashi Mobile : +919892844710 Ph : 02255945629 The information contained in this email has been classified as: [ ] L&T Infotech General Business [x] L&T Infotech Internal Use [ ] L&T Infotech Confidential [ ] L&T Infotech Proprietary This email may contain confidential or privileged information for the intended recipient(s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. Larsen & Toubro Infotech Ltd. www.Lntinfotech.com This Document is classified as: L&T Infotech Proprietary L&T Infotech Confidential L&T Infotech Internal Use Only L&T Infotech General Business This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________ --=_alternative 0043EB816525735A_= Content-Type: text/html; charset="US-ASCII"
Hi All,
        My doubts are in following..
1)in 2.6 it is written that "The Diameter Peer Table is used in message forwarding, and referenced
  by the Realm Routing Table" .Does is mean that both the tables are manually configured in all Peers in a Diameter Implementation?
2)In The Realm-Based Routing Table as per the Local Action filed the Incoming messages will FORWARD/RELAY/PROXY..etcHow it is possible for an incoming message?Is there any AVP required for the selection process or it is determined from Realm Name?

Thanks & Regards,
Sitansu Sekhar Swain
Software Engineer
POSDATA ODC
Communication & Embedded Systems SBU
L & T Infotech Limited
Vashi
Mobile : +919892844710
Ph : 02255945629

The information contained in this email has been classified as:
[  ] L&T Infotech General Business
[x] L&T Infotech Internal Use
[  ] L&T Infotech Confidential
[  ] L&T Infotech Proprietary
This email may contain confidential or privileged information for the intended recipient(s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

Larsen & Toubro Infotech Ltd.
www.Lntinfotech.com

This Document is classified as:

L&T Infotech Proprietary   L&T Infotech Confidential   L&T Infotech Internal Use Only   L&T Infotech General Business  

This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
______________________________________________________________________
--=_alternative 0043EB816525735A_=-- --===============0200384937== 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 --===============0200384937==-- From dime-bounces@ietf.org Tue Sep 18 08:22:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXc4f-0004ur-DH; Tue, 18 Sep 2007 08:21:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXc4d-0004nq-Gh for dime@ietf.org; Tue, 18 Sep 2007 08:21:03 -0 Larsen & Toubro Infotech Ltd. www.Lntinfotech.com This Document is classified as: L&T Infotech Proprietary L&T Infotech Confidential L&T Infotech Internal Use Only L&T Infotech General Business This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________ --=_alternative 0043EB816525735A_= Content-Type: text/html; charset="US-ASCII"
Hi All,
        My doubts are in following..
1)in 2.6 it is written that "The Diameter Peer Table is used in message forwarding, and referenced
  by the Realm Routing Table" .Does is mean that both the tables are manually configured in all Peers in a Diameter Implementation?
2)In The Realm-Based Routing Table as per the Local Action filed the Incoming messages will FORWARD/RELAY/PROXY..etcHow it is possible for an incoming message?Is there any AVP required for the selection process or it is determined from Realm Name?

Thanks & Regards,
Sitansu Sekhar Swain
Software Engineer
POSDATA ODC
Communication & Embedded Systems SBU
L & T Infotech Limited
Vashi
Mobile : +919892844710
Ph : 02255945629

The information contained in this email has been classified as:
[  ] L&T Infotech General Business
[x] L&T Infotech Internal Use
[  ] L&T Infotech Confidential
[  ] L&T Infotech Proprietary
This email may contain confidential or privileged information for the intended recipient(s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

Larsen & Toubro Infotech Ltd.
www.Lntinfotech.com

This Document is classified as:

L&T Infotech Proprietary   L&T Infotech Confidential   L&T Infotech Internal Use Only   L&T Infotech General Business  

This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
______________________________________________________________________
--=_alternative 0043EB816525735A_=-- --===============0200384937== 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 --===============0200384937==-- From dime-bounces@ietf.org Tue Sep 18 08:22:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXc4f-0004ur-DH; Tue, 18 Sep 2007 08:21:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXc4d-0004nq-Gh for dime@ietf.org; Tue, 18 Sep 2007 08:21:03 -0400 Received: from mail44.messagelabs.com ([216.82.249.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IXc4V-0005dR-0V for dime@ietf.org; Tue, 18 Sep 2007 08:21:03 -0400 X-VirusChecked: Checked X-Env-Sender: Sitansu.Swain@lntinfotech.com X-Msg-Ref: server-21.tower-44.messagelabs.com!1190118027!39414804!2 X-StarScan-Version: 5.5.12.14.2; banners=lntinfotech.com,-,- X-Originating-IP: [202.80.57.66] Received: (qmail 25884 invoked from network); 18 Sep 2007 12:20:30 -0000 Received: from unknown (HELO VASHIOUT.lntinfotech.com) (202.80.57.66) by server-21.tower-44.messagelabs.com with SMTP; 18 Sep 2007 12:20:30 -0000 Received: from vashi.lntinfotech.com ([172.17.25.8]) by VASHIOUT.lntinfotech.com (Lotus Domino Release 6.5.4) with ESMTP id 2007091817471049-18601 ; Tue, 18 Sep 2007 17:47:10 +0530 MIME-Version: 1.0 To: dime@ietf.org X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Sitansu Swain Date: Tue, 18 Sep 2007 17:51:11 +0530 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 09/18/2007 05:51:21 PM, Serialize complete at 09/18/2007 05:51:21 PM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 09/18/2007 05:47:10 PM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 09/18/2007 05:50:28 PM, Serialize complete at 09/18/2007 05:50:28 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [Dime] Clarification required on Peer and Realm-Based Routing Table 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="===============0558255715==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0558255715== Content-Type: multipart/alternative; boundary="=_alternative 0043F0416525735A_=" This is a multipart message in MIME format. --=_alternative 0043F0416525735A_= Content-Type: text/plain; charset="US-ASCII" Hi All, My doubts are in following.. 1)in 2.6 it is written that "The Diameter Peer Table is used in message forwarding, and referenced by the Realm Routing Table" .Does is mean that both the tables are manually configured in all Peers in a Diameter Implementation? 2)In The Realm-Based Routing Table as per the Local Action filed the Incoming messages will FORWARD/RELAY/PROXY..etcHow it is possible for an incoming message?Is there any AVP required for the selection process or it is determined from Realm Name? Thanks & Regards, Sitansu Sekhar Swain Software Engineer POSDATA ODC Communication & Embedded Systems SBU L & T Infotech Limited Vashi Mobile : +919892844710 Ph : 02255945629 The information contained in this email has been classified as: [ ] L&T Infotech General Business [x] L&T Infotech Internal Use [ ] L&T Infotech Confidential [ ] L&T Infotech Proprietary This email may contain confidential or privileged information for the intended recipient(s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. Larsen & Toubro Infotech Ltd. www.Lntinfotech.com This Document is classified as: L&T Infotech Proprietary L&T Infotech Confidential L&T Infotech Internal Use Only L&T Infotech General Business This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete 400 Received: from mail44.messagelabs.com ([216.82.249.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IXc4V-0005dR-0V for dime@ietf.org; Tue, 18 Sep 2007 08:21:03 -0400 X-VirusChecked: Checked X-Env-Sender: Sitansu.Swain@lntinfotech.com X-Msg-Ref: server-21.tower-44.messagelabs.com!1190118027!39414804!2 X-StarScan-Version: 5.5.12.14.2; banners=lntinfotech.com,-,- X-Originating-IP: [202.80.57.66] Received: (qmail 25884 invoked from network); 18 Sep 2007 12:20:30 -0000 Received: from unknown (HELO VASHIOUT.lntinfotech.com) (202.80.57.66) by server-21.tower-44.messagelabs.com with SMTP; 18 Sep 2007 12:20:30 -0000 Received: from vashi.lntinfotech.com ([172.17.25.8]) by VASHIOUT.lntinfotech.com (Lotus Domino Release 6.5.4) with ESMTP id 2007091817471049-18601 ; Tue, 18 Sep 2007 17:47:10 +0530 MIME-Version: 1.0 To: dime@ietf.org X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Sitansu Swain Date: Tue, 18 Sep 2007 17:51:11 +0530 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 09/18/2007 05:51:21 PM, Serialize complete at 09/18/2007 05:51:21 PM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 09/18/2007 05:47:10 PM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 09/18/2007 05:50:28 PM, Serialize complete at 09/18/2007 05:50:28 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [Dime] Clarification required on Peer and Realm-Based Routing Table 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="===============0558255715==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0558255715== Content-Type: multipart/alternative; boundary="=_alternative 0043F0416525735A_=" This is a multipart message in MIME format. --=_alternative 0043F0416525735A_= Content-Type: text/plain; charset="US-ASCII" Hi All, My doubts are in following.. 1)in 2.6 it is written that "The Diameter Peer Table is used in message forwarding, and referenced by the Realm Routing Table" .Does is mean that both the tables are manually configured in all Peers in a Diameter Implementation? 2)In The Realm-Based Routing Table as per the Local Action filed the Incoming messages will FORWARD/RELAY/PROXY..etcHow it is possible for an incoming message?Is there any AVP required for the selection process or it is determined from Realm Name? Thanks & Regards, Sitansu Sekhar Swain Software Engineer POSDATA ODC Communication & Embedded Systems SBU L & T Infotech Limited Vashi Mobile : +919892844710 Ph : 02255945629 The information contained in this email has been classified as: [ ] L&T Infotech General Business [x] L&T Infotech Internal Use [ ] L&T Infotech Confidential [ ] L&T Infotech Proprietary This email may contain confidential or privileged information for the intended recipient(s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. Larsen & Toubro Infotech Ltd. www.Lntinfotech.com This Document is classified as: L&T Infotech Proprietary L&T Infotech Confidential L&T Infotech Internal Use Only L&T Infotech General Business This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________ --=_alternative 0043F0416525735A_= Content-Type: text/html; charset="US-ASCII"
Hi All,
        My doubts are in following..
1)in 2.6 it is written that "The Diameter Peer Table is used in message forwarding, and referenced
  by the Realm Routing Table" .Does is mean that both the tables are manually configured in all Peers in a Diameter Implementation?
2)In The Realm-Based Routing Table as per the Local Action filed the Incoming messages will FORWARD/RELAY/PROXY..etcHow it is possible for an incoming message?Is there any AVP required for the selection process or it is determined from Realm Name?

Thanks & Regards,
Sitansu Sekhar Swain
Software Engineer
POSDATA ODC
Communication & Embedded Systems SBU
L & T Infotech Limited
Vashi
Mobile : +919892844710
Ph : 02255945629

The information contained in this email has been classified as:
[  ] L&T Infotech General Business
[x] L&T Infotech Internal Use
[  ] L&T Infotech Confidential
[  ] L&T Infotech Proprietary
This email may contain confidential or privileged information for the intended recipient(s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

Larsen & Toubro Infotech Ltd.
www.Lntinfotech.com

This Document is classified as:

L&T Infotech Proprietary   L&T Infotech Confidential   L&T Infotech Internal Use Only   L&T Infotech General Business  

This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
______________________________________________________________________
--=_alternative 0043F0416525735A_=-- --===============0558255715== 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 --===============0558255715==-- it from your system. ______________________________________________________________________ --=_alternative 0043F0416525735A_= Content-Type: text/html; charset="US-ASCII"
Hi All,
        My doubts are in following..
1)in 2.6 it is written that "The Diameter Peer Table is used in message forwarding, and referenced
  by the Realm Routing Table" .Does is mean that both the tables are manually configured in all Peers in a Diameter Implementation?
2)In The Realm-Based Routing Table as per the Local Action filed the Incoming messages will FORWARD/RELAY/PROXY..etcHow it is possible for an incoming message?Is there any AVP required for the selection process or it is determined from Realm Name?

Thanks & Regards,
Sitansu Sekhar Swain
Software Engineer
POSDATA ODC
Communication & Embedded Systems SBU
L & T Infotech Limited
Vashi
Mobile : +919892844710
Ph : 02255945629

The information contained in this email has been classified as:
[  ] L&T Infotech General Business
[x] L&T Infotech Internal Use
[  ] L&T Infotech Confidential
[  ] L&T Infotech Proprietary
This email may contain confidential or privileged information for the intended recipient(s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

Larsen & Toubro Infotech Ltd.
www.Lntinfotech.com

This Document is classified as:

L&T Infotech Proprietary   L&T Infotech Confidential   L&T Infotech Internal Use Only   L&T Infotech General Business  

This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
______________________________________________________________________
--=_alternative 0043F0416525735A_=-- --===============0558255715== 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 --===============0558255715==-- From dime-bounces@ietf.org Tue Sep 18 10:38:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXeDg-0007nr-36; Tue, 18 Sep 2007 10:38:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXeDe-0007mE-IB for dime@ietf.org; Tue, 18 Sep 2007 10:38:30 -0400 Received: from jaguar.aricent.com ([61.246.186.17]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXeDd-0004YD-Ef for dime@ietf.org; Tue, 18 Sep 2007 10:38:30 -0400 Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id l8IEV3Me015660 for ; Tue, 18 Sep 2007 20:01:03 +0530 Received: from sandesh.gur.aricent.com (sandesh [10.203.142.21]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id l8IEV3qa015631 for ; Tue, 18 Sep 2007 20:01:03 +0530 To: dime@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Navneil Rai Wadhawan Date: Tue, 18 Sep 2007 20:08:10 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 18/09/2007 08:12:48 PM, Serialize complete at 18/09/2007 08:12:48 PM X-Spam-Score: 2.8 (++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [Dime] Diameter Client Accounting State Machine 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="===============1261019597==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1261019597== Content-Type: multipart/alternative; boundary="=_alternative 005069A06525735A_=" This is a multipart message in MIME format. --=_alternative 005069A06525735A_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 VGhlcmUgaXMgbm8gc3RhdGUgdHJhbnNpdGlvbiBmcm9tIE9wZW4gU3RhdGUgdG8gUGVuZGluZ0Ig c3RhdGUgaW4gY2xpZW50IA0KYWNjb3VudGluZyBzdGF0ZSBtYWNoaW5lLg0KU28gaW4gYSBzaXR1 YXRpb24gd2hlcmUgd2UgbW92ZWQgZnJvbSBQZW5kaW5nUyBzdGF0ZSB0byBPcGVuIHN0YXRlIGFu ZCANCnN0b3JlIHRoZSBzdGFydCByZWNvcmQgKFRoaXMgaGFwcGVucyB3aGVuIHRoZSBzdGFydCBt ZXNzYWdlIGZhaWxlZCB0byANCnNlbmQsIGJ1ZmZlciBzcGFjZSBpcyBhdmFpbGFibGUgYW5kIFJl YWxUaW1lIGlzIG5vdCBlcXVhbCB0byANCkRFTElWRVJfQU5EX0dSQU5UKSwgbm93IHdlIGRvIG5v dCBoYXZlIGFueSBwcm92aXNpb24gdG8gc2VuZCBzdGFydCByZWNvcmQgDQppbiBPcGVuIFN0YXRl LCBzbyB0aGUgb25seSB3YXkgdGhhdCByZW1haW5zIGlzIHRvIHRlcm1pbmF0ZSB0aGUgc2Vzc2lv biANCmFuZCAgbW92ZSB0byBQZW5kaW5nTCBzdGF0ZSBhbmQgYWdhaW4gaWYgd2UgZmFpbCB0byBz ZW5kIGFuZCBidWZmZXIgdGhlIA0KcmVxdWVzdCwgdGhlIGlzc3VlIGlzIGhvdyBhbmQgd2hlbiB0 aGUgc3RvcmVkIHJlY29yZHMgYmUgY2xlYXJlZC4NCkFub3RoZXIgaXNzdWUgaXMgcmVnYXJkaW5n IHRoZSBJbnRlZ3JhdGlvbiBvZiBBdXRob3JpemF0aW9uIGFuZCBBY2NvdW50aW5nIA0KU3RhdGUg TWFjaGluZXMuIEhlcmUgaXMgaXQgcG9zc2libGUgdG8gaW50ZWdyYXRlIGJvdGggdGhlIHN0YXRl IG1hY2hpbmVzIA0KZm9yIHRoZSBzYW1lIHNlc3Npb24gb3Igd2Ugc2hhbGwgbWFpbnRhaW4gYSBk aWZmZXJlbnQgc3RhdGUgbWFjaGluZS4gDQpQbGVhc2UgY29tbWVudCBvbiB0aGUgYW50aWNpcGF0 ZWQgaXNzdWVzIGlmIGFueS4NCg0KVGhhbmtzIGluIEFkdmFuY2UNCk5hdm5laWwNCg0KKioqKioq KioqKioqKioqKioqKioqKiogIEFyaWNlbnQtUmVzdHJpY3RlZCAgICoqKioqKioqKioqKioqKioq KioqKioqDQoiRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEFyaWNl bnQgIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgCnRoZSBpbmRpdmlkdWFs IHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIG9yIGNv bmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSAKY2lyY3VsYXRlZCBvciB1 c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIApwbGVhc2Ugbm90aWZ5 IHRoZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQpwcm9oaWJp dGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250 ZW50cyBvZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eSBm b3IgCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlv biB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4i Cg== --=_alternative 005069A06525735A_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZXJlIGlzIG5vIHN0YXRlIHRy YW5zaXRpb24gZnJvbSBPcGVuDQpTdGF0ZSB0byBQZW5kaW5nQiBzdGF0ZSBpbiBjbGllbnQgYWNj b3VudGluZyBzdGF0ZSBtYWNoaW5lLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+U28gaW4gYSBzaXR1YXRpb24gd2hlcmUgd2UgbW92ZWQgZnJvbQ0KUGVuZGluZ1Mg c3RhdGUgdG8gT3BlbiBzdGF0ZSBhbmQgc3RvcmUgdGhlIHN0YXJ0IHJlY29yZCAoVGhpcyBoYXBw ZW5zIHdoZW4NCnRoZSBzdGFydCBtZXNzYWdlIGZhaWxlZCB0byBzZW5kLCBidWZmZXIgc3BhY2Ug aXMgYXZhaWxhYmxlIGFuZCBSZWFsVGltZQ0KaXMgbm90IGVxdWFsIHRvIERFTElWRVJfQU5EX0dS QU5UKSwgbm93IHdlIGRvIG5vdCBoYXZlIGFueSBwcm92aXNpb24gdG8NCnNlbmQgc3RhcnQgcmVj b3JkIGluIE9wZW4gU3RhdGUsIHNvIHRoZSBvbmx5IHdheSB0aGF0IHJlbWFpbnMgaXMgdG8gdGVy bWluYXRlDQp0aGUgc2Vzc2lvbiBhbmQgJm5ic3A7bW92ZSB0byBQZW5kaW5nTCBzdGF0ZSBhbmQg YWdhaW4gaWYgd2UgZmFpbCB0byBzZW5kDQphbmQgYnVmZmVyIHRoZSByZXF1ZXN0LCB0aGUgaXNz dWUgaXMgaG93IGFuZCB3aGVuIHRoZSBzdG9yZWQgcmVjb3JkcyBiZQ0KY2xlYXJlZC48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFub3RoZXIgaXNzdWUgaXMgcmVn YXJkaW5nIHRoZSBJbnRlZ3JhdGlvbg0Kb2YgQXV0aG9yaXphdGlvbiBhbmQgQWNjb3VudGluZyBT dGF0ZSBNYWNoaW5lcy4gSGVyZSBpcyBpdCBwb3NzaWJsZSB0bw0KaW50ZWdyYXRlIGJvdGggdGhl IHN0YXRlIG1hY2hpbmVzIGZvciB0aGUgc2FtZSBzZXNzaW9uIG9yIHdlIHNoYWxsIG1haW50YWlu DQphIGRpZmZlcmVudCBzdGF0ZSBtYWNoaW5lLiBQbGVhc2UgY29tbWVudCBvbiB0aGUgYW50aWNp cGF0ZWQgaXNzdWVzIGlmDQphbnkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5UaGFua3MgaW4gQWR2YW5jZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+TmF2bmVpbDxicj4NCjxicj4NCioqKioqKioqKioqKioqKioqKioq KioqICZuYnNwO0FyaWNlbnQtUmVzdHJpY3RlZCAmbmJzcDsgKioqKioqKioqKioqKioqKioqKioq Kio8L2ZvbnQ+DQo8dGFibGU+PHRyPjx0ZCBiZ2NvbG9yPSNmZmZmZmY+PGZvbnQgY29sb3I9IzAw MDAwMD48cHJlPiJESVNDTEFJTUVSOiBUaGlzIG1lc3NhZ2UgaXMgcHJvcHJpZXRhcnkgdG8gQXJp Y2VudCAgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiAKdGhlIGluZGl2aWR1 YWwgdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQuIEl0IG1heSBjb250YWluIHByaXZpbGVnZWQgb3Ig Y29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGFuZCBzaG91bGQgbm90IGJlIApjaXJjdWxhdGVkIG9y IHVzZWQgZm9yIGFueSBwdXJwb3NlIG90aGVyIHRoYW4gZm9yIHdoYXQgaXQgaXMgaW50ZW5kZWQu IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgCnBsZWFzZSBub3Rp ZnkgdGhlIG9yaWdpbmF0b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHlvdSBhcmUgbm90aWZpZWQgdGhhdCB5b3UgYXJlIHN0cmljdGx5CnByb2hp Yml0ZWQgZnJvbSB1c2luZywgY29weWluZywgYWx0ZXJpbmcsIG9yIGRpc2Nsb3NpbmcgdGhlIGNv bnRlbnRzIG9mIHRoaXMgbWVzc2FnZS4gQXJpY2VudCBhY2NlcHRzIG5vIHJlc3BvbnNpYmlsaXR5 IGZvciAKbG9zcyBvciBkYW1hZ2UgYXJpc2luZyBmcm9tIHRoZSB1c2Ugb2YgdGhlIGluZm9ybWF0 aW9uIHRyYW5zbWl0dGVkIGJ5IHRoaXMgZW1haWwgaW5jbHVkaW5nIGRhbWFnZSBmcm9tIHZpcnVz LiIKPC9wcmU+PC9mb250PjwvdGQ+PC90cj48L3RhYmxlPg== --=_alternative 005069A06525735A_=-- --===============1261019597== 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 --===============1261019597==-- From dime-bounces@ietf.org Wed Sep 19 01:34:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXsCC-0003AW-9k; Wed, 19 Sep 2007 01:33:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXsCB-00039x-5F; Wed, 19 Sep 2007 01:33:55 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXsCA-0004KZ-R7; Wed, 19 Sep 2007 01:33:55 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 22:33:54 -0700 Message-ID: <46F0B4BF.1050706@azairenet.com> Date: Tue, 18 Sep 2007 22:33:51 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Dime] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization References: <46DD4BCA.8090200@gmx.net> In-Reply-To: <46DD4BCA.8090200@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2007 05:33:54.0234 (UTC) FILETIME=[AAD641A0:01C7FA7E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Mobile IPv6 Mailing List , 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 Hannes, Hannes Tschofenig wrote: > Hi all, > during his review of "Diameter Mobile IPv6: HA<->AAA" Ahmad made the > following comment: >>>> > We discussed before that AUTHORIZATION for ROUTE OPTIMIZATION is needed. > I did not see it included here?! As we discussed last time, operators do > care about having control over the willingness of the MN to have route > optimization. If that the case, then there should be a process to enable > that kind of authorization. No? > <<< > > Does the group think that we need to provide any backend infrastructure > support to enable this type of functionality? IMO, it is not needed. Regards Vijay _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 20 12:06:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYOY5-0005il-BJ; Thu, 20 Sep 2007 12:06:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYOY1-0005hd-UH; Thu, 20 Sep 2007 12:06:39 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYOY1-0002tp-Cs; Thu, 20 Sep 2007 12:06:37 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id C9961A80CD; Thu, 20 Sep 2007 12:06:33 -0400 (EDT) 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 01938-17; Thu, 20 Sep 2007 12:06:33 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP; Thu, 20 Sep 2007 12:06:33 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 12:04:04 -0400 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] Diameter Mobile IPv6 Bootstrapping: Authorizing RouteOptimization Date: Thu, 20 Sep 2007 12:04:04 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA636@exchtewks2.starentnetworks.com> In-Reply-To: <46F0B4BF.1050706@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 Bootstrapping: Authorizing RouteOptimization Thread-Index: Acf6fuMzyVWMRCCDRKSO42ACCqQH0ABIMPIA From: "Chowdhury, Kuntal" To: "Vijay Devarapalli" , "Hannes Tschofenig" X-OriginalArrivalTime: 20 Sep 2007 16:04:04.0338 (UTC) FILETIME=[DDD40520:01C7FB9F] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Mobile IPv6 Mailing List , 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 I think it is needed. Primarily because the decision to authorize or de-authorize RO (RR signaling) should be taken in the AAA infrastructure based on several factors including user's subscription data. BR, Kuntal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Wednesday, September 19, 2007 12:34 AM > To: Hannes Tschofenig > Cc: Mobile IPv6 Mailing List; dime@ietf.org > Subject: Re: [Dime] Diameter Mobile IPv6 Bootstrapping: Authorizing > RouteOptimization >=20 > Hi Hannes, >=20 > Hannes Tschofenig wrote: > > Hi all, > > during his review of "Diameter Mobile IPv6: HA<->AAA" Ahmad made the > > following comment: > >>>> > > We discussed before that AUTHORIZATION for ROUTE OPTIMIZATION is needed. > > I did not see it included here?! As we discussed last time, operators do > > care about having control over the willingness of the MN to have route > > optimization. If that the case, then there should be a process to enable > > that kind of authorization. No? > > <<< > > > > Does the group think that we need to provide any backend infrastructure > > support to enable this type of functionality? >=20 > IMO, it is not needed. >=20 > Regards > Vijay >=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 Mon Sep 24 18:24:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZwLc-0006Sz-GB; Mon, 24 Sep 2007 18:24:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZwLb-0006Ms-2x for dime@ietf.org; Mon, 24 Sep 2007 18:24:11 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IZwLV-0007Xi-NR for dime@ietf.org; Mon, 24 Sep 2007 18:24:07 -0400 Received: (qmail invoked by alias); 24 Sep 2007 22:17:14 -0000 Received: from p54986D53.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.109.83] by mail.gmx.net (mp042) with SMTP; 25 Sep 2007 00:17:14 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/3U+ho0S33K/CX6+tpJVqGRqccIBWnE93XpPN4kS q8tpVeOXlI0yWn Message-ID: <46F8376A.8060305@gmx.net> Date: Tue, 25 Sep 2007 00:17:14 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ECRIT , dime@ietf.org, keyprov@ietf.org, "nsis@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Dime] [Fwd: Deployment of the Internet-Draft Submission Tool] 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 -------- Original Message -------- Subject: Deployment of the Internet-Draft Submission Tool Date: Wed, 19 Sep 2007 15:32:20 -0400 From: IETF Secretariat Reply-To: idst-developers@ietf.org To: IETF Announcement list CC: wgchairs@ietf.org The IETF Secretariat is pleased to announce the deployment of the Internet-Draft Submission Tool (IDST)-Phase I. The IDST is a Web-based application that will allow an IETF participant to submit an Internet-Draft online, obtain approval to post the draft (if necessary), and make the draft immediately available to the community on the IETF Web site without the assistance of the Secretariat (in most cases). The URL for the IDST is: https://datatracker.ietf.org/idst/upload.cgi The URL for instructions for using the IDST is: http://www.ietf.org/idsubmit_instructions.html Although it will still be possible to submit your drafts by e-mail (i.e., by sending them to internet-drafts@ietf.org), the tool is available for use effective immediately, and we encourage you to submit your drafts via the tool starting today. If you have any questions about using the tool or wish to report a bug, then please send a message to idst-developers@ietf.org. Enjoy!! The IETF Secretariat _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 26 01:24:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaPNC-0008C4-2r; Wed, 26 Sep 2007 01:23:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaPNA-0007xa-15 for dime@ietf.org; Wed, 26 Sep 2007 01:23:44 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaPMx-0006XX-OH for dime@ietf.org; Wed, 26 Sep 2007 01:23:37 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 07:23:04 +0200 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, 26 Sep 2007 07:23:04 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222D09F@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 4004 Diameter MIP issues Thread-Index: Acf//VAzwhid8e60R2ucOGnB3Ro1HQ== From: To: X-OriginalArrivalTime: 26 Sep 2007 05:23:04.0944 (UTC) FILETIME=[50B8B700:01C7FFFD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: pete.mccann@motorola.com Subject: [Dime] RFC 4004 Diameter MIP issues 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, I was reading RFC 4004 (again). Both MIP-HA-to-MN-SPI and MIP-MN-to-HA-SPI are listed in respective command ABNFs as mandatory AVPs & in AVP occurrence tables; see sections 9.4., 9.6., and 11.1. However, no code values have been allocated and no types has been defined. Any particular reason for this or am I missing something? Cheers, Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 26 11:51:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaZAV-0003EU-21; Wed, 26 Sep 2007 11:51:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaZAU-0003EP-AC for dime@ietf.org; Wed, 26 Sep 2007 11:51:18 -0400 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaZAN-0005p3-Af for dime@ietf.org; Wed, 26 Sep 2007 11:51:18 -0400 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l8QFopom065769 for ; Wed, 26 Sep 2007 17:50:52 +0200 (CEST) (envelope-from Ulf.Bodin@operax.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Sep 2007 17:50:52 +0200 Message-ID: <33656995C5C5094A983DE84DA649A92401C79C8C@lulex02.ad.operax.com> In-Reply-To: <33656995C5C5094A983DE84DA649A9240164172F@lulex02.ad.operax.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter state synchronization - PART 2 Thread-Index: Acep5dCmWImxFqp+QR20+AFV7RfBYAFXPKmwAPJ8bQATT9SCMA== References: <33656995C5C5094A983DE84DA649A92401590C17@lulex02.ad.operax.com><7DBAFEC6A76F3E42817DF1EBE64CB02604A2C3C7@FTRDMEL2.rd.francetelecom.fr> <33656995C5C5094A983DE84DA649A9240164172F@lulex02.ad.operax.com> From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Wed, 26 Sep 2007 17:50:52 +0200 (CEST) X-Spam-Status: No, score=-152.1 required=4.7 tests=ALL_TRUSTED,BAYES_00, HTML_40_50, HTML_MESSAGE, USER_IN_BLACKLIST, USER_IN_WHITELIST autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/4404/Wed Sep 26 14:53:15 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 10e6cb90de4fe268e7150fb24857273b Subject: [Dime] Diameter state synchronization - PART 2 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="===============1856449218==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1856449218== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80055.03EE5DBA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80055.03EE5DBA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All,=20 =20 Continuing the work on Diameter state synchronization I've looked through sections 5.2.3 and 5.2.4 of http://www.ietf.org/internet-drafts/draft-asveren-dime-state-recovery-01 .txt [SR]. Sections 5.2.1 and 5.2.2 were discussed in June (see PART 1 below). Going through section 5.2.3 and 5.2.4 (PART 1) of [SR] and matching against http://www.ietf.org/internet-drafts/draft-asveren-dime-state-recovery-03 .txt [RM-ext] I noted the following:=20 =20 1) Active instance guided backup server selection means to inform peer Diameter peers about the identity of backup server, or servers in case loadsharing is to be applied, in which states need to be rebuilt after failover (see section 5.2.3 of [SR]). Active instance guided selection could be achieved through AVP(s) returned in regular application signalling. This approach could work also for backup instance guided backup server selection case as I see it.=20 =20 Alternatively, in case loadsharing is to be applied the information on how the load should be distributed among multiple backup servers could be provided already in a notification message message from the backup/standby about active/primary server failure (i.e. the message identified in section 5.2.1 - Notificaiton from Standby Instance).=20 =20 In my view the approach of using a separate notificaiton message can be beneficial also for active instance guided backup server selection since the loadsharing information will then be available before reqular application signalling occurs. That is, sudden increases in signalling load will then be distributed correctly immediately instead of after information in the first returning application message answers has been received and processed. At high load scenarios that may cause overload situation that server(s) may handle more or less well depending on implementation. Would be good avoiding relying on that servers implement proper overload control IMHO and I therefore prefer the separate message approach (i.e. using the same separate message that needs to be defined to solve the section 5.2.1 - Notificaiton from Standby Instance problem).=20 =20 2) The timing of state reconstruction after failure (covered in section 5.2.4 of [SR]) can be challenging due to the potentially large amount of states that need to be synchronized. Therefore a mechnism to perform bulk transfers of state information is needed. Such mechanism is defined in [RM-ext]. That is, a Resource-Bag AVP can be included in an Session-Resource-Reply (SSR) message. The actual information (AVP(S)) that needs to be provided should if possible be restricted to what's needed by the server to take over the work of the active/primary server. The information to be synchronized shold in my view be clearly defined by Diameter applications aiming at using a generic Diameter state synchronization mechanism (i.e. the subset of information that must be synchronized should be identified by the appliocation).=20 =20 For state reconstruction upon reception of a request (second part of section 5.2.4 of [SR], the same need for identifying the subset of information that must be synchronized in application specification appears. Also, a backup server without complete resynchronized state must be capable of separating request messages that update soft-state and/or are issued for synchronization purposes from request messages that are sent to create a new state/session. E.g. 3GPP Gq and ETSI TSIAPN Gq' relies on that the server recognizes the session ID of an AAR as a new ID or an ID that belongs to an existing session. This precludes the backup server from treating update/synchronization messages different from requests for new sessions, which may be desired e.g. to handle overload situations properly. Therefore I beleive it would be beneficial to define an boolean AVP for new session/not new session as part of a Diameter state synchrinization mechnism together with rules for when this AVP shall/should be used by applications in request messages.=20 =20 Comments? =20 BR Ulf =20 All,=20 I've been looking in whether the original work on Diameter resource management extensions now captured in http://www.ietf.org/internet-drafts/draft-bodin-dime-auditing-reqs-02.tx t [RM-ext] would meet the demands identified in http://www.ietf.org/internet-drafts/draft-asveren-dime-state-recovery-01 .txt [SR] on Diameter state recovery considerations. Comments on this analyze are very wellcome.=20 Going through section 5.2.1 and 5.2.2 (PART 1) of [SR] and matching against [RM-ext] I noted the following (remaing sections/PARTs in following mail):=20 1) Having a standby node informing remote peers of the failure of an active instance (i.e. 5.2.1 in [SR]) is not covered by [RM-ext], not in any other spec (as far as I know). I'm not sure what kind of message would be appropriate for this purpose (i.e. a new mesage or an existing one such as CER). Any views on this?=20 [Lionel Morand] CER/CEA are used to initiate a transport connection between diameter peers. In this specific case, we may assume that the Standby node may actually also indicate the active instance failure by sending a CER to the remote peers. The transport connection establishment would be a hint for the remote peers to detect that the Standby node is now active and that therefore the previous active node is down. The only problem is that CER/CAA messages can not be proxied, redirected or relayed i.e. it would be not possible to use this mechanism if a proxy/redirect/relay agent is present in the Diameter path between remote peers and Stanby/active node. This can not be therefore defined as a generic mechanism. =20 [Ulf1] You're right of course. Informing remote peers of the failure of an active instance would henece require a new message I guess. that is, a message the be sent immediately after the CER/CAA message exchange directly following the detection of that an Active instance has become permanetly inavailable.=20 2) Synchronizing state (i.e. 5.2.2, first paragraph in [SR]) is not natively supported by [RM-ext], but could be suppored with a small change/addition I beleive. E.g. through a flag in the SRQ saying whether all session information is requested for all active sessions (all information on all sessions is requested when no Session-Id is provided in the SRQ), or just the session-Id of all active sesisons (i.e. an SRR without any Resource-bag AVPs).=20 [Lionel Morand] if needed, I think that this could be easily fulfilled with an optional AVP in SQR e.g. "State Synchronization AVP" of Enumarated type, that would clearly indicate the granularity of requested information about active sessions.=20 [Ulf1] Yes. I agree. I forsee a potential value in having a set of predefined values for different granularities. For example, (a) all information on all active sessions, (b) session ids only for all active sessions, (c) all information or session ids only for all sessions that'll time out with x seconds, (d) all information or session ids only for all sessions with application property x (related to one or more application specific AVPs), etc. While I see a clear need for differentiating between (a) and (b), I think (c) and (d) type of values would be interesting to discuss to found out whether that can be useful or just makes the solution more complex. =20 3) Reconstructing session state using application messages (i.e. 5.2.2, Using Application Messages in [SR]) is generally not supported by Diameter nor in [RM-ext]. As I understand the protocol a AAR updating an existing session is identified by that the Session-Id is known by the server (i.e. is active), while an AAR establishing a new session provides a new Session-Id not currently being used for any active session. Hence, a flag indicating that the message is for an existing sesison (or a separate message) would be needed to facilitate state reconstruction using mid-session messages. =20 4) Reconstructing session state using generic messages (i.e. 5.2.2, Using a Generic Message in [SR]) is indeed supported by [RM-ext] (i.e. through SRQ and SRR in which state information for several sessions can be requested and provided respectively).=20 Best regards, Ulf=20 ------_=_NextPart_001_01C80055.03EE5DBA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Diameter auditing - PART 1
All, 
 
Continuing the work on Diameter state = synchronization=20 I've looked through = sections 5.2.3=20 and 5.2.4 of http://www.ietf.org/internet-drafts/draft-asveren-dime-state-rec= overy-01.txt [SR]. = Sections 5.2.1 and=20 5.2.2 were discussed in June (see PART 1 below). Going through section 5.2.3 and 5.2.4 (PART 1) of [SR] and = matching=20 against http://www.ietf.org/internet-drafts/draft-asveren-dime-state-rec= overy-03.txt = [RM-ext] I noted=20 the following:=20
 <= /DIV>
1) Active instance guided backup server=20 selection means to inform peer Diameter peers about the = identity of=20 backup server, or servers in case loadsharing is to be applied, in = which=20 states need to be rebuilt after failover (see section 5.2.3 of [SR]). = Active=20 instance guided selection could be achieved through AVP(s) returned = in=20 regular application signalling. This approach could work also for = backup=20 instance guided backup server selection case as I see it.=20
 <= /DIV>
Alternatively, in case loadsharing is to = be applied=20 the information on how the load should be distributed among multiple = backup=20 servers could be provided already in a notification message message from = the=20 backup/standby about active/primary server failure (i.e. the message = identified=20 in section 5.2.1 - Notificaiton from Standby Instance).=20
 <= /DIV>
In my view the approach of using a = separate=20 notificaiton message can be beneficial also for active instance guided = backup=20 server selection since the loadsharing information will then be = available before=20 reqular application signalling occurs. That is, sudden increases in = signalling=20 load will then be distributed correctly immediately instead of after = information=20 in the first returning application message answers has been received and = processed. At high load scenarios that may cause overload situation that = server(s) may handle more or less well depending on implementation. = Would be=20 good avoiding relying on that servers implement proper overload = control=20 IMHO and I therefore prefer the separate message approach (i.e. using = the same=20 separate message that needs to be defined to solve the section = 5.2.1 -=20 Notificaiton from Standby Instance problem).=20
 <= /DIV>
2) The timing=20 of state reconstruction after failure (covered in section 5.2.4 of [SR]) = can be=20 challenging due to the potentially large amount of states that need to = be=20 synchronized. Therefore a mechnism to perform bulk transfers = of state=20 information is needed. Such mechanism is defined in [RM-ext]. That is, a = Resource-Bag AVP can be included in an Session-Resource-Reply (SSR) = message. The=20 actual information (AVP(S)) that needs to be provided should if possible = be=20 restricted to what's needed by the server to take over the work of the=20 active/primary server. The information to be synchronized shold in my = view be=20 clearly defined by Diameter applications aiming at using a generic = Diameter=20 state synchronization mechanism (i.e. the subset of information that = must be=20 synchronized should be identified by the appliocation).=20
 <= /DIV>
For state=20 reconstruction upon reception of a request (second part of section 5.2.4 = of=20 [SR], the same need for identifying the subset of information that must = be=20 synchronized in application specification appears. Also, a backup server = without=20 complete resynchronized state must be capable of separating request = messages=20 that update soft-state and/or are issued for synchronization purposes = from=20 request messages that are sent to create a new state/session. E.g. 3GPP = Gq and=20 ETSI TSIAPN Gq' relies on that the server recognizes the session ID of = an AAR as=20 a new ID or an ID that belongs to an existing session. This precludes = the backup=20 server from treating update/synchronization messages different from = requests for=20 new sessions, which may be desired e.g. to handle overload situations = properly.=20 Therefore I beleive it would be beneficial to define an boolean = AVP for new=20 session/not new session as part of a Diameter state synchrinization = mechnism=20 together with rules for when this AVP shall/should be used by = applications in=20 request=20 messages. 
 <= /DIV>
Comments?
 <= /DIV>
BR Ulf=20  

All,

I've been looking in = whether the=20 original work on Diameter resource management extensions now captured = in=20 http://www.ietf.org/internet-drafts/draft-bodin-dime-auditing-re= qs-02.txt [RM-ext] would meet the demands = identified in=20 http://www.ietf.org/internet-drafts/draft-asveren-dime-state-rec= overy-01.txt [SR] on Diameter state recovery = considerations. Comments on this analyze are very wellcome. =

Going through section = 5.2.1 and 5.2.2=20 (PART 1) of [SR] and matching against [RM-ext] I noted the following = (remaing=20 sections/PARTs in following mail):

1) Having a = standby node=20 informing remote peers of the failure of an active instance (i.e. = 5.2.1 in=20 [SR]) is not covered by [RM-ext], not in any other spec (as far as I = know).=20 I'm not sure what kind of message would be appropriate for this = purpose (i.e.=20 a new mesage or an existing one such as CER). Any views on this? =
[Lionel = Morand] CER/CEA are=20 used to initiate a transport connection between diameter peers. In = this=20 specific case, we may assume that the Standby node may = actually also=20 indicate the active instance failure by sending a CER to the remote = peers. The=20 transport connection establishment would be a hint for the remote = peers to=20 detect that the Standby node is now active and that = therefore the=20 previous active node is down. The only problem is that CER/CAA = messages can=20 not be proxied, redirected or relayed i.e. it would be not possible to = use=20 this mechanism if a proxy/redirect/relay agent is present in the = Diameter path=20 between remote peers and Stanby/active node. This can not be = therefore=20 defined as a generic mechanism.  

[Ulf1] You're right = of course.=20 Informing remote peers of the failure of an active instance would = henece=20 require a new message I guess. that is, a message the be sent = immediately=20 after the CER/CAA message exchange directly following the detection of = that an=20 Active instance has become permanetly inavailable.=20

2) Synchronizing = state (i.e.=20 5.2.2, first paragraph in [SR]) is not natively supported by [RM-ext], = but=20 could be suppored with a small change/addition I beleive. E.g. through = a flag=20 in the SRQ saying whether all session information is requested for all = active=20 sessions (all information on all sessions is requested when no = Session-Id is=20 provided in the SRQ), or just the session-Id of all active sesisons = (i.e. an=20 SRR without any Resource-bag AVPs).
[Lionel Morand] if needed, I think that this = could be=20 easily fulfilled with an optional AVP in SQR e.g. "State = Synchronization AVP"=20 of Enumarated type, that would clearly indicate the granularity of = requested=20 information about active sessions. 

[Ulf1] Yes. I agree. = I forsee a=20 potential value in having a set of predefined values for different=20 granularities. For example, (a) all information on all active = sessions, (b)=20 session ids only for all active sessions, (c) all information or = session ids=20 only for all sessions that'll time out with x seconds, (d) all=20 information or session ids only for all sessions with application = property x (related to one or more application specific AVPs), etc. = While I=20 see a clear need for differentiating between (a) and (b), I think (c) = and (d)=20 type of values would be interesting to discuss to found out = whether that=20 can be useful or just makes the solution more complex.=20  

3) Reconstructing = session state=20 using application messages (i.e. 5.2.2, Using Application Messages in = [SR]) is=20 generally not supported by Diameter nor in [RM-ext]. As I understand = the=20 protocol a AAR updating an existing session is identified by that the=20 Session-Id is known by the server (i.e. is active), while an AAR = establishing=20 a new session provides a new Session-Id not currently being used for = any=20 active session. Hence, a flag indicating that the message is for an = existing=20 sesison (or a separate message) would be needed to facilitate state=20 reconstruction using mid-session messages.  

4) Reconstructing = session state using=20 generic messages (i.e. 5.2.2, Using a Generic Message in [SR]) is = indeed=20 supported by [RM-ext] (i.e. through SRQ and SRR in which state = information for=20 several sessions can be requested and provided respectively).=20

Best regards,
Ulf=20



------_=_NextPart_001_01C80055.03EE5DBA-- --===============1856449218== 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 --===============1856449218==-- From dime-bounces@ietf.org Wed Sep 26 12:40:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaZw9-0007pR-Vq; Wed, 26 Sep 2007 12:40:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaZw9-0007pJ-37; Wed, 26 Sep 2007 12:40:33 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaZw7-0007ii-Ve; Wed, 26 Sep 2007 12:40:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id E239F32893; Wed, 26 Sep 2007 16:40:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IaZvd-0008H3-R0; Wed, 26 Sep 2007 12:40:01 -0400 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, 26 Sep 2007 12:40:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-api-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 : The Diameter API Author(s) : P. Calhoun, D. Frascone Filename : draft-ietf-dime-diameter-api-03.txt Pages : 48 Date : 2007-09-26 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-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-api-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-api-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: <2007-09-26123816.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-diameter-api-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-diameter-api-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-26123816.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 Sep 26 21:10:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iahth-00080W-GU; Wed, 26 Sep 2007 21:10:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iahth-0007x1-1r; Wed, 26 Sep 2007 21:10:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iahtg-0005ID-MW; Wed, 26 Sep 2007 21:10:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 4F06D175C8; Thu, 27 Sep 2007 01:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IahtB-0006Q8-QE; Wed, 26 Sep 2007 21:10:01 -0400 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, 26 Sep 2007 21:10:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-api-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 : The Diameter API Author(s) : P. Calhoun, D. Frascone Filename : draft-ietf-dime-diameter-api-04.txt Pages : 48 Date : 2007-09-26 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-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-api-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-api-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: <2007-09-26210033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-diameter-api-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-diameter-api-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-26210033.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 Fri Sep 28 15:35:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbLbv-0007OQ-Na; Fri, 28 Sep 2007 15:34:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbLbu-0007Js-K2 for dime@ietf.org; Fri, 28 Sep 2007 15:34:50 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IbLbt-00024W-VS for dime@ietf.org; Fri, 28 Sep 2007 15:34:50 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1191008085!20944626!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9281 invoked from network); 28 Sep 2007 19:34:45 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-119.messagelabs.com with SMTP; 28 Sep 2007 19:34:45 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8SJYjUv013571 for ; Fri, 28 Sep 2007 12:34:45 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l8SJYi8q027632 for ; Fri, 28 Sep 2007 14:34:45 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l8SJYicF027622 for ; Fri, 28 Sep 2007 14:34:44 -0500 (CDT) 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, 28 Sep 2007 15:34:43 -0400 Message-ID: In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30222D09F@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 4004 Diameter MIP issues Thread-Index: Acf//VAzwhid8e60R2ucOGnB3Ro1HQBQqU9w References: <59D7431DE2527D4CB0F1EFEDA5683ED30222D09F@SEHAN021MB.tcad.telia.se> From: "McCann Peter-A001034" To: , X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: Subject: [Dime] RE: RFC 4004 Diameter MIP issues 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 jouni.korhonen@teliasonera.com wrote: > Hi, >=20 > I was reading RFC 4004 (again). Both MIP-HA-to-MN-SPI and > MIP-MN-to-HA-SPI are listed in respective command ABNFs as mandatory > AVPs & in AVP occurrence tables; see sections 9.4., 9.6., and 11.1. > However, no code values have been allocated and no types has been > defined. Any particular reason for this or am I missing something? =20 >=20 > Cheers, > Jouni Hi, Jouni, As this is the 3rd time this question has come up on the list, I went back and closely re-read the spec regarding key distribution. I think I've found a number of errors that need to be corrected. I hope we can develop an errata in the near future that addresses these things. 1. We left out the AAA-SPI needed for RFC 3957. In Section 8.2: The hashing algorithm used by the mobile node to construct the session key has to be the same as that used by the AAAH in the session key generation procedure. The AAAH therefore indicates the algorithm used along with the nonce. Should be: The hashing algorithm used by the mobile node to construct the session key has to be the same as that used by the AAAH in the session key generation procedure. The AAAH therefore indicates the algorithm used along with the nonce by including a AAA SPI. In Section 9: Need to add a new AVP to the table called "MIP-AAA-SPI" of type "Unsigned32". In Section 9.5. MIP-MN-to-FA-MSA AVP Need to include "{MIP-AAA-SPI}" right before the "{MIP-Nonce}" In Section 9.6 MIP-MN-to-HA-MSA AVP Need to include "{MIP-AAA-SPI}" right before the "{MIP-Nonce}" Create new section 9.15 describing the AAA-SPI: 9.15. MIP-AAA-SPI AVP The MIP-AAA-SPI AVP (AVP Code TBD) is of type Unsigned32 and contains the Security Parameter Index the AAA and MN use to=20 indicate the algorithm used to generate a Mobile IP Session Key from a Mobile IP Nonce. It appears in registration replies according to [RFC3957]. 2. The MN-FA SPI is created by the FA but is currently not being transferred in the AMR. This is needed by the HA to construct the Registration Reply that contains the Generalized MN-FA Key Generation Nonce Reply Extension. Section 5.1 AA-Mobile-Node-Request Need to include "[ MIP-MN-to-FA-SPI "] right after "[ MIP-HA-to-FA-SPI ]" in the grammar for AMR. Section 8.4 Distributing the Mobile-Foreign Session Key The HA also includes the SPIs proposed by the mobile node and foreign agent in the "Generalized MN-FA Key Generation Nonce Request" extension. Should be: The HA also includes the SPI proposed by the FA in the "Generalized MN-FA Key Generation Nonce Reply" extension. Note that the MIP-MN-to-FA-SPI is correctly included in=20 the MIP-MN-to-FA-MSA that is carried in the HAR and defined=20 in Section 9.5. This attribute, however, needs to be added to the table in Section 9: Insert "MIP-MN-to-FA-SPI" right after "MIP-HA-to-FA-SPI" in this table. Need to add a new Section 9.16: 9.16. MIP-MN-to-FA-SPI AVP The MIP-MN-to-FA-SPI AVP (AVP Code TBD) is of type Unsigned32 and contains the Security Parameter Index the MN and FA use to refer to the MN-FA mobility security association. The FA allocates the SPI, and it MUST NOT have a value between zero (0) and 255, which is the reserved namespace defined in [MOBILEIP]. 3. MN-HA SPI is not needed in the MN-HA MSA AVP. This AVP is sent to the HA, and the HA is the one that must choose the SPI. Therefore the SPI is not even available to send from the AAAH to the HA. Also, the text incorrectly states that the MN-HA-MSA AVP is carried in an AMR, when it should be AMA: In Section 9.6:=20 This AVP is conveyed to the HA in an HAR message for FA COA Mobile IPv4 and in an AMR for collocated Mobile IPv4. The HA allocates the MIP-MN-to-HA-SPI. The MN creates the MN-FA authentication extension using the session key and algorithm, and the HA verifies that extension using the same session key and algorithm. Should be: This AVP is conveyed to the HA in an HAR message for FA COA Mobile IPv4 and in an AMA for collocated Mobile IPv4. The HA allocates the MIP-MN-to-HA-SPI. The MN creates the MN-HA session key using the nonce and an algorithm indexed by the AAA SPI. Delete the line { MIP-MN-HA-SPI } from the ABNF. 4. The HA-MN SPI is not needed in the HA-MN MSA AVP. This is because the HA-MN SPI (chosen by the MN) is already present in the Registration Request that gets sent to the HA. Delete the line { MIP-HA-to-MN-SPI } from the ABNF in Section 9.4. 5. For consistency, we should change the text in Section 9.5 to match what I proposed above for Section 9.6: The MN creates the MN-FA authentication extension by using the session key and algorithm, and the FA verifies that extension using the same key and algorithm. Should be: The MN creates the MN-FA session key by using the nonce and an algorithm indexed by the AAA SPI. -Pete _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 28 16:05:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbM5G-0003cq-6Q; Fri, 28 Sep 2007 16:05:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbM5E-0003aP-Mv for dime@ietf.org; Fri, 28 Sep 2007 16:05:08 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbM54-0002m8-4S for dime@ietf.org; Fri, 28 Sep 2007 16:04:58 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 22:04:56 +0200 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, 28 Sep 2007 22:04:52 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222D140@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 4004 Diameter MIP issues Thread-Index: Acf//VAzwhid8e60R2ucOGnB3Ro1HQBQqU9wADKIjBA= From: To: , X-OriginalArrivalTime: 28 Sep 2007 20:04:56.0095 (UTC) FILETIME=[D70D22F0:01C8020A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [Dime] RE: RFC 4004 Diameter MIP issues 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 Pete, > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 >=20 > jouni.korhonen@teliasonera.com wrote: > > Hi, > >=20 > > I was reading RFC 4004 (again). Both MIP-HA-to-MN-SPI and=20 > > MIP-MN-to-HA-SPI are listed in respective command ABNFs as=20 > mandatory=20 > > AVPs & in AVP occurrence tables; see sections 9.4., 9.6., and 11.1. > > However, no code values have been allocated and no types has been > > defined. Any particular reason for this or am I missing=20 > something? =20 > >=20 > > Cheers, > > Jouni >=20 > Hi, Jouni, >=20 > As this is the 3rd time this question has come up on the=20 Heh.. Sorry ;) Reading archives is not my best virtue. > list, I went back and closely re-read the spec regarding key=20 > distribution. > I think I've found a number of errors that need to be corrected. > I hope we can develop an errata in the near future that=20 > addresses these things. Thanks for the list! It is pretty thorough. Cheers, Jouni [snip] >=20 > -Pete >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Sep 29 14:50:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbhOc-0000C9-QK; Sat, 29 Sep 2007 14:50:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbhOb-0000Bg-96; Sat, 29 Sep 2007 14:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbhOa-0007Ss-Rj; Sat, 29 Sep 2007 14:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id BB4D32AC50; Sat, 29 Sep 2007 18:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IbhO6-000818-78; Sat, 29 Sep 2007 14:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sat, 29 Sep 2007 14:50:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-mip6-split-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 : Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-split-05.txt Pages : 28 Date : 2007-09-29 Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the Home Agent and the Diameter server of the Mobile Service Provider (MSP). This document specifies the interaction between a Mobile IP Home Agent and the Diameter server. Several different mechanisms for authenticating a Mobile Node are supported. The usage of the Internet Key Exchange v2 (IKEv2) protocol allows different mechanisms, such as the Extensible Authentication Protocol (EAP), certificates and pre-shared secrets in IKEv2 to be used. Furthermore, another method makes use of the Mobile IPv6 Authentication protocol. In addition to authentication authorization, the configuration of Mobile IPv6 specific parameters and accounting is specified in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-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-mip6-split-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-mip6-split-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 From dime-bounces@ietf.org Sat Sep 29 14:50:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbhOc-0000C9-QK; Sat, 29 Sep 2007 14:50:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbhOb-0000Bg-96; Sat, 29 Sep 2007 14:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbhOa-0007Ss-Rj; Sat, 29 Sep 2007 14:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id BB4D32AC50; Sat, 29 Sep 2007 18:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IbhO6-000818-78; Sat, 29 Sep 2007 14:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sat, 29 Sep 2007 14:50:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-mip6-split-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 : Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-split-05.txt Pages : 28 Date : 2007-09-29 Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the Home Agent and the Diameter server of the Mobile Service Provider (MSP). This document specifies the interaction between a Mobile IP Home Agent and the Diameter server. Several different mechanisms for authenticating a Mobile Node are supported. The usage of the Internet Key Exchange v2 (IKEv2) protocol allows different mechanisms, such as the Extensible Authentication Protocol (EAP), certificates and pre-shared secrets in IKEv2 to be used. Furthermore, another method makes use of the Mobile IPv6 Authentication protocol. In addition to authentication authorization, the configuration of Mobile IPv6 specific parameters and accounting is specified in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-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-mip6-split-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-mip6-split-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: <2007-09-29144244.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-split-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-split-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-29144244.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 Sat Sep 29 14:50:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbhOe-0000Gj-TL; Sat, 29 Sep 2007 14:50:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbhOb-0000Bq-Hk; Sat, 29 Sep 2007 14:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbhOb-0007Sv-2t; Sat, 29 Sep 2007 14:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id AEEEA175A5; Sat, 29 Sep 2007 18:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IbhO6-00081B-82; Sat, 29 Sep 2007 14:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sat, 29 Sep 2007 14:50:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-qos-attributes-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 --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-02.txt Pages : 20 Date : 2007-09-29 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 is made available to the Diameter Network Access Server Application, the Diameter Credit Control Application and the Diameter Extensible Authentication Protocol (EAP) Application. Future Diameter applications can easily integrate Quality of Service support in addition to packet filtering. A URL for this Internet-Draft is: http://www.ietf.org/inFrom dime-bounces@ietf.org Sat Sep 29 14:50:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbhOc-0000C9-QK; Sat, 29 Sep 2007 14:50:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbhOb-0000Bg-96; Sat, 29 Sep 2007 14:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbhOa-0007Ss-Rj; Sat, 29 Sep 2007 14:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id BB4D32AC50; Sat, 29 Sep 2007 18:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IbhO6-000818-78; Sat, 29 Sep 2007 14:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sat, 29 Sep 2007 14:50:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-mip6-split-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 : Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-split-05.txt Pages : 28 Date : 2007-09-29 Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the Home Agent and the Diameter server of the Mobile Service Provider (MSP). This document specifies the interaction between a Mobile IP Home Agent and the Diameter server. Several different mechanisms for authenticating a Mobile Node are supported. The usage of the Internet Key Exchange v2 (IKEv2) protocol allows different mechanisms, such as the Extensible Authentication Protocol (EAP), certificates and pre-shared secrets in IKEv2 to be used. Furthermore, another method makes use of the Mobile IPv6 Authentication protocol. In addition to authentication authorization, the configuration of Mobile IPv6 specific parameters and accounting is specified in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-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-mip6-split-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-mip6-split-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: <2007-09-29144244.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-split-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-split-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-29144244.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 Sat Sep 29 14:50:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbhOe-0000Gj-TL; Sat, 29 Sep 2007 14:50:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbhOb-0000Bq-Hk; Sat, 29 Sep 2007 14:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbhOb-0007Sv-2t; Sat, 29 Sep 2007 14:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id AEEEA175A5; Sat, 29 Sep 2007 18:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IbhO6-00081B-82; Sat, 29 Sep 2007 14:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sat, 29 Sep 2007 14:50:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-qos-attributes-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 --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-02.txt Pages : 20 Date : 2007-09-29 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 is made available to the Diameter Network Access Server Application, the Diameter Credit Control Application and the Diameter Extensible Authentication Protocol (EAP) Application. Future Diameter applications can easily integrate Quality of Service support in addition to packet filtering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-02.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-02.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-02.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: <2007-09-29144311.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-qos-attributes-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-qos-attributes-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-29144311.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 Sat Sep 29 14:50:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbhOe-0000Gf-MA; Sat, 29 Sep 2007 14:50:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbhOb-0000Bo-Fz; Sat, 29 Sep 2007 14:50:33 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbhOa-0006uY-C1; Sat, 29 Sep 2007 14:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 56A9D328A1; Sat, 29 Sep 2007 18:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IbhO6-00081D-8d; Sat, 29 Sep 2007 14:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sat, 29 Sep 2007 14:50:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-qos-parameters-01.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: ENCODING mime FILE /internet-drafts/draft-ietf-dime-qos-attributes-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-qos-attributes-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-29144311.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 Sat Sep 29 14:50:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbhOe-0000Gf-MA; Sat, 29 Sep 2007 14:50:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbhOb-0000Bo-Fz; Sat, 29 Sep 2007 14:50:33 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbhOa-0006uY-C1; Sat, 29 Sep 2007 14:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 56A9D328A1; Sat, 29 Sep 2007 18:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IbhO6-00081D-8d; Sat, 29 Sep 2007 14:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sat, 29 Sep 2007 14:50:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-qos-parameters-01.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: ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-split-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-split-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-29144244.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 Sat Sep 29 14:50:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbhOe-0000Gj-TL; Sat, 29 Sep 2007 14:50:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbhOb-0000Bq-Hk; Sat, 29 Sep 2007 14:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbhOb-0007Sv-2t; Sat, 29 Sep 2007 14:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id AEEEA175A5; Sat, 29 Sep 2007 18:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IbhO6-00081B-82; Sat, 29 Sep 2007 14:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sat, 29 Sep 2007 14:50:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-qos-attributes-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 --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-02.txt Pages : 20 Date : 2007-09-29 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 is made available to the Diameter Network Access Server Application, the Diameter Credit Control Application and the Diameter Extensible Authentication Protocol (EAP) Application. Future Diameter applications can easily integrate Quality of Service support in addition to packet filtering. A URL for this Internet-Draft is: http://www.ietf.org/inime>, 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 Parameters for Usage with the AAA Framework Author(s) : J. Korhonen, H. Tschofenig Filename : draft-ietf-dime-qos-parameters-01.txt Pages : 19 Date : 2007-09-29 This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.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-parameters-01.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-parameters-01.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: <2007-09-29144326.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-qos-parameters-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-qos-parameters-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-29144326.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-- ime>, 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 Parameters for Usage with the AAA Framework Author(s) : J. Korhonen, H. Tschofenig Filename : draft-ietf-dime-qos-parameters-01.txt Pages : 19 Date : 2007-09-29 This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.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-parameters-01.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-parameters-01.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: <2007-09-29144326.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-qos-parameters-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-qos-parameters-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-29144326.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-- ternet-drafts/draft-ietf-dime-qos-attributes-02.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-02.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-02.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: <2007-09-29144311.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-qos-attributes-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-qos-attributes-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-29144311.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 Sat Sep 29 14:50:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbhOe-0000Gf-MA; Sat, 29 Sep 2007 14:50:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbhOb-0000Bo-Fz; Sat, 29 Sep 2007 14:50:33 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbhOa-0006uY-C1; Sat, 29 Sep 2007 14:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 56A9D328A1; Sat, 29 Sep 2007 18:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IbhO6-00081D-8d; Sat, 29 Sep 2007 14:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sat, 29 Sep 2007 14:50:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-qos-parameters-01.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 Parameters for Usage with the AAA Framework Author(s) : J. Korhonen, H. Tschofenig Filename : draft-ietf-dime-qos-parameters-01.txt Pages : 19 Date : 2007-09-29 This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.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-parameters-01.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-parameters-01.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: <2007-09-29144326.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-qos-parameters-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-qos-parameters-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-29144326.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 Sun Sep 30 03:59:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibtgl-0006ER-VO; Sun, 30 Sep 2007 03:58:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibtgk-0006DO-HP for dime@ietf.org; Sun, 30 Sep 2007 03:58:06 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ibtgd-0004Mz-O8 for dime@ietf.org; Sun, 30 Sep 2007 03:58:00 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Sep 2007 09:57:57 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C80337.9D11073E" Subject: FW: [Dime] I-D Action:draft-ietf-dime-mip6-split-05.txt Date: Sun, 30 Sep 2007 09:57:57 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222D14B@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Dime] I-D Action:draft-ietf-dime-mip6-split-05.txt Thread-Index: AcgCynW85XYtGhJ4SLq5iFz4k/nZwQAa99Pg From: To: X-OriginalArrivalTime: 30 Sep 2007 07:57:57.0894 (UTC) FILETIME=[9D675A60:01C80337] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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 is a multi-part message in MIME format. ------_=_NextPart_001_01C80337.9D11073E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable FYI. Quick summary of changes: o text for IKEv2 with certificate based mobile node authentication added o text for IKEv2 with pre-shared key based mobile node authentication added o RFC4285 support reworked, including few new AVPs so that the job gets done (it is now adequate for 3GPP2 usage of the auth option. WiMAX one needs to be still verified) o AVP tables are now up to date o a lot of small text tweaks here and there=20 I encourage people with interest and connections to "interest" SDOs to review the I-D, especially for the RFC4285 part. Cheers, Jouni > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Saturday, September 29, 2007 9:50 PM > To: i-d-announce@ietf.org > Cc: dime@ietf.org > Subject: [Dime] I-D Action:draft-ietf-dime-mip6-split-05.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Diameter Maintenance and=20 > Extensions Working Group of the IETF. >=20 >=20 > Title : Diameter Mobile IPv6: Support for=20 > Home Agent to Diameter Server Interaction > Author(s) : J. Korhonen, et al. > Filename : draft-ietf-dime-mip6-split-05.txt > Pages : 28 > Date : 2007-09-29 >=20 > Mobile IPv6 deployments may want to bootstrap their=20 > operations dynamically based on an interaction between the=20 > Home Agent and the Diameter server of the Mobile Service=20 > Provider (MSP). This document specifies the interaction=20 > between a Mobile IP Home Agent and the Diameter server. >=20 > Several different mechanisms for authenticating a Mobile Node=20 > are supported. The usage of the Internet Key Exchange v2=20 > (IKEv2) protocol allows different mechanisms, such as the=20 > Extensible Authentication Protocol (EAP), certificates and=20 > pre-shared secrets in > IKEv2 to be used. Furthermore, another method makes use of=20 > the Mobile IPv6 Authentication protocol. In addition to=20 > authentication authorization, the configuration of Mobile=20 > IPv6 specific parameters and accounting is specified in this document. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-05.txt ------_=_NextPart_001_01C80337.9D11073E Content-Type: text/plain; charset="us-ascii"; name="draft-ietf-dime-mip6-split-05.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-dime-mip6-split-05.txt Content-Disposition: attachment; filename="draft-ietf-dime-mip6-split-05.txt" RklMRSBRVUFSQU5USU5FRA0KLS0tLS0tLS0tLS0tLS0tLQ0KDQpNaWNyb3NvZnQgQW50aWdlbiBm b3IgRXhjaGFuZ2UgcmVtb3ZlZCBhIGZpbGUgc2luY2UgaXQgd2FzIGZvdW5kIHRvIG1hdGNoIGEg ZmlsdGVyLg0KRmlsZSBuYW1lOiAiZHJhZnRfaWV0Zl9kaW1lX21pcDZfc3BsaXRfMDUuVVJMIg0K RmlsdGVyIG5hbWU6ICJGSUxFIEZJTFRFUj0gdW5uYW1lZDogKi51cmwiDQo= ------_=_NextPart_001_01C80337.9D11073E 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_001_01C80337.9D11073E-- From dime-bounces@ietf.org Sun Sep 30 04:15:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibtwl-0000HJ-Pn; Sun, 30 Sep 2007 04:14:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibtwk-0000H4-LG for dime@ietf.org; Sun, 30 Sep 2007 04:14:38 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ibtwb-0004tf-SY for dime@ietf.org; Sun, 30 Sep 2007 04:14:30 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Sep 2007 10:14:28 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C80339.EBAB1164" Subject: FW: [Dime] I-D Action:draft-ietf-dime-qos-parameters-01.txt Date: Sun, 30 Sep 2007 10:14:27 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222D14C@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Dime] I-D Action:draft-ietf-dime-qos-parameters-01.txt Thread-Index: AcgCynJMWGYZKtB0QcKKLh2jG6bxXQAbentA From: To: X-OriginalArrivalTime: 30 Sep 2007 08:14:28.0760 (UTC) FILETIME=[EC018180:01C80339] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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 is a multi-part message in MIME format. ------_=_NextPart_001_01C80339.EBAB1164 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable FYI.. quick summary of changes: o We added a section about the general extensibility of QoS profiles in general, which basically allows now IANA registry for profiles and vendor spefic values o IANA considerations have been spelled out now instead of just having a reference there o small text fixes here and there Cheers, Jouni > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Saturday, September 29, 2007 9:50 PM > To: i-d-announce@ietf.org > Cc: dime@ietf.org > Subject: [Dime] I-D Action:draft-ietf-dime-qos-parameters-01.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Diameter Maintenance and=20 > Extensions Working Group of the IETF. >=20 >=20 > Title : Quality of Service Parameters for=20 > Usage with the AAA Framework > Author(s) : J. Korhonen, H. Tschofenig > Filename : draft-ietf-dime-qos-parameters-01.txt > Pages : 19 > Date : 2007-09-29 >=20 > This document defines a number of Quality of Service (QoS)=20 > parameters that can be reused for conveying QoS information=20 > within RADIUS and Diameter. >=20 > The payloads used to carry these QoS parameters are opaque=20 > for the AAA client and the AAA server itself and interpreted=20 > by the respective Resource Management Function. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parame > ters-01.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-dime-qos-parameters-01.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-dime-qos-parameters-01.txt". >=20 > 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=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 ------_=_NextPart_001_01C80339.EBAB1164 Content-Type: text/plain; charset="us-ascii"; name="draft-ietf-dime-qos-parameters-01.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-dime-qos-parameters-01.txt Content-Disposition: attachment; filename="draft-ietf-dime-qos-parameters-01.txt" RklMRSBRVUFSQU5USU5FRA0KLS0tLS0tLS0tLS0tLS0tLQ0KDQpNaWNyb3NvZnQgQW50aWdlbiBm b3IgRXhjaGFuZ2UgcmVtb3ZlZCBhIGZpbGUgc2luY2UgaXQgd2FzIGZvdW5kIHRvIG1hdGNoIGEg ZmlsdGVyLg0KRmlsZSBuYW1lOiAiZHJhZnRfaWV0Zl9kaW1lX3Fvc19wYXJhbWV0ZXJzXzAxLlVS TCINCkZpbHRlciBuYW1lOiAiRklMRSBGSUxURVI9IHVubmFtZWQ6ICoudXJsIg0K ------_=_NextPart_001_01C80339.EBAB1164 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_001_01C80339.EBAB1164-- From dime-bounces@ietf.org Sun Sep 30 04:29:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbuBC-0005nl-1b; Sun, 30 Sep 2007 04:29:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbuBA-0005gT-9F for dime@ietf.org; Sun, 30 Sep 2007 04:29:32 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbuB9-0001xI-QL for dime@ietf.org; Sun, 30 Sep 2007 04:29:32 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Sep 2007 10:29:30 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8033C.05260F5A" Subject: FW: [Dime] I-D Action:draft-ietf-dime-qos-attributes-02.txt Date: Sun, 30 Sep 2007 10:29:28 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222D14D@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Dime] I-D Action:draft-ietf-dime-qos-attributes-02.txt Thread-Index: AcgCynJ12eFoEgyFQQOBVGir4aNLmAAb57ug From: To: X-OriginalArrivalTime: 30 Sep 2007 08:29:30.0486 (UTC) FILETIME=[0579F960:01C8033C] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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 is a multi-part message in MIME format. ------_=_NextPart_001_01C8033C.05260F5A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable FYI.. Quick summary of changes: o QoS Profile changes in the QoS-Parameters I-D also reflected in this I-D o AVP tables corrected (except an error sneaked in for QoS-Profile type) o There was a clash between QoS parameter and QoS-Parameter AVP that made the distinction between different meanings hard to notice. Thus we changed QoS-Parameter AVP to QoS-Blob-Group and QSPEC to QoS-Blob etc (talk about innovative AVP naming ;) o QoS filtering information has now a flag indicating to which direction those filters should be tried to match o With QoS-Profile AVP it is now possible to provide QoS profiles that get initiated by a reference only i.e. pre-provisioned QoS profiles are possible and no need to transfer QoS-Blob between nodes o Corrections on signaling flows o Proper IANA considerations o Description of semantics of QoS Profiles.. Cheers, Jouni > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Saturday, September 29, 2007 9:50 PM > To: i-d-announce@ietf.org > Cc: dime@ietf.org > Subject: [Dime] I-D Action:draft-ietf-dime-qos-attributes-02.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Diameter Maintenance and=20 > Extensions Working Group of the IETF. >=20 >=20 > Title : Quality of Service Attributes for Diameter > Author(s) : J. Korhonen, et al. > Filename : draft-ietf-dime-qos-attributes-02.txt > Pages : 20 > Date : 2007-09-29 >=20 > This document extends the QoSFilterRule AVP functionality of=20 > the Diameter Base protocol and the functionality of the=20 > QoS-Filter-Rule AVP defined in RFC 4005. The ability to=20 > convey Quality of Service information is made available to=20 > the Diameter Network Access Server Application, the Diameter=20 > Credit Control Application and the Diameter Extensible=20 > Authentication Protocol (EAP) Application. Future Diameter=20 > applications can easily integrate Quality of Service support=20 > in addition to packet filtering. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attrib > utes-02.txt ------_=_NextPart_001_01C8033C.05260F5A Content-Type: text/plain; charset="us-ascii"; name="draft-ietf-dime-qos-attributes-02.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-dime-qos-attributes-02.txt Content-Disposition: attachment; filename="draft-ietf-dime-qos-attributes-02.txt" RklMRSBRVUFSQU5USU5FRA0KLS0tLS0tLS0tLS0tLS0tLQ0KDQpNaWNyb3NvZnQgQW50aWdlbiBm b3IgRXhjaGFuZ2UgcmVtb3ZlZCBhIGZpbGUgc2luY2UgaXQgd2FzIGZvdW5kIHRvIG1hdGNoIGEg ZmlsdGVyLg0KRmlsZSBuYW1lOiAiZHJhZnRfaWV0Zl9kaW1lX3Fvc19hdHRyaWJ1dGVzXzAyLlVS TCINCkZpbHRlciBuYW1lOiAiRklMRSBGSUxURVI9IHVubmFtZWQ6ICoudXJsIg0K ------_=_NextPart_001_01C8033C.05260F5A 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_001_01C8033C.05260F5A--