From dime-bounces@ietf.org Mon Oct 02 05:04:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUJj8-0007L8-Hx; Mon, 02 Oct 2006 05:04:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUJj7-0007L3-PO for dime@ietf.org; Mon, 02 Oct 2006 05:04:41 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUJj6-0006mJ-Eb for dime@ietf.org; Mon, 02 Oct 2006 05:04:41 -0400 Received: by ug-out-1314.google.com with SMTP id 72so425021ugd for ; Mon, 02 Oct 2006 02:04:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=OvYgxy55PZ7sGmcZWYPnGq3VUjFkM9ZscgKX0yycGfcDjD+a9cGSf9ElSZkox44pG2+zf1PKj9+xLgy2uDvZBf8lQmt40MceTbb9eJ4jLrYPTrQbqzO7eQxhiVblnPO3ilTQTMI6CF2td3q2/eVuS1r6rTof2MHy0f5b/srmX9Q= Received: by 10.66.216.20 with SMTP id o20mr2610816ugg; Mon, 02 Oct 2006 02:04:39 -0700 (PDT) Received: by 10.66.237.2 with HTTP; Mon, 2 Oct 2006 02:04:39 -0700 (PDT) Message-ID: Date: Mon, 2 Oct 2006 11:04:39 +0200 From: "Gerardo Giaretta" To: dime@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Dime] Some thoughts about Diameter MIPv6 Application 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 would like to share with you some considerations about the Diameter Application for MIPv6. Some questions also follow. - first of all I think the proposal made by Yoshi to use rfc4072 in AUTHENTICATION_ONLY mode and define another MIP6-specific application for authorization is the right one. Indeed, this would let separate clearly the authentication procedure from the authorization step and I think this is really needed in case IKEv2 is used. Suppose for example a node acts as both VPN concentrator and HA (or 3GPP PDG and HA): it supports IKEv2 signaling and acts as EAP pass-through authenticator in order to setup the IPsec SA with the peer. If a MN starts an IKEv2 exchange with this node, this node has no way to know if the MN is going to use MIPv6 service or not (since the MN could be just setting up the SA for remore access). Therefore, we need to take into account that the HA is not sure that the MN is going to use MIPv6 service untill it receives a BU. In my view, this is a valid reason to keep authentication and authorization separated: the former is based on rfc4072 and occurs during IKEv2 exchange, the latter is mip6-specific and can be done later - based on what stated above, the first authorization request should be sent by the HA upon the receipt of the first BU. However, this will increase the latency of the first registration, since the AAA of the MSA will be involved. Notice that in case the MN is moving from the home link to a visited link, the first registration has low handoff latency requirements. An alternative approach to handle this scenario is that the HA sends the Authorization Request in a proactive way, before receiving the BU. However, based on what stated above, this is possible only if the HA is sure the MN will use MIPv6 service (i.e. the IKEv2 responder acts only as HA and not as a generic node providing remote access) - based on draft-ietf-mip6-aaa-ha-goals the AAA server may send an Abort Session Request to the HA in order to stop the MIPv6 service for a MN. This message may be very similar to the ASR in NASREQ. One question is: from a MIPv6 perspective, is there any signaling the HA will send to the MN to communicate that the session is over for a specific reason? Or the MN is just blocked? - I guess, as in NASREQ, the AAA-MSA sends an authorization lifetime to the HA and this lifetime will be renewed later. Is this authorization lifetime related with the BU/BA lifetime? Are they equal or orthogonal? The HA may set the binding lifetime in the BA equal to the authorization lifetime. Is this approach useful? - again on the re-authorization: which are the information used to request the re-authorization? Does a change of CoA trigger a re-authentication? This will let the operator to authorize the MN depending on the location. However this will increase the handoff latency experienced by the MN. - on the identities used by the MN: which identity is used by the HA to identify the MN in the authorization phase? There is no identity in the BU, unless we use the HoA as the identity. Otherwise the HA must keep the identity used in IKEv2 by the MN. Any thought? --Gerardo _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 02 10:42:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOzs-0002ru-OW; Mon, 02 Oct 2006 10:42:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOzs-0002oz-1l for dime@ietf.org; Mon, 02 Oct 2006 10:42:20 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOzp-0002G1-LX for dime@ietf.org; Mon, 02 Oct 2006 10:42:20 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Oct 2006 07:42:17 -0700 X-IronPort-AV: i="4.09,245,1157353200"; d="scan'208"; a="44497070:sNHT57954460" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92EgH8A026824; Mon, 2 Oct 2006 10:42:17 -0400 Received: from [161.44.55.201] (dhcp-161-44-55-201.cisco.com [161.44.55.201]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k92EgGuI004506; Mon, 2 Oct 2006 10:42:16 -0400 (EDT) Message-ID: <45212547.5030908@cisco.com> Date: Mon, 02 Oct 2006 10:42:15 -0400 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] receving connections from 3868 with multiple instances. References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=3476; t=1159800137; x=1160664137; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andersk@cisco.com; z=From:Anders=20Kristensen=20 |Subject:Re=3A=20[Dime]=20receving=20connections=20from=203868=20with=20multiple= 20instances. |To:Tolga=20Asveren=20; X=v=3Dcisco.com=3B=20h=3DJEzmlgBBbrPo5Z4fjZlYznRLiqs=3D; b=rwyo5DlebzBZRZMovkXImE5fNKG2Me6lW05mlhnaCZOmY9UclyOxMfXSgUQhoRguaximc6iE zTNc/GB1ddFhf8MTiG0Znw+tyMmPnpg+7AmxxSy0PvBaxgADcoHlQbdb; Authentication-Results: rtp-dkim-2.cisco.com; header.From=andersk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: dime@ietf.org, Andreas Fredriksson , Valesh Chandu 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 agree that we should get rid of the "must listen on port 3868" rule and that it should be OK for multiple Diameter nodes to reside on the same physical host, even using the same IP. It would probably also be a good idea for us to nail down how SRV is used for Diameter. Could go into 3588bis. Thanks, Anders Tolga Asveren wrote: > Hi Andreas, > > For a truly dynamic discovery, wouldn't the "Port" in SRV lookup result > address your concern of not being able to distinguish between multiple > instances on the same host? > > Thanks, > Tolga > > >>-----Original Message----- >>From: Andreas Fredriksson [mailto:Andreas.Fredriksson@digitalroute.com] >>Sent: Thursday, September 21, 2006 3:27 AM >>To: Timothy Smith >>Cc: dime@ietf.org; Valesh Chandu >>Subject: Re: [Dime] receving connections from 3868 with multiple >>instances. >> >> >>Timothy Smith wrote: >> >>>Hi Chandu, >>> >>>I think you have touched on an area where there are a couple of >>>unclear points. I also interpret that you can have multiple Diameter >>>nodes on the same host. I think this implies: >>>1) Each node must listen on a different port as you have pointed out. >>> So, only one of the nodes can use the recommended port 3868. >>>2) The Origin-Host AVP is also problematic in that its value conflicts >>>in a host with multiple Diameter nodes. The Origin-Host is of type >>>Diameter Identity, and "The value of the Origin-Host AVP is guaranteed >>>to be unique within a single host". But also, "DiameterIdentity value >>>is used to uniquely identify a Diameter node for purposes of duplicate >>>connection..." These two statements are inconsistent on a host with >>>multiple Diameter nodes. The Diameter Identity is a FQDN which >>>realistically means you can only have a single Origin-Host name for >>>all of the nodes on a given host. So, the dilemma is that if you have >>>multiple Diameter nodes on host A and multiple Diameter nodes on host >>>B, then because of the single connection rule, you will only be able >>>to set up one connection between one of the nodes on host A and one of >>>the nodes on host B. This is something that I think should be >>>clarified in the BIS document. My preference would be to say that the >>>Origin-Host AVP should be a FQDN, but not that it must be a FQDN. >>> That way, you could assign a unique Origin-Host name to each Diameter >>>node on a host. And any or all nodes on Host A could establish a >>>connection to any or all nodes on Host B. >> >>Hi, >>I think the port 3868 restriction helps when you're doing dynamic peer >>discovery. If an implementation sees an unknown diameter identity it >>could try the various discovery options outlined in the RFC (e.g. DNS >>lookups). These do not include a port anywhere IIRC and if there are >>multiple stacks running on a single IP messages could end up on the >>wrong stack. >> >>However, it's perfectly fine to use several IP addresses (using ethernet >>aliases) on a single box which map to different FQDNs. This removes the >>above limitation and is fine as far as the RFC goes. >> >>Best regards, >>Andreas >> >>_______________________________________________ >>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 Oct 02 11:31:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUPlI-0003qn-HJ; Mon, 02 Oct 2006 11:31:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUPlH-0003qi-F7 for dime@ietf.org; Mon, 02 Oct 2006 11:31:19 -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 1GUPlH-0000ML-1c for dime@ietf.org; Mon, 02 Oct 2006 11:31:19 -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 k92FUVh9030574; Mon, 2 Oct 2006 11:30:31 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <45213097.5030202@tari.toshiba.com> Date: Mon, 02 Oct 2006 11:30:31 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.5 (X11/20060812) MIME-Version: 1.0 To: Anders Kristensen Subject: Re: [Dime] receving connections from 3868 with multiple instances. References: <45212547.5030908@cisco.com> In-Reply-To: <45212547.5030908@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: dime@ietf.org, Andreas Fredriksson , Valesh Chandu 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 Anders, > I agree that we should get rid of the "must listen on port 3868" rule > and that it should be OK for multiple Diameter nodes to reside on the > same physical host, even using the same IP. It would probably also be > a good idea for us to nail down how SRV is used for Diameter. Could go > into 3588bis. Maybe I'm missing something but why should we remove the text "must listen on port 3868" ? regards, victor > > Thanks, > Anders > > Tolga Asveren wrote: >> Hi Andreas, >> >> For a truly dynamic discovery, wouldn't the "Port" in SRV lookup result >> address your concern of not being able to distinguish between multiple >> instances on the same host? >> >> Thanks, >> Tolga >> >> >>> -----Original Message----- >>> From: Andreas Fredriksson [mailto:Andreas.Fredriksson@digitalroute.com] >>> Sent: Thursday, September 21, 2006 3:27 AM >>> To: Timothy Smith >>> Cc: dime@ietf.org; Valesh Chandu >>> Subject: Re: [Dime] receving connections from 3868 with multiple >>> instances. >>> >>> >>> Timothy Smith wrote: >>> >>>> Hi Chandu, >>>> >>>> I think you have touched on an area where there are a couple of >>>> unclear points. I also interpret that you can have multiple Diameter >>>> nodes on the same host. I think this implies: >>>> 1) Each node must listen on a different port as you have pointed out. >>>> So, only one of the nodes can use the recommended port 3868. >>>> 2) The Origin-Host AVP is also problematic in that its value conflicts >>>> in a host with multiple Diameter nodes. The Origin-Host is of type >>>> Diameter Identity, and "The value of the Origin-Host AVP is guaranteed >>>> to be unique within a single host". But also, "DiameterIdentity value >>>> is used to uniquely identify a Diameter node for purposes of duplicate >>>> connection..." These two statements are inconsistent on a host with >>>> multiple Diameter nodes. The Diameter Identity is a FQDN which >>>> realistically means you can only have a single Origin-Host name for >>>> all of the nodes on a given host. So, the dilemma is that if you have >>>> multiple Diameter nodes on host A and multiple Diameter nodes on host >>>> B, then because of the single connection rule, you will only be able >>>> to set up one connection between one of the nodes on host A and one of >>>> the nodes on host B. This is something that I think should be >>>> clarified in the BIS document. My preference would be to say that the >>>> Origin-Host AVP should be a FQDN, but not that it must be a FQDN. >>>> That way, you could assign a unique Origin-Host name to each Diameter >>>> node on a host. And any or all nodes on Host A could establish a >>>> connection to any or all nodes on Host B. >>> >>> Hi, >>> I think the port 3868 restriction helps when you're doing dynamic peer >>> discovery. If an implementation sees an unknown diameter identity it >>> could try the various discovery options outlined in the RFC (e.g. DNS >>> lookups). These do not include a port anywhere IIRC and if there are >>> multiple stacks running on a single IP messages could end up on the >>> wrong stack. >>> >>> However, it's perfectly fine to use several IP addresses (using >>> ethernet >>> aliases) on a single box which map to different FQDNs. This removes the >>> above limitation and is fine as far as the RFC goes. >>> >>> Best regards, >>> Andreas >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 02 14:13:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUSIX-00037b-6v; Mon, 02 Oct 2006 14:13:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUSIW-00033l-57 for dime@ietf.org; Mon, 02 Oct 2006 14:13:48 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUSIU-0003n2-PG for dime@ietf.org; Mon, 02 Oct 2006 14:13:48 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Oct 2006 14:13:46 -0400 X-IronPort-AV: i="4.09,245,1157342400"; d="scan'208"; a="105409098:sNHT62732768" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92IDkSI021656; Mon, 2 Oct 2006 14:13:46 -0400 Received: from [161.44.55.201] (dhcp-161-44-55-201.cisco.com [161.44.55.201]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k92IDjdM022250; Mon, 2 Oct 2006 14:13:45 -0400 (EDT) Message-ID: <452156D9.8090503@cisco.com> Date: Mon, 02 Oct 2006 14:13:45 -0400 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Victor Fajardo Subject: Re: [Dime] receving connections from 3868 with multiple instances. References: <45212547.5030908@cisco.com> <45213097.5030202@tari.toshiba.com> In-Reply-To: <45213097.5030202@tari.toshiba.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=4237; t=1159812826; x=1160676826; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andersk@cisco.com; z=From:Anders=20Kristensen=20 |Subject:Re=3A=20[Dime]=20receving=20connections=20from=203868=20with=20multiple= 20instances. |To:Victor=20Fajardo=20; X=v=3Dcisco.com=3B=20h=3DJEzmlgBBbrPo5Z4fjZlYznRLiqs=3D; b=n1mTw+ZkF8Qp4yxhTwohNczFmq4NZnrWvzfxH471RzQmLlbE7C4VcKtVzurerg/tXpO672z+ Vlv/lIMzkTcnct3AuStasiNzl/PxxawU/uNO5t6Keh7cn40oal+LCEek; Authentication-Results: rtp-dkim-2.cisco.com; header.From=andersk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: dime@ietf.org, Andreas Fredriksson , Valesh Chandu 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 Victor Fajardo wrote: > Hi Anders, > >> I agree that we should get rid of the "must listen on port 3868" rule >> and that it should be OK for multiple Diameter nodes to reside on the >> same physical host, even using the same IP. It would probably also be >> a good idea for us to nail down how SRV is used for Diameter. Could go >> into 3588bis. > > > Maybe I'm missing something but why should we remove the text "must > listen on port 3868" ? Because we want to allow multiple logical "nodes" to run on a single host without them necessarily using separate IP addresses. Only one node can listen on port 3868. Anders > > regards, > victor > >> >> Thanks, >> Anders >> >> Tolga Asveren wrote: >> >>> Hi Andreas, >>> >>> For a truly dynamic discovery, wouldn't the "Port" in SRV lookup result >>> address your concern of not being able to distinguish between multiple >>> instances on the same host? >>> >>> Thanks, >>> Tolga >>> >>> >>>> -----Original Message----- >>>> From: Andreas Fredriksson [mailto:Andreas.Fredriksson@digitalroute.com] >>>> Sent: Thursday, September 21, 2006 3:27 AM >>>> To: Timothy Smith >>>> Cc: dime@ietf.org; Valesh Chandu >>>> Subject: Re: [Dime] receving connections from 3868 with multiple >>>> instances. >>>> >>>> >>>> Timothy Smith wrote: >>>> >>>>> Hi Chandu, >>>>> >>>>> I think you have touched on an area where there are a couple of >>>>> unclear points. I also interpret that you can have multiple Diameter >>>>> nodes on the same host. I think this implies: >>>>> 1) Each node must listen on a different port as you have pointed out. >>>>> So, only one of the nodes can use the recommended port 3868. >>>>> 2) The Origin-Host AVP is also problematic in that its value conflicts >>>>> in a host with multiple Diameter nodes. The Origin-Host is of type >>>>> Diameter Identity, and "The value of the Origin-Host AVP is guaranteed >>>>> to be unique within a single host". But also, "DiameterIdentity value >>>>> is used to uniquely identify a Diameter node for purposes of duplicate >>>>> connection..." These two statements are inconsistent on a host with >>>>> multiple Diameter nodes. The Diameter Identity is a FQDN which >>>>> realistically means you can only have a single Origin-Host name for >>>>> all of the nodes on a given host. So, the dilemma is that if you have >>>>> multiple Diameter nodes on host A and multiple Diameter nodes on host >>>>> B, then because of the single connection rule, you will only be able >>>>> to set up one connection between one of the nodes on host A and one of >>>>> the nodes on host B. This is something that I think should be >>>>> clarified in the BIS document. My preference would be to say that the >>>>> Origin-Host AVP should be a FQDN, but not that it must be a FQDN. >>>>> That way, you could assign a unique Origin-Host name to each Diameter >>>>> node on a host. And any or all nodes on Host A could establish a >>>>> connection to any or all nodes on Host B. >>>> >>>> >>>> Hi, >>>> I think the port 3868 restriction helps when you're doing dynamic peer >>>> discovery. If an implementation sees an unknown diameter identity it >>>> could try the various discovery options outlined in the RFC (e.g. DNS >>>> lookups). These do not include a port anywhere IIRC and if there are >>>> multiple stacks running on a single IP messages could end up on the >>>> wrong stack. >>>> >>>> However, it's perfectly fine to use several IP addresses (using >>>> ethernet >>>> aliases) on a single box which map to different FQDNs. This removes the >>>> above limitation and is fine as far as the RFC goes. >>>> >>>> Best regards, >>>> Andreas >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> >>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 02 16:04:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUU1b-0001BE-QM; Mon, 02 Oct 2006 16:04:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUU1b-0001B9-Dd for dime@ietf.org; Mon, 02 Oct 2006 16:04:27 -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 1GUU1a-0008Iu-W3 for dime@ietf.org; Mon, 02 Oct 2006 16:04:27 -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 k92K3WmT032062; Mon, 2 Oct 2006 16:03:32 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <45217094.1080900@tari.toshiba.com> Date: Mon, 02 Oct 2006 16:03:32 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.5 (X11/20060812) MIME-Version: 1.0 To: Anders Kristensen Subject: Re: [Dime] receving connections from 3868 with multiple instances. References: <45212547.5030908@cisco.com> <45213097.5030202@tari.toshiba.com> <452156D9.8090503@cisco.com> In-Reply-To: <452156D9.8090503@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: dime@ietf.org, Andreas Fredriksson , Valesh Chandu 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 Anders, > Because we want to allow multiple logical "nodes" to run on a single > host without them necessarily using separate IP addresses. Only one > node can listen on port 3868. Hmmm ... but maybe this type of scenario's is an implementation/deployment specific issue. My concern is whether people consider this a real issue in 3588. I'm not sure it is significant enough to merit changes in bis. regards, victor > > Anders > >> >> regards, >> victor >> >>> >>> Thanks, >>> Anders >>> >>> Tolga Asveren wrote: >>> >>>> Hi Andreas, >>>> >>>> For a truly dynamic discovery, wouldn't the "Port" in SRV lookup >>>> result >>>> address your concern of not being able to distinguish between multiple >>>> instances on the same host? >>>> >>>> Thanks, >>>> Tolga >>>> >>>> >>>>> -----Original Message----- >>>>> From: Andreas Fredriksson >>>>> [mailto:Andreas.Fredriksson@digitalroute.com] >>>>> Sent: Thursday, September 21, 2006 3:27 AM >>>>> To: Timothy Smith >>>>> Cc: dime@ietf.org; Valesh Chandu >>>>> Subject: Re: [Dime] receving connections from 3868 with multiple >>>>> instances. >>>>> >>>>> >>>>> Timothy Smith wrote: >>>>> >>>>>> Hi Chandu, >>>>>> >>>>>> I think you have touched on an area where there are a couple of >>>>>> unclear points. I also interpret that you can have multiple >>>>>> Diameter >>>>>> nodes on the same host. I think this implies: >>>>>> 1) Each node must listen on a different port as you have pointed >>>>>> out. >>>>>> So, only one of the nodes can use the recommended port 3868. >>>>>> 2) The Origin-Host AVP is also problematic in that its value >>>>>> conflicts >>>>>> in a host with multiple Diameter nodes. The Origin-Host is of type >>>>>> Diameter Identity, and "The value of the Origin-Host AVP is >>>>>> guaranteed >>>>>> to be unique within a single host". But also, "DiameterIdentity >>>>>> value >>>>>> is used to uniquely identify a Diameter node for purposes of >>>>>> duplicate >>>>>> connection..." These two statements are inconsistent on a host >>>>>> with >>>>>> multiple Diameter nodes. The Diameter Identity is a FQDN which >>>>>> realistically means you can only have a single Origin-Host name for >>>>>> all of the nodes on a given host. So, the dilemma is that if you >>>>>> have >>>>>> multiple Diameter nodes on host A and multiple Diameter nodes on >>>>>> host >>>>>> B, then because of the single connection rule, you will only be able >>>>>> to set up one connection between one of the nodes on host A and >>>>>> one of >>>>>> the nodes on host B. This is something that I think should be >>>>>> clarified in the BIS document. My preference would be to say >>>>>> that the >>>>>> Origin-Host AVP should be a FQDN, but not that it must be a FQDN. >>>>>> That way, you could assign a unique Origin-Host name to each >>>>>> Diameter >>>>>> node on a host. And any or all nodes on Host A could establish a >>>>>> connection to any or all nodes on Host B. >>>>> >>>>> >>>>> Hi, >>>>> I think the port 3868 restriction helps when you're doing dynamic >>>>> peer >>>>> discovery. If an implementation sees an unknown diameter identity it >>>>> could try the various discovery options outlined in the RFC (e.g. DNS >>>>> lookups). These do not include a port anywhere IIRC and if there are >>>>> multiple stacks running on a single IP messages could end up on the >>>>> wrong stack. >>>>> >>>>> However, it's perfectly fine to use several IP addresses (using >>>>> ethernet >>>>> aliases) on a single box which map to different FQDNs. This >>>>> removes the >>>>> above limitation and is fine as far as the RFC goes. >>>>> >>>>> Best regards, >>>>> Andreas >>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> >> > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 02 17:14:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUV7L-00068T-Tg; Mon, 02 Oct 2006 17:14:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUV7J-00063Q-LJ for dime@ietf.org; Mon, 02 Oct 2006 17:14:25 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GUV7G-0002K6-Vu for dime@ietf.org; Mon, 02 Oct 2006 17:14:25 -0400 Received: (qmail invoked by alias); 02 Oct 2006 21:14:21 -0000 Received: from p549868EA.dip.t-dialin.net (EHLO [192.168.2.35]) [84.152.104.234] by mail.gmx.net (mp001) with SMTP; 02 Oct 2006 23:14:21 +0200 X-Authenticated: #29516787 Message-ID: <4521812D.4050404@gmx.net> Date: Mon, 02 Oct 2006 23:14:21 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Gerardo Giaretta Subject: Re: [Dime] Some thoughts about Diameter MIPv6 Application 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.1 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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, Gerardo Giaretta schrieb: > Hi all, > > I would like to share with you some considerations about the Diameter > Application for MIPv6. Some questions also follow. > > - first of all I think the proposal made by Yoshi to use rfc4072 in > AUTHENTICATION_ONLY mode and define another MIP6-specific application > for authorization is the right one. I think it is a good starting point for further discussions. Indeed, this would let separate > clearly the authentication procedure from the authorization step and I > think this is really needed in case IKEv2 is used. Suppose for example > a node acts as both VPN concentrator and HA (or 3GPP PDG and HA): it > supports IKEv2 signaling and acts as EAP pass-through authenticator in > order to setup the IPsec SA with the peer. If a MN starts an IKEv2 > exchange with this node, this node has no way to know if the MN is > going to use MIPv6 service or not (since the MN could be just setting > up the SA for remore access). Therefore, we need to take into account > that the HA is not sure that the MN is going to use MIPv6 service > untill it receives a BU. In my view, this is a valid reason to keep > authentication and authorization separated: the former is based on > rfc4072 and occurs during IKEv2 exchange, the latter is mip6-specific > and can be done later A problem appears only if the IKEv2 responder plays two roles and if the authorization decisions are different for the two. > > - based on what stated above, the first authorization request should > be sent by the HA upon the receipt of the first BU. However, this will > increase the latency of the first registration, since the AAA of the > MSA will be involved. Notice that in case the MN is moving from the > home link to a visited link, the first registration has low handoff > latency requirements. > An alternative approach to handle this scenario is that the HA sends > the Authorization Request in a proactive way, before receiving the BU. > However, based on what stated above, this is possible only if the HA > is sure the MN will use MIPv6 service (i.e. the IKEv2 responder acts > only as HA and not as a generic node providing remote access) > > - based on draft-ietf-mip6-aaa-ha-goals the AAA server may send an > Abort Session Request to the HA in order to stop the MIPv6 service for > a MN. This message may be very similar to the ASR in NASREQ. One > question is: from a MIPv6 perspective, is there any signaling the HA > will send to the MN to communicate that the session is over for a > specific reason? Or the MN is just blocked? > > - I guess, as in NASREQ, the AAA-MSA sends an authorization lifetime > to the HA and this lifetime will be renewed later. Is this > authorization lifetime related with the BU/BA lifetime? Are they equal > or orthogonal? The HA may set the binding lifetime in the BA equal to > the authorization lifetime. Is this approach useful? I think this is largely a policy decision. A short discussion in the document would be useful though. > > - again on the re-authorization: which are the information used to > request the re-authorization? Does a change of CoA trigger a > re-authentication? This will let the operator to authorize the MN > depending on the location. However this will increase the handoff > latency experienced by the MN. That's a good question and also showed up in QoS discussions in the past. It is again a policy decision. If it is purely a policy at the HA then there is no problem since it can trigger a re-authorization procedure with the HA whenever necessary. The problem appears only when the AAA server wants to trigger the HA to initiate re-authorization procedure in presence of certain events (e.g., change of CoA). In this case there is a need for an extension. Which one do we want here? > > - on the identities used by the MN: which identity is used by the HA > to identify the MN in the authorization phase? There is no identity in > the BU, unless we use the HoA as the identity. Otherwise the HA must > keep the identity used in IKEv2 by the MN. Any thought? Good question. What about using the session identifier? For accounting records one might also use the session identifier (in the Acct-Multi-Session-Id) to indicate that accounting records relate to the previous authentication/authorization protocol message exchange. Ciao Hannes > > --Gerardo > > _______________________________________________ > 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 Oct 02 21:10:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUYnn-0001jm-KH; Mon, 02 Oct 2006 21:10:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUYnn-0001jh-5v for dime@ietf.org; Mon, 02 Oct 2006 21:10:31 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUYnn-0002Ee-1v for dime@ietf.org; Mon, 02 Oct 2006 21:10:31 -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 1GUYnk-0006gX-Rv for dime@ietf.org; Mon, 02 Oct 2006 21:10:30 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k9314W1f033131; Mon, 2 Oct 2006 21:04:33 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Mon, 2 Oct 2006 21:04:34 -0400 To: Hannes Tschofenig Subject: Re: [Dime] My Summary of the MIPv6 Bootstrapping Discussion Message-ID: <20061003010433.GD16683@steelhead> References: <45123A23.7090405@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <45123A23.7090405@gmx.net> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 92 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 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, On Thu, Sep 21, 2006 at 03:07:15AM -0400, Hannes Tschofenig wrote: > Hi all, > > let me try to summarize what was discussed recently with regard to MIPv6 > bootstrapping. > > We agreed that it would be useful to differentiate the following two cases: > > (1) NAS<->AAA Server > > (2) HA<->AAA Server > > [We need to change the titles of our document a bit.] > > With regard to (1) a number of folks were in favor of introducing a > capability mechanism that allows the NAS to indicate that it supports a > certain functionality. As Avi said, this newly required AVP would be > optional to use and optional to understand. If a NAS does support > bootstrapping for MIPv6 it includes the attribute in AR (NASREQ or EAP). > If it lands at a server that understands this attribute, then it will > respond correctly if it wants to bootstrap MIPv6. If it lands at a > server that doesn't understand the attribute then bootstrapping via AAA > will not occur. I would like to do more deep analysis on this solution. It sounds like not only the capability AVP but also all other MIPv6-related AVPs need to be defined as optional to use and optional to understand in order to get around the permutations problem with NASREQ and EAP. If we consider general applicability of this solution to other applications such as QoS, an application may want to have some application-specific AVPs to be mandatory to use for the application to work while some other application-specific AVPs to be optional to use, but if we need to define all application-specific AVPs to be optional to use and optional to understand, such differentiation among application-specific AVPs would be no longer possible, which might lead to an interoperability issue as far as I can anticipate. It might be possible to expect each application to define more detailed AVP processing rule to overcome this issue, i.e., defining a detailed set of rules to deal with the case where AVPs that are define as *optional to use in ABNF but actually mandatory to use in the application* are missing, but we are not taking an advantage of ABNF to differentiate required AVPs from optional ones any more. Regards, Yoshihiro Ohba > > Defining a new AppID is not needed and consequently the Diameter > NASREQ/EAP message would hit the same server that also supports MIPv6 > bootstrapping. > > As an alternative, Yoshi suggested to go along the same approach as in > (2). The drawback would be the performance hit. This would, however, > allow the two servers to be different (if this is at all useful). > > With regard to (2) Yoshi suggested a new AppID to be used for > Authorization and Accounting and not to reuse the EAP/NASREQ ABNF. > As Julien wrote, we are able to continue to use Diameter EAP for > Authentication. Thus, the HA will use Diameter EAP with the AVP > Auth-Request-Type set to AUTHENTICATE_ONLY and then the HA will use this > MIP6 Application for Authorization/Accounting of the Mobile IPv6 service. > > This would avoid to update the application if RFC 4072 is updated and > this could be a way to proceed if other applications need EAP for > Authentication but have different needs for the Authorization and > Accounting part. > > Again, there is a performance disadvantage if a separate exchange is > used instead of piggybacking functionality. > > [I am still not sure how this nicely interworks with the QoS work we do > in the group. That's for further investigation.] > > I think we made progress in our discussions. Julien has initiated a poll > to see what todo regarding (2) and whether the group likes Yoshi's > suggestion. For (1) I got the impression that the focus currently is > more on the capability exchange but we might need to initiate another > poll there as well. > > Btw, the conclusions we make in this discussion can also be reused for > the Diameter QoS work. > > 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 Oct 03 06:35:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUhcN-0007Vb-Bp; Tue, 03 Oct 2006 06:35:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUhcM-0007VW-5m for dime@ietf.org; Tue, 03 Oct 2006 06:35:18 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUhcK-0006EV-MO for dime@ietf.org; Tue, 03 Oct 2006 06:35:18 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 9181C2FDA3; Tue, 3 Oct 2006 12:35:01 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GUheC-0005cW-Jl; Tue, 03 Oct 2006 12:37:12 +0200 Date: Tue, 3 Oct 2006 12:37:12 +0200 From: Julien Bournelle To: Gerardo Giaretta Subject: Re: [Dime] Some thoughts about Diameter MIPv6 Application Message-ID: <20061003103712.GA21578@ipv6-3.int-evry.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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, all, thanks for this considerations, On Mon, Oct 02, 2006 at 11:04:39AM +0200, Gerardo Giaretta wrote: > Hi all, > > I would like to share with you some considerations about the Diameter > Application for MIPv6. Some questions also follow. > > - first of all I think the proposal made by Yoshi to use rfc4072 in > AUTHENTICATION_ONLY mode and define another MIP6-specific application > for authorization is the right one. yes. > Indeed, this would let separate > clearly the authentication procedure from the authorization step and I > think this is really needed in case IKEv2 is used. Suppose for example > a node acts as both VPN concentrator and HA (or 3GPP PDG and HA): it > supports IKEv2 signaling and acts as EAP pass-through authenticator in > order to setup the IPsec SA with the peer. If a MN starts an IKEv2 > exchange with this node, this node has no way to know if the MN is > going to use MIPv6 service or not (since the MN could be just setting > up the SA for remore access). Therefore, we need to take into account > that the HA is not sure that the MN is going to use MIPv6 service > untill it receives a BU. In my view, this is a valid reason to keep > authentication and authorization separated: the former is based on > rfc4072 and occurs during IKEv2 exchange, the latter is mip6-specific > and can be done later > > - based on what stated above, the first authorization request should > be sent by the HA upon the receipt of the first BU. However, this will > increase the latency of the first registration, since the AAA of the > MSA will be involved. Notice that in case the MN is moving from the > home link to a visited link, the first registration has low handoff > latency requirements. This basically raises the following general question: when do the HA use the mip6-Authz application ? I think to solve this issue, we also have to take into considerations the Home Address Allocation. Let me start a new thread on this particular subject. > An alternative approach to handle this scenario is that the HA sends > the Authorization Request in a proactive way, before receiving the BU. > However, based on what stated above, this is possible only if the HA > is sure the MN will use MIPv6 service (i.e. the IKEv2 responder acts > only as HA and not as a generic node providing remote access) > > - based on draft-ietf-mip6-aaa-ha-goals the AAA server may send an > Abort Session Request to the HA in order to stop the MIPv6 service for > a MN. This message may be very similar to the ASR in NASREQ. One > question is: from a MIPv6 perspective, is there any signaling the HA > will send to the MN to communicate that the session is over for a > specific reason? Or the MN is just blocked? that's indeed a good question. Maybe we should also ask it to the mip6 WG. Personnally, I think the MN should be informed. > > - I guess, as in NASREQ, the AAA-MSA sends an authorization lifetime > to the HA and this lifetime will be renewed later. Is this > authorization lifetime related with the BU/BA lifetime? Are they equal > or orthogonal? The HA may set the binding lifetime in the BA equal to > the authorization lifetime. Is this approach useful? this raises another question. As we use 2 Diameter Application for this, which one provide the Authorization-Lifetime and for which purposes ? In fact, we may also consider the lifetime of the IPsec SAs. So we can consider: - IPsec SAs lifetime - Binding Lifetime (related to BU/BA) - Mobile IPv6 Session Lifetime others ? > > - again on the re-authorization: which are the information used to > request the re-authorization? Does a change of CoA trigger a > re-authentication? This will let the operator to authorize the MN > depending on the location. However this will increase the handoff > latency experienced by the MN. > > - on the identities used by the MN: which identity is used by the HA > to identify the MN in the authorization phase? There is no identity in > the BU, unless we use the HoA as the identity. Otherwise the HA must > keep the identity used in IKEv2 by the MN. Any thought? I thought that the HA should use the identity provided in the IKEv2 exchange. Sorry to bring more questions than responses... Julien > > --Gerardo > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 03 06:50:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUhr5-0003dB-OV; Tue, 03 Oct 2006 06:50:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUhr4-0003d6-Q8 for dime@ietf.org; Tue, 03 Oct 2006 06:50:30 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUhr3-0007bK-H1 for dime@ietf.org; Tue, 03 Oct 2006 06:50:30 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id E53B22FDFA for ; Tue, 3 Oct 2006 12:50:26 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GUht7-0005cv-VE for dime@ietf.org; Tue, 03 Oct 2006 12:52:37 +0200 Date: Tue, 3 Oct 2006 12:52:37 +0200 From: Julien Bournelle To: dime@ietf.org Message-ID: <20061003105237.GB21578@ipv6-3.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Dime] HA-to-AAAH support/When ? HoA allocation considerations 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, as promised, some considerations concerning triggering the mip6-authz process. As noted by gerardo, the IKEv2 responder may act both as a HA and as a VPN concentrator. In this case, it knows that it will be used as a HA while receiving a BU. So, we may think that the mip6-authz could be used at this point of time. However, we also have to consider the Home-Address (HoA) allocation. As you may know the MN may auto-assign its HoA or requests one. (cf. draft-ietf-mip6-bootstrapping-split-02.txt) If it wants to auto-assign its HoA, it has 2 possibilities: 1/ It autoassignes its HoA and includes it in the CFG_REQUEST (INTERNAL_IP6_ADDRESS)i in the first IKE_AUTH message. If the HA is ok, it replies with the CFG_REPLY with the same address. 2/ The MN asks for the Home Prefix (CFG_REQUEST with MIP6_HOME_PREFIX). The HA sends the Home prefix in the CFG_REPLY. Then the MN uses a CREATE_CHILD_SA. This raises some questions: 1/ Do we consider that it is the HA which decides if the MN is authorized to configure its HoA (policy configuration at the HA) ? or do we consider that it is a per-MN policy and thus that the HA should request that to the MSA ? If we consider that the MSA should decide this, as the HoA is sent after the MN being authenticated by EAP. This implies that the mip6-authz app should be used before this last IKEv2 message. If the MN requests a HoA to the HA, we also have the following question: 1/ do we allow the AAA server to allocate this address ? or do we need an AVP to carry the HoA from the AAA to the HA ? regards, Julien _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 03 07:25:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUiOa-0002Jn-7u; Tue, 03 Oct 2006 07:25:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUiOZ-0002Ji-Ch for dime@ietf.org; Tue, 03 Oct 2006 07:25:07 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUiOX-0003et-F1 for dime@ietf.org; Tue, 03 Oct 2006 07:25:07 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 13:24:59 +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] HA-to-AAAH support/When ? HoA allocation considerations Date: Tue, 3 Oct 2006 13:24:59 +0200 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E03014DF675@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] HA-to-AAAH support/When ? HoA allocation considerations Thread-Index: Acbm2c1HEtRCeZyISIG7+1R4teP7uQAAh8hw From: To: , X-OriginalArrivalTime: 03 Oct 2006 11:24:59.0913 (UTC) FILETIME=[8FF78790:01C6E6DE] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 Julien, Just a quick comment or few inline..=20 > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]=20 > Sent: 3. lokakuuta 2006 13:53 > To: dime@ietf.org > Subject: [Dime] HA-to-AAAH support/When ? HoA allocation=20 > considerations >=20 > Hi all, >=20 > as promised, some considerations concerning triggering the=20 > mip6-authz process. >=20 > As noted by gerardo, the IKEv2 responder may act both as a=20 > HA and as a VPN concentrator. In this case, it knows that it=20 > will be used as a HA while receiving a BU. So, we may think=20 > that the mip6-authz could be used at this point of time. >=20 > However, we also have to consider the Home-Address (HoA)=20 > allocation. As you may know the MN may auto-assign its HoA=20 > or requests one. (cf. > draft-ietf-mip6-bootstrapping-split-02.txt) >=20 > If it wants to auto-assign its HoA, it has 2 possibilities: >=20 > 1/ It autoassignes its HoA and includes it in the CFG_REQUEST > (INTERNAL_IP6_ADDRESS)i in the first IKE_AUTH message.=20 > If the HA is ok, it replies with the CFG_REPLY > with the same address. >=20 > 2/ The MN asks for the Home Prefix (CFG_REQUEST with > MIP6_HOME_PREFIX). The HA sends the Home prefix in the CFG_REPLY. > Then > the MN uses a CREATE_CHILD_SA. >=20 > This raises some questions: >=20 > 1/ Do we consider that it is the HA which decides if the MN=20 > is authorized to configure its HoA (policy configuration at=20 > the HA) ? or do we consider that it is a per-MN policy and=20 > thus that the HA should request that to the MSA ? Imho both.. depends on operator's deployment. > If we consider that the MSA should decide this, as the HoA=20 > is sent after the MN being authenticated by EAP. This=20 > implies that the mip6-authz app should be used before this=20 > last IKEv2 message. >=20 > If the MN requests a HoA to the HA, we also have the following > question: >=20 > 1/ do we allow the AAA server to allocate this address ? or=20 > do we need an AVP to carry the HoA from the AAA to the HA ? I'm not entirely sure what the above is supposed to mean.. but imho again depending on the operator's deployment either HA or AAA should be able to allocate the HoA. Cheers, Jouni > =20 > regards, >=20 > Julien > =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 Oct 03 07:49:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUimE-0001x3-GY; Tue, 03 Oct 2006 07:49:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUimD-0001wv-Ew for dime@ietf.org; Tue, 03 Oct 2006 07:49:33 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUimC-0006cV-UB for dime@ietf.org; Tue, 03 Oct 2006 07:49:33 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 13:49:27 +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] My Summary of the MIPv6 Bootstrapping Discussion Date: Tue, 3 Oct 2006 13:49:26 +0200 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E03014DF676@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] My Summary of the MIPv6 Bootstrapping Discussion Thread-Index: AcbmiOrQyjNFRoNXRq6QKThtpTmNZwAVfBzw From: To: , X-OriginalArrivalTime: 03 Oct 2006 11:49:27.0167 (UTC) FILETIME=[FA84B8F0:01C6E6E1] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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 Yoshihiro,=20 > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20 > Sent: 3. lokakuuta 2006 4:05 > To: Hannes Tschofenig > Cc: dime@ietf.org > Subject: Re: [Dime] My Summary of the MIPv6 Bootstrapping Discussion >=20 > Hi Hannes, >=20 > On Thu, Sep 21, 2006 at 03:07:15AM -0400, Hannes Tschofenig wrote: > > Hi all, > >=20 > > let me try to summarize what was discussed recently with regard to=20 > > MIPv6 bootstrapping. > >=20 > > We agreed that it would be useful to differentiate the=20 > following two cases: > >=20 > > (1) NAS<->AAA Server > >=20 > > (2) HA<->AAA Server > >=20 > > [We need to change the titles of our document a bit.] > >=20 > > With regard to (1) a number of folks were in favor of introducing a=20 > > capability mechanism that allows the NAS to indicate that=20 > it supports=20 > > a certain functionality. As Avi said, this newly required=20 > AVP would be=20 > > optional to use and optional to understand. If a NAS does support=20 > > bootstrapping for MIPv6 it includes the attribute in AR=20 > (NASREQ or EAP). > > If it lands at a server that understands this attribute,=20 > then it will=20 > > respond correctly if it wants to bootstrap MIPv6. If it lands at a=20 > > server that doesn't understand the attribute then bootstrapping via=20 > > AAA will not occur. >=20 > I would like to do more deep analysis on this solution. It=20 > sounds like not only the capability AVP but also all other=20 > MIPv6-related AVPs need to be defined as optional to use and=20 > optional to understand in order to get around the=20 I thought this was the case already. All AVPs for the NAS-AAAH are supposed to optinal. > permutations problem with NASREQ and EAP. If we consider=20 > general applicability of this solution to other applications=20 > such as QoS, an application may want to have some=20 > application-specific AVPs to be mandatory to use for the=20 > application to work while some other application-specific=20 > AVPs to be optional to use, but if we need to define all=20 > application-specific AVPs to be optional to use and optional=20 > to understand, such differentiation among=20 > application-specific AVPs would be no longer possible, which=20 > might lead to an interoperability issue as far as I can=20 Well that's true but I'm not sure if it is an issue with NAS-AAAH as that is more like an optimization done during the access auth. The MN has always a way (hopefully ;) to fallback to other bootstrapping method if the integrated scenario fails. > anticipate. It might be possible to expect each application=20 > to define more detailed AVP processing rule to overcome this=20 > issue, i.e., defining a detailed set of rules to deal with=20 That's what other SDOs tend to do for their own deploymeent scenarios. > the case where AVPs that are define as *optional to use in=20 > ABNF but actually mandatory to use in the > application* are missing, but we are not taking an advantage=20 > of ABNF to differentiate required AVPs from optional ones any more. > > Regards, > Yoshihiro Ohba Cheers, Jouni >=20 > >=20 > > Defining a new AppID is not needed and consequently the Diameter=20 > > NASREQ/EAP message would hit the same server that also=20 > supports MIPv6=20 > > bootstrapping. > >=20 > > As an alternative, Yoshi suggested to go along the same=20 > approach as in=20 > > (2). The drawback would be the performance hit. This would,=20 > however,=20 > > allow the two servers to be different (if this is at all useful). > >=20 > > With regard to (2) Yoshi suggested a new AppID to be used for=20 > > Authorization and Accounting and not to reuse the EAP/NASREQ ABNF. > > As Julien wrote, we are able to continue to use Diameter EAP for=20 > > Authentication. Thus, the HA will use Diameter EAP with the AVP=20 > > Auth-Request-Type set to AUTHENTICATE_ONLY and then the HA will use=20 > > this > > MIP6 Application for Authorization/Accounting of the Mobile=20 > IPv6 service. > >=20 > > This would avoid to update the application if RFC 4072 is=20 > updated and=20 > > this could be a way to proceed if other applications need EAP for=20 > > Authentication but have different needs for the Authorization and=20 > > Accounting part. > >=20 > > Again, there is a performance disadvantage if a separate=20 > exchange is=20 > > used instead of piggybacking functionality. > >=20 > > [I am still not sure how this nicely interworks with the=20 > QoS work we=20 > > do in the group. That's for further investigation.] > >=20 > > I think we made progress in our discussions. Julien has initiated a=20 > > poll to see what todo regarding (2) and whether the group likes=20 > > Yoshi's suggestion. For (1) I got the impression that the focus=20 > > currently is more on the capability exchange but we might need to=20 > > initiate another poll there as well. > >=20 > > Btw, the conclusions we make in this discussion can also be=20 > reused for=20 > > the Diameter QoS work. > >=20 > > Ciao > > Hannes > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 03 11:12:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUlwz-0007Ml-7L; Tue, 03 Oct 2006 11:12:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUlwx-0007IJ-Sd for dime@ietf.org; Tue, 03 Oct 2006 11:12:51 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUlww-0004jC-I6 for dime@ietf.org; Tue, 03 Oct 2006 11:12:51 -0400 Received: by ug-out-1314.google.com with SMTP id 72so573776ugd for ; Tue, 03 Oct 2006 08:12:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qncjCMYIiBMfbznUXBtkOJJFIcGew8Oxxubv10K7LVIZaNVdlNeT6gt3CZUDY9wk+GYo/kwEIwc3d/6FsgjUx1kHuwhD2boMRiUt+8sVtDPt5pINryoi2H2wFCD6L6S8kh5hzJRIL663LibIVEtwDYEuy5NTnxLLnKWxZwTWOHM= Received: by 10.67.97.7 with SMTP id z7mr3871977ugl; Tue, 03 Oct 2006 08:12:49 -0700 (PDT) Received: by 10.66.237.2 with HTTP; Tue, 3 Oct 2006 08:12:49 -0700 (PDT) Message-ID: Date: Tue, 3 Oct 2006 17:12:49 +0200 From: "Gerardo Giaretta" To: dime@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 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, please review the document. --Gerardo ---------- Forwarded message ---------- From: Basavaraj Patil Date: Oct 3, 2006 4:49 PM Subject: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 To: mip6@ietf.org Hello, This is a Working group last call for the WG I-D: AAA Goals for Mobile IPv6 (draft-ietf-mip6-aaa-ha-goals-03). The draft is intended to serve as the AAA requirements for Mobile IPv6. Please review the I-D and submit your comments to the authors or to the list directly. The WGLC expires on Oct 18th, 06. The I-D is intended to be published as an Informational RFC. -Raj _______________________________________________ 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 Oct 03 18:37:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUssr-0006Nx-Ql; Tue, 03 Oct 2006 18:37:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUssq-0006Jv-I0 for dime@ietf.org; Tue, 03 Oct 2006 18:37:04 -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 1GUssq-0007U7-1M for dime@ietf.org; Tue, 03 Oct 2006 18:37:04 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k93Mala8000227; Tue, 3 Oct 2006 18:36:48 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Tue, 3 Oct 2006 18:36:46 -0400 To: jouni.korhonen@teliasonera.com Subject: Re: [Dime] My Summary of the MIPv6 Bootstrapping Discussion Message-ID: <20061003223553.GH9097@steelhead> References: <5D25AEFB114D034FBDC8B156FCA78E03014DF676@SEHAN021MB.tcad.telia.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <5D25AEFB114D034FBDC8B156FCA78E03014DF676@SEHAN021MB.tcad.telia.se> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 157 X-Spam-Score: -2.4 (--) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 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, On Tue, Oct 03, 2006 at 01:49:26PM +0200, jouni.korhonen@teliasonera.com wrote: > Hi Yoshihiro, > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: 3. lokakuuta 2006 4:05 > > To: Hannes Tschofenig > > Cc: dime@ietf.org > > Subject: Re: [Dime] My Summary of the MIPv6 Bootstrapping Discussion > > > > Hi Hannes, > > > > On Thu, Sep 21, 2006 at 03:07:15AM -0400, Hannes Tschofenig wrote: > > > Hi all, > > > > > > let me try to summarize what was discussed recently with regard to > > > MIPv6 bootstrapping. > > > > > > We agreed that it would be useful to differentiate the > > following two cases: > > > > > > (1) NAS<->AAA Server > > > > > > (2) HA<->AAA Server > > > > > > [We need to change the titles of our document a bit.] > > > > > > With regard to (1) a number of folks were in favor of introducing a > > > capability mechanism that allows the NAS to indicate that > > it supports > > > a certain functionality. As Avi said, this newly required > > AVP would be > > > optional to use and optional to understand. If a NAS does support > > > bootstrapping for MIPv6 it includes the attribute in AR > > (NASREQ or EAP). > > > If it lands at a server that understands this attribute, > > then it will > > > respond correctly if it wants to bootstrap MIPv6. If it lands at a > > > server that doesn't understand the attribute then bootstrapping via > > > AAA will not occur. > > > > I would like to do more deep analysis on this solution. It > > sounds like not only the capability AVP but also all other > > MIPv6-related AVPs need to be defined as optional to use and > > optional to understand in order to get around the > > I thought this was the case already. All AVPs for the NAS-AAAH are > supposed > to optinal. Most AVPs defined in NASREQ and EAP are defined as optional to use but mandatory to understand (i.e., 'M' bit is set). The above solution is different (worse) in that the AVPs are not only optional to use but also optional to understand. Yoshihiro Ohba > > > permutations problem with NASREQ and EAP. If we consider > > general applicability of this solution to other applications > > such as QoS, an application may want to have some > > application-specific AVPs to be mandatory to use for the > > application to work while some other application-specific > > AVPs to be optional to use, but if we need to define all > > application-specific AVPs to be optional to use and optional > > to understand, such differentiation among > > application-specific AVPs would be no longer possible, which > > might lead to an interoperability issue as far as I can > > Well that's true but I'm not sure if it is an issue with NAS-AAAH as > that is more like an optimization done during the access auth. The MN > has always a way (hopefully ;) to fallback to other bootstrapping method > if the integrated scenario fails. > > > anticipate. It might be possible to expect each application > > to define more detailed AVP processing rule to overcome this > > issue, i.e., defining a detailed set of rules to deal with > > That's what other SDOs tend to do for their own deploymeent scenarios. > > > the case where AVPs that are define as *optional to use in > > ABNF but actually mandatory to use in the > > application* are missing, but we are not taking an advantage > > of ABNF to differentiate required AVPs from optional ones any more. > > > > Regards, > > Yoshihiro Ohba > > Cheers, > Jouni > > > > > > > > > > Defining a new AppID is not needed and consequently the Diameter > > > NASREQ/EAP message would hit the same server that also > > supports MIPv6 > > > bootstrapping. > > > > > > As an alternative, Yoshi suggested to go along the same > > approach as in > > > (2). The drawback would be the performance hit. This would, > > however, > > > allow the two servers to be different (if this is at all useful). > > > > > > With regard to (2) Yoshi suggested a new AppID to be used for > > > Authorization and Accounting and not to reuse the EAP/NASREQ ABNF. > > > As Julien wrote, we are able to continue to use Diameter EAP for > > > Authentication. Thus, the HA will use Diameter EAP with the AVP > > > Auth-Request-Type set to AUTHENTICATE_ONLY and then the HA will use > > > this > > > MIP6 Application for Authorization/Accounting of the Mobile > > IPv6 service. > > > > > > This would avoid to update the application if RFC 4072 is > > updated and > > > this could be a way to proceed if other applications need EAP for > > > Authentication but have different needs for the Authorization and > > > Accounting part. > > > > > > Again, there is a performance disadvantage if a separate > > exchange is > > > used instead of piggybacking functionality. > > > > > > [I am still not sure how this nicely interworks with the > > QoS work we > > > do in the group. That's for further investigation.] > > > > > > I think we made progress in our discussions. Julien has initiated a > > > poll to see what todo regarding (2) and whether the group likes > > > Yoshi's suggestion. For (1) I got the impression that the focus > > > currently is more on the capability exchange but we might need to > > > initiate another poll there as well. > > > > > > Btw, the conclusions we make in this discussion can also be > > reused for > > > the Diameter QoS work. > > > > > > 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 Oct 03 19:41:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUttT-0007kW-2W; Tue, 03 Oct 2006 19:41:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUttR-0007kQ-S0 for dime@ietf.org; Tue, 03 Oct 2006 19:41:45 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUttP-0003py-Cy for dime@ietf.org; Tue, 03 Oct 2006 19:41:45 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6L00CNR30DC7@usaga01-in.huawei.com> for dime@ietf.org; Tue, 03 Oct 2006 16:38:37 -0700 (PDT) Received: from huawei6cc10c70 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J6L00DWZ309R1@usaga01-in.huawei.com> for dime@ietf.org; Tue, 03 Oct 2006 16:38:37 -0700 (PDT) Date: Tue, 03 Oct 2006 16:41:37 -0700 From: Madjid Nakhjiri Subject: RE: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) In-reply-to: <20060915102114.GA6527@ipv6-3.int-evry.fr> To: 'Julien Bournelle' , dime@ietf.org Message-id: <003b01c6e745$78525860$2f01a8c0@huawei6cc10c70> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbYsPVsF8W5Nk2QSWSGWbgq91kDTwOj4qdQ X-Spam-Score: 0.8 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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 Julien, Sorry for responding late. I was making a point to go through all email up to this point. I definitely do not support option 1, since it does not make sense to make MIP6 application depend on EAP application, first due to the spaghetti application design process it creates, and second due to the fact that we don't want to bind people to use EAP for MIP6 authentication. Now to option 2, it is great that you are considering authorization and authorization credentials as a separate matter than authentication. The industry for years has failed to make that distinction. However, the current option 2 is not strong from security and AAA design. Yes, a Mobility service provider and its AAA server should look at the MN and its service profile to see if it is authorized to use MIP6 service and how it is supposed to pay for it. But we need to figure out what "authorization credentials" to be used for this authorization. Now this includes 1) something that securely identifies the MN (this includes proof of authentication) 2) something that proves MN's right to MIP6 service, i.e. an authorization token or indication to a profile that the AAA server of MSP has of MN that shows MN should have MIP6 service. If you are separating authorization spec from authentication spec, then both of these need to be included in the authorization spec. The MN identity used MIP6 may or may not be the same as that used in a previous EAP, especially in split scenario, so it seems that in split scenario you run two EAPs, one with MN ASP ID and one with MN MSP ID. When you produce a separate authorization spec ("Diameter MIP6 spec" separate from "Diameter EAP spec"), you need make sure that 1) MN uses the same ID during EAP and during MIP6? 2) even if it does, the MN's ID the MN is using is authenticated? There must be a proof of a previous authentication. Just saying MN has run EAP before it is not enough. When you are separating Diameter MIP spec and Diameter EAP spec and taking authentication out, then the MIP spec needs to specify how the MN provides proof that it has run a previous EAP (or another authentication method) by probably signing its MIP6 authorization request with a key that was generated during a previous EAP or authentication. Otherwise, there is no way to know that the MN has actually been authenticated, meaning it is very difficult to separate authorization from authorization. Having said that I am hesitant to state that support option 2 as well. And yes, Update of 4072 should not affect update of MIP6 application. Diameter MIP6 application needs to stand on its own and if it is going to only define authorization and accounting and rely on a previous authentication, then it must be independent of whether the authentication is EAP or something else. We are not here to just solve a specific optimization problem... My two rusty (late) pennies, Regards, Madjid -----Original Message----- From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] Sent: Friday, September 15, 2006 3:21 AM To: dime@ietf.org Subject: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) Hi all, this is a new polling concerning the ha-aaah interface for the Mobile IPv6 Boostrapping. To date, at the previous one, there was a consensus on moving forward with a new App-ID. But, yoshi has proposed an interesting idea that should be considered by the WG. As you may recall, in the ha-aaah case, the MN is authenticated by EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH interface must, at least, be able to carry EAP packets. It appears that we now have 2 options: (1) We define a new Diameter application for Mobile IPv6 with a new App-ID that carry EAP packets as it is done in RFC 4072 (Diameter EAP) but Authorization and Accouting is specific to Mobile IPv6 (thus the need for a new App-ID). The risk, as noted by yoshi, is that an update of the RFC4072 may result in an update of this application. (2) We define a new Diameter Application for Mobile IPv6 but which is used for Authorization and Accounting. We continue to use Diameter EAP for the Authentication. Thus the HA will use Diameter EAP with the AVP Auth-Request-Type set to AUTHENTICATE_ONLY and then the HA will use this MIP6 Application for Authorization/Accounting of the Mobile IPv6 service. This new application will have its own App-ID. This would avoid to update the application if 4072 is updated and this could be a way to proceed if other applications need EAP for Authentication but have different needs for the Authorization and Accounting part. Please indicate wether you prefer (1) or (2). As in the previous polling: - it might be useful to state a reason for your decision. - indicate wether some aspects are still unclear to you. Regards, Julien _______________________________________________ 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 Oct 04 05:39:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV3Dr-0004Ca-U7; Wed, 04 Oct 2006 05:39:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV3Dq-00049U-9o for dime@ietf.org; Wed, 04 Oct 2006 05:39:26 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV3Do-0004Ln-OA for dime@ietf.org; Wed, 04 Oct 2006 05:39:26 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 7545D2FD35; Wed, 4 Oct 2006 11:39:18 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GV3Fo-00064q-8J; Wed, 04 Oct 2006 11:41:28 +0200 Date: Wed, 4 Oct 2006 11:41:28 +0200 From: Julien Bournelle To: Madjid Nakhjiri Subject: Re: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) Message-ID: <20061004094128.GA23345@ipv6-3.int-evry.fr> References: <20060915102114.GA6527@ipv6-3.int-evry.fr> <003b01c6e745$78525860$2f01a8c0@huawei6cc10c70> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003b01c6e745$78525860$2f01a8c0@huawei6cc10c70> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.8 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 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 madjid, On Tue, Oct 03, 2006 at 04:41:37PM -0700, Madjid Nakhjiri wrote: > Hi Julien, > > Sorry for responding late. I was making a point to go through all email up > to this point. > > I definitely do not support option 1, since it does not make sense to make > MIP6 application depend on EAP application, first due to the spaghetti > application design process it creates, and second due to the fact that we > don't want to bind people to use EAP for MIP6 authentication. > > Now to option 2, it is great that you are considering authorization and > authorization credentials as a separate matter than authentication. The > industry for years has failed to make that distinction. However, the current > option 2 is not strong from security and AAA design. > > Yes, a Mobility service provider and its AAA server should look at the MN > and its service profile to see if it is authorized to use MIP6 service and > how it is supposed to pay for it. But we need to figure out what > "authorization credentials" to be used for this authorization. Now this > includes > 1) something that securely identifies the MN (this includes proof of > authentication) > 2) something that proves MN's right to MIP6 service, i.e. an authorization > token or indication to a profile that the AAA server of MSP has of MN that > shows MN should have MIP6 service. > > If you are separating authorization spec from authentication spec, then both > of these need to be included in the authorization spec. that's indeed a good question. At this point of time, I thought that in the mip6-authz messages, we didn't need sort of "authz token". I thought that the authentication process was implicit for the AAA-MIP6 Authz server and that finally it was the HA which basically need to be sure that the MN is authenticated. so my question: can't the AAA-MIP6 authz server assume that the MN has been authenticated while receiving an authz request ? > The MN identity used MIP6 may or may not be the same as that used in a > previous EAP, especially in split scenario, so it seems that in split > scenario you run two EAPs, one with MN ASP ID and one with MN MSP ID. When > you produce a separate authorization spec ("Diameter MIP6 spec" separate > from "Diameter EAP spec"), you need make sure that > > 1) MN uses the same ID during EAP and during MIP6? Concerning Identity used in the MIP6 Authz process, we have two options: 1/ The HA uses the Identity provided in the IDi field during the IKE_AUTH phase. In this case, the identity will be the same than the one provided with the Diameter EAP Application. 2/ The HA uses something provided in the BU. In this case, it implies that the mip6-authz application is used after the whole EAP authentication process. This may not be possible if we want to do authorization of HoA allocation (cf. my thread on this subject). > 2) even if it does, the MN's ID the MN is using is authenticated? There must > be a proof of a previous authentication. Just saying MN has run EAP before > it is not enough. When you are separating Diameter MIP spec and Diameter EAP > spec and taking authentication out, then the MIP spec needs to specify how > the MN provides proof that it has run a previous EAP (or another > authentication method) by probably signing its MIP6 authorization request > with a key that was generated during a previous EAP or authentication. > Otherwise, there is no way to know that the MN has actually been > authenticated, meaning it is very difficult to separate authorization from > authorization. well, as noted below, I tend to think that the Authz server doesn't need a proof that the MN has been authenticated. The Authz server could trust the HA for this. Julien > Having said that I am hesitant to state that support option 2 as well. > And yes, Update of 4072 should not affect update of MIP6 application. > > Diameter MIP6 application needs to stand on its own and if it is going to > only define authorization and accounting and rely on a previous > authentication, then it must be independent of whether the authentication is > EAP or something else. We are not here to just solve a specific optimization > problem... > > My two rusty (late) pennies, > > Regards, > > Madjid > > > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > Sent: Friday, September 15, 2006 3:21 AM > To: dime@ietf.org > Subject: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) > > Hi all, > > this is a new polling concerning the ha-aaah interface for the Mobile > IPv6 Boostrapping. To date, at the previous one, there was a > consensus on moving forward with a new App-ID. But, yoshi has > proposed an interesting idea that should be considered by the WG. > > As you may recall, in the ha-aaah case, the MN is authenticated by > EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH > interface must, at least, be able to carry EAP packets. It appears that > we now have 2 options: > > (1) We define a new Diameter application for Mobile IPv6 with a new > App-ID that carry EAP packets as it is done in RFC 4072 (Diameter > EAP) but Authorization and Accouting is specific to Mobile IPv6 > (thus the need for a new App-ID). The risk, as noted by yoshi, is > that an update of the RFC4072 may result in an update of this > application. > > > (2) We define a new Diameter Application for Mobile IPv6 but which is > used for Authorization and Accounting. We continue to use > Diameter EAP for the Authentication. Thus the HA will use > Diameter EAP with the AVP Auth-Request-Type set to > AUTHENTICATE_ONLY and then the HA will use this MIP6 Application > for Authorization/Accounting of the Mobile IPv6 service. This new > application will have its own App-ID. > > This would avoid to update the application if 4072 is updated and > this could be a way to proceed if other applications need EAP for > Authentication but have different needs for the Authorization and > Accounting part. > > Please indicate wether you prefer (1) or (2). > > As in the previous polling: > - it might be useful to state a reason for your decision. > - indicate wether some aspects are still unclear to you. > > Regards, > > Julien > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 04 07:31:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV4yc-0006EO-KK; Wed, 04 Oct 2006 07:31:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV4yb-0006EE-4r for dime@ietf.org; Wed, 04 Oct 2006 07:31:49 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV4yZ-0005vl-NV for dime@ietf.org; Wed, 04 Oct 2006 07:31:49 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id EEAD32FD35; Wed, 4 Oct 2006 13:31:38 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GV50W-0006Du-Ls; Wed, 04 Oct 2006 13:33:48 +0200 Date: Wed, 4 Oct 2006 13:33:48 +0200 From: Julien Bournelle To: jouni.korhonen@teliasonera.com, dime@ietf.org Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation considerations Message-ID: <20061004113348.GA23909@ipv6-3.int-evry.fr> References: <5D25AEFB114D034FBDC8B156FCA78E03014DF675@SEHAN021MB.tcad.telia.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D25AEFB114D034FBDC8B156FCA78E03014DF675@SEHAN021MB.tcad.telia.se> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi jouni, On Tue, Oct 03, 2006 at 01:24:59PM +0200, jouni.korhonen@teliasonera.com wrote: > > However, we also have to consider the Home-Address (HoA) > > allocation. As you may know the MN may auto-assign its HoA > > or requests one. (cf. > > draft-ietf-mip6-bootstrapping-split-02.txt) > > > > If it wants to auto-assign its HoA, it has 2 possibilities: > > > > 1/ It autoassignes its HoA and includes it in the CFG_REQUEST > > (INTERNAL_IP6_ADDRESS)i in the first IKE_AUTH message. > > If the HA is ok, it replies with the CFG_REPLY > > with the same address. > > > > 2/ The MN asks for the Home Prefix (CFG_REQUEST with > > MIP6_HOME_PREFIX). The HA sends the Home prefix in the CFG_REPLY. > > Then > > the MN uses a CREATE_CHILD_SA. > > > > This raises some questions: > > > > 1/ Do we consider that it is the HA which decides if the MN > > is authorized to configure its HoA (policy configuration at > > the HA) ? or do we consider that it is a per-MN policy and > > thus that the HA should request that to the MSA ? > > Imho both.. depends on operator's deployment. if we want both. This implies that the mip6-authz process occurs during the EAP authentication process (probably when the HA receives the result of the EAP authentication from the AAAH). I'm also in favor of that but then we have the issue raised by gerardo concerning the fact that the IKEv2 responder may play 2 roles (VPN concentrator and HA). How do the IKEv2-R know that the MN wants to use mip6 ? > > > If we consider that the MSA should decide this, as the HoA > > is sent after the MN being authenticated by EAP. This > > implies that the mip6-authz app should be used before this > > last IKEv2 message. > > > > If the MN requests a HoA to the HA, we also have the following > > question: > > > > 1/ do we allow the AAA server to allocate this address ? or > > do we need an AVP to carry the HoA from the AAA to the HA ? > > I'm not entirely sure what the above is supposed to mean.. but > imho again depending on the operator's deployment either HA or > AAA should be able to allocate the HoA. I also agree with you. It also implies that the mip6-Authz App should be used during EAP authentication process. Julien > > Cheers, > Jouni > > > > > > regards, > > > > Julien > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 04 08:23:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV5mD-00012h-J8; Wed, 04 Oct 2006 08:23:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV5mB-00011C-Tc for dime@ietf.org; Wed, 04 Oct 2006 08:23:04 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV5mA-0003v9-I3 for dime@ietf.org; Wed, 04 Oct 2006 08:23:03 -0400 Received: by ug-out-1314.google.com with SMTP id 72so41589ugd for ; Wed, 04 Oct 2006 05:23:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pm7soMXqz7AqEg0mOczeJXCpVbagDWsvjBK/55AH82cO8E6TsqMvTQ0g5Ih8oatRNyvxEwjWklTNy3k9ukinmf1G6zbIuVUL+DjP1P9/oosD8Bvt9LSpmFP9RqbakJI/j0y+HQn+G4ZpwM0OfRSFwsGMnbo5dH0Xllom8owzFYE= Received: by 10.67.21.11 with SMTP id y11mr495300ugi; Wed, 04 Oct 2006 05:23:01 -0700 (PDT) Received: by 10.66.237.2 with HTTP; Wed, 4 Oct 2006 05:23:01 -0700 (PDT) Message-ID: Date: Wed, 4 Oct 2006 14:23:01 +0200 From: "Gerardo Giaretta" To: "Julien Bournelle" Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation considerations In-Reply-To: <20061004113348.GA23909@ipv6-3.int-evry.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5D25AEFB114D034FBDC8B156FCA78E03014DF675@SEHAN021MB.tcad.telia.se> <20061004113348.GA23909@ipv6-3.int-evry.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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 Julien and Jouni, > > > However, we also have to consider the Home-Address (HoA) > > > allocation. As you may know the MN may auto-assign its HoA > > > or requests one. (cf. > > > draft-ietf-mip6-bootstrapping-split-02.txt) > > > > > > If it wants to auto-assign its HoA, it has 2 possibilities: > > > > > > 1/ It autoassignes its HoA and includes it in the CFG_REQUEST > > > (INTERNAL_IP6_ADDRESS)i in the first IKE_AUTH message. > > > If the HA is ok, it replies with the CFG_REPLY > > > with the same address. > > > > > > 2/ The MN asks for the Home Prefix (CFG_REQUEST with > > > MIP6_HOME_PREFIX). The HA sends the Home prefix in the CFG_REPLY. > > > Then > > > the MN uses a CREATE_CHILD_SA. > > > > > > This raises some questions: > > > > > > 1/ Do we consider that it is the HA which decides if the MN > > > is authorized to configure its HoA (policy configuration at > > > the HA) ? or do we consider that it is a per-MN policy and > > > thus that the HA should request that to the MSA ? > > > > Imho both.. depends on operator's deployment. > > if we want both. This implies that the mip6-authz process occurs during > the EAP authentication process (probably when the HA receives the > result of the EAP authentication from the AAAH). > This is needed only for autoconfiguration. But autoconfiguration has been introduced in mip6-split for rfc3041 addresses and CGAs. Do we want the AAA to decide if theMN can use CGA? I'm not sure this is the case. I think what is important from an operator perspective is that the address may be allocated by either AAA or HA. However, to get this, we do not need to start mip6-authz during EAP exchange, since it is a generic IKEv2 address assignment issue and not a MIP specific one. --Gerardo > I'm also in favor of that but then we have the issue raised by gerardo > concerning the fact that the IKEv2 responder may play 2 roles (VPN > concentrator and HA). How do the IKEv2-R know that the MN wants to use > mip6 ? > > > > > > If we consider that the MSA should decide this, as the HoA > > > is sent after the MN being authenticated by EAP. This > > > implies that the mip6-authz app should be used before this > > > last IKEv2 message. > > > > > > If the MN requests a HoA to the HA, we also have the following > > > question: > > > > > > 1/ do we allow the AAA server to allocate this address ? or > > > do we need an AVP to carry the HoA from the AAA to the HA ? > > > > I'm not entirely sure what the above is supposed to mean.. but > > imho again depending on the operator's deployment either HA or > > AAA should be able to allocate the HoA. > > I also agree with you. It also implies that the mip6-Authz App should > be used during EAP authentication process. > > Julien > > > > > Cheers, > > Jouni > > > > > > > > > > regards, > > > > > > Julien > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > -- > julien.bournelle at int-evry.fr > > _______________________________________________ > 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 Oct 04 10:11:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7Su-0001JY-N6; Wed, 04 Oct 2006 10:11:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7St-0001Hg-Eb for dime@ietf.org; Wed, 04 Oct 2006 10:11:15 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV7Sr-0005Ob-HU for dime@ietf.org; Wed, 04 Oct 2006 10:11:15 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id D195990007 for ; Wed, 4 Oct 2006 10:11:08 -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 18517-03 for ; Wed, 4 Oct 2006 10:11:08 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 4 Oct 2006 10:10:43 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 10:10:43 -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] HA-to-AAAH support/When ? HoA allocation considerations Date: Wed, 4 Oct 2006 10:10:43 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D783748C@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] HA-to-AAAH support/When ? HoA allocation considerations Thread-Index: Acbm2czD/5Ip61lrTc24ks9gJ5qitAA5GT2Q From: "Chowdhury, Kuntal" To: "Julien Bournelle" , X-OriginalArrivalTime: 04 Oct 2006 14:10:43.0721 (UTC) FILETIME=[E159F790:01C6E7BE] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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 Julien Good questions. Please see my comments inline. -Kuntal > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > Sent: Tuesday, October 03, 2006 5:53 AM > To: dime@ietf.org > Subject: [Dime] HA-to-AAAH support/When ? HoA allocation considerations >=20 > Hi all, >=20 > as promised, some considerations concerning triggering the mip6-authz > process. >=20 > As noted by gerardo, the IKEv2 responder may act both as a HA and as a > VPN concentrator. In this case, it knows that it will be used as a HA > while receiving a BU. So, we may think that the mip6-authz could be > used at this point of time. >=20 > However, we also have to consider the Home-Address (HoA) allocation. As > you > may know the MN may auto-assign its HoA or requests one. (cf. > draft-ietf-mip6-bootstrapping-split-02.txt) >=20 > If it wants to auto-assign its HoA, it has 2 possibilities: >=20 > 1/ It autoassignes its HoA and includes it in the CFG_REQUEST > (INTERNAL_IP6_ADDRESS)i in the first IKE_AUTH message. > If the HA is ok, it replies with the CFG_REPLY > with the same address. >=20 > 2/ The MN asks for the Home Prefix (CFG_REQUEST with > MIP6_HOME_PREFIX). The HA sends the Home prefix in the CFG_REPLY. > Then > the MN uses a CREATE_CHILD_SA. >=20 > This raises some questions: >=20 > 1/ Do we consider that it is the HA which decides if the MN is > authorized to configure its HoA (policy configuration at the HA) ? or do > we > consider that it is a per-MN policy and thus that the HA should request > that to the MSA ? >=20 [KC>] We should allow the flexibility to either have this policy provisioned at the HA or the HA requesting it from the MSA. So, we should define the HA-MSA interaction for HoA auto-config policy and even HoA pool/prefix information. =20 > If we consider that the MSA should decide this, as the HoA is sent > after the MN being authenticated by EAP. This implies that the > mip6-authz app should be used before this last IKEv2 message. >=20 [KC>] Yes. > If the MN requests a HoA to the HA, we also have the following > question: >=20 > 1/ do we allow the AAA server to allocate this address ? or do we need > an AVP to carry the HoA from the AAA to the HA ? >=20 [KC>] We need AVPs to convey two things: whether the MN is allowed to auto-config its HoA, if yes, which prefix/pool-id the HA should use to assign the HoA to the MN. > regards, >=20 > Julien >=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 Wed Oct 04 10:23:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7es-0002D8-D0; Wed, 04 Oct 2006 10:23:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7er-0002D2-ET for dime@ietf.org; Wed, 04 Oct 2006 10:23:37 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV7em-0008W7-VG for dime@ietf.org; Wed, 04 Oct 2006 10:23:37 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id A394290007 for ; Wed, 4 Oct 2006 10:23:29 -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 18824-09 for ; Wed, 4 Oct 2006 10:23:28 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 4 Oct 2006 10:23:24 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 10:23:06 -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] HA-to-AAAH support/When ? HoA allocation considerations Date: Wed, 4 Oct 2006 10:23:06 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD320@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] HA-to-AAAH support/When ? HoA allocation considerations Thread-Index: Acbm2c1HEtRCeZyISIG7+1R4teP7uQAAh8hwADjbJ+A= From: "Chowdhury, Kuntal" To: , , X-OriginalArrivalTime: 04 Oct 2006 14:23:06.0800 (UTC) FILETIME=[9C42D300:01C6E7C0] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Jouni, regarding your comment: > I'm not entirely sure what the above is supposed to mean.. but > imho again depending on the operator's deployment either HA or > AAA should be able to allocate the HoA. When AAA assigns a HoA for a user (MN) it is normally a statically configured HoA in the user's AAA profile in the MSA. I think we should clarify this. We have stumbled upon the HoA-allocation-by-AAA issue too many times in the past. -Kuntal > -----Original Message----- > From: jouni.korhonen@teliasonera.com > [mailto:jouni.korhonen@teliasonera.com] > Sent: Tuesday, October 03, 2006 6:25 AM > To: julien.bournelle@int-evry.fr; dime@ietf.org > Subject: RE: [Dime] HA-to-AAAH support/When ? HoA allocation > considerations >=20 > Hi Julien, >=20 > Just a quick comment or few inline.. >=20 > > -----Original Message----- > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > Sent: 3. lokakuuta 2006 13:53 > > To: dime@ietf.org > > Subject: [Dime] HA-to-AAAH support/When ? HoA allocation > > considerations > > > > Hi all, > > > > as promised, some considerations concerning triggering the > > mip6-authz process. > > > > As noted by gerardo, the IKEv2 responder may act both as a > > HA and as a VPN concentrator. In this case, it knows that it > > will be used as a HA while receiving a BU. So, we may think > > that the mip6-authz could be used at this point of time. > > > > However, we also have to consider the Home-Address (HoA) > > allocation. As you may know the MN may auto-assign its HoA > > or requests one. (cf. > > draft-ietf-mip6-bootstrapping-split-02.txt) > > > > If it wants to auto-assign its HoA, it has 2 possibilities: > > > > 1/ It autoassignes its HoA and includes it in the CFG_REQUEST > > (INTERNAL_IP6_ADDRESS)i in the first IKE_AUTH message. > > If the HA is ok, it replies with the CFG_REPLY > > with the same address. > > > > 2/ The MN asks for the Home Prefix (CFG_REQUEST with > > MIP6_HOME_PREFIX). The HA sends the Home prefix in the CFG_REPLY. > > Then > > the MN uses a CREATE_CHILD_SA. > > > > This raises some questions: > > > > 1/ Do we consider that it is the HA which decides if the MN > > is authorized to configure its HoA (policy configuration at > > the HA) ? or do we consider that it is a per-MN policy and > > thus that the HA should request that to the MSA ? >=20 > Imho both.. depends on operator's deployment. >=20 > > If we consider that the MSA should decide this, as the HoA > > is sent after the MN being authenticated by EAP. This > > implies that the mip6-authz app should be used before this > > last IKEv2 message. > > > > If the MN requests a HoA to the HA, we also have the following > > question: > > > > 1/ do we allow the AAA server to allocate this address ? or > > do we need an AVP to carry the HoA from the AAA to the HA ? >=20 > I'm not entirely sure what the above is supposed to mean.. but > imho again depending on the operator's deployment either HA or > AAA should be able to allocate the HoA. >=20 > Cheers, > Jouni >=20 >=20 > > > > regards, > > > > Julien > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 04 10:24:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7fx-0002uI-Iz; Wed, 04 Oct 2006 10:24:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7fw-0002u7-DR for dime@ietf.org; Wed, 04 Oct 2006 10:24:44 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV7fu-0000K1-UT for dime@ietf.org; Wed, 04 Oct 2006 10:24:44 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 0CABD2FEDC; Wed, 4 Oct 2006 16:24:38 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GV7hv-0006RG-Ix; Wed, 04 Oct 2006 16:26:47 +0200 Date: Wed, 4 Oct 2006 16:26:47 +0200 From: Julien Bournelle To: Gerardo Giaretta Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation considerations Message-ID: <20061004142647.GA24730@ipv6-3.int-evry.fr> References: <5D25AEFB114D034FBDC8B156FCA78E03014DF675@SEHAN021MB.tcad.telia.se> <20061004113348.GA23909@ipv6-3.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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 On Wed, Oct 04, 2006 at 02:23:01PM +0200, Gerardo Giaretta wrote: > >> > If it wants to auto-assign its HoA, it has 2 possibilities: > >> > > >> > 1/ It autoassignes its HoA and includes it in the CFG_REQUEST > >> > (INTERNAL_IP6_ADDRESS)i in the first IKE_AUTH message. > >> > If the HA is ok, it replies with the CFG_REPLY > >> > with the same address. > >> > > >> > 2/ The MN asks for the Home Prefix (CFG_REQUEST with > >> > MIP6_HOME_PREFIX). The HA sends the Home prefix in the CFG_REPLY. > >> > Then > >> > the MN uses a CREATE_CHILD_SA. > >> > > >> > This raises some questions: > >> > > >> > 1/ Do we consider that it is the HA which decides if the MN > >> > is authorized to configure its HoA (policy configuration at > >> > the HA) ? or do we consider that it is a per-MN policy and > >> > thus that the HA should request that to the MSA ? > >> > >> Imho both.. depends on operator's deployment. > > > > if we want both. This implies that the mip6-authz process occurs during > > the EAP authentication process (probably when the HA receives the > > result of the EAP authentication from the AAAH). > > > > This is needed only for autoconfiguration. But autoconfiguration has > been introduced in mip6-split for rfc3041 addresses and CGAs. Do we > want the AAA to decide if theMN can use CGA? I'm not sure this is the > case. LEt's call AAA-MIP6 the AAA server contacted by the HA for the authorization process. I'm not saying that the AAA should decide if the MN can use CGA. I'm just asking if we want that the AAA-MIP6 be able to authorize if the MN can auto-assign its address. > I think what is important from an operator perspective is that the > address may be allocated by either AAA or HA. However, to get this, we > do not need to start mip6-authz during EAP exchange, since it is a > generic IKEv2 address assignment issue and not a MIP specific one. If the HoA is allocated by the AAA-MIP6, the HA must get this address before sending the last IKEv2 message: HDR, SK {AUTH, [CP(CFG_REPLY,] SAr2, TSi, TSr } but you're right that the mip6-authz can be used right after the reception of the EAP-Success (but not after this last message and thus not after reception of the BU). If we want the AAA-MIP6 to authorize the MN to auto-assign its address, it is the same conclusion. It must be contacted before this last IKEv2 message. Julien > > --Gerardo > > > I'm also in favor of that but then we have the issue raised by gerardo > > concerning the fact that the IKEv2 responder may play 2 roles (VPN > > concentrator and HA). How do the IKEv2-R know that the MN wants to use > > mip6 ? > > > >> > >> > If we consider that the MSA should decide this, as the HoA > >> > is sent after the MN being authenticated by EAP. This > >> > implies that the mip6-authz app should be used before this > >> > last IKEv2 message. > >> > > >> > If the MN requests a HoA to the HA, we also have the following > >> > question: > >> > > >> > 1/ do we allow the AAA server to allocate this address ? or > >> > do we need an AVP to carry the HoA from the AAA to the HA ? > >> > >> I'm not entirely sure what the above is supposed to mean.. but > >> imho again depending on the operator's deployment either HA or > >> AAA should be able to allocate the HoA. > > > > I also agree with you. It also implies that the mip6-Authz App should > > be used during EAP authentication process. > > > > Julien > > > >> > >> Cheers, > >> Jouni > >> > >> > >> > > >> > regards, > >> > > >> > Julien > >> > > >> > > >> > _______________________________________________ > >> > DiME mailing list > >> > DiME@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/dime > >> > > > > >-- > >julien.bournelle at int-evry.fr > > > >_______________________________________________ > >DiME mailing list > >DiME@ietf.org > >https://www1.ietf.org/mailman/listinfo/dime > > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 04 10:29:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7k7-0007gs-3X; Wed, 04 Oct 2006 10:29:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7k6-0007gm-7h for dime@ietf.org; Wed, 04 Oct 2006 10:29:02 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV7k3-00018q-OS for dime@ietf.org; Wed, 04 Oct 2006 10:29:02 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 662BF90007 for ; Wed, 4 Oct 2006 10:28:56 -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 19007-10 for ; Wed, 4 Oct 2006 10:28:55 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 4 Oct 2006 10:28:55 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 10:28:55 -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] HA-to-AAAH support/When ? HoA allocation considerations Date: Wed, 4 Oct 2006 10:28:55 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD321@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] HA-to-AAAH support/When ? HoA allocation considerations Thread-Index: AcbnqL0vkhZHRob8SH2w/AhQSCsH0gAGAhrA From: "Chowdhury, Kuntal" To: "Julien Bournelle" , , X-OriginalArrivalTime: 04 Oct 2006 14:28:55.0489 (UTC) FILETIME=[6C188B10:01C6E7C1] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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 Julien, I am not sure about this: > I'm also in favor of that but then we have the issue raised by gerardo > concerning the fact that the IKEv2 responder may play 2 roles (VPN > concentrator and HA). How do the IKEv2-R know that the MN wants to use > mip6 ? IKEv2 transaction is taking place between the MN and the _HA_. So, why are we wondering whether the MN intends to do mip6 or not? =20 Nevertheless, we need to assume that the HA is contacting the AAA server in the MSA for EAP auth also. If we cannot assume this, then we need two separate AAA transactions with two separate domains i.e. EAP server somewhere and AAA server in the MSA. -Kuntal > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > Sent: Wednesday, October 04, 2006 6:34 AM > To: jouni.korhonen@teliasonera.com; dime@ietf.org > Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation > considerations >=20 > Hi jouni, >=20 > On Tue, Oct 03, 2006 at 01:24:59PM +0200, jouni.korhonen@teliasonera.com > wrote: >=20 > >=20 > > > However, we also have to consider the Home-Address (HoA) > > > allocation. As you may know the MN may auto-assign its HoA > > > or requests one. (cf. > > > draft-ietf-mip6-bootstrapping-split-02.txt) > > > > > > If it wants to auto-assign its HoA, it has 2 possibilities: > > > > > > 1/ It autoassignes its HoA and includes it in the CFG_REQUEST > > > (INTERNAL_IP6_ADDRESS)i in the first IKE_AUTH message. > > > If the HA is ok, it replies with the CFG_REPLY > > > with the same address. > > > > > > 2/ The MN asks for the Home Prefix (CFG_REQUEST with > > > MIP6_HOME_PREFIX). The HA sends the Home prefix in the CFG_REPLY. > > > Then > > > the MN uses a CREATE_CHILD_SA. > > > > > > This raises some questions: > > > > > > 1/ Do we consider that it is the HA which decides if the MN > > > is authorized to configure its HoA (policy configuration at > > > the HA) ? or do we consider that it is a per-MN policy and > > > thus that the HA should request that to the MSA ? > > > > Imho both.. depends on operator's deployment. >=20 > if we want both. This implies that the mip6-authz process occurs during > the EAP authentication process (probably when the HA receives the > result of the EAP authentication from the AAAH). >=20 > I'm also in favor of that but then we have the issue raised by gerardo > concerning the fact that the IKEv2 responder may play 2 roles (VPN > concentrator and HA). How do the IKEv2-R know that the MN wants to use > mip6 ? >=20 > > > > > If we consider that the MSA should decide this, as the HoA > > > is sent after the MN being authenticated by EAP. This > > > implies that the mip6-authz app should be used before this > > > last IKEv2 message. > > > > > > If the MN requests a HoA to the HA, we also have the following > > > question: > > > > > > 1/ do we allow the AAA server to allocate this address ? or > > > do we need an AVP to carry the HoA from the AAA to the HA ? > > > > I'm not entirely sure what the above is supposed to mean.. but > > imho again depending on the operator's deployment either HA or > > AAA should be able to allocate the HoA. >=20 > I also agree with you. It also implies that the mip6-Authz App should > be used during EAP authentication process. >=20 > Julien >=20 > > > > Cheers, > > Jouni > > > > > > > > > > regards, > > > > > > Julien > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > >=20 > -- > julien.bournelle at int-evry.fr >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 04 10:39:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7u2-0005Zl-M5; Wed, 04 Oct 2006 10:39:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7u0-0005Yw-Up for dime@ietf.org; Wed, 04 Oct 2006 10:39:17 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV7tz-0003G1-Bi for dime@ietf.org; Wed, 04 Oct 2006 10:39:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 01DC49004A for ; Wed, 4 Oct 2006 10:39:10 -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 19256-07 for ; Wed, 4 Oct 2006 10:39:09 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 4 Oct 2006 10:39:09 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 10:39:08 -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] HA-to-AAAH support/When ? HoA allocation considerations Date: Wed, 4 Oct 2006 10:39:08 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD322@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] HA-to-AAAH support/When ? HoA allocation considerations Thread-Index: AcbnsBLcrxGWqkbtTXid0JMJITKR8AAEaioA From: "Chowdhury, Kuntal" To: "Gerardo Giaretta" , "Julien Bournelle" X-OriginalArrivalTime: 04 Oct 2006 14:39:08.0962 (UTC) FILETIME=[D9C11820:01C6E7C2] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 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, Regarding your comment: > I think what is important from an operator perspective is that the > address may be allocated by either AAA or HA. However, to get this, we > do not need to start mip6-authz during EAP exchange, since it is a > generic IKEv2 address assignment issue and not a MIP specific one. I think it is important to verify whether the user is allowed to use a particular HoA. For example, the user may intentionally or accidentally set the INTERNAL_IP6_ADDRESS to someone else's statically assigned HoA. The HA may not keep track of the statically assigned HoAs of all the users belonging to an MSA. If the HA does not verify with the MSA (AAA) the user will get an address which actually belongs to someone else.=20 To circumvent the problem, in some deployments the prefix that can be used to auto-configure HoAs by MNs is kept separate from the ones used for static HoA assignment. The HA should have this knowledge either via local config or via AAA transaction. -Kuntal =20 > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Wednesday, October 04, 2006 7:23 AM > To: Julien Bournelle > Cc: dime@ietf.org > Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation > considerations >=20 > Hi Julien and Jouni, >=20 > > > > However, we also have to consider the Home-Address (HoA) > > > > allocation. As you may know the MN may auto-assign its HoA > > > > or requests one. (cf. > > > > draft-ietf-mip6-bootstrapping-split-02.txt) > > > > > > > > If it wants to auto-assign its HoA, it has 2 possibilities: > > > > > > > > 1/ It autoassignes its HoA and includes it in the CFG_REQUEST > > > > (INTERNAL_IP6_ADDRESS)i in the first IKE_AUTH message. > > > > If the HA is ok, it replies with the CFG_REPLY > > > > with the same address. > > > > > > > > 2/ The MN asks for the Home Prefix (CFG_REQUEST with > > > > MIP6_HOME_PREFIX). The HA sends the Home prefix in the CFG_REPLY. > > > > Then > > > > the MN uses a CREATE_CHILD_SA. > > > > > > > > This raises some questions: > > > > > > > > 1/ Do we consider that it is the HA which decides if the MN > > > > is authorized to configure its HoA (policy configuration at > > > > the HA) ? or do we consider that it is a per-MN policy and > > > > thus that the HA should request that to the MSA ? > > > > > > Imho both.. depends on operator's deployment. > > > > if we want both. This implies that the mip6-authz process occurs during > > the EAP authentication process (probably when the HA receives the > > result of the EAP authentication from the AAAH). > > >=20 > This is needed only for autoconfiguration. But autoconfiguration has > been introduced in mip6-split for rfc3041 addresses and CGAs. Do we > want the AAA to decide if theMN can use CGA? I'm not sure this is the > case. >=20 > I think what is important from an operator perspective is that the > address may be allocated by either AAA or HA. However, to get this, we > do not need to start mip6-authz during EAP exchange, since it is a > generic IKEv2 address assignment issue and not a MIP specific one. >=20 > --Gerardo >=20 > > I'm also in favor of that but then we have the issue raised by gerardo > > concerning the fact that the IKEv2 responder may play 2 roles (VPN > > concentrator and HA). How do the IKEv2-R know that the MN wants to use > > mip6 ? > > > > > > > > > If we consider that the MSA should decide this, as the HoA > > > > is sent after the MN being authenticated by EAP. This > > > > implies that the mip6-authz app should be used before this > > > > last IKEv2 message. > > > > > > > > If the MN requests a HoA to the HA, we also have the following > > > > question: > > > > > > > > 1/ do we allow the AAA server to allocate this address ? or > > > > do we need an AVP to carry the HoA from the AAA to the HA ? > > > > > > I'm not entirely sure what the above is supposed to mean.. but > > > imho again depending on the operator's deployment either HA or > > > AAA should be able to allocate the HoA. > > > > I also agree with you. It also implies that the mip6-Authz App should > > be used during EAP authentication process. > > > > Julien > > > > > > > > Cheers, > > > Jouni > > > > > > > > > > > > > > regards, > > > > > > > > Julien > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > -- > > julien.bournelle at int-evry.fr > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 04 10:51:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV85j-0006Z1-Ux; Wed, 04 Oct 2006 10:51:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV85j-0006Vm-68 for dime@ietf.org; Wed, 04 Oct 2006 10:51:23 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV85i-0006PW-Kl for dime@ietf.org; Wed, 04 Oct 2006 10:51:23 -0400 Received: by ug-out-1314.google.com with SMTP id 72so61841ugd for ; Wed, 04 Oct 2006 07:51:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ui+7TzgV4MT/7+rhx+WsO7yqgVPuhKkccPvmHbDKcfK1pcTOyMRlN6MPWAYISPt5aM0dWWCbq6JIn0NOSFG6R6LpB8N08bI8eljHPeH3YwUtpVJyJRxuc0jPA4ktKmLN57DsmN6eK42CbHTuFhcop65Si7IbFRvM0p61t/Lq3rw= Received: by 10.67.105.19 with SMTP id h19mr653009ugm; Wed, 04 Oct 2006 07:51:21 -0700 (PDT) Received: by 10.66.237.2 with HTTP; Wed, 4 Oct 2006 07:51:21 -0700 (PDT) Message-ID: Date: Wed, 4 Oct 2006 16:51:21 +0200 From: "Gerardo Giaretta" To: "Chowdhury, Kuntal" Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation considerations In-Reply-To: <7CCD07160348804497EF29E9EA5560D7FBD322$0001@exchtewks2.starentnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7CCD07160348804497EF29E9EA5560D7FBD322$0001@exchtewks2.starentnetworks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 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 Kuntal, I agree with your point that the HoA assignment procedure may be controlled by the AAA.. I'm just trying to figure out how the two applications (Diameter EAP application based on rfc4072 and Diameter MIP6 Authorization Application) will work together and when we need to start the exchange of MIP6 Authorization Application. My original thought was that the MIP6 Authorization Application can be started and used at the reception of the first BU since it is from that moment that the MN begins using MIP6 service. Based on this consideration, I'm wondering if we can leave the HoA assignment to the Diameter EAP part, but this seems not so clean. The other issue is that the IKEv2 responder may be a HA, but may be also a combined HA/PDG/VPN concentrator. Are we assuming that the IKEv2 responder acts only as HA? If so, the MIPv6 authorization application can start during IKEv2 exchange. But if not, how the IKEv2 responder (i.e. HA/PDG/ VPN concentrator) knows that the user is a MIP user or not? --Gerardo On 10/4/06, Chowdhury, Kuntal wrote: > Hi Gerardo, > > Regarding your comment: > > > I think what is important from an operator perspective is that the > > address may be allocated by either AAA or HA. However, to get this, we > > do not need to start mip6-authz during EAP exchange, since it is a > > generic IKEv2 address assignment issue and not a MIP specific one. > > I think it is important to verify whether the user is allowed to use a > particular HoA. For example, the user may intentionally or accidentally > set the INTERNAL_IP6_ADDRESS to someone else's statically assigned HoA. > The HA may not keep track of the statically assigned HoAs of all the > users belonging to an MSA. If the HA does not verify with the MSA (AAA) > the user will get an address which actually belongs to someone else. > > To circumvent the problem, in some deployments the prefix that can be > used to auto-configure HoAs by MNs is kept separate from the ones used > for static HoA assignment. The HA should have this knowledge either via > local config or via AAA transaction. > > -Kuntal > > > > -----Original Message----- > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > Sent: Wednesday, October 04, 2006 7:23 AM > > To: Julien Bournelle > > Cc: dime@ietf.org > > Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation > > considerations > > > > Hi Julien and Jouni, > > > > > > > However, we also have to consider the Home-Address (HoA) > > > > > allocation. As you may know the MN may auto-assign its HoA > > > > > or requests one. (cf. > > > > > draft-ietf-mip6-bootstrapping-split-02.txt) > > > > > > > > > > If it wants to auto-assign its HoA, it has 2 possibilities: > > > > > > > > > > 1/ It autoassignes its HoA and includes it in the CFG_REQUEST > > > > > (INTERNAL_IP6_ADDRESS)i in the first IKE_AUTH message. > > > > > If the HA is ok, it replies with the CFG_REPLY > > > > > with the same address. > > > > > > > > > > 2/ The MN asks for the Home Prefix (CFG_REQUEST with > > > > > MIP6_HOME_PREFIX). The HA sends the Home prefix in the > CFG_REPLY. > > > > > Then > > > > > the MN uses a CREATE_CHILD_SA. > > > > > > > > > > This raises some questions: > > > > > > > > > > 1/ Do we consider that it is the HA which decides if the MN > > > > > is authorized to configure its HoA (policy configuration at > > > > > the HA) ? or do we consider that it is a per-MN policy and > > > > > thus that the HA should request that to the MSA ? > > > > > > > > Imho both.. depends on operator's deployment. > > > > > > if we want both. This implies that the mip6-authz process occurs > during > > > the EAP authentication process (probably when the HA receives the > > > result of the EAP authentication from the AAAH). > > > > > > > This is needed only for autoconfiguration. But autoconfiguration has > > been introduced in mip6-split for rfc3041 addresses and CGAs. Do we > > want the AAA to decide if theMN can use CGA? I'm not sure this is the > > case. > > > > I think what is important from an operator perspective is that the > > address may be allocated by either AAA or HA. However, to get this, we > > do not need to start mip6-authz during EAP exchange, since it is a > > generic IKEv2 address assignment issue and not a MIP specific one. > > > > --Gerardo > > > > > I'm also in favor of that but then we have the issue raised by > gerardo > > > concerning the fact that the IKEv2 responder may play 2 roles (VPN > > > concentrator and HA). How do the IKEv2-R know that the MN wants to > use > > > mip6 ? > > > > > > > > > > > > If we consider that the MSA should decide this, as the HoA > > > > > is sent after the MN being authenticated by EAP. This > > > > > implies that the mip6-authz app should be used before this > > > > > last IKEv2 message. > > > > > > > > > > If the MN requests a HoA to the HA, we also have the following > > > > > question: > > > > > > > > > > 1/ do we allow the AAA server to allocate this address ? or > > > > > do we need an AVP to carry the HoA from the AAA to the HA ? > > > > > > > > I'm not entirely sure what the above is supposed to mean.. but > > > > imho again depending on the operator's deployment either HA or > > > > AAA should be able to allocate the HoA. > > > > > > I also agree with you. It also implies that the mip6-Authz App > should > > > be used during EAP authentication process. > > > > > > Julien > > > > > > > > > > > Cheers, > > > > Jouni > > > > > > > > > > > > > > > > > > regards, > > > > > > > > > > Julien > > > > > > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > -- > > > julien.bournelle at int-evry.fr > > > > > > _______________________________________________ > > > 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 > > > "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you." > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 04 14:15:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBHJ-0002mG-16; Wed, 04 Oct 2006 14:15:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBHI-0002mB-Ar for dime@ietf.org; Wed, 04 Oct 2006 14:15:32 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVBHF-0002Hm-7S for dime@ietf.org; Wed, 04 Oct 2006 14:15:32 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 610851FAC5E; Wed, 4 Oct 2006 20:15:26 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18969-01-76; Wed, 4 Oct 2006 20:15:24 +0200 (CEST) Received: from [207.3.232.120] (unknown [207.3.232.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id C837C1FABD9; Wed, 4 Oct 2006 20:15:22 +0200 (CEST) Message-ID: <4523F9FC.4020902@dif.um.es> Date: Wed, 04 Oct 2006 14:14:20 -0400 From: Rafa Marin Lopez Organization: University of Murcia User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gerardo Giaretta Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation considerations References: <7CCD07160348804497EF29E9EA5560D7FBD322$0001@exchtewks2.starentnetworks.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 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, > > My original thought was that the MIP6 Authorization Application can be > started and used at the reception of the first BU since it is from > that moment that the MN begins using MIP6 service. Based on this > consideration, I'm wondering if we can leave the HoA assignment to the > Diameter EAP part, but this seems not so clean. But in that case, you are already receiving MIP6 authorization information within Diameter EAP... correct? > > The other issue is that the IKEv2 responder may be a HA, but may be > also a combined HA/PDG/VPN concentrator. Are we assuming that the > IKEv2 responder acts only as HA? If so, the MIPv6 authorization > application can start during IKEv2 exchange. But if not, how the IKEv2 > responder (i.e. HA/PDG/ VPN concentrator) knows that the user is a MIP > user or not? I have a question: is the assumption here that HA/PDG/VPN may need to ask authorization about different services (e.g. VPN parameters or/and MIP6 parameters) depending on MN requires? Another question: how would HA/PDG/VPN know it has to use RFC 4072 with AUTHENTICATE_ONLY for MIP6 service? Initially, it looks that the a simple answer would be that HA/PDG/VPN is configured to send AUTHENTICATE_ONLY no matter the service. Thanks. > > --Gerardo > > On 10/4/06, Chowdhury, Kuntal wrote: > >> Hi Gerardo, >> >> Regarding your comment: >> >> > I think what is important from an operator perspective is that the >> > address may be allocated by either AAA or HA. However, to get this, we >> > do not need to start mip6-authz during EAP exchange, since it is a >> > generic IKEv2 address assignment issue and not a MIP specific one. >> >> I think it is important to verify whether the user is allowed to use a >> particular HoA. For example, the user may intentionally or accidentally >> set the INTERNAL_IP6_ADDRESS to someone else's statically assigned HoA. >> The HA may not keep track of the statically assigned HoAs of all the >> users belonging to an MSA. If the HA does not verify with the MSA (AAA) >> the user will get an address which actually belongs to someone else. >> >> To circumvent the problem, in some deployments the prefix that can be >> used to auto-configure HoAs by MNs is kept separate from the ones used >> for static HoA assignment. The HA should have this knowledge either via >> local config or via AAA transaction. >> >> -Kuntal >> >> >> > -----Original Message----- >> > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] >> > Sent: Wednesday, October 04, 2006 7:23 AM >> > To: Julien Bournelle >> > Cc: dime@ietf.org >> > Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation >> > considerations >> > >> > Hi Julien and Jouni, >> > >> > > > > However, we also have to consider the Home-Address (HoA) >> > > > > allocation. As you may know the MN may auto-assign its HoA >> > > > > or requests one. (cf. >> > > > > draft-ietf-mip6-bootstrapping-split-02.txt) >> > > > > >> > > > > If it wants to auto-assign its HoA, it has 2 possibilities: >> > > > > >> > > > > 1/ It autoassignes its HoA and includes it in the CFG_REQUEST >> > > > > (INTERNAL_IP6_ADDRESS)i in the first IKE_AUTH message. >> > > > > If the HA is ok, it replies with the CFG_REPLY >> > > > > with the same address. >> > > > > >> > > > > 2/ The MN asks for the Home Prefix (CFG_REQUEST with >> > > > > MIP6_HOME_PREFIX). The HA sends the Home prefix in the >> CFG_REPLY. >> > > > > Then >> > > > > the MN uses a CREATE_CHILD_SA. >> > > > > >> > > > > This raises some questions: >> > > > > >> > > > > 1/ Do we consider that it is the HA which decides if the MN >> > > > > is authorized to configure its HoA (policy configuration at >> > > > > the HA) ? or do we consider that it is a per-MN policy and >> > > > > thus that the HA should request that to the MSA ? >> > > > >> > > > Imho both.. depends on operator's deployment. >> > > >> > > if we want both. This implies that the mip6-authz process occurs >> during >> > > the EAP authentication process (probably when the HA receives the >> > > result of the EAP authentication from the AAAH). >> > > >> > >> > This is needed only for autoconfiguration. But autoconfiguration has >> > been introduced in mip6-split for rfc3041 addresses and CGAs. Do we >> > want the AAA to decide if theMN can use CGA? I'm not sure this is the >> > case. >> > >> > I think what is important from an operator perspective is that the >> > address may be allocated by either AAA or HA. However, to get this, we >> > do not need to start mip6-authz during EAP exchange, since it is a >> > generic IKEv2 address assignment issue and not a MIP specific one. >> > >> > --Gerardo >> > >> > > I'm also in favor of that but then we have the issue raised by >> gerardo >> > > concerning the fact that the IKEv2 responder may play 2 roles (VPN >> > > concentrator and HA). How do the IKEv2-R know that the MN wants to >> use >> > > mip6 ? >> > > >> > > > >> > > > > If we consider that the MSA should decide this, as the HoA >> > > > > is sent after the MN being authenticated by EAP. This >> > > > > implies that the mip6-authz app should be used before this >> > > > > last IKEv2 message. >> > > > > >> > > > > If the MN requests a HoA to the HA, we also have the following >> > > > > question: >> > > > > >> > > > > 1/ do we allow the AAA server to allocate this address ? or >> > > > > do we need an AVP to carry the HoA from the AAA to the HA ? >> > > > >> > > > I'm not entirely sure what the above is supposed to mean.. but >> > > > imho again depending on the operator's deployment either HA or >> > > > AAA should be able to allocate the HoA. >> > > >> > > I also agree with you. It also implies that the mip6-Authz App >> should >> > > be used during EAP authentication process. >> > > >> > > Julien >> > > >> > > > >> > > > Cheers, >> > > > Jouni >> > > > >> > > > >> > > > > >> > > > > regards, >> > > > > >> > > > > Julien >> > > > > >> > > > > >> > > > > _______________________________________________ >> > > > > DiME mailing list >> > > > > DiME@ietf.org >> > > > > https://www1.ietf.org/mailman/listinfo/dime >> > > > > >> > > >> > > -- >> > > julien.bournelle at int-evry.fr >> > > >> > > _______________________________________________ >> > > 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 >> >> >> "This email message and any attachments are confidential information >> of Starent Networks, Corp. The information transmitted may not be >> used to create or change any contractual obligations of Starent >> Networks, Corp. Any review, retransmission, dissemination or other >> use of, or taking of any action in reliance upon this e-mail and its >> attachments by persons or entities other than the intended recipient >> is prohibited. If you are not the intended recipient, please notify >> the sender immediately -- by replying to this message or by sending >> an email to postmaster@starentnetworks.com -- and destroy all copies >> of this message and any attachments without reading or disclosing >> their contents. Thank you." >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 04 18:16:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVF1y-0006ll-SY; Wed, 04 Oct 2006 18:15:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVF1x-0006lg-SM for dime@ietf.org; Wed, 04 Oct 2006 18:15:57 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVF1v-0006Sv-6x for dime@ietf.org; Wed, 04 Oct 2006 18:15:57 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 7CE2C9004F for ; Wed, 4 Oct 2006 18:15:51 -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 28540-06 for ; Wed, 4 Oct 2006 18:15:50 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 4 Oct 2006 18:15:50 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 18:15:50 -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] HA-to-AAAH support/When ? HoA allocation considerations Date: Wed, 4 Oct 2006 18:15:50 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD32D@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] HA-to-AAAH support/When ? HoA allocation considerations Thread-Index: Acbn4S6+p5Lq50pRRUe5p3VzbKo1fQAIQDrg From: "Chowdhury, Kuntal" To: "Rafa Marin Lopez" , "Gerardo Giaretta" X-OriginalArrivalTime: 04 Oct 2006 22:15:50.0360 (UTC) FILETIME=[A6429D80:01C6E802] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 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 Rafa, I am not sure why we are bringing scenarios that are outside the scope of MIP6. In MIP6 IPsec/IKEv2 happens between the MN and the HA. PDG/VPN etc. are outside the scope of what we are defining here i.e. HA-HAAA Diameter interface, IMHO. -Kuntal > -----Original Message----- > From: Rafa Marin Lopez [mailto:rafa@dif.um.es] > Sent: Wednesday, October 04, 2006 1:14 PM > To: Gerardo Giaretta > Cc: dime@ietf.org > Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation > considerations >=20 > Hi Gerardo, >=20 > > > > My original thought was that the MIP6 Authorization Application can be > > started and used at the reception of the first BU since it is from > > that moment that the MN begins using MIP6 service. Based on this > > consideration, I'm wondering if we can leave the HoA assignment to the > > Diameter EAP part, but this seems not so clean. >=20 > But in that case, you are already receiving MIP6 authorization > information within Diameter EAP... correct? >=20 > > > > The other issue is that the IKEv2 responder may be a HA, but may be > > also a combined HA/PDG/VPN concentrator. Are we assuming that the > > IKEv2 responder acts only as HA? If so, the MIPv6 authorization > > application can start during IKEv2 exchange. But if not, how the IKEv2 > > responder (i.e. HA/PDG/ VPN concentrator) knows that the user is a MIP > > user or not? >=20 > I have a question: is the assumption here that HA/PDG/VPN may need to > ask authorization about different services (e.g. VPN parameters or/and > MIP6 parameters) depending on MN requires? >=20 > Another question: how would HA/PDG/VPN know it has to use RFC 4072 with > AUTHENTICATE_ONLY for MIP6 service? > Initially, it looks that the a simple answer would be that HA/PDG/VPN is > configured to send AUTHENTICATE_ONLY no matter the service. >=20 > Thanks. >=20 > > > > --Gerardo > > > > On 10/4/06, Chowdhury, Kuntal wrote: > > > >> Hi Gerardo, > >> > >> Regarding your comment: > >> > >> > I think what is important from an operator perspective is that the > >> > address may be allocated by either AAA or HA. However, to get this, > we > >> > do not need to start mip6-authz during EAP exchange, since it is a > >> > generic IKEv2 address assignment issue and not a MIP specific one. > >> > >> I think it is important to verify whether the user is allowed to use a > >> particular HoA. For example, the user may intentionally or accidentally > >> set the INTERNAL_IP6_ADDRESS to someone else's statically assigned HoA. > >> The HA may not keep track of the statically assigned HoAs of all the > >> users belonging to an MSA. If the HA does not verify with the MSA (AAA) > >> the user will get an address which actually belongs to someone else. > >> > >> To circumvent the problem, in some deployments the prefix that can be > >> used to auto-configure HoAs by MNs is kept separate from the ones used > >> for static HoA assignment. The HA should have this knowledge either via > >> local config or via AAA transaction. > >> > >> -Kuntal > >> > >> > >> > -----Original Message----- > >> > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > >> > Sent: Wednesday, October 04, 2006 7:23 AM > >> > To: Julien Bournelle > >> > Cc: dime@ietf.org > >> > Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation > >> > considerations > >> > > >> > Hi Julien and Jouni, > >> > > >> > > > > However, we also have to consider the Home-Address (HoA) > >> > > > > allocation. As you may know the MN may auto-assign its HoA > >> > > > > or requests one. (cf. > >> > > > > draft-ietf-mip6-bootstrapping-split-02.txt) > >> > > > > > >> > > > > If it wants to auto-assign its HoA, it has 2 possibilities: > >> > > > > > >> > > > > 1/ It autoassignes its HoA and includes it in the CFG_REQUEST > >> > > > > (INTERNAL_IP6_ADDRESS)i in the first IKE_AUTH message. > >> > > > > If the HA is ok, it replies with the CFG_REPLY > >> > > > > with the same address. > >> > > > > > >> > > > > 2/ The MN asks for the Home Prefix (CFG_REQUEST with > >> > > > > MIP6_HOME_PREFIX). The HA sends the Home prefix in the > >> CFG_REPLY. > >> > > > > Then > >> > > > > the MN uses a CREATE_CHILD_SA. > >> > > > > > >> > > > > This raises some questions: > >> > > > > > >> > > > > 1/ Do we consider that it is the HA which decides if the MN > >> > > > > is authorized to configure its HoA (policy configuration at > >> > > > > the HA) ? or do we consider that it is a per-MN policy and > >> > > > > thus that the HA should request that to the MSA ? > >> > > > > >> > > > Imho both.. depends on operator's deployment. > >> > > > >> > > if we want both. This implies that the mip6-authz process occurs > >> during > >> > > the EAP authentication process (probably when the HA receives the > >> > > result of the EAP authentication from the AAAH). > >> > > > >> > > >> > This is needed only for autoconfiguration. But autoconfiguration has > >> > been introduced in mip6-split for rfc3041 addresses and CGAs. Do we > >> > want the AAA to decide if theMN can use CGA? I'm not sure this is the > >> > case. > >> > > >> > I think what is important from an operator perspective is that the > >> > address may be allocated by either AAA or HA. However, to get this, > we > >> > do not need to start mip6-authz during EAP exchange, since it is a > >> > generic IKEv2 address assignment issue and not a MIP specific one. > >> > > >> > --Gerardo > >> > > >> > > I'm also in favor of that but then we have the issue raised by > >> gerardo > >> > > concerning the fact that the IKEv2 responder may play 2 roles (VPN > >> > > concentrator and HA). How do the IKEv2-R know that the MN wants to > >> use > >> > > mip6 ? > >> > > > >> > > > > >> > > > > If we consider that the MSA should decide this, as the HoA > >> > > > > is sent after the MN being authenticated by EAP. This > >> > > > > implies that the mip6-authz app should be used before this > >> > > > > last IKEv2 message. > >> > > > > > >> > > > > If the MN requests a HoA to the HA, we also have the following > >> > > > > question: > >> > > > > > >> > > > > 1/ do we allow the AAA server to allocate this address ? or > >> > > > > do we need an AVP to carry the HoA from the AAA to the HA ? > >> > > > > >> > > > I'm not entirely sure what the above is supposed to mean.. but > >> > > > imho again depending on the operator's deployment either HA or > >> > > > AAA should be able to allocate the HoA. > >> > > > >> > > I also agree with you. It also implies that the mip6-Authz App > >> should > >> > > be used during EAP authentication process. > >> > > > >> > > Julien > >> > > > >> > > > > >> > > > Cheers, > >> > > > Jouni > >> > > > > >> > > > > >> > > > > > >> > > > > regards, > >> > > > > > >> > > > > Julien > >> > > > > > >> > > > > > >> > > > > _______________________________________________ > >> > > > > DiME mailing list > >> > > > > DiME@ietf.org > >> > > > > https://www1.ietf.org/mailman/listinfo/dime > >> > > > > > >> > > > >> > > -- > >> > > julien.bournelle at int-evry.fr > >> > > > >> > > _______________________________________________ > >> > > 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 > >> > >> > >> "This email message and any attachments are confidential information > >> of Starent Networks, Corp. The information transmitted may not be > >> used to create or change any contractual obligations of Starent > >> Networks, Corp. Any review, retransmission, dissemination or other > >> use of, or taking of any action in reliance upon this e-mail and its > >> attachments by persons or entities other than the intended recipient > >> is prohibited. If you are not the intended recipient, please notify > >> the sender immediately -- by replying to this message or by sending > >> an email to postmaster@starentnetworks.com -- and destroy all copies > >> of this message and any attachments without reading or disclosing > >> their contents. Thank you." > >> > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > >=20 >=20 > -- > ------------------------------------------------------ > Rafael Marin Lopez > Faculty of Computer Science-University of Murcia > 30071 Murcia - Spain > Telf: +34968367645 e-mail: rafa@dif.um.es > ------------------------------------------------------ >=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 Wed Oct 04 19:30:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVGC0-0002fB-BX; Wed, 04 Oct 2006 19:30:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVGBz-0002br-EP for dime@ietf.org; Wed, 04 Oct 2006 19:30:23 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVGBy-0003E6-Ub for dime@ietf.org; Wed, 04 Oct 2006 19:30:23 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6M0087SX5E2V@usaga01-in.huawei.com> for dime@ietf.org; Wed, 04 Oct 2006 16:27:15 -0700 (PDT) Received: from huawei6cc10c70 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J6M00265X5AX7@usaga01-in.huawei.com> for dime@ietf.org; Wed, 04 Oct 2006 16:27:14 -0700 (PDT) Date: Wed, 04 Oct 2006 16:30:12 -0700 From: Madjid Nakhjiri Subject: RE: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) In-reply-to: <20061004094128.GA23345@ipv6-3.int-evry.fr> To: 'Julien Bournelle' Message-id: <001601c6e80d$0bec6b20$2f01a8c0@huawei6cc10c70> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbnmZRB8ZUp2UNqSNiGCzVAr8Vl4AAcQFgA X-Spam-Score: 0.8 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e 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 Julien, Snip > Yes, a Mobility service provider and its AAA server should look at the MN > and its service profile to see if it is authorized to use MIP6 service and > how it is supposed to pay for it. But we need to figure out what > "authorization credentials" to be used for this authorization. Now this > includes > 1) something that securely identifies the MN (this includes proof of > authentication) > 2) something that proves MN's right to MIP6 service, i.e. an authorization > token or indication to a profile that the AAA server of MSP has of MN that > shows MN should have MIP6 service. > > If you are separating authorization spec from authentication spec, then both > of these need to be included in the authorization spec. that's indeed a good question. At this point of time, I thought that in the mip6-authz messages, we didn't need sort of "authz token". I thought that the authentication process was implicit for the AAA-MIP6 Authz server and that finally it was the HA which basically need to be sure that the MN is authenticated. Madjid>>Traditionally, the authorization token is not an absolute necessity, as long as there is a proof of a previous authentication and as long as there is profile info in the MSP AAA server on the MN. However, "authorization token" would provide a clean separation of authorization and authentication. I say this because I have seen talk about having different MIP6 and EAP servers on this list. so my question: can't the AAA-MIP6 authz server assume that the MN has been authenticated while receiving an authz request ? Madjid>>When it comes to security, you cannot assume anything:) If the process depends on a previous authentication, then a proof of a previous authentication needs to be provided. This could either be a key resulted from a previous authentication signing the authorization request, or an authorization token, IMO. The other question I have after reading the split scenario doc is that you guys are saying bootstrapping of some of MIP6 info (such as HoA) is done as part of IKEv2 signaling. How can you then separate a Diameter MIP6 authorization from the IKEv2 authentication? > The MN identity used MIP6 may or may not be the same as that used in a > previous EAP, especially in split scenario, so it seems that in split > scenario you run two EAPs, one with MN ASP ID and one with MN MSP ID. When > you produce a separate authorization spec ("Diameter MIP6 spec" separate > from "Diameter EAP spec"), you need make sure that > > 1) MN uses the same ID during EAP and during MIP6? Concerning Identity used in the MIP6 Authz process, we have two options: 1/ The HA uses the Identity provided in the IDi field during the IKE_AUTH phase. In this case, the identity will be the same than the one provided with the Diameter EAP Application. Madjid>>This could work, as long as the MSP AAA server recognizes the MN with the same ID that the EAP server. Again, we need to very careful in writing the spec, so that we avoid dependency of MIP6 spec on EAP spec, or feasibility of MIP solution on a prior EAP run. That is why providing proof for authentication or an authorization token is important, this way you know what ID has been used before. I still have the question as before: how do you do MIP6 HoA bootstrapping if authn and authz are separated? 2/ The HA uses something provided in the BU. In this case, it implies that the mip6-authz application is used after the whole EAP authentication process. This may not be possible if we want to do authorization of HoA allocation (cf. my thread on this subject). Madjid>>Yes, if the identity used during authz is different from that during authn, then you have potential for identity fraud. > 2) even if it does, the MN's ID the MN is using is authenticated? There must > be a proof of a previous authentication. Just saying MN has run EAP before > it is not enough. When you are separating Diameter MIP spec and Diameter EAP > spec and taking authentication out, then the MIP spec needs to specify how > the MN provides proof that it has run a previous EAP (or another > authentication method) by probably signing its MIP6 authorization request > with a key that was generated during a previous EAP or authentication. > Otherwise, there is no way to know that the MN has actually been > authenticated, meaning it is very difficult to separate authorization from > authorization. well, as noted below, I tend to think that the Authz server doesn't need a proof that the MN has been authenticated. The Authz server could trust the HA for this. Madjid>> You seem to be making assumptions about HA here, i.e. HA knows about the previous EAP and knows MN with that same identity. If this is true, then the HA may have been provided with some info (a key or a token) from the EAP/AAA server and then the HA can use that knowledge with the MSP/AAA to show that MN has been authenticated. R, Madjid Julien > Having said that I am hesitant to state that support option 2 as well. > And yes, Update of 4072 should not affect update of MIP6 application. > > Diameter MIP6 application needs to stand on its own and if it is going to > only define authorization and accounting and rely on a previous > authentication, then it must be independent of whether the authentication is > EAP or something else. We are not here to just solve a specific optimization > problem... > > My two rusty (late) pennies, > > Regards, > > Madjid > > > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > Sent: Friday, September 15, 2006 3:21 AM > To: dime@ietf.org > Subject: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) > > Hi all, > > this is a new polling concerning the ha-aaah interface for the Mobile > IPv6 Boostrapping. To date, at the previous one, there was a > consensus on moving forward with a new App-ID. But, yoshi has > proposed an interesting idea that should be considered by the WG. > > As you may recall, in the ha-aaah case, the MN is authenticated by > EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH > interface must, at least, be able to carry EAP packets. It appears that > we now have 2 options: > > (1) We define a new Diameter application for Mobile IPv6 with a new > App-ID that carry EAP packets as it is done in RFC 4072 (Diameter > EAP) but Authorization and Accouting is specific to Mobile IPv6 > (thus the need for a new App-ID). The risk, as noted by yoshi, is > that an update of the RFC4072 may result in an update of this > application. > > > (2) We define a new Diameter Application for Mobile IPv6 but which is > used for Authorization and Accounting. We continue to use > Diameter EAP for the Authentication. Thus the HA will use > Diameter EAP with the AVP Auth-Request-Type set to > AUTHENTICATE_ONLY and then the HA will use this MIP6 Application > for Authorization/Accounting of the Mobile IPv6 service. This new > application will have its own App-ID. > > This would avoid to update the application if 4072 is updated and > this could be a way to proceed if other applications need EAP for > Authentication but have different needs for the Authorization and > Accounting part. > > Please indicate wether you prefer (1) or (2). > > As in the previous polling: > - it might be useful to state a reason for your decision. > - indicate wether some aspects are still unclear to you. > > Regards, > > Julien > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 05 03:48:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVNxy-0006WP-WA; Thu, 05 Oct 2006 03:48:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVNxy-0006WK-HS for dime@ietf.org; Thu, 05 Oct 2006 03:48:26 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVNxx-00021N-VY for dime@ietf.org; Thu, 05 Oct 2006 03:48:26 -0400 Received: by ug-out-1314.google.com with SMTP id 72so146713ugd for ; Thu, 05 Oct 2006 00:48:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=t1LlsRVFOLuDP6YEzsY/LCKoKEUso/E4T/u5HBmVBZH5ZmA5qBqihaO+qF3LnaM85uqcp+KRrJnzTOOEox7vN3kOWwCQzbzt98bfK/w0wBJWz/MB79whPssGaaadUDVcoWGzZO8V6Yr4nas+fBenSg13hHgpRDt7ZRQjgH7AaA4= Received: by 10.66.221.6 with SMTP id t6mr1561037ugg; Thu, 05 Oct 2006 00:48:24 -0700 (PDT) Received: by 10.66.237.2 with HTTP; Thu, 5 Oct 2006 00:48:24 -0700 (PDT) Message-ID: Date: Thu, 5 Oct 2006 09:48:24 +0200 From: "Gerardo Giaretta" To: "Rafa Marin Lopez" Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation considerations In-Reply-To: <4523F9FC.4020902@dif.um.es> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7CCD07160348804497EF29E9EA5560D7FBD322$0001@exchtewks2.starentnetworks.com> <4523F9FC.4020902@dif.um.es> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba 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 Rafa, > > My original thought was that the MIP6 Authorization Application can be > > started and used at the reception of the first BU since it is from > > that moment that the MN begins using MIP6 service. Based on this > > consideration, I'm wondering if we can leave the HoA assignment to the > > Diameter EAP part, but this seems not so clean. > > But in that case, you are already receiving MIP6 authorization > information within Diameter EAP... correct? > Yes, and I think this is the main issue. > > > > The other issue is that the IKEv2 responder may be a HA, but may be > > also a combined HA/PDG/VPN concentrator. Are we assuming that the > > IKEv2 responder acts only as HA? If so, the MIPv6 authorization > > application can start during IKEv2 exchange. But if not, how the IKEv2 > > responder (i.e. HA/PDG/ VPN concentrator) knows that the user is a MIP > > user or not? > > I have a question: is the assumption here that HA/PDG/VPN may need to > ask authorization about different services (e.g. VPN parameters or/and > MIP6 parameters) depending on MN requires? > I think yes, at least from a deployment perspective. > Another question: how would HA/PDG/VPN know it has to use RFC 4072 with > AUTHENTICATE_ONLY for MIP6 service? > Initially, it looks that the a simple answer would be that HA/PDG/VPN is > configured to send AUTHENTICATE_ONLY no matter the service. > That would be a solution. But the HoA assignment is still an open issue. --Gerardo > Thanks. > > > > > --Gerardo > > > > On 10/4/06, Chowdhury, Kuntal wrote: > > > >> Hi Gerardo, > >> > >> Regarding your comment: > >> > >> > I think what is important from an operator perspective is that the > >> > address may be allocated by either AAA or HA. However, to get this, we > >> > do not need to start mip6-authz during EAP exchange, since it is a > >> > generic IKEv2 address assignment issue and not a MIP specific one. > >> > >> I think it is important to verify whether the user is allowed to use a > >> particular HoA. For example, the user may intentionally or accidentally > >> set the INTERNAL_IP6_ADDRESS to someone else's statically assigned HoA. > >> The HA may not keep track of the statically assigned HoAs of all the > >> users belonging to an MSA. If the HA does not verify with the MSA (AAA) > >> the user will get an address which actually belongs to someone else. > >> > >> To circumvent the problem, in some deployments the prefix that can be > >> used to auto-configure HoAs by MNs is kept separate from the ones used > >> for static HoA assignment. The HA should have this knowledge either via > >> local config or via AAA transaction. > >> > >> -Kuntal > >> > >> > >> > -----Original Message----- > >> > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > >> > Sent: Wednesday, October 04, 2006 7:23 AM > >> > To: Julien Bournelle > >> > Cc: dime@ietf.org > >> > Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation > >> > considerations > >> > > >> > Hi Julien and Jouni, > >> > > >> > > > > However, we also have to consider the Home-Address (HoA) > >> > > > > allocation. As you may know the MN may auto-assign its HoA > >> > > > > or requests one. (cf. > >> > > > > draft-ietf-mip6-bootstrapping-split-02.txt) > >> > > > > > >> > > > > If it wants to auto-assign its HoA, it has 2 possibilities: > >> > > > > > >> > > > > 1/ It autoassignes its HoA and includes it in the CFG_REQUEST > >> > > > > (INTERNAL_IP6_ADDRESS)i in the first IKE_AUTH message. > >> > > > > If the HA is ok, it replies with the CFG_REPLY > >> > > > > with the same address. > >> > > > > > >> > > > > 2/ The MN asks for the Home Prefix (CFG_REQUEST with > >> > > > > MIP6_HOME_PREFIX). The HA sends the Home prefix in the > >> CFG_REPLY. > >> > > > > Then > >> > > > > the MN uses a CREATE_CHILD_SA. > >> > > > > > >> > > > > This raises some questions: > >> > > > > > >> > > > > 1/ Do we consider that it is the HA which decides if the MN > >> > > > > is authorized to configure its HoA (policy configuration at > >> > > > > the HA) ? or do we consider that it is a per-MN policy and > >> > > > > thus that the HA should request that to the MSA ? > >> > > > > >> > > > Imho both.. depends on operator's deployment. > >> > > > >> > > if we want both. This implies that the mip6-authz process occurs > >> during > >> > > the EAP authentication process (probably when the HA receives the > >> > > result of the EAP authentication from the AAAH). > >> > > > >> > > >> > This is needed only for autoconfiguration. But autoconfiguration has > >> > been introduced in mip6-split for rfc3041 addresses and CGAs. Do we > >> > want the AAA to decide if theMN can use CGA? I'm not sure this is the > >> > case. > >> > > >> > I think what is important from an operator perspective is that the > >> > address may be allocated by either AAA or HA. However, to get this, we > >> > do not need to start mip6-authz during EAP exchange, since it is a > >> > generic IKEv2 address assignment issue and not a MIP specific one. > >> > > >> > --Gerardo > >> > > >> > > I'm also in favor of that but then we have the issue raised by > >> gerardo > >> > > concerning the fact that the IKEv2 responder may play 2 roles (VPN > >> > > concentrator and HA). How do the IKEv2-R know that the MN wants to > >> use > >> > > mip6 ? > >> > > > >> > > > > >> > > > > If we consider that the MSA should decide this, as the HoA > >> > > > > is sent after the MN being authenticated by EAP. This > >> > > > > implies that the mip6-authz app should be used before this > >> > > > > last IKEv2 message. > >> > > > > > >> > > > > If the MN requests a HoA to the HA, we also have the following > >> > > > > question: > >> > > > > > >> > > > > 1/ do we allow the AAA server to allocate this address ? or > >> > > > > do we need an AVP to carry the HoA from the AAA to the HA ? > >> > > > > >> > > > I'm not entirely sure what the above is supposed to mean.. but > >> > > > imho again depending on the operator's deployment either HA or > >> > > > AAA should be able to allocate the HoA. > >> > > > >> > > I also agree with you. It also implies that the mip6-Authz App > >> should > >> > > be used during EAP authentication process. > >> > > > >> > > Julien > >> > > > >> > > > > >> > > > Cheers, > >> > > > Jouni > >> > > > > >> > > > > >> > > > > > >> > > > > regards, > >> > > > > > >> > > > > Julien > >> > > > > > >> > > > > > >> > > > > _______________________________________________ > >> > > > > DiME mailing list > >> > > > > DiME@ietf.org > >> > > > > https://www1.ietf.org/mailman/listinfo/dime > >> > > > > > >> > > > >> > > -- > >> > > julien.bournelle at int-evry.fr > >> > > > >> > > _______________________________________________ > >> > > 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 > >> > >> > >> "This email message and any attachments are confidential information > >> of Starent Networks, Corp. The information transmitted may not be > >> used to create or change any contractual obligations of Starent > >> Networks, Corp. Any review, retransmission, dissemination or other > >> use of, or taking of any action in reliance upon this e-mail and its > >> attachments by persons or entities other than the intended recipient > >> is prohibited. If you are not the intended recipient, please notify > >> the sender immediately -- by replying to this message or by sending > >> an email to postmaster@starentnetworks.com -- and destroy all copies > >> of this message and any attachments without reading or disclosing > >> their contents. Thank you." > >> > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > -- > ------------------------------------------------------ > Rafael Marin Lopez > Faculty of Computer Science-University of Murcia > 30071 Murcia - Spain > Telf: +34968367645 e-mail: rafa@dif.um.es > ------------------------------------------------------ > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 05 03:50:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVO0H-00076Z-20; Thu, 05 Oct 2006 03:50:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVO0F-00073Y-QD for dime@ietf.org; Thu, 05 Oct 2006 03:50:47 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVO0D-0002fl-64 for dime@ietf.org; Thu, 05 Oct 2006 03:50:47 -0400 Received: by ug-out-1314.google.com with SMTP id 72so146851ugd for ; Thu, 05 Oct 2006 00:50:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OkPU22Wr2k6yB8CVgSlO3/n0SD2mW98nT2lzLGjA6/wNORDDJN16kMN0WvTocuDByrzr/zYcfptzcu4qp8PwgY7wUv5bSS8DCVs0M5xX4K1TM0gISJgUG+yCmH2Lbg3pUVxnndGe2fjyyR0kiWp+XhUIx4ZgKmu7uhbarspaHMI= Received: by 10.67.100.12 with SMTP id c12mr1580265ugm; Thu, 05 Oct 2006 00:50:44 -0700 (PDT) Received: by 10.66.237.2 with HTTP; Thu, 5 Oct 2006 00:50:43 -0700 (PDT) Message-ID: Date: Thu, 5 Oct 2006 09:50:43 +0200 From: "Gerardo Giaretta" To: "Chowdhury, Kuntal" Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation considerations In-Reply-To: <7CCD07160348804497EF29E9EA5560D7FBD32D$0001@exchtewks2.starentnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7CCD07160348804497EF29E9EA5560D7FBD32D$0001@exchtewks2.starentnetworks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb 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 Kuntal, > I am not sure why we are bringing scenarios that are outside the scope > of MIP6. In MIP6 IPsec/IKEv2 happens between the MN and the HA. PDG/VPN > etc. are outside the scope of what we are defining here i.e. HA-HAAA > Diameter interface, IMHO. > Indeed I just asked the question: do we all agree that the we can assume the HA acts only as HA and not as any other IKEv2 responder? I think that from a deployment perspective there may be cases where the IKEv2 responder may be a HA but also a VPN server. But if everybody agrees to restrict the case where the HA acts just as HA, I may be fine with that. I'm just raising a possible deployment issue. --Gerardo > -Kuntal > > > > -----Original Message----- > > From: Rafa Marin Lopez [mailto:rafa@dif.um.es] > > Sent: Wednesday, October 04, 2006 1:14 PM > > To: Gerardo Giaretta > > Cc: dime@ietf.org > > Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation > > considerations > > > > Hi Gerardo, > > > > > > > > My original thought was that the MIP6 Authorization Application can > be > > > started and used at the reception of the first BU since it is from > > > that moment that the MN begins using MIP6 service. Based on this > > > consideration, I'm wondering if we can leave the HoA assignment to > the > > > Diameter EAP part, but this seems not so clean. > > > > But in that case, you are already receiving MIP6 authorization > > information within Diameter EAP... correct? > > > > > > > > The other issue is that the IKEv2 responder may be a HA, but may be > > > also a combined HA/PDG/VPN concentrator. Are we assuming that the > > > IKEv2 responder acts only as HA? If so, the MIPv6 authorization > > > application can start during IKEv2 exchange. But if not, how the > IKEv2 > > > responder (i.e. HA/PDG/ VPN concentrator) knows that the user is a > MIP > > > user or not? > > > > I have a question: is the assumption here that HA/PDG/VPN may need to > > ask authorization about different services (e.g. VPN parameters or/and > > MIP6 parameters) depending on MN requires? > > > > Another question: how would HA/PDG/VPN know it has to use RFC 4072 > with > > AUTHENTICATE_ONLY for MIP6 service? > > Initially, it looks that the a simple answer would be that HA/PDG/VPN > is > > configured to send AUTHENTICATE_ONLY no matter the service. > > > > Thanks. > > > > > > > > --Gerardo > > > > > > On 10/4/06, Chowdhury, Kuntal > wrote: > > > > > >> Hi Gerardo, > > >> > > >> Regarding your comment: > > >> > > >> > I think what is important from an operator perspective is that > the > > >> > address may be allocated by either AAA or HA. However, to get > this, > > we > > >> > do not need to start mip6-authz during EAP exchange, since it is > a > > >> > generic IKEv2 address assignment issue and not a MIP specific > one. > > >> > > >> I think it is important to verify whether the user is allowed to > use a > > >> particular HoA. For example, the user may intentionally or > accidentally > > >> set the INTERNAL_IP6_ADDRESS to someone else's statically assigned > HoA. > > >> The HA may not keep track of the statically assigned HoAs of all > the > > >> users belonging to an MSA. If the HA does not verify with the MSA > (AAA) > > >> the user will get an address which actually belongs to someone > else. > > >> > > >> To circumvent the problem, in some deployments the prefix that can > be > > >> used to auto-configure HoAs by MNs is kept separate from the ones > used > > >> for static HoA assignment. The HA should have this knowledge either > via > > >> local config or via AAA transaction. > > >> > > >> -Kuntal > > >> > > >> > > >> > -----Original Message----- > > >> > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > >> > Sent: Wednesday, October 04, 2006 7:23 AM > > >> > To: Julien Bournelle > > >> > Cc: dime@ietf.org > > >> > Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation > > >> > considerations > > >> > > > >> > Hi Julien and Jouni, > > >> > > > >> > > > > However, we also have to consider the Home-Address (HoA) > > >> > > > > allocation. As you may know the MN may auto-assign its HoA > > >> > > > > or requests one. (cf. > > >> > > > > draft-ietf-mip6-bootstrapping-split-02.txt) > > >> > > > > > > >> > > > > If it wants to auto-assign its HoA, it has 2 > possibilities: > > >> > > > > > > >> > > > > 1/ It autoassignes its HoA and includes it in the > CFG_REQUEST > > >> > > > > (INTERNAL_IP6_ADDRESS)i in the first IKE_AUTH message. > > >> > > > > If the HA is ok, it replies with the CFG_REPLY > > >> > > > > with the same address. > > >> > > > > > > >> > > > > 2/ The MN asks for the Home Prefix (CFG_REQUEST with > > >> > > > > MIP6_HOME_PREFIX). The HA sends the Home prefix in the > > >> CFG_REPLY. > > >> > > > > Then > > >> > > > > the MN uses a CREATE_CHILD_SA. > > >> > > > > > > >> > > > > This raises some questions: > > >> > > > > > > >> > > > > 1/ Do we consider that it is the HA which decides if the > MN > > >> > > > > is authorized to configure its HoA (policy configuration > at > > >> > > > > the HA) ? or do we consider that it is a per-MN policy and > > >> > > > > thus that the HA should request that to the MSA ? > > >> > > > > > >> > > > Imho both.. depends on operator's deployment. > > >> > > > > >> > > if we want both. This implies that the mip6-authz process > occurs > > >> during > > >> > > the EAP authentication process (probably when the HA receives > the > > >> > > result of the EAP authentication from the AAAH). > > >> > > > > >> > > > >> > This is needed only for autoconfiguration. But autoconfiguration > has > > >> > been introduced in mip6-split for rfc3041 addresses and CGAs. Do > we > > >> > want the AAA to decide if theMN can use CGA? I'm not sure this is > the > > >> > case. > > >> > > > >> > I think what is important from an operator perspective is that > the > > >> > address may be allocated by either AAA or HA. However, to get > this, > > we > > >> > do not need to start mip6-authz during EAP exchange, since it is > a > > >> > generic IKEv2 address assignment issue and not a MIP specific > one. > > >> > > > >> > --Gerardo > > >> > > > >> > > I'm also in favor of that but then we have the issue raised by > > >> gerardo > > >> > > concerning the fact that the IKEv2 responder may play 2 roles > (VPN > > >> > > concentrator and HA). How do the IKEv2-R know that the MN > wants to > > >> use > > >> > > mip6 ? > > >> > > > > >> > > > > > >> > > > > If we consider that the MSA should decide this, as the HoA > > >> > > > > is sent after the MN being authenticated by EAP. This > > >> > > > > implies that the mip6-authz app should be used before this > > >> > > > > last IKEv2 message. > > >> > > > > > > >> > > > > If the MN requests a HoA to the HA, we also have the > following > > >> > > > > question: > > >> > > > > > > >> > > > > 1/ do we allow the AAA server to allocate this address ? > or > > >> > > > > do we need an AVP to carry the HoA from the AAA to the HA > ? > > >> > > > > > >> > > > I'm not entirely sure what the above is supposed to mean.. > but > > >> > > > imho again depending on the operator's deployment either HA > or > > >> > > > AAA should be able to allocate the HoA. > > >> > > > > >> > > I also agree with you. It also implies that the mip6-Authz App > > >> should > > >> > > be used during EAP authentication process. > > >> > > > > >> > > Julien > > >> > > > > >> > > > > > >> > > > Cheers, > > >> > > > Jouni > > >> > > > > > >> > > > > > >> > > > > > > >> > > > > regards, > > >> > > > > > > >> > > > > Julien > > >> > > > > > > >> > > > > > > >> > > > > _______________________________________________ > > >> > > > > DiME mailing list > > >> > > > > DiME@ietf.org > > >> > > > > https://www1.ietf.org/mailman/listinfo/dime > > >> > > > > > > >> > > > > >> > > -- > > >> > > julien.bournelle at int-evry.fr > > >> > > > > >> > > _______________________________________________ > > >> > > 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 > > >> > > >> > > >> "This email message and any attachments are confidential > information > > >> of Starent Networks, Corp. The information transmitted may not be > > >> used to create or change any contractual obligations of Starent > > >> Networks, Corp. Any review, retransmission, dissemination or other > > >> use of, or taking of any action in reliance upon this e-mail and > its > > >> attachments by persons or entities other than the intended > recipient > > >> is prohibited. If you are not the intended recipient, please notify > > >> the sender immediately -- by replying to this message or by sending > > >> an email to postmaster@starentnetworks.com -- and destroy all > copies > > >> of this message and any attachments without reading or disclosing > > >> their contents. Thank you." > > >> > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > -- > > ------------------------------------------------------ > > Rafael Marin Lopez > > Faculty of Computer Science-University of Murcia > > 30071 Murcia - Spain > > Telf: +34968367645 e-mail: rafa@dif.um.es > > ------------------------------------------------------ > > > > > > _______________________________________________ > > 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 Oct 05 06:50:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVQnz-0005Db-0m; Thu, 05 Oct 2006 06:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVQny-0005CA-DV for dime@ietf.org; Thu, 05 Oct 2006 06:50:18 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVQnx-00062y-OV for dime@ietf.org; Thu, 05 Oct 2006 06:50:18 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 61E832FE03; Thu, 5 Oct 2006 12:50:11 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GVQpv-0006nj-TS; Thu, 05 Oct 2006 12:52:19 +0200 Date: Thu, 5 Oct 2006 12:52:19 +0200 From: Julien Bournelle To: Madjid Nakhjiri Subject: Re: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) Message-ID: <20061005105219.GA26139@ipv6-3.int-evry.fr> References: <20061004094128.GA23345@ipv6-3.int-evry.fr> <001601c6e80d$0bec6b20$2f01a8c0@huawei6cc10c70> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001601c6e80d$0bec6b20$2f01a8c0@huawei6cc10c70> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.8 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 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 madjid, On Wed, Oct 04, 2006 at 04:30:12PM -0700, Madjid Nakhjiri wrote: > > that's indeed a good question. At this point of time, I thought that > in the mip6-authz messages, we didn't need sort of "authz token". > I thought that the authentication process was implicit for the AAA-MIP6 > Authz server and that finally it was the HA which basically need to be > sure that the MN is authenticated. > > Madjid>>Traditionally, the authorization token is not an absolute > necessity, as long as there is a proof of a previous authentication and as > long as there is profile info in the MSP AAA server on the MN. However, > "authorization token" would provide a clean separation of authorization and > authentication. I say this because I have seen talk about having different > MIP6 and EAP servers on this list. yes. as we are defining a new App for the Authz, the AAA-EAP and AAA-MIP6 may be different servers. But, from my point of view, as we are decoupling Authentication from the Authorization/Accounting process, the AAA-MIP6 does not need to authenticate again the MN. The HA is reponsible of this and it does so with 4072. > > so my question: can't the AAA-MIP6 authz server assume that the MN has > been authenticated while receiving an authz request ? > > Madjid>>When it comes to security, you cannot assume anything:) If the > process depends on a previous authentication, then a proof of a previous > authentication needs to be provided. well. I'm not sure about that. Basically, it is the HA which needs to ensure that the MN is correctly authenticated. The AAA-MIP6 is here just to check the profile. what do other think ? > This could either be a key resulted > from a previous authentication signing the authorization request, or an > authorization token, IMO. > The other question I have after reading the split scenario doc is that you > guys are saying bootstrapping of some of MIP6 info (such as HoA) is done as > part of IKEv2 signaling. How can you then separate a Diameter MIP6 > authorization from the IKEv2 authentication? the HA uses both 4072 and the Authz Application during the IKEv2 exchange. > > > The MN identity used MIP6 may or may not be the same as that used in a > > previous EAP, especially in split scenario, so it seems that in split > > scenario you run two EAPs, one with MN ASP ID and one with MN MSP ID. When > > you produce a separate authorization spec ("Diameter MIP6 spec" separate > > from "Diameter EAP spec"), you need make sure that > > > > 1) MN uses the same ID during EAP and during MIP6? > > Concerning Identity used in the MIP6 Authz process, we have two > options: > > 1/ The HA uses the Identity provided in the IDi field during the > IKE_AUTH phase. In this case, the identity will be the same than the > one provided with the Diameter EAP Application. > > Madjid>>This could work, as long as the MSP AAA server recognizes the MN > with the same ID that the EAP server. Again, we need to very careful in > writing the spec, so that we avoid dependency of MIP6 spec on EAP spec, or > feasibility of MIP solution on a prior EAP run. That is why providing proof > for authentication or an authorization token is important, this way you know > what ID has been used before. > I still have the question as before: how do you do MIP6 HoA bootstrapping if > authn and authz are separated? do I answer to your question above ? > > 2/ The HA uses something provided in the BU. In this case, it implies > that the mip6-authz application is used after the whole EAP > authentication process. This may not be possible if we want to do > authorization of HoA allocation (cf. my thread on this subject). > > Madjid>>Yes, if the identity used during authz is different from that during > authn, then you have potential for identity fraud. > > > 2) even if it does, the MN's ID the MN is using is authenticated? There > must > > be a proof of a previous authentication. Just saying MN has run EAP before > > it is not enough. When you are separating Diameter MIP spec and Diameter > EAP > > spec and taking authentication out, then the MIP spec needs to specify how > > the MN provides proof that it has run a previous EAP (or another > > authentication method) by probably signing its MIP6 authorization request > > with a key that was generated during a previous EAP or authentication. > > Otherwise, there is no way to know that the MN has actually been > > authenticated, meaning it is very difficult to separate authorization from > > authorization. > > well, as noted below, I tend to think that the Authz server doesn't > need a proof that the MN has been authenticated. The Authz server > could trust the HA for this. > > Madjid>> You seem to be making assumptions about HA here, i.e. HA knows > about the previous EAP and knows MN with that same identity. that's not a big assumption :). > If this is > true, then the HA may have been provided with some info (a key or a token) > from the EAP/AAA server and then the HA can use that knowledge with the > MSP/AAA to show that MN has been authenticated. I don't see how.. the AAA-MIP6 is not aware of this key. Julien > > R, > > Madjid > > Julien > > > Having said that I am hesitant to state that support option 2 as well. > > And yes, Update of 4072 should not affect update of MIP6 application. > > > > Diameter MIP6 application needs to stand on its own and if it is going to > > only define authorization and accounting and rely on a previous > > authentication, then it must be independent of whether the authentication > is > > EAP or something else. We are not here to just solve a specific > optimization > > problem... > > > > My two rusty (late) pennies, > > > > Regards, > > > > Madjid > > > > > > -----Original Message----- > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > Sent: Friday, September 15, 2006 3:21 AM > > To: dime@ietf.org > > Subject: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) > > > > Hi all, > > > > this is a new polling concerning the ha-aaah interface for the Mobile > > IPv6 Boostrapping. To date, at the previous one, there was a > > consensus on moving forward with a new App-ID. But, yoshi has > > proposed an interesting idea that should be considered by the WG. > > > > As you may recall, in the ha-aaah case, the MN is authenticated by > > EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH > > interface must, at least, be able to carry EAP packets. It appears that > > we now have 2 options: > > > > (1) We define a new Diameter application for Mobile IPv6 with a new > > App-ID that carry EAP packets as it is done in RFC 4072 (Diameter > > EAP) but Authorization and Accouting is specific to Mobile IPv6 > > (thus the need for a new App-ID). The risk, as noted by yoshi, is > > that an update of the RFC4072 may result in an update of this > > application. > > > > > > (2) We define a new Diameter Application for Mobile IPv6 but which is > > used for Authorization and Accounting. We continue to use > > Diameter EAP for the Authentication. Thus the HA will use > > Diameter EAP with the AVP Auth-Request-Type set to > > AUTHENTICATE_ONLY and then the HA will use this MIP6 Application > > for Authorization/Accounting of the Mobile IPv6 service. This new > > application will have its own App-ID. > > > > This would avoid to update the application if 4072 is updated and > > this could be a way to proceed if other applications need EAP for > > Authentication but have different needs for the Authorization and > > Accounting part. > > > > Please indicate wether you prefer (1) or (2). > > > > As in the previous polling: > > - it might be useful to state a reason for your decision. > > - indicate wether some aspects are still unclear to you. > > > > Regards, > > > > Julien > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > -- > julien.bournelle at int-evry.fr > > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 05 08:09:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVS2f-0004bo-A3; Thu, 05 Oct 2006 08:09:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVS2e-0004bg-Hz for dime@ietf.org; Thu, 05 Oct 2006 08:09:32 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVS2S-0002Kb-GX for dime@ietf.org; Thu, 05 Oct 2006 08:09:32 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k95C94TZ024117; Thu, 5 Oct 2006 21:09:04 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k95C95XG011780; Thu, 5 Oct 2006 21:09:05 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with ESMTP id XAA11779; Thu, 5 Oct 2006 21:09:05 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k95C93Wh005886; Thu, 5 Oct 2006 21:09:03 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k95C93Em015636; Thu, 5 Oct 2006 21:09:03 +0900 (JST) Received: from steelhead ([133.199.17.7]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J6N00AYYWEVHBF0@mail.po.toshiba.co.jp>; Thu, 05 Oct 2006 21:09:03 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GVRp0-0005Xc-SE; Thu, 05 Oct 2006 04:55:26 -0700 Date: Thu, 05 Oct 2006 07:55:26 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) In-reply-to: <001601c6e80d$0bec6b20$2f01a8c0@huawei6cc10c70> To: Madjid Nakhjiri Message-id: <20061005115526.GA20850@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20061004094128.GA23345@ipv6-3.int-evry.fr> <001601c6e80d$0bec6b20$2f01a8c0@huawei6cc10c70> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.8 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 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 Madjid, You are making a very good point. I agree with you that "authorization token" will make the architecture of separating authentication and authorization securer. I can imagine that this can be easily achived based on: the AAA client requests the authentication server to sign information that indicates that a particular MN was authenticated by the server via a particular NAS at a certain data and time using the server's public key and the authentication server returns the signed information back to the AAA client. The AAA client can then present the signed information to the authorization server as a proof of successful authentication of the MN by the authentication server. On the other hand, we can discuss whether this securer mechanism should be mandatory or optional. I prefer making such a mechanism optional because AAA clients, authentication server and authorization server are fairly trusted entities with each other in a particular deployment. Yoshihiro Ohba On Wed, Oct 04, 2006 at 04:30:12PM -0700, Madjid Nakhjiri wrote: > Hi Julien, > > Snip > > > Yes, a Mobility service provider and its AAA server should look at the MN > > and its service profile to see if it is authorized to use MIP6 service and > > how it is supposed to pay for it. But we need to figure out what > > "authorization credentials" to be used for this authorization. Now this > > includes > > 1) something that securely identifies the MN (this includes proof of > > authentication) > > 2) something that proves MN's right to MIP6 service, i.e. an authorization > > token or indication to a profile that the AAA server of MSP has of MN that > > shows MN should have MIP6 service. > > > > If you are separating authorization spec from authentication spec, then > both > > of these need to be included in the authorization spec. > > that's indeed a good question. At this point of time, I thought that > in the mip6-authz messages, we didn't need sort of "authz token". > I thought that the authentication process was implicit for the AAA-MIP6 > Authz server and that finally it was the HA which basically need to be > sure that the MN is authenticated. > > Madjid>>Traditionally, the authorization token is not an absolute > necessity, as long as there is a proof of a previous authentication and as > long as there is profile info in the MSP AAA server on the MN. However, > "authorization token" would provide a clean separation of authorization and > authentication. I say this because I have seen talk about having different > MIP6 and EAP servers on this list. > > so my question: can't the AAA-MIP6 authz server assume that the MN has > been authenticated while receiving an authz request ? > > Madjid>>When it comes to security, you cannot assume anything:) If the > process depends on a previous authentication, then a proof of a previous > authentication needs to be provided. This could either be a key resulted > from a previous authentication signing the authorization request, or an > authorization token, IMO. > The other question I have after reading the split scenario doc is that you > guys are saying bootstrapping of some of MIP6 info (such as HoA) is done as > part of IKEv2 signaling. How can you then separate a Diameter MIP6 > authorization from the IKEv2 authentication? > > > The MN identity used MIP6 may or may not be the same as that used in a > > previous EAP, especially in split scenario, so it seems that in split > > scenario you run two EAPs, one with MN ASP ID and one with MN MSP ID. When > > you produce a separate authorization spec ("Diameter MIP6 spec" separate > > from "Diameter EAP spec"), you need make sure that > > > > 1) MN uses the same ID during EAP and during MIP6? > > Concerning Identity used in the MIP6 Authz process, we have two > options: > > 1/ The HA uses the Identity provided in the IDi field during the > IKE_AUTH phase. In this case, the identity will be the same than the > one provided with the Diameter EAP Application. > > Madjid>>This could work, as long as the MSP AAA server recognizes the MN > with the same ID that the EAP server. Again, we need to very careful in > writing the spec, so that we avoid dependency of MIP6 spec on EAP spec, or > feasibility of MIP solution on a prior EAP run. That is why providing proof > for authentication or an authorization token is important, this way you know > what ID has been used before. > I still have the question as before: how do you do MIP6 HoA bootstrapping if > authn and authz are separated? > > 2/ The HA uses something provided in the BU. In this case, it implies > that the mip6-authz application is used after the whole EAP > authentication process. This may not be possible if we want to do > authorization of HoA allocation (cf. my thread on this subject). > > Madjid>>Yes, if the identity used during authz is different from that during > authn, then you have potential for identity fraud. > > > 2) even if it does, the MN's ID the MN is using is authenticated? There > must > > be a proof of a previous authentication. Just saying MN has run EAP before > > it is not enough. When you are separating Diameter MIP spec and Diameter > EAP > > spec and taking authentication out, then the MIP spec needs to specify how > > the MN provides proof that it has run a previous EAP (or another > > authentication method) by probably signing its MIP6 authorization request > > with a key that was generated during a previous EAP or authentication. > > Otherwise, there is no way to know that the MN has actually been > > authenticated, meaning it is very difficult to separate authorization from > > authorization. > > well, as noted below, I tend to think that the Authz server doesn't > need a proof that the MN has been authenticated. The Authz server > could trust the HA for this. > > Madjid>> You seem to be making assumptions about HA here, i.e. HA knows > about the previous EAP and knows MN with that same identity. If this is > true, then the HA may have been provided with some info (a key or a token) > from the EAP/AAA server and then the HA can use that knowledge with the > MSP/AAA to show that MN has been authenticated. > > R, > > Madjid > > Julien > > > Having said that I am hesitant to state that support option 2 as well. > > And yes, Update of 4072 should not affect update of MIP6 application. > > > > Diameter MIP6 application needs to stand on its own and if it is going to > > only define authorization and accounting and rely on a previous > > authentication, then it must be independent of whether the authentication > is > > EAP or something else. We are not here to just solve a specific > optimization > > problem... > > > > My two rusty (late) pennies, > > > > Regards, > > > > Madjid > > > > > > -----Original Message----- > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > Sent: Friday, September 15, 2006 3:21 AM > > To: dime@ietf.org > > Subject: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) > > > > Hi all, > > > > this is a new polling concerning the ha-aaah interface for the Mobile > > IPv6 Boostrapping. To date, at the previous one, there was a > > consensus on moving forward with a new App-ID. But, yoshi has > > proposed an interesting idea that should be considered by the WG. > > > > As you may recall, in the ha-aaah case, the MN is authenticated by > > EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH > > interface must, at least, be able to carry EAP packets. It appears that > > we now have 2 options: > > > > (1) We define a new Diameter application for Mobile IPv6 with a new > > App-ID that carry EAP packets as it is done in RFC 4072 (Diameter > > EAP) but Authorization and Accouting is specific to Mobile IPv6 > > (thus the need for a new App-ID). The risk, as noted by yoshi, is > > that an update of the RFC4072 may result in an update of this > > application. > > > > > > (2) We define a new Diameter Application for Mobile IPv6 but which is > > used for Authorization and Accounting. We continue to use > > Diameter EAP for the Authentication. Thus the HA will use > > Diameter EAP with the AVP Auth-Request-Type set to > > AUTHENTICATE_ONLY and then the HA will use this MIP6 Application > > for Authorization/Accounting of the Mobile IPv6 service. This new > > application will have its own App-ID. > > > > This would avoid to update the application if 4072 is updated and > > this could be a way to proceed if other applications need EAP for > > Authentication but have different needs for the Authorization and > > Accounting part. > > > > Please indicate wether you prefer (1) or (2). > > > > As in the previous polling: > > - it might be useful to state a reason for your decision. > > - indicate wether some aspects are still unclear to you. > > > > Regards, > > > > Julien > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > -- > julien.bournelle at int-evry.fr > > > > _______________________________________________ > 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 Oct 05 08:48:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVSe1-0004WD-N5; Thu, 05 Oct 2006 08:48:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVSe1-0004W8-70 for dime@ietf.org; Thu, 05 Oct 2006 08:48:09 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVSdz-0005hI-Ex for dime@ietf.org; Thu, 05 Oct 2006 08:48:09 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 7143F2FE6B; Thu, 5 Oct 2006 14:48:00 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GVSfw-0006oj-SM; Thu, 05 Oct 2006 14:50:08 +0200 Date: Thu, 5 Oct 2006 14:50:08 +0200 From: Julien Bournelle To: Yoshihiro Ohba Subject: Re: [Dime] HA-AAAH case: auth. token ? Message-ID: <20061005125008.GA26201@ipv6-3.int-evry.fr> References: <20061004094128.GA23345@ipv6-3.int-evry.fr> <001601c6e80d$0bec6b20$2f01a8c0@huawei6cc10c70> <20061005115526.GA20850@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061005115526.GA20850@steelhead> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.8 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 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 yoshi, On Thu, Oct 05, 2006 at 07:55:26AM -0400, Yoshihiro Ohba wrote: > > Hi Madjid, > > You are making a very good point. I agree with you that > "authorization token" will make the architecture of separating > authentication and authorization securer. I can imagine that this can > be easily achived based on: the AAA client requests the authentication > server to sign information that indicates that a particular MN was > authenticated by the server via a particular NAS at a certain data and > time using the server's public key and the authentication server > returns the signed information back to the AAA client. The AAA client > can then present the signed information to the authorization server as > a proof of successful authentication of the MN by the authentication > server. > > On the other hand, we can discuss whether this securer mechanism > should be mandatory or optional. I prefer making such a mechanism > optional because AAA clients, authentication server and authorization > server are fairly trusted entities with each other in a particular > deployment. I think that if we want such a mechanism, it should be better to define it in another document because it is would be a general mechanism that could be used by other authorization application. what do you think ? Julien > > Yoshihiro Ohba > > > On Wed, Oct 04, 2006 at 04:30:12PM -0700, Madjid Nakhjiri wrote: > > Hi Julien, > > > > Snip > > > > > Yes, a Mobility service provider and its AAA server should look at the MN > > > and its service profile to see if it is authorized to use MIP6 service and > > > how it is supposed to pay for it. But we need to figure out what > > > "authorization credentials" to be used for this authorization. Now this > > > includes > > > 1) something that securely identifies the MN (this includes proof of > > > authentication) > > > 2) something that proves MN's right to MIP6 service, i.e. an authorization > > > token or indication to a profile that the AAA server of MSP has of MN that > > > shows MN should have MIP6 service. > > > > > > If you are separating authorization spec from authentication spec, then > > both > > > of these need to be included in the authorization spec. > > > > that's indeed a good question. At this point of time, I thought that > > in the mip6-authz messages, we didn't need sort of "authz token". > > I thought that the authentication process was implicit for the AAA-MIP6 > > Authz server and that finally it was the HA which basically need to be > > sure that the MN is authenticated. > > > > Madjid>>Traditionally, the authorization token is not an absolute > > necessity, as long as there is a proof of a previous authentication and as > > long as there is profile info in the MSP AAA server on the MN. However, > > "authorization token" would provide a clean separation of authorization and > > authentication. I say this because I have seen talk about having different > > MIP6 and EAP servers on this list. > > > > so my question: can't the AAA-MIP6 authz server assume that the MN has > > been authenticated while receiving an authz request ? > > > > Madjid>>When it comes to security, you cannot assume anything:) If the > > process depends on a previous authentication, then a proof of a previous > > authentication needs to be provided. This could either be a key resulted > > from a previous authentication signing the authorization request, or an > > authorization token, IMO. > > The other question I have after reading the split scenario doc is that you > > guys are saying bootstrapping of some of MIP6 info (such as HoA) is done as > > part of IKEv2 signaling. How can you then separate a Diameter MIP6 > > authorization from the IKEv2 authentication? > > > > > The MN identity used MIP6 may or may not be the same as that used in a > > > previous EAP, especially in split scenario, so it seems that in split > > > scenario you run two EAPs, one with MN ASP ID and one with MN MSP ID. When > > > you produce a separate authorization spec ("Diameter MIP6 spec" separate > > > from "Diameter EAP spec"), you need make sure that > > > > > > 1) MN uses the same ID during EAP and during MIP6? > > > > Concerning Identity used in the MIP6 Authz process, we have two > > options: > > > > 1/ The HA uses the Identity provided in the IDi field during the > > IKE_AUTH phase. In this case, the identity will be the same than the > > one provided with the Diameter EAP Application. > > > > Madjid>>This could work, as long as the MSP AAA server recognizes the MN > > with the same ID that the EAP server. Again, we need to very careful in > > writing the spec, so that we avoid dependency of MIP6 spec on EAP spec, or > > feasibility of MIP solution on a prior EAP run. That is why providing proof > > for authentication or an authorization token is important, this way you know > > what ID has been used before. > > I still have the question as before: how do you do MIP6 HoA bootstrapping if > > authn and authz are separated? > > > > 2/ The HA uses something provided in the BU. In this case, it implies > > that the mip6-authz application is used after the whole EAP > > authentication process. This may not be possible if we want to do > > authorization of HoA allocation (cf. my thread on this subject). > > > > Madjid>>Yes, if the identity used during authz is different from that during > > authn, then you have potential for identity fraud. > > > > > 2) even if it does, the MN's ID the MN is using is authenticated? There > > must > > > be a proof of a previous authentication. Just saying MN has run EAP before > > > it is not enough. When you are separating Diameter MIP spec and Diameter > > EAP > > > spec and taking authentication out, then the MIP spec needs to specify how > > > the MN provides proof that it has run a previous EAP (or another > > > authentication method) by probably signing its MIP6 authorization request > > > with a key that was generated during a previous EAP or authentication. > > > Otherwise, there is no way to know that the MN has actually been > > > authenticated, meaning it is very difficult to separate authorization from > > > authorization. > > > > well, as noted below, I tend to think that the Authz server doesn't > > need a proof that the MN has been authenticated. The Authz server > > could trust the HA for this. > > > > Madjid>> You seem to be making assumptions about HA here, i.e. HA knows > > about the previous EAP and knows MN with that same identity. If this is > > true, then the HA may have been provided with some info (a key or a token) > > from the EAP/AAA server and then the HA can use that knowledge with the > > MSP/AAA to show that MN has been authenticated. > > > > R, > > > > Madjid > > > > Julien > > > > > Having said that I am hesitant to state that support option 2 as well. > > > And yes, Update of 4072 should not affect update of MIP6 application. > > > > > > Diameter MIP6 application needs to stand on its own and if it is going to > > > only define authorization and accounting and rely on a previous > > > authentication, then it must be independent of whether the authentication > > is > > > EAP or something else. We are not here to just solve a specific > > optimization > > > problem... > > > > > > My two rusty (late) pennies, > > > > > > Regards, > > > > > > Madjid > > > > > > > > > -----Original Message----- > > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > > Sent: Friday, September 15, 2006 3:21 AM > > > To: dime@ietf.org > > > Subject: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) > > > > > > Hi all, > > > > > > this is a new polling concerning the ha-aaah interface for the Mobile > > > IPv6 Boostrapping. To date, at the previous one, there was a > > > consensus on moving forward with a new App-ID. But, yoshi has > > > proposed an interesting idea that should be considered by the WG. > > > > > > As you may recall, in the ha-aaah case, the MN is authenticated by > > > EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH > > > interface must, at least, be able to carry EAP packets. It appears that > > > we now have 2 options: > > > > > > (1) We define a new Diameter application for Mobile IPv6 with a new > > > App-ID that carry EAP packets as it is done in RFC 4072 (Diameter > > > EAP) but Authorization and Accouting is specific to Mobile IPv6 > > > (thus the need for a new App-ID). The risk, as noted by yoshi, is > > > that an update of the RFC4072 may result in an update of this > > > application. > > > > > > > > > (2) We define a new Diameter Application for Mobile IPv6 but which is > > > used for Authorization and Accounting. We continue to use > > > Diameter EAP for the Authentication. Thus the HA will use > > > Diameter EAP with the AVP Auth-Request-Type set to > > > AUTHENTICATE_ONLY and then the HA will use this MIP6 Application > > > for Authorization/Accounting of the Mobile IPv6 service. This new > > > application will have its own App-ID. > > > > > > This would avoid to update the application if 4072 is updated and > > > this could be a way to proceed if other applications need EAP for > > > Authentication but have different needs for the Authorization and > > > Accounting part. > > > > > > Please indicate wether you prefer (1) or (2). > > > > > > As in the previous polling: > > > - it might be useful to state a reason for your decision. > > > - indicate wether some aspects are still unclear to you. > > > > > > Regards, > > > > > > Julien > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > -- > > julien.bournelle at int-evry.fr > > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 05 10:05:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVTrG-0003Q8-8L; Thu, 05 Oct 2006 10:05:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVTrE-0003Pt-Pc for dime@ietf.org; Thu, 05 Oct 2006 10:05:53 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVTrB-0007P5-Mb for dime@ietf.org; Thu, 05 Oct 2006 10:05:52 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id D816523CD00; Thu, 5 Oct 2006 16:05:48 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19358-01-14; Thu, 5 Oct 2006 16:05:48 +0200 (CEST) Received: from [207.3.232.120] (unknown [207.3.232.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id 5AE5C23CCEB; Thu, 5 Oct 2006 16:05:45 +0200 (CEST) Message-ID: <452510EB.3060109@dif.um.es> Date: Thu, 05 Oct 2006 10:04:27 -0400 From: Rafa Marin Lopez Organization: University of Murcia User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julien Bournelle Subject: Re: [Dime] HA-AAAH case: auth. token ? References: <20061004094128.GA23345@ipv6-3.int-evry.fr> <001601c6e80d$0bec6b20$2f01a8c0@huawei6cc10c70> <20061005115526.GA20850@steelhead> <20061005125008.GA26201@ipv6-3.int-evry.fr> In-Reply-To: <20061005125008.GA26201@ipv6-3.int-evry.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.8 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 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 Julien, all I agree with all of you that having a "authentication token" may be a way to "bind" that authentication with the authorization. However, Julien made a good point: I don't think this mechanism is exclusive to MIP6 authz because it can be generally used when authorization and authentication are separately done (typically with two AAA servers). My 2 cents. Julien Bournelle wrote: >Hi yoshi, > >On Thu, Oct 05, 2006 at 07:55:26AM -0400, Yoshihiro Ohba wrote: > > >>Hi Madjid, >> >>You are making a very good point. I agree with you that >>"authorization token" will make the architecture of separating >>authentication and authorization securer. I can imagine that this can >>be easily achived based on: the AAA client requests the authentication >>server to sign information that indicates that a particular MN was >>authenticated by the server via a particular NAS at a certain data and >>time using the server's public key and the authentication server >>returns the signed information back to the AAA client. The AAA client >>can then present the signed information to the authorization server as >>a proof of successful authentication of the MN by the authentication >>server. >> >>On the other hand, we can discuss whether this securer mechanism >>should be mandatory or optional. I prefer making such a mechanism >>optional because AAA clients, authentication server and authorization >>server are fairly trusted entities with each other in a particular >>deployment. >> >> > > I think that if > we want such a mechanism, it should be better to define it in another > document because it is would be a general mechanism that could be used > by other authorization application. > > what do you think ? > > Julien > > > >>Yoshihiro Ohba >> >> >>On Wed, Oct 04, 2006 at 04:30:12PM -0700, Madjid Nakhjiri wrote: >> >> >>>Hi Julien, >>> >>>Snip >>> >>> >>> >>>>Yes, a Mobility service provider and its AAA server should look at the MN >>>>and its service profile to see if it is authorized to use MIP6 service and >>>>how it is supposed to pay for it. But we need to figure out what >>>>"authorization credentials" to be used for this authorization. Now this >>>>includes >>>>1) something that securely identifies the MN (this includes proof of >>>>authentication) >>>>2) something that proves MN's right to MIP6 service, i.e. an authorization >>>>token or indication to a profile that the AAA server of MSP has of MN that >>>>shows MN should have MIP6 service. >>>> >>>>If you are separating authorization spec from authentication spec, then >>>> >>>> >>>both >>> >>> >>>>of these need to be included in the authorization spec. >>>> >>>> >>> that's indeed a good question. At this point of time, I thought that >>> in the mip6-authz messages, we didn't need sort of "authz token". >>> I thought that the authentication process was implicit for the AAA-MIP6 >>> Authz server and that finally it was the HA which basically need to be >>> sure that the MN is authenticated. >>> >>> Madjid>>Traditionally, the authorization token is not an absolute >>>necessity, as long as there is a proof of a previous authentication and as >>>long as there is profile info in the MSP AAA server on the MN. However, >>>"authorization token" would provide a clean separation of authorization and >>>authentication. I say this because I have seen talk about having different >>>MIP6 and EAP servers on this list. >>> >>>so my question: can't the AAA-MIP6 authz server assume that the MN has >>> been authenticated while receiving an authz request ? >>> >>>Madjid>>When it comes to security, you cannot assume anything:) If the >>>process depends on a previous authentication, then a proof of a previous >>>authentication needs to be provided. This could either be a key resulted >>>from a previous authentication signing the authorization request, or an >>>authorization token, IMO. >>>The other question I have after reading the split scenario doc is that you >>>guys are saying bootstrapping of some of MIP6 info (such as HoA) is done as >>>part of IKEv2 signaling. How can you then separate a Diameter MIP6 >>>authorization from the IKEv2 authentication? >>> >>> >>> >>>>The MN identity used MIP6 may or may not be the same as that used in a >>>>previous EAP, especially in split scenario, so it seems that in split >>>>scenario you run two EAPs, one with MN ASP ID and one with MN MSP ID. When >>>>you produce a separate authorization spec ("Diameter MIP6 spec" separate >>>>from "Diameter EAP spec"), you need make sure that >>>> >>>>1) MN uses the same ID during EAP and during MIP6? >>>> >>>> >>> Concerning Identity used in the MIP6 Authz process, we have two >>> options: >>> >>> 1/ The HA uses the Identity provided in the IDi field during the >>> IKE_AUTH phase. In this case, the identity will be the same than the >>> one provided with the Diameter EAP Application. >>> >>>Madjid>>This could work, as long as the MSP AAA server recognizes the MN >>>with the same ID that the EAP server. Again, we need to very careful in >>>writing the spec, so that we avoid dependency of MIP6 spec on EAP spec, or >>>feasibility of MIP solution on a prior EAP run. That is why providing proof >>>for authentication or an authorization token is important, this way you know >>>what ID has been used before. >>>I still have the question as before: how do you do MIP6 HoA bootstrapping if >>>authn and authz are separated? >>> >>> 2/ The HA uses something provided in the BU. In this case, it implies >>> that the mip6-authz application is used after the whole EAP >>> authentication process. This may not be possible if we want to do >>> authorization of HoA allocation (cf. my thread on this subject). >>> >>>Madjid>>Yes, if the identity used during authz is different from that during >>>authn, then you have potential for identity fraud. >>> >>> >>> >>>>2) even if it does, the MN's ID the MN is using is authenticated? There >>>> >>>> >>>must >>> >>> >>>>be a proof of a previous authentication. Just saying MN has run EAP before >>>>it is not enough. When you are separating Diameter MIP spec and Diameter >>>> >>>> >>>EAP >>> >>> >>>>spec and taking authentication out, then the MIP spec needs to specify how >>>>the MN provides proof that it has run a previous EAP (or another >>>>authentication method) by probably signing its MIP6 authorization request >>>>with a key that was generated during a previous EAP or authentication. >>>>Otherwise, there is no way to know that the MN has actually been >>>>authenticated, meaning it is very difficult to separate authorization from >>>>authorization. >>>> >>>> >>> well, as noted below, I tend to think that the Authz server doesn't >>> need a proof that the MN has been authenticated. The Authz server >>> could trust the HA for this. >>> >>>Madjid>> You seem to be making assumptions about HA here, i.e. HA knows >>>about the previous EAP and knows MN with that same identity. If this is >>>true, then the HA may have been provided with some info (a key or a token) >>>from the EAP/AAA server and then the HA can use that knowledge with the >>>MSP/AAA to show that MN has been authenticated. >>> >>>R, >>> >>>Madjid >>> >>> Julien >>> >>> >>> >>>>Having said that I am hesitant to state that support option 2 as well. >>>>And yes, Update of 4072 should not affect update of MIP6 application. >>>> >>>>Diameter MIP6 application needs to stand on its own and if it is going to >>>>only define authorization and accounting and rely on a previous >>>>authentication, then it must be independent of whether the authentication >>>> >>>> >>>is >>> >>> >>>>EAP or something else. We are not here to just solve a specific >>>> >>>> >>>optimization >>> >>> >>>>problem... >>>> >>>>My two rusty (late) pennies, >>>> >>>>Regards, >>>> >>>>Madjid >>>> >>>> >>>>-----Original Message----- >>>>From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] >>>>Sent: Friday, September 15, 2006 3:21 AM >>>>To: dime@ietf.org >>>>Subject: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) >>>> >>>>Hi all, >>>> >>>> this is a new polling concerning the ha-aaah interface for the Mobile >>>> IPv6 Boostrapping. To date, at the previous one, there was a >>>> consensus on moving forward with a new App-ID. But, yoshi has >>>> proposed an interesting idea that should be considered by the WG. >>>> >>>> As you may recall, in the ha-aaah case, the MN is authenticated by >>>> EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH >>>> interface must, at least, be able to carry EAP packets. It appears that >>>> we now have 2 options: >>>> >>>> (1) We define a new Diameter application for Mobile IPv6 with a new >>>> App-ID that carry EAP packets as it is done in RFC 4072 (Diameter >>>> EAP) but Authorization and Accouting is specific to Mobile IPv6 >>>> (thus the need for a new App-ID). The risk, as noted by yoshi, is >>>> that an update of the RFC4072 may result in an update of this >>>> application. >>>> >>>> >>>> (2) We define a new Diameter Application for Mobile IPv6 but which is >>>> used for Authorization and Accounting. We continue to use >>>> Diameter EAP for the Authentication. Thus the HA will use >>>> Diameter EAP with the AVP Auth-Request-Type set to >>>> AUTHENTICATE_ONLY and then the HA will use this MIP6 Application >>>> for Authorization/Accounting of the Mobile IPv6 service. This new >>>> application will have its own App-ID. >>>> >>>> This would avoid to update the application if 4072 is updated and >>>> this could be a way to proceed if other applications need EAP for >>>> Authentication but have different needs for the Authorization and >>>> Accounting part. >>>> >>>> Please indicate wether you prefer (1) or (2). >>>> >>>> As in the previous polling: >>>> - it might be useful to state a reason for your decision. >>>> - indicate wether some aspects are still unclear to you. >>>> >>>> Regards, >>>> >>>> Julien >>>> >>>>_______________________________________________ >>>>DiME mailing list >>>>DiME@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/dime >>>> >>>> >>>> >>>> >>>-- >>>julien.bournelle at int-evry.fr >>> >>> >>> >>>_______________________________________________ >>>DiME mailing list >>>DiME@ietf.org >>>https://www1.ietf.org/mailman/listinfo/dime >>> >>> >>> > > > -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 05 12:50:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVWQc-0002Mv-LW; Thu, 05 Oct 2006 12:50:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVWQZ-0002Jp-Ih for dime@ietf.org; Thu, 05 Oct 2006 12:50:31 -0400 Received: from maile.telecomitalia.it ([156.54.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVWQX-0006E5-Rd for dime@ietf.org; Thu, 05 Oct 2006 12:50:31 -0400 Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 18:50:28 +0200 Received: from PTPEVS108BA020.idc.cww.telecomitalia.it ([156.54.241.228]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 18:50:28 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Content-Class: urn:content-classes:message Importance: normal Priority: normal MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: R: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) Date: Thu, 5 Oct 2006 18:50:27 +0200 Message-ID: In-Reply-To: <003b01c6e745$78525860$2f01a8c0@huawei6cc10c70> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) thread-index: AcbYsPVsF8W5Nk2QSWSGWbgq91kDTwOj4qdQAFR4HSA= From: "La Monaca Michele" To: X-OriginalArrivalTime: 05 Oct 2006 16:50:28.0268 (UTC) FILETIME=[5C9986C0:01C6E89E] X-Spam-Score: 0.8 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 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 Madjid, all, I'm quite new to this topic so forgive if my comments (in line) are = misapplied. > -----Messaggio originale----- > Da: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com] > Inviato: mercoled=EC 4 ottobre 2006 1.42 > A: 'Julien Bournelle'; dime@ietf.org > Oggetto: RE: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling = part 2) >=20 > Hi Julien, >=20 > Sorry for responding late. I was making a point to go through all = email up > to this point. >=20 > I definitely do not support option 1, since it does not make sense to = make > MIP6 application depend on EAP application, first due to the spaghetti > application design process it creates, and second due to the fact that = we > don't want to bind people to use EAP for MIP6 authentication. >=20 > Now to option 2, it is great that you are considering authorization = and > authorization credentials as a separate matter than authentication. = The > industry for years has failed to make that distinction. However, the = current > option 2 is not strong from security and AAA design. >=20 > Yes, a Mobility service provider and its AAA server should look at the = MN > and its service profile to see if it is authorized to use MIP6 service = and > how it is supposed to pay for it. But we need to figure out what > "authorization credentials" to be used for this authorization. Now = this > includes > 1) something that securely identifies the MN (this includes proof of > authentication) > 2) something that proves MN's right to MIP6 service, i.e. an = authorization > token or indication to a profile that the AAA server of MSP has of MN = that > shows MN should have MIP6 service. >=20 > If you are separating authorization spec from authentication spec, = then both > of these need to be included in the authorization spec. >=20 > The MN identity used MIP6 may or may not be the same as that used in a > previous EAP, especially in split scenario, so it seems that in split > scenario you run two EAPs, one with MN ASP ID and one with MN MSP ID.=20 > When you produce a separate authorization spec ("Diameter MIP6 spec" = separate > from "Diameter EAP spec"), you need make sure that > > 1) MN uses the same ID during EAP and during MIP6? My understanding is that four (possibly) different MN's identities are = involved: 1) EAP access ID --> known only by AAAH (integrated scenario) 2) IKEv2 IDi --> known by AAAH and HA 3) EAP mip6 (outer) ID --> known by AAAH and HA 4) EAP mip6 (inner) ID --> known only by AAAH Requisites: - in an integrated scenario AAAH should be able to correlate 1) and 3) = if different (but this is up to the AAAH, not our problem) - the IDi provided by the MN must contain a valid @DOMAIN info since it = is used to contact the right AAAH for the authentication, but we cannot = count on this ID to uniquely identify a specific user between HA and = AAAH, since the user part may be neither meaningful nor unique (e.g. = FAKE_ID_BY_MN@DOMAIN) - 4) is the only option I foresee to uniquely identify a specific user = between HA and AAAH since HA could build a NAI like this = UNIQUE_ID_BY_HA!FAKE_ID_BY_MN@DOMAIN for the EAP Response ID - Then AAAH can easily bind UNIQUE_ID_BY_HA!FAKE_ID_BY_MN@DOMAIN ID = provided by the HA with the EAP mip6 (inner) ID provided by the MN > 2) even if it does, the MN's ID the MN is using is authenticated? = There must > be a proof of a previous authentication. Just saying MN has run EAP = before > it is not enough.=20 > When you are separating Diameter MIP spec and Diameter EAP > spec and taking authentication out, then the MIP spec needs to specify = how > the MN provides proof that it has run a previous EAP (or another > authentication method) by probably signing its MIP6 authorization = request > with a key that was generated during a previous EAP or authentication. > Otherwise, there is no way to know that the MN has actually been > authenticated, meaning it is very difficult to separate authorization = from > authorization. After the EAPoIKEv2 authentication, MN is implicitly authenticated since = it holds an IPSec SA with the HA.=20 My 2 cents, --Michele > Having said that I am hesitant to state that support option 2 as well. > And yes, Update of 4072 should not affect update of MIP6 application. >=20 > Diameter MIP6 application needs to stand on its own and if it is going = to > only define authorization and accounting and rely on a previous > authentication, then it must be independent of whether the = authentication is > EAP or something else. We are not here to just solve a specific = optimization > problem... >=20 > My two rusty (late) pennies, >=20 > Regards, >=20 > Madjid >=20 >=20 > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > Sent: Friday, September 15, 2006 3:21 AM > To: dime@ietf.org > Subject: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part = 2) >=20 > Hi all, >=20 > this is a new polling concerning the ha-aaah interface for the Mobile > IPv6 Boostrapping. To date, at the previous one, there was a > consensus on moving forward with a new App-ID. But, yoshi has > proposed an interesting idea that should be considered by the WG. >=20 > As you may recall, in the ha-aaah case, the MN is authenticated by > EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH > interface must, at least, be able to carry EAP packets. It appears = that > we now have 2 options: >=20 > (1) We define a new Diameter application for Mobile IPv6 with a new > App-ID that carry EAP packets as it is done in RFC 4072 (Diameter > EAP) but Authorization and Accouting is specific to Mobile IPv6 > (thus the need for a new App-ID). The risk, as noted by yoshi, is > that an update of the RFC4072 may result in an update of this > application. >=20 >=20 > (2) We define a new Diameter Application for Mobile IPv6 but which is > used for Authorization and Accounting. We continue to use > Diameter EAP for the Authentication. Thus the HA will use > Diameter EAP with the AVP Auth-Request-Type set to > AUTHENTICATE_ONLY and then the HA will use this MIP6 Application > for Authorization/Accounting of the Mobile IPv6 service. This new > application will have its own App-ID. >=20 > This would avoid to update the application if 4072 is updated and > this could be a way to proceed if other applications need EAP for > Authentication but have different needs for the Authorization and > Accounting part. >=20 > Please indicate wether you prefer (1) or (2). >=20 > As in the previous polling: > - it might be useful to state a reason for your decision. > - indicate wether some aspects are still unclear to you. >=20 > Regards, >=20 > Julien >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 05 19:01:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVcD5-00054h-66; Thu, 05 Oct 2006 19:00:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVcD4-00054P-3r for dime@ietf.org; Thu, 05 Oct 2006 19:00:58 -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 1GVcD2-0006HM-8z for dime@ietf.org; Thu, 05 Oct 2006 19:00:57 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k95N00U6010640; Thu, 5 Oct 2006 19:00:01 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Thu, 5 Oct 2006 19:00:04 -0400 To: Julien Bournelle Subject: Re: [Dime] HA-AAAH case: auth. token ? Message-ID: <20061005230004.GD30331@steelhead> References: <20061004094128.GA23345@ipv6-3.int-evry.fr> <001601c6e80d$0bec6b20$2f01a8c0@huawei6cc10c70> <20061005115526.GA20850@steelhead> <20061005125008.GA26201@ipv6-3.int-evry.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <20061005125008.GA26201@ipv6-3.int-evry.fr> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 246 X-Spam-Score: -1.6 (-) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 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 Julien, I agree with you that such a token mechanism (if needed) is better defined in a separate document. On the other hand, actual AVPs that are used for realizing the mechanism would need to be carried in each application and thus each application specification would need to have the AVPs in its ABNF. Regards, Yoshihiro Ohba On Thu, Oct 05, 2006 at 02:50:08PM +0200, Julien Bournelle wrote: > Hi yoshi, > > On Thu, Oct 05, 2006 at 07:55:26AM -0400, Yoshihiro Ohba wrote: > > > > Hi Madjid, > > > > You are making a very good point. I agree with you that > > "authorization token" will make the architecture of separating > > authentication and authorization securer. I can imagine that this can > > be easily achived based on: the AAA client requests the authentication > > server to sign information that indicates that a particular MN was > > authenticated by the server via a particular NAS at a certain data and > > time using the server's public key and the authentication server > > returns the signed information back to the AAA client. The AAA client > > can then present the signed information to the authorization server as > > a proof of successful authentication of the MN by the authentication > > server. > > > > On the other hand, we can discuss whether this securer mechanism > > should be mandatory or optional. I prefer making such a mechanism > > optional because AAA clients, authentication server and authorization > > server are fairly trusted entities with each other in a particular > > deployment. > > I think that if > we want such a mechanism, it should be better to define it in another > document because it is would be a general mechanism that could be used > by other authorization application. > > what do you think ? > > Julien > > > > > Yoshihiro Ohba > > > > > > On Wed, Oct 04, 2006 at 04:30:12PM -0700, Madjid Nakhjiri wrote: > > > Hi Julien, > > > > > > Snip > > > > > > > Yes, a Mobility service provider and its AAA server should look at the MN > > > > and its service profile to see if it is authorized to use MIP6 service and > > > > how it is supposed to pay for it. But we need to figure out what > > > > "authorization credentials" to be used for this authorization. Now this > > > > includes > > > > 1) something that securely identifies the MN (this includes proof of > > > > authentication) > > > > 2) something that proves MN's right to MIP6 service, i.e. an authorization > > > > token or indication to a profile that the AAA server of MSP has of MN that > > > > shows MN should have MIP6 service. > > > > > > > > If you are separating authorization spec from authentication spec, then > > > both > > > > of these need to be included in the authorization spec. > > > > > > that's indeed a good question. At this point of time, I thought that > > > in the mip6-authz messages, we didn't need sort of "authz token". > > > I thought that the authentication process was implicit for the AAA-MIP6 > > > Authz server and that finally it was the HA which basically need to be > > > sure that the MN is authenticated. > > > > > > Madjid>>Traditionally, the authorization token is not an absolute > > > necessity, as long as there is a proof of a previous authentication and as > > > long as there is profile info in the MSP AAA server on the MN. However, > > > "authorization token" would provide a clean separation of authorization and > > > authentication. I say this because I have seen talk about having different > > > MIP6 and EAP servers on this list. > > > > > > so my question: can't the AAA-MIP6 authz server assume that the MN has > > > been authenticated while receiving an authz request ? > > > > > > Madjid>>When it comes to security, you cannot assume anything:) If the > > > process depends on a previous authentication, then a proof of a previous > > > authentication needs to be provided. This could either be a key resulted > > > from a previous authentication signing the authorization request, or an > > > authorization token, IMO. > > > The other question I have after reading the split scenario doc is that you > > > guys are saying bootstrapping of some of MIP6 info (such as HoA) is done as > > > part of IKEv2 signaling. How can you then separate a Diameter MIP6 > > > authorization from the IKEv2 authentication? > > > > > > > The MN identity used MIP6 may or may not be the same as that used in a > > > > previous EAP, especially in split scenario, so it seems that in split > > > > scenario you run two EAPs, one with MN ASP ID and one with MN MSP ID. When > > > > you produce a separate authorization spec ("Diameter MIP6 spec" separate > > > > from "Diameter EAP spec"), you need make sure that > > > > > > > > 1) MN uses the same ID during EAP and during MIP6? > > > > > > Concerning Identity used in the MIP6 Authz process, we have two > > > options: > > > > > > 1/ The HA uses the Identity provided in the IDi field during the > > > IKE_AUTH phase. In this case, the identity will be the same than the > > > one provided with the Diameter EAP Application. > > > > > > Madjid>>This could work, as long as the MSP AAA server recognizes the MN > > > with the same ID that the EAP server. Again, we need to very careful in > > > writing the spec, so that we avoid dependency of MIP6 spec on EAP spec, or > > > feasibility of MIP solution on a prior EAP run. That is why providing proof > > > for authentication or an authorization token is important, this way you know > > > what ID has been used before. > > > I still have the question as before: how do you do MIP6 HoA bootstrapping if > > > authn and authz are separated? > > > > > > 2/ The HA uses something provided in the BU. In this case, it implies > > > that the mip6-authz application is used after the whole EAP > > > authentication process. This may not be possible if we want to do > > > authorization of HoA allocation (cf. my thread on this subject). > > > > > > Madjid>>Yes, if the identity used during authz is different from that during > > > authn, then you have potential for identity fraud. > > > > > > > 2) even if it does, the MN's ID the MN is using is authenticated? There > > > must > > > > be a proof of a previous authentication. Just saying MN has run EAP before > > > > it is not enough. When you are separating Diameter MIP spec and Diameter > > > EAP > > > > spec and taking authentication out, then the MIP spec needs to specify how > > > > the MN provides proof that it has run a previous EAP (or another > > > > authentication method) by probably signing its MIP6 authorization request > > > > with a key that was generated during a previous EAP or authentication. > > > > Otherwise, there is no way to know that the MN has actually been > > > > authenticated, meaning it is very difficult to separate authorization from > > > > authorization. > > > > > > well, as noted below, I tend to think that the Authz server doesn't > > > need a proof that the MN has been authenticated. The Authz server > > > could trust the HA for this. > > > > > > Madjid>> You seem to be making assumptions about HA here, i.e. HA knows > > > about the previous EAP and knows MN with that same identity. If this is > > > true, then the HA may have been provided with some info (a key or a token) > > > from the EAP/AAA server and then the HA can use that knowledge with the > > > MSP/AAA to show that MN has been authenticated. > > > > > > R, > > > > > > Madjid > > > > > > Julien > > > > > > > Having said that I am hesitant to state that support option 2 as well. > > > > And yes, Update of 4072 should not affect update of MIP6 application. > > > > > > > > Diameter MIP6 application needs to stand on its own and if it is going to > > > > only define authorization and accounting and rely on a previous > > > > authentication, then it must be independent of whether the authentication > > > is > > > > EAP or something else. We are not here to just solve a specific > > > optimization > > > > problem... > > > > > > > > My two rusty (late) pennies, > > > > > > > > Regards, > > > > > > > > Madjid > > > > > > > > > > > > -----Original Message----- > > > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > > > Sent: Friday, September 15, 2006 3:21 AM > > > > To: dime@ietf.org > > > > Subject: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) > > > > > > > > Hi all, > > > > > > > > this is a new polling concerning the ha-aaah interface for the Mobile > > > > IPv6 Boostrapping. To date, at the previous one, there was a > > > > consensus on moving forward with a new App-ID. But, yoshi has > > > > proposed an interesting idea that should be considered by the WG. > > > > > > > > As you may recall, in the ha-aaah case, the MN is authenticated by > > > > EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH > > > > interface must, at least, be able to carry EAP packets. It appears that > > > > we now have 2 options: > > > > > > > > (1) We define a new Diameter application for Mobile IPv6 with a new > > > > App-ID that carry EAP packets as it is done in RFC 4072 (Diameter > > > > EAP) but Authorization and Accouting is specific to Mobile IPv6 > > > > (thus the need for a new App-ID). The risk, as noted by yoshi, is > > > > that an update of the RFC4072 may result in an update of this > > > > application. > > > > > > > > > > > > (2) We define a new Diameter Application for Mobile IPv6 but which is > > > > used for Authorization and Accounting. We continue to use > > > > Diameter EAP for the Authentication. Thus the HA will use > > > > Diameter EAP with the AVP Auth-Request-Type set to > > > > AUTHENTICATE_ONLY and then the HA will use this MIP6 Application > > > > for Authorization/Accounting of the Mobile IPv6 service. This new > > > > application will have its own App-ID. > > > > > > > > This would avoid to update the application if 4072 is updated and > > > > this could be a way to proceed if other applications need EAP for > > > > Authentication but have different needs for the Authorization and > > > > Accounting part. > > > > > > > > Please indicate wether you prefer (1) or (2). > > > > > > > > As in the previous polling: > > > > - it might be useful to state a reason for your decision. > > > > - indicate wether some aspects are still unclear to you. > > > > > > > > Regards, > > > > > > > > Julien > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > -- > > > julien.bournelle at int-evry.fr > > > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > -- > julien.bournelle at int-evry.fr > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 05 20:28:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVdZJ-0001ty-8v; Thu, 05 Oct 2006 20:28:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVdZI-0001tt-TH for dime@ietf.org; Thu, 05 Oct 2006 20:28:00 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVdZG-0001qY-IM for dime@ietf.org; Thu, 05 Oct 2006 20:28:00 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6O000GGUH709@usaga01-in.huawei.com> for dime@ietf.org; Thu, 05 Oct 2006 17:24:43 -0700 (PDT) Received: from huawei6cc10c70 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J6O00EJYUH3BV@usaga01-in.huawei.com> for dime@ietf.org; Thu, 05 Oct 2006 17:24:43 -0700 (PDT) Date: Thu, 05 Oct 2006 17:27:43 -0700 From: Madjid Nakhjiri Subject: RE: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) In-reply-to: <20061005105219.GA26139@ipv6-3.int-evry.fr> To: 'Julien Bournelle' Message-id: <004101c6e8de$3daefde0$2f01a8c0@huawei6cc10c70> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbobKbZICyVEmB2QbOcEfP9pOwUeQAbKXfg X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 -----Original Message----- From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] Sent: Thursday, October 05, 2006 3:52 AM To: Madjid Nakhjiri Cc: 'Julien Bournelle'; dime@ietf.org Subject: Re: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) Hi madjid, On Wed, Oct 04, 2006 at 04:30:12PM -0700, Madjid Nakhjiri wrote: > > that's indeed a good question. At this point of time, I thought that > in the mip6-authz messages, we didn't need sort of "authz token". > I thought that the authentication process was implicit for the AAA-MIP6 > Authz server and that finally it was the HA which basically need to be > sure that the MN is authenticated. > > Madjid>>Traditionally, the authorization token is not an absolute > necessity, as long as there is a proof of a previous authentication and as > long as there is profile info in the MSP AAA server on the MN. However, > "authorization token" would provide a clean separation of authorization and > authentication. I say this because I have seen talk about having different > MIP6 and EAP servers on this list. yes. as we are defining a new App for the Authz, the AAA-EAP and AAA-MIP6 may be different servers. But, from my point of view, as we are decoupling Authentication from the Authorization/Accounting process, the AAA-MIP6 does not need to authenticate again the MN. The HA is reponsible of this and it does so with 4072. Madjid>>Ok, so the ongoing assumption is that AAA-MIP6 can be different from AAA-EAP, and AAA-MIP6 is an authorization server that can authorize MN with the ID the MN has presented to the HA and to the AAA_EAP. And the AAA-MIP6 trusts that the MN has authenticated through the HA. So the trust of MN is transitive. This is a security consideration, see below. > > so my question: can't the AAA-MIP6 authz server assume that the MN has > been authenticated while receiving an authz request ? > > Madjid>>When it comes to security, you cannot assume anything:) If the > process depends on a previous authentication, then a proof of a previous > authentication needs to be provided. well. I'm not sure about that. Basically, it is the HA which needs to ensure that the MN is correctly authenticated. The AAA-MIP6 is here just to check the profile. what do other think ? Madjid>>So you are saying HA is fully trusted by AAA-MIP6? So AAA-MIP6 takes HA's word for MN having been authenticated and if MN ends up not paying its bill because HA lied or was compromised, then this should be covered in the security consideration, then... > This could either be a key resulted > from a previous authentication signing the authorization request, or an > authorization token, IMO. > The other question I have after reading the split scenario doc is that you > guys are saying bootstrapping of some of MIP6 info (such as HoA) is done as > part of IKEv2 signaling. How can you then separate a Diameter MIP6 > authorization from the IKEv2 authentication? the HA uses both 4072 and the Authz Application during the IKEv2 exchange. Madjid>>Ok, I guess the devil is in the details at this point:) Are you saying some of the MIP6 bootstrapping (IKEv2 PSK for an MN-HA IPsec SA? And HoA) is done during 4072? I will have to read some more.. . > > well, as noted below, I tend to think that the Authz server doesn't > need a proof that the MN has been authenticated. The Authz server > could trust the HA for this. > > Madjid>> You seem to be making assumptions about HA here, i.e. HA knows > about the previous EAP and knows MN with that same identity. that's not a big assumption :). Madjid>>Ok, I guess I was mixing split and integrated scenarios. Julien _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 05 20:42:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVdmq-0001b3-RY; Thu, 05 Oct 2006 20:42:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVdmp-0001as-F6 for dime@ietf.org; Thu, 05 Oct 2006 20:41:59 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVdmo-0004ws-TE for dime@ietf.org; Thu, 05 Oct 2006 20:41:59 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6O0008RV4T09@usaga01-in.huawei.com> for dime@ietf.org; Thu, 05 Oct 2006 17:38:53 -0700 (PDT) Received: from huawei6cc10c70 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J6O00JLIV4OS6@usaga01-in.huawei.com> for dime@ietf.org; Thu, 05 Oct 2006 17:38:53 -0700 (PDT) Date: Thu, 05 Oct 2006 17:41:52 -0700 From: Madjid Nakhjiri Subject: RE: [Dime] HA-AAAH case: auth. token ? In-reply-to: <20061005125008.GA26201@ipv6-3.int-evry.fr> To: 'Julien Bournelle' , 'Yoshihiro Ohba' Message-id: <004301c6e8e0$37f0e3d0$2f01a8c0@huawei6cc10c70> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbofRi55mmd+FRaReGmvRh7z5I+NAAYti6g X-Spam-Score: 0.8 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad 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 I think we should be aware of the security implications and once the design is done, if there are security considerations, assess whether they are tolerable or not, If they are, cover those in the related sections. If they are not, solve the issue, which would be mandatory (otherwise the issue would have been tolerable:) ) Madjid -----Original Message----- From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] Sent: Thursday, October 05, 2006 5:50 AM To: Yoshihiro Ohba Cc: Madjid Nakhjiri; 'Julien Bournelle'; dime@ietf.org Subject: Re: [Dime] HA-AAAH case: auth. token ? Hi yoshi, On Thu, Oct 05, 2006 at 07:55:26AM -0400, Yoshihiro Ohba wrote: > > Hi Madjid, > > You are making a very good point. I agree with you that > "authorization token" will make the architecture of separating > authentication and authorization securer. I can imagine that this can > be easily achived based on: the AAA client requests the authentication > server to sign information that indicates that a particular MN was > authenticated by the server via a particular NAS at a certain data and > time using the server's public key and the authentication server > returns the signed information back to the AAA client. The AAA client > can then present the signed information to the authorization server as > a proof of successful authentication of the MN by the authentication > server. > > On the other hand, we can discuss whether this securer mechanism > should be mandatory or optional. I prefer making such a mechanism > optional because AAA clients, authentication server and authorization > server are fairly trusted entities with each other in a particular > deployment. I think that if we want such a mechanism, it should be better to define it in another document because it is would be a general mechanism that could be used by other authorization application. what do you think ? Julien > > Yoshihiro Ohba > > > On Wed, Oct 04, 2006 at 04:30:12PM -0700, Madjid Nakhjiri wrote: > > Hi Julien, > > > > Snip > > > > > Yes, a Mobility service provider and its AAA server should look at the MN > > > and its service profile to see if it is authorized to use MIP6 service and > > > how it is supposed to pay for it. But we need to figure out what > > > "authorization credentials" to be used for this authorization. Now this > > > includes > > > 1) something that securely identifies the MN (this includes proof of > > > authentication) > > > 2) something that proves MN's right to MIP6 service, i.e. an authorization > > > token or indication to a profile that the AAA server of MSP has of MN that > > > shows MN should have MIP6 service. > > > > > > If you are separating authorization spec from authentication spec, then > > both > > > of these need to be included in the authorization spec. > > > > that's indeed a good question. At this point of time, I thought that > > in the mip6-authz messages, we didn't need sort of "authz token". > > I thought that the authentication process was implicit for the AAA-MIP6 > > Authz server and that finally it was the HA which basically need to be > > sure that the MN is authenticated. > > > > Madjid>>Traditionally, the authorization token is not an absolute > > necessity, as long as there is a proof of a previous authentication and as > > long as there is profile info in the MSP AAA server on the MN. However, > > "authorization token" would provide a clean separation of authorization and > > authentication. I say this because I have seen talk about having different > > MIP6 and EAP servers on this list. > > > > so my question: can't the AAA-MIP6 authz server assume that the MN has > > been authenticated while receiving an authz request ? > > > > Madjid>>When it comes to security, you cannot assume anything:) If the > > process depends on a previous authentication, then a proof of a previous > > authentication needs to be provided. This could either be a key resulted > > from a previous authentication signing the authorization request, or an > > authorization token, IMO. > > The other question I have after reading the split scenario doc is that you > > guys are saying bootstrapping of some of MIP6 info (such as HoA) is done as > > part of IKEv2 signaling. How can you then separate a Diameter MIP6 > > authorization from the IKEv2 authentication? > > > > > The MN identity used MIP6 may or may not be the same as that used in a > > > previous EAP, especially in split scenario, so it seems that in split > > > scenario you run two EAPs, one with MN ASP ID and one with MN MSP ID. When > > > you produce a separate authorization spec ("Diameter MIP6 spec" separate > > > from "Diameter EAP spec"), you need make sure that > > > > > > 1) MN uses the same ID during EAP and during MIP6? > > > > Concerning Identity used in the MIP6 Authz process, we have two > > options: > > > > 1/ The HA uses the Identity provided in the IDi field during the > > IKE_AUTH phase. In this case, the identity will be the same than the > > one provided with the Diameter EAP Application. > > > > Madjid>>This could work, as long as the MSP AAA server recognizes the MN > > with the same ID that the EAP server. Again, we need to very careful in > > writing the spec, so that we avoid dependency of MIP6 spec on EAP spec, or > > feasibility of MIP solution on a prior EAP run. That is why providing proof > > for authentication or an authorization token is important, this way you know > > what ID has been used before. > > I still have the question as before: how do you do MIP6 HoA bootstrapping if > > authn and authz are separated? > > > > 2/ The HA uses something provided in the BU. In this case, it implies > > that the mip6-authz application is used after the whole EAP > > authentication process. This may not be possible if we want to do > > authorization of HoA allocation (cf. my thread on this subject). > > > > Madjid>>Yes, if the identity used during authz is different from that during > > authn, then you have potential for identity fraud. > > > > > 2) even if it does, the MN's ID the MN is using is authenticated? There > > must > > > be a proof of a previous authentication. Just saying MN has run EAP before > > > it is not enough. When you are separating Diameter MIP spec and Diameter > > EAP > > > spec and taking authentication out, then the MIP spec needs to specify how > > > the MN provides proof that it has run a previous EAP (or another > > > authentication method) by probably signing its MIP6 authorization request > > > with a key that was generated during a previous EAP or authentication. > > > Otherwise, there is no way to know that the MN has actually been > > > authenticated, meaning it is very difficult to separate authorization from > > > authorization. > > > > well, as noted below, I tend to think that the Authz server doesn't > > need a proof that the MN has been authenticated. The Authz server > > could trust the HA for this. > > > > Madjid>> You seem to be making assumptions about HA here, i.e. HA knows > > about the previous EAP and knows MN with that same identity. If this is > > true, then the HA may have been provided with some info (a key or a token) > > from the EAP/AAA server and then the HA can use that knowledge with the > > MSP/AAA to show that MN has been authenticated. > > > > R, > > > > Madjid > > > > Julien > > > > > Having said that I am hesitant to state that support option 2 as well. > > > And yes, Update of 4072 should not affect update of MIP6 application. > > > > > > Diameter MIP6 application needs to stand on its own and if it is going to > > > only define authorization and accounting and rely on a previous > > > authentication, then it must be independent of whether the authentication > > is > > > EAP or something else. We are not here to just solve a specific > > optimization > > > problem... > > > > > > My two rusty (late) pennies, > > > > > > Regards, > > > > > > Madjid > > > > > > > > > -----Original Message----- > > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > > Sent: Friday, September 15, 2006 3:21 AM > > > To: dime@ietf.org > > > Subject: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) > > > > > > Hi all, > > > > > > this is a new polling concerning the ha-aaah interface for the Mobile > > > IPv6 Boostrapping. To date, at the previous one, there was a > > > consensus on moving forward with a new App-ID. But, yoshi has > > > proposed an interesting idea that should be considered by the WG. > > > > > > As you may recall, in the ha-aaah case, the MN is authenticated by > > > EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH > > > interface must, at least, be able to carry EAP packets. It appears that > > > we now have 2 options: > > > > > > (1) We define a new Diameter application for Mobile IPv6 with a new > > > App-ID that carry EAP packets as it is done in RFC 4072 (Diameter > > > EAP) but Authorization and Accouting is specific to Mobile IPv6 > > > (thus the need for a new App-ID). The risk, as noted by yoshi, is > > > that an update of the RFC4072 may result in an update of this > > > application. > > > > > > > > > (2) We define a new Diameter Application for Mobile IPv6 but which is > > > used for Authorization and Accounting. We continue to use > > > Diameter EAP for the Authentication. Thus the HA will use > > > Diameter EAP with the AVP Auth-Request-Type set to > > > AUTHENTICATE_ONLY and then the HA will use this MIP6 Application > > > for Authorization/Accounting of the Mobile IPv6 service. This new > > > application will have its own App-ID. > > > > > > This would avoid to update the application if 4072 is updated and > > > this could be a way to proceed if other applications need EAP for > > > Authentication but have different needs for the Authorization and > > > Accounting part. > > > > > > Please indicate wether you prefer (1) or (2). > > > > > > As in the previous polling: > > > - it might be useful to state a reason for your decision. > > > - indicate wether some aspects are still unclear to you. > > > > > > Regards, > > > > > > Julien > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > -- > > julien.bournelle at int-evry.fr > > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 06 00:38:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVhTS-0001h6-FD; Fri, 06 Oct 2006 00:38:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVhTR-0001gx-Lo for dime@ietf.org; Fri, 06 Oct 2006 00:38:13 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVhTR-0005xg-1E for dime@ietf.org; Fri, 06 Oct 2006 00:38:13 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 5D53690029 for ; Fri, 6 Oct 2006 00:38:09 -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 25737-08 for ; Fri, 6 Oct 2006 00:38:08 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 6 Oct 2006 00:38:08 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 00:38:08 -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] HA-to-AAAH support/When ? HoA allocation considerations Date: Fri, 6 Oct 2006 00:38:07 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD34C@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] HA-to-AAAH support/When ? HoA allocation considerations Thread-Index: AcboUvisDWFx1kKgTSyfy9aEA/8wJgArZ+JQ From: "Chowdhury, Kuntal" To: "Gerardo Giaretta" X-OriginalArrivalTime: 06 Oct 2006 04:38:08.0011 (UTC) FILETIME=[389425B0:01C6E901] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae 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, I understand the deployment scenario that you have in mind. Collocation of a VPN gateway with the HA is an implementation issue, albeit quite possible. I think IKEv2 exchange with a VPN/PDG is more related to NAS-HAAA interface where the VPN/PDG is acting as the NAS. Mip6 related parameters could be downloaded to the VPN/PDG (NAS) in such a case. -Kuntal > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Thursday, October 05, 2006 2:51 AM > To: Chowdhury, Kuntal > Cc: Rafa Marin Lopez; dime@ietf.org > Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation > considerations >=20 > Hi Kuntal, >=20 > > I am not sure why we are bringing scenarios that are outside the scope > > of MIP6. In MIP6 IPsec/IKEv2 happens between the MN and the HA. PDG/VPN > > etc. are outside the scope of what we are defining here i.e. HA-HAAA > > Diameter interface, IMHO. > > >=20 > Indeed I just asked the question: do we all agree that the we can > assume the HA acts only as HA and not as any other IKEv2 responder? >=20 > I think that from a deployment perspective there may be cases where > the IKEv2 responder may be a HA but also a VPN server. But if > everybody agrees to restrict the case where the HA acts just as HA, I > may be fine with that. I'm just raising a possible deployment issue. >=20 > --Gerardo >=20 >=20 > > -Kuntal > > > > > > > -----Original Message----- > > > From: Rafa Marin Lopez [mailto:rafa@dif.um.es] > > > Sent: Wednesday, October 04, 2006 1:14 PM > > > To: Gerardo Giaretta > > > Cc: dime@ietf.org > > > Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation > > > considerations > > > > > > Hi Gerardo, > > > > > > > > > > > My original thought was that the MIP6 Authorization Application can > > be > > > > started and used at the reception of the first BU since it is from > > > > that moment that the MN begins using MIP6 service. Based on this > > > > consideration, I'm wondering if we can leave the HoA assignment to > > the > > > > Diameter EAP part, but this seems not so clean. > > > > > > But in that case, you are already receiving MIP6 authorization > > > information within Diameter EAP... correct? > > > > > > > > > > > The other issue is that the IKEv2 responder may be a HA, but may be > > > > also a combined HA/PDG/VPN concentrator. Are we assuming that the > > > > IKEv2 responder acts only as HA? If so, the MIPv6 authorization > > > > application can start during IKEv2 exchange. But if not, how the > > IKEv2 > > > > responder (i.e. HA/PDG/ VPN concentrator) knows that the user is a > > MIP > > > > user or not? > > > > > > I have a question: is the assumption here that HA/PDG/VPN may need to > > > ask authorization about different services (e.g. VPN parameters or/and > > > MIP6 parameters) depending on MN requires? > > > > > > Another question: how would HA/PDG/VPN know it has to use RFC 4072 > > with > > > AUTHENTICATE_ONLY for MIP6 service? > > > Initially, it looks that the a simple answer would be that HA/PDG/VPN > > is > > > configured to send AUTHENTICATE_ONLY no matter the service. > > > > > > Thanks. > > > > > > > > > > > --Gerardo > > > > > > > > On 10/4/06, Chowdhury, Kuntal > > wrote: > > > > > > > >> Hi Gerardo, > > > >> > > > >> Regarding your comment: > > > >> > > > >> > I think what is important from an operator perspective is that > > the > > > >> > address may be allocated by either AAA or HA. However, to get > > this, > > > we > > > >> > do not need to start mip6-authz during EAP exchange, since it is > > a > > > >> > generic IKEv2 address assignment issue and not a MIP specific > > one. > > > >> > > > >> I think it is important to verify whether the user is allowed to > > use a > > > >> particular HoA. For example, the user may intentionally or > > accidentally > > > >> set the INTERNAL_IP6_ADDRESS to someone else's statically assigned > > HoA. > > > >> The HA may not keep track of the statically assigned HoAs of all > > the > > > >> users belonging to an MSA. If the HA does not verify with the MSA > > (AAA) > > > >> the user will get an address which actually belongs to someone > > else. > > > >> > > > >> To circumvent the problem, in some deployments the prefix that can > > be > > > >> used to auto-configure HoAs by MNs is kept separate from the ones > > used > > > >> for static HoA assignment. The HA should have this knowledge either > > via > > > >> local config or via AAA transaction. > > > >> > > > >> -Kuntal > > > >> > > > >> > > > >> > -----Original Message----- > > > >> > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > >> > Sent: Wednesday, October 04, 2006 7:23 AM > > > >> > To: Julien Bournelle > > > >> > Cc: dime@ietf.org > > > >> > Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation > > > >> > considerations > > > >> > > > > >> > Hi Julien and Jouni, > > > >> > > > > >> > > > > However, we also have to consider the Home-Address (HoA) > > > >> > > > > allocation. As you may know the MN may auto-assign its HoA > > > >> > > > > or requests one. (cf. > > > >> > > > > draft-ietf-mip6-bootstrapping-split-02.txt) > > > >> > > > > > > > >> > > > > If it wants to auto-assign its HoA, it has 2 > > possibilities: > > > >> > > > > > > > >> > > > > 1/ It autoassignes its HoA and includes it in the > > CFG_REQUEST > > > >> > > > > (INTERNAL_IP6_ADDRESS)i in the first IKE_AUTH message. > > > >> > > > > If the HA is ok, it replies with the CFG_REPLY > > > >> > > > > with the same address. > > > >> > > > > > > > >> > > > > 2/ The MN asks for the Home Prefix (CFG_REQUEST with > > > >> > > > > MIP6_HOME_PREFIX). The HA sends the Home prefix in the > > > >> CFG_REPLY. > > > >> > > > > Then > > > >> > > > > the MN uses a CREATE_CHILD_SA. > > > >> > > > > > > > >> > > > > This raises some questions: > > > >> > > > > > > > >> > > > > 1/ Do we consider that it is the HA which decides if the > > MN > > > >> > > > > is authorized to configure its HoA (policy configuration > > at > > > >> > > > > the HA) ? or do we consider that it is a per-MN policy and > > > >> > > > > thus that the HA should request that to the MSA ? > > > >> > > > > > > >> > > > Imho both.. depends on operator's deployment. > > > >> > > > > > >> > > if we want both. This implies that the mip6-authz process > > occurs > > > >> during > > > >> > > the EAP authentication process (probably when the HA receives > > the > > > >> > > result of the EAP authentication from the AAAH). > > > >> > > > > > >> > > > > >> > This is needed only for autoconfiguration. But autoconfiguration > > has > > > >> > been introduced in mip6-split for rfc3041 addresses and CGAs. Do > > we > > > >> > want the AAA to decide if theMN can use CGA? I'm not sure this is > > the > > > >> > case. > > > >> > > > > >> > I think what is important from an operator perspective is that > > the > > > >> > address may be allocated by either AAA or HA. However, to get > > this, > > > we > > > >> > do not need to start mip6-authz during EAP exchange, since it is > > a > > > >> > generic IKEv2 address assignment issue and not a MIP specific > > one. > > > >> > > > > >> > --Gerardo > > > >> > > > > >> > > I'm also in favor of that but then we have the issue raised by > > > >> gerardo > > > >> > > concerning the fact that the IKEv2 responder may play 2 roles > > (VPN > > > >> > > concentrator and HA). How do the IKEv2-R know that the MN > > wants to > > > >> use > > > >> > > mip6 ? > > > >> > > > > > >> > > > > > > >> > > > > If we consider that the MSA should decide this, as the HoA > > > >> > > > > is sent after the MN being authenticated by EAP. This > > > >> > > > > implies that the mip6-authz app should be used before this > > > >> > > > > last IKEv2 message. > > > >> > > > > > > > >> > > > > If the MN requests a HoA to the HA, we also have the > > following > > > >> > > > > question: > > > >> > > > > > > > >> > > > > 1/ do we allow the AAA server to allocate this address ? > > or > > > >> > > > > do we need an AVP to carry the HoA from the AAA to the HA > > ? > > > >> > > > > > > >> > > > I'm not entirely sure what the above is supposed to mean.. > > but > > > >> > > > imho again depending on the operator's deployment either HA > > or > > > >> > > > AAA should be able to allocate the HoA. > > > >> > > > > > >> > > I also agree with you. It also implies that the mip6-Authz App > > > >> should > > > >> > > be used during EAP authentication process. > > > >> > > > > > >> > > Julien > > > >> > > > > > >> > > > > > > >> > > > Cheers, > > > >> > > > Jouni > > > >> > > > > > > >> > > > > > > >> > > > > > > > >> > > > > regards, > > > >> > > > > > > > >> > > > > Julien > > > >> > > > > > > > >> > > > > > > > >> > > > > _______________________________________________ > > > >> > > > > DiME mailing list > > > >> > > > > DiME@ietf.org > > > >> > > > > https://www1.ietf.org/mailman/listinfo/dime > > > >> > > > > > > > >> > > > > > >> > > -- > > > >> > > julien.bournelle at int-evry.fr > > > >> > > > > > >> > > _______________________________________________ > > > >> > > 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 > > > >> > > > >> > > > >> "This email message and any attachments are confidential > > information > > > >> of Starent Networks, Corp. The information transmitted may not be > > > >> used to create or change any contractual obligations of Starent > > > >> Networks, Corp. Any review, retransmission, dissemination or other > > > >> use of, or taking of any action in reliance upon this e-mail and > > its > > > >> attachments by persons or entities other than the intended > > recipient > > > >> is prohibited. If you are not the intended recipient, please notify > > > >> the sender immediately -- by replying to this message or by sending > > > >> an email to postmaster@starentnetworks.com -- and destroy all > > copies > > > >> of this message and any attachments without reading or disclosing > > > >> their contents. Thank you." > > > >> > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > -- > > > ------------------------------------------------------ > > > Rafael Marin Lopez > > > Faculty of Computer Science-University of Murcia > > > 30071 Murcia - Spain > > > Telf: +34968367645 e-mail: rafa@dif.um.es > > > ------------------------------------------------------ > > > > > > > > > _______________________________________________ > > > 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 Oct 06 01:25:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GViD5-0001l3-Vq; Fri, 06 Oct 2006 01:25:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GViCJ-0001Xn-UT for dime@ietf.org; Fri, 06 Oct 2006 01:24:35 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVhxw-0007dx-LM for dime@ietf.org; Fri, 06 Oct 2006 01:09:45 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 4724A90039 for ; Fri, 6 Oct 2006 01:09:41 -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 26210-05 for ; Fri, 6 Oct 2006 01:09:40 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 6 Oct 2006 01:08:32 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 01:08:31 -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] HA-AAAH case: auth. token ? Date: Fri, 6 Oct 2006 01:08:31 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD34F@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] HA-AAAH case: auth. token ? Thread-Index: AcbofJc+uB1/EmV/QMW/dm5yhC2P0wAiD+IA From: "Chowdhury, Kuntal" To: "Julien Bournelle" , "Yoshihiro Ohba" X-OriginalArrivalTime: 06 Oct 2006 05:08:31.0992 (UTC) FILETIME=[77C18F80:01C6E905] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.8 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 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 I concur with Julien. If such a "securer" mechanism needs to be defined to tie the authentication step with the authorization step, it should be defined as a generic solution in a separate document.=20 -Kuntal > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > Sent: Thursday, October 05, 2006 7:50 AM > To: Yoshihiro Ohba > Cc: dime@ietf.org > Subject: Re: [Dime] HA-AAAH case: auth. token ? >=20 > Hi yoshi, >=20 > On Thu, Oct 05, 2006 at 07:55:26AM -0400, Yoshihiro Ohba wrote: > > > > Hi Madjid, > > > > You are making a very good point. I agree with you that > > "authorization token" will make the architecture of separating > > authentication and authorization securer. I can imagine that this can > > be easily achived based on: the AAA client requests the authentication > > server to sign information that indicates that a particular MN was > > authenticated by the server via a particular NAS at a certain data and > > time using the server's public key and the authentication server > > returns the signed information back to the AAA client. The AAA client > > can then present the signed information to the authorization server as > > a proof of successful authentication of the MN by the authentication > > server. > > > > On the other hand, we can discuss whether this securer mechanism > > should be mandatory or optional. I prefer making such a mechanism > > optional because AAA clients, authentication server and authorization > > server are fairly trusted entities with each other in a particular > > deployment. >=20 > I think that if > we want such a mechanism, it should be better to define it in another > document because it is would be a general mechanism that could be used > by other authorization application. >=20 > what do you think ? >=20 > Julien >=20 > > > > Yoshihiro Ohba > > > > > > On Wed, Oct 04, 2006 at 04:30:12PM -0700, Madjid Nakhjiri wrote: > > > Hi Julien, > > > > > > Snip > > > > > > > Yes, a Mobility service provider and its AAA server should look at > the MN > > > > and its service profile to see if it is authorized to use MIP6 > service and > > > > how it is supposed to pay for it. But we need to figure out what > > > > "authorization credentials" to be used for this authorization. Now > this > > > > includes > > > > 1) something that securely identifies the MN (this includes proof of > > > > authentication) > > > > 2) something that proves MN's right to MIP6 service, i.e. an > authorization > > > > token or indication to a profile that the AAA server of MSP has of > MN that > > > > shows MN should have MIP6 service. > > > > > > > > If you are separating authorization spec from authentication spec, > then > > > both > > > > of these need to be included in the authorization spec. > > > > > > that's indeed a good question. At this point of time, I thought that > > > in the mip6-authz messages, we didn't need sort of "authz token". > > > I thought that the authentication process was implicit for the AAA- > MIP6 > > > Authz server and that finally it was the HA which basically need to > be > > > sure that the MN is authenticated. > > > > > > Madjid>>Traditionally, the authorization token is not an absolute > > > necessity, as long as there is a proof of a previous authentication > and as > > > long as there is profile info in the MSP AAA server on the MN. However, > > > "authorization token" would provide a clean separation of > authorization and > > > authentication. I say this because I have seen talk about having > different > > > MIP6 and EAP servers on this list. > > > > > > so my question: can't the AAA-MIP6 authz server assume that the MN has > > > been authenticated while receiving an authz request ? > > > > > > Madjid>>When it comes to security, you cannot assume anything:) If the > > > process depends on a previous authentication, then a proof of a > previous > > > authentication needs to be provided. This could either be a key > resulted > > > from a previous authentication signing the authorization request, or > an > > > authorization token, IMO. > > > The other question I have after reading the split scenario doc is that > you > > > guys are saying bootstrapping of some of MIP6 info (such as HoA) is > done as > > > part of IKEv2 signaling. How can you then separate a Diameter MIP6 > > > authorization from the IKEv2 authentication? > > > > > > > The MN identity used MIP6 may or may not be the same as that used in > a > > > > previous EAP, especially in split scenario, so it seems that in > split > > > > scenario you run two EAPs, one with MN ASP ID and one with MN MSP ID. > When > > > > you produce a separate authorization spec ("Diameter MIP6 spec" > separate > > > > from "Diameter EAP spec"), you need make sure that > > > > > > > > 1) MN uses the same ID during EAP and during MIP6? > > > > > > Concerning Identity used in the MIP6 Authz process, we have two > > > options: > > > > > > 1/ The HA uses the Identity provided in the IDi field during the > > > IKE_AUTH phase. In this case, the identity will be the same than the > > > one provided with the Diameter EAP Application. > > > > > > Madjid>>This could work, as long as the MSP AAA server recognizes the > MN > > > with the same ID that the EAP server. Again, we need to very careful > in > > > writing the spec, so that we avoid dependency of MIP6 spec on EAP spec, > or > > > feasibility of MIP solution on a prior EAP run. That is why providing > proof > > > for authentication or an authorization token is important, this way > you know > > > what ID has been used before. > > > I still have the question as before: how do you do MIP6 HoA > bootstrapping if > > > authn and authz are separated? > > > > > > 2/ The HA uses something provided in the BU. In this case, it implies > > > that the mip6-authz application is used after the whole EAP > > > authentication process. This may not be possible if we want to do > > > authorization of HoA allocation (cf. my thread on this subject). > > > > > > Madjid>>Yes, if the identity used during authz is different from that > during > > > authn, then you have potential for identity fraud. > > > > > > > 2) even if it does, the MN's ID the MN is using is authenticated? > There > > > must > > > > be a proof of a previous authentication. Just saying MN has run EAP > before > > > > it is not enough. When you are separating Diameter MIP spec and > Diameter > > > EAP > > > > spec and taking authentication out, then the MIP spec needs to > specify how > > > > the MN provides proof that it has run a previous EAP (or another > > > > authentication method) by probably signing its MIP6 authorization > request > > > > with a key that was generated during a previous EAP or > authentication. > > > > Otherwise, there is no way to know that the MN has actually been > > > > authenticated, meaning it is very difficult to separate > authorization from > > > > authorization. > > > > > > well, as noted below, I tend to think that the Authz server doesn't > > > need a proof that the MN has been authenticated. The Authz server > > > could trust the HA for this. > > > > > > Madjid>> You seem to be making assumptions about HA here, i.e. HA > knows > > > about the previous EAP and knows MN with that same identity. If this > is > > > true, then the HA may have been provided with some info (a key or a > token) > > > from the EAP/AAA server and then the HA can use that knowledge with > the > > > MSP/AAA to show that MN has been authenticated. > > > > > > R, > > > > > > Madjid > > > > > > Julien > > > > > > > Having said that I am hesitant to state that support option 2 as > well. > > > > And yes, Update of 4072 should not affect update of MIP6 application. > > > > > > > > Diameter MIP6 application needs to stand on its own and if it is > going to > > > > only define authorization and accounting and rely on a previous > > > > authentication, then it must be independent of whether the > authentication > > > is > > > > EAP or something else. We are not here to just solve a specific > > > optimization > > > > problem... > > > > > > > > My two rusty (late) pennies, > > > > > > > > Regards, > > > > > > > > Madjid > > > > > > > > > > > > -----Original Message----- > > > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > > > Sent: Friday, September 15, 2006 3:21 AM > > > > To: dime@ietf.org > > > > Subject: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling > part 2) > > > > > > > > Hi all, > > > > > > > > this is a new polling concerning the ha-aaah interface for the > Mobile > > > > IPv6 Boostrapping. To date, at the previous one, there was a > > > > consensus on moving forward with a new App-ID. But, yoshi has > > > > proposed an interesting idea that should be considered by the WG. > > > > > > > > As you may recall, in the ha-aaah case, the MN is authenticated by > > > > EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH > > > > interface must, at least, be able to carry EAP packets. It appears > that > > > > we now have 2 options: > > > > > > > > (1) We define a new Diameter application for Mobile IPv6 with a new > > > > App-ID that carry EAP packets as it is done in RFC 4072 > (Diameter > > > > EAP) but Authorization and Accouting is specific to Mobile IPv6 > > > > (thus the need for a new App-ID). The risk, as noted by yoshi, > is > > > > that an update of the RFC4072 may result in an update of this > > > > application. > > > > > > > > > > > > (2) We define a new Diameter Application for Mobile IPv6 but which > is > > > > used for Authorization and Accounting. We continue to use > > > > Diameter EAP for the Authentication. Thus the HA will use > > > > Diameter EAP with the AVP Auth-Request-Type set to > > > > AUTHENTICATE_ONLY and then the HA will use this MIP6 > Application > > > > for Authorization/Accounting of the Mobile IPv6 service. This > new > > > > application will have its own App-ID. > > > > > > > > This would avoid to update the application if 4072 is updated > and > > > > this could be a way to proceed if other applications need EAP > for > > > > Authentication but have different needs for the Authorization > and > > > > Accounting part. > > > > > > > > Please indicate wether you prefer (1) or (2). > > > > > > > > As in the previous polling: > > > > - it might be useful to state a reason for your decision. > > > > - indicate wether some aspects are still unclear to you. > > > > > > > > Regards, > > > > > > > > Julien > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > -- > > > julien.bournelle at int-evry.fr > > > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > >=20 > -- > julien.bournelle at int-evry.fr >=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 Fri Oct 06 05:30:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVm2L-0003W3-Ne; Fri, 06 Oct 2006 05:30:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVm2K-0003Vs-KC for dime@ietf.org; Fri, 06 Oct 2006 05:30:32 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GVm2J-0000fK-CR for dime@ietf.org; Fri, 06 Oct 2006 05:30:32 -0400 X-VirusChecked: Checked X-Env-Sender: in1236c@motorola.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1160127029!9132727!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 18273 invoked from network); 6 Oct 2006 09:30:30 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-119.messagelabs.com with SMTP; 6 Oct 2006 09:30:30 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k969UPKv018437 for ; Fri, 6 Oct 2006 02:30:29 -0700 (MST) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k969UOEU019570 for ; Fri, 6 Oct 2006 04:30:25 -0500 (CDT) Received: from A21224-01.migv.mot.com ([10.232.35.38]) by ZMY16EXM67.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 6 Oct 2006 17:30:22 +0800 From: Satendra To: dime@ietf.org Content-Type: text/plain Date: Fri, 06 Oct 2006 14:58:51 +0530 Message-Id: <1160126931.14184.48.camel@bigmountain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2006 09:30:23.0458 (UTC) FILETIME=[0C850420:01C6E92A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [Dime] Issue 18 updated: Reconnect behavior of peer based on value of Disconnect-Cause AVP 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've updated issue 18 with the proposed text. Please review the text, if it is appropriate or if other folks has other opinions. Regards, Satendra _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 06 06:17:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVmlx-0004hg-Ow; Fri, 06 Oct 2006 06:17:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVmlx-0004h9-0u for dime@ietf.org; Fri, 06 Oct 2006 06:17:41 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVmlw-0003At-67 for dime@ietf.org; Fri, 06 Oct 2006 06:17:41 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 18AFF2FDC0; Fri, 6 Oct 2006 12:17:25 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GVmnk-00074f-AU; Fri, 06 Oct 2006 12:19:32 +0200 Date: Fri, 6 Oct 2006 12:19:32 +0200 From: Julien Bournelle To: Yoshihiro Ohba Subject: Re: [Dime] HA-AAAH case: auth. token ? Message-ID: <20061006101932.GA27187@ipv6-3.int-evry.fr> References: <20061004094128.GA23345@ipv6-3.int-evry.fr> <001601c6e80d$0bec6b20$2f01a8c0@huawei6cc10c70> <20061005115526.GA20850@steelhead> <20061005125008.GA26201@ipv6-3.int-evry.fr> <20061005230004.GD30331@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061005230004.GD30331@steelhead> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.8 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd 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 yoshi, On Thu, Oct 05, 2006 at 07:00:04PM -0400, Yoshihiro Ohba wrote: > Hi Julien, > > I agree with you that such a token mechanism (if needed) is better > defined in a separate document. On the other hand, actual AVPs that > are used for realizing the mechanism would need to be carried in each > application and thus each application specification would need to have > the AVPs in its ABNF. yes, you're fully right. Moreover, we can imagine that mulitple mechanism are possible for this. So, before going into details we should analyse if we need that or not. Julien > > Regards, > Yoshihiro Ohba > > > > On Thu, Oct 05, 2006 at 02:50:08PM +0200, Julien Bournelle wrote: > > Hi yoshi, > > > > On Thu, Oct 05, 2006 at 07:55:26AM -0400, Yoshihiro Ohba wrote: > > > > > > Hi Madjid, > > > > > > You are making a very good point. I agree with you that > > > "authorization token" will make the architecture of separating > > > authentication and authorization securer. I can imagine that this can > > > be easily achived based on: the AAA client requests the authentication > > > server to sign information that indicates that a particular MN was > > > authenticated by the server via a particular NAS at a certain data and > > > time using the server's public key and the authentication server > > > returns the signed information back to the AAA client. The AAA client > > > can then present the signed information to the authorization server as > > > a proof of successful authentication of the MN by the authentication > > > server. > > > > > > On the other hand, we can discuss whether this securer mechanism > > > should be mandatory or optional. I prefer making such a mechanism > > > optional because AAA clients, authentication server and authorization > > > server are fairly trusted entities with each other in a particular > > > deployment. > > > > I think that if > > we want such a mechanism, it should be better to define it in another > > document because it is would be a general mechanism that could be used > > by other authorization application. > > > > what do you think ? > > > > Julien > > > > > > > > Yoshihiro Ohba > > > > > > > > > On Wed, Oct 04, 2006 at 04:30:12PM -0700, Madjid Nakhjiri wrote: > > > > Hi Julien, > > > > > > > > Snip > > > > > > > > > Yes, a Mobility service provider and its AAA server should look at the MN > > > > > and its service profile to see if it is authorized to use MIP6 service and > > > > > how it is supposed to pay for it. But we need to figure out what > > > > > "authorization credentials" to be used for this authorization. Now this > > > > > includes > > > > > 1) something that securely identifies the MN (this includes proof of > > > > > authentication) > > > > > 2) something that proves MN's right to MIP6 service, i.e. an authorization > > > > > token or indication to a profile that the AAA server of MSP has of MN that > > > > > shows MN should have MIP6 service. > > > > > > > > > > If you are separating authorization spec from authentication spec, then > > > > both > > > > > of these need to be included in the authorization spec. > > > > > > > > that's indeed a good question. At this point of time, I thought that > > > > in the mip6-authz messages, we didn't need sort of "authz token". > > > > I thought that the authentication process was implicit for the AAA-MIP6 > > > > Authz server and that finally it was the HA which basically need to be > > > > sure that the MN is authenticated. > > > > > > > > Madjid>>Traditionally, the authorization token is not an absolute > > > > necessity, as long as there is a proof of a previous authentication and as > > > > long as there is profile info in the MSP AAA server on the MN. However, > > > > "authorization token" would provide a clean separation of authorization and > > > > authentication. I say this because I have seen talk about having different > > > > MIP6 and EAP servers on this list. > > > > > > > > so my question: can't the AAA-MIP6 authz server assume that the MN has > > > > been authenticated while receiving an authz request ? > > > > > > > > Madjid>>When it comes to security, you cannot assume anything:) If the > > > > process depends on a previous authentication, then a proof of a previous > > > > authentication needs to be provided. This could either be a key resulted > > > > from a previous authentication signing the authorization request, or an > > > > authorization token, IMO. > > > > The other question I have after reading the split scenario doc is that you > > > > guys are saying bootstrapping of some of MIP6 info (such as HoA) is done as > > > > part of IKEv2 signaling. How can you then separate a Diameter MIP6 > > > > authorization from the IKEv2 authentication? > > > > > > > > > The MN identity used MIP6 may or may not be the same as that used in a > > > > > previous EAP, especially in split scenario, so it seems that in split > > > > > scenario you run two EAPs, one with MN ASP ID and one with MN MSP ID. When > > > > > you produce a separate authorization spec ("Diameter MIP6 spec" separate > > > > > from "Diameter EAP spec"), you need make sure that > > > > > > > > > > 1) MN uses the same ID during EAP and during MIP6? > > > > > > > > Concerning Identity used in the MIP6 Authz process, we have two > > > > options: > > > > > > > > 1/ The HA uses the Identity provided in the IDi field during the > > > > IKE_AUTH phase. In this case, the identity will be the same than the > > > > one provided with the Diameter EAP Application. > > > > > > > > Madjid>>This could work, as long as the MSP AAA server recognizes the MN > > > > with the same ID that the EAP server. Again, we need to very careful in > > > > writing the spec, so that we avoid dependency of MIP6 spec on EAP spec, or > > > > feasibility of MIP solution on a prior EAP run. That is why providing proof > > > > for authentication or an authorization token is important, this way you know > > > > what ID has been used before. > > > > I still have the question as before: how do you do MIP6 HoA bootstrapping if > > > > authn and authz are separated? > > > > > > > > 2/ The HA uses something provided in the BU. In this case, it implies > > > > that the mip6-authz application is used after the whole EAP > > > > authentication process. This may not be possible if we want to do > > > > authorization of HoA allocation (cf. my thread on this subject). > > > > > > > > Madjid>>Yes, if the identity used during authz is different from that during > > > > authn, then you have potential for identity fraud. > > > > > > > > > 2) even if it does, the MN's ID the MN is using is authenticated? There > > > > must > > > > > be a proof of a previous authentication. Just saying MN has run EAP before > > > > > it is not enough. When you are separating Diameter MIP spec and Diameter > > > > EAP > > > > > spec and taking authentication out, then the MIP spec needs to specify how > > > > > the MN provides proof that it has run a previous EAP (or another > > > > > authentication method) by probably signing its MIP6 authorization request > > > > > with a key that was generated during a previous EAP or authentication. > > > > > Otherwise, there is no way to know that the MN has actually been > > > > > authenticated, meaning it is very difficult to separate authorization from > > > > > authorization. > > > > > > > > well, as noted below, I tend to think that the Authz server doesn't > > > > need a proof that the MN has been authenticated. The Authz server > > > > could trust the HA for this. > > > > > > > > Madjid>> You seem to be making assumptions about HA here, i.e. HA knows > > > > about the previous EAP and knows MN with that same identity. If this is > > > > true, then the HA may have been provided with some info (a key or a token) > > > > from the EAP/AAA server and then the HA can use that knowledge with the > > > > MSP/AAA to show that MN has been authenticated. > > > > > > > > R, > > > > > > > > Madjid > > > > > > > > Julien > > > > > > > > > Having said that I am hesitant to state that support option 2 as well. > > > > > And yes, Update of 4072 should not affect update of MIP6 application. > > > > > > > > > > Diameter MIP6 application needs to stand on its own and if it is going to > > > > > only define authorization and accounting and rely on a previous > > > > > authentication, then it must be independent of whether the authentication > > > > is > > > > > EAP or something else. We are not here to just solve a specific > > > > optimization > > > > > problem... > > > > > > > > > > My two rusty (late) pennies, > > > > > > > > > > Regards, > > > > > > > > > > Madjid > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > > > > Sent: Friday, September 15, 2006 3:21 AM > > > > > To: dime@ietf.org > > > > > Subject: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) > > > > > > > > > > Hi all, > > > > > > > > > > this is a new polling concerning the ha-aaah interface for the Mobile > > > > > IPv6 Boostrapping. To date, at the previous one, there was a > > > > > consensus on moving forward with a new App-ID. But, yoshi has > > > > > proposed an interesting idea that should be considered by the WG. > > > > > > > > > > As you may recall, in the ha-aaah case, the MN is authenticated by > > > > > EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH > > > > > interface must, at least, be able to carry EAP packets. It appears that > > > > > we now have 2 options: > > > > > > > > > > (1) We define a new Diameter application for Mobile IPv6 with a new > > > > > App-ID that carry EAP packets as it is done in RFC 4072 (Diameter > > > > > EAP) but Authorization and Accouting is specific to Mobile IPv6 > > > > > (thus the need for a new App-ID). The risk, as noted by yoshi, is > > > > > that an update of the RFC4072 may result in an update of this > > > > > application. > > > > > > > > > > > > > > > (2) We define a new Diameter Application for Mobile IPv6 but which is > > > > > used for Authorization and Accounting. We continue to use > > > > > Diameter EAP for the Authentication. Thus the HA will use > > > > > Diameter EAP with the AVP Auth-Request-Type set to > > > > > AUTHENTICATE_ONLY and then the HA will use this MIP6 Application > > > > > for Authorization/Accounting of the Mobile IPv6 service. This new > > > > > application will have its own App-ID. > > > > > > > > > > This would avoid to update the application if 4072 is updated and > > > > > this could be a way to proceed if other applications need EAP for > > > > > Authentication but have different needs for the Authorization and > > > > > Accounting part. > > > > > > > > > > Please indicate wether you prefer (1) or (2). > > > > > > > > > > As in the previous polling: > > > > > - it might be useful to state a reason for your decision. > > > > > - indicate wether some aspects are still unclear to you. > > > > > > > > > > Regards, > > > > > > > > > > Julien > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > -- > > > > julien.bournelle at int-evry.fr > > > > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > -- > > julien.bournelle at int-evry.fr > > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 06 06:27:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVmv3-0001Bw-0r; Fri, 06 Oct 2006 06:27:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVmv2-000181-0C for dime@ietf.org; Fri, 06 Oct 2006 06:27:04 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVmv0-0004ej-I9 for dime@ietf.org; Fri, 06 Oct 2006 06:27:03 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 724042FE1D; Fri, 6 Oct 2006 12:26:59 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GVmx0-00074n-Mx; Fri, 06 Oct 2006 12:29:06 +0200 Date: Fri, 6 Oct 2006 12:29:06 +0200 From: Julien Bournelle To: Madjid Nakhjiri Subject: Re: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) Message-ID: <20061006102906.GB27187@ipv6-3.int-evry.fr> References: <20061005105219.GA26139@ipv6-3.int-evry.fr> <004101c6e8de$3daefde0$2f01a8c0@huawei6cc10c70> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004101c6e8de$3daefde0$2f01a8c0@huawei6cc10c70> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 madjid, On Thu, Oct 05, 2006 at 05:27:43PM -0700, Madjid Nakhjiri wrote: > yes. as we are defining a new App for the Authz, the AAA-EAP and > AAA-MIP6 may be different servers. But, from my point of view, as we > are decoupling Authentication from the Authorization/Accounting > process, the AAA-MIP6 does not need to authenticate again the MN. The > HA is reponsible of this and it does so with 4072. > > Madjid>>Ok, so the ongoing assumption is that AAA-MIP6 can be different from > AAA-EAP, and AAA-MIP6 is an authorization server that can authorize MN with > the ID the MN has presented to the HA and to the AAA_EAP. And the AAA-MIP6 > trusts that the MN has authenticated through the HA. So the trust of MN is > transitive. right > This is a security consideration, see below. > > > > > so my question: can't the AAA-MIP6 authz server assume that the MN has > > been authenticated while receiving an authz request ? > > > > Madjid>>When it comes to security, you cannot assume anything:) If the > > process depends on a previous authentication, then a proof of a previous > > authentication needs to be provided. > > well. I'm not sure about that. Basically, it is the HA which needs to > ensure that the MN is correctly authenticated. The AAA-MIP6 is here > just to check the profile. > > what do other think ? > > Madjid>>So you are saying HA is fully trusted by AAA-MIP6? yes, we have a trust relationship since the HA is a Diameter client. > So AAA-MIP6 takes > HA's word for MN having been authenticated and if MN ends up not paying its > bill because HA lied or was compromised, then this should be covered in the > security consideration, then... > As noted by Monica in her mail, if the HA does not authenticate the MN with 4072, we won't have IPsec SAs for mip6 service since the AUTH payload in IKEv2 is computed with the key delivered by the EAP server. Am I missing something ? > the HA uses both 4072 and the Authz Application during the IKEv2 > exchange. > > Madjid>>Ok, I guess the devil is in the details at this point:) > Are you saying some of the MIP6 bootstrapping (IKEv2 PSK for an MN-HA IPsec > SA? And HoA) is done during 4072? I will have to read some more.. the key used for the AUTH payload comes from 4072. HoA should be delivered by the AAA-MIP6. Julien > > . > > > > well, as noted below, I tend to think that the Authz server doesn't > > need a proof that the MN has been authenticated. The Authz server > > could trust the HA for this. > > > > Madjid>> You seem to be making assumptions about HA here, i.e. HA knows > > about the previous EAP and knows MN with that same identity. > > that's not a big assumption :). > > Madjid>>Ok, I guess I was mixing split and integrated scenarios. > > Julien > > > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 06 06:37:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVn51-00070w-UY; Fri, 06 Oct 2006 06:37:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVn51-00070r-9x for dime@ietf.org; Fri, 06 Oct 2006 06:37:23 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVn4z-0006e6-0A for dime@ietf.org; Fri, 06 Oct 2006 06:37:23 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 2F8C02FE1D for ; Fri, 6 Oct 2006 12:37:13 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GVn6u-00075A-Do for dime@ietf.org; Fri, 06 Oct 2006 12:39:20 +0200 Date: Fri, 6 Oct 2006 12:39:20 +0200 From: Julien Bournelle To: dime@ietf.org Message-ID: <20061006103920.GA27220@ipv6-3.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Dime] HA-to-AAAH/need for a auth. token ? 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 start a new thread on the auth. token issue. The issue is to know if the AAA-MIP6 needs a way to know if the MN has been authenticated by the AAA-EAP before authorizing (or not) the mip6 service. One way to do this could be to add a "token" in the authorization request. This token would be a proof that the MN has been correctly authenticated. However, as noted by Monica, the AUTH payload in the IKEv2 exchange is computed by relying on the EAP keying. So, the HA can't compute the AUTH payload if it does not authenticate the MN with 4072. If it can't compute this AUTH payload, IPsec SAs won't be setup between the MN and HA and thus the mip6 service can't be offered. This is just a first step in the analysis but it seems that we finally not need such a token mechanism. Any comments on this ? Julien _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 06 06:56:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVnNW-0000QA-Jq; Fri, 06 Oct 2006 06:56:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVnNV-0000Q4-W5 for dime@ietf.org; Fri, 06 Oct 2006 06:56:29 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVnNT-0001qT-N7 for dime@ietf.org; Fri, 06 Oct 2006 06:56:29 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 612F92FE13 for ; Fri, 6 Oct 2006 12:56:25 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GVnPU-00075p-Jy for dime@ietf.org; Fri, 06 Oct 2006 12:58:32 +0200 Date: Fri, 6 Oct 2006 12:58:32 +0200 From: Julien Bournelle To: dime@ietf.org Message-ID: <20061006105832.GA27260@ipv6-3.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Dime] HA-to-AAAH/HA as a single box ? 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 also prefer start a new thread on this subject. Gerardo raised an issue concerning the fact that the IKEv2 Responder of the HA may also act as a VPN concentrator. The issue is that the IKEv2 responder has (a priori) no way to know if the IKEv2 Initiator wants mip6 service or VPN. If it wants mip6 service, it should use 4072 in AUTHENTICATE_ONLY mode and then use the mip6 Authorization application. If it wants VPN, I guess 4072 would be used in a different way. So before trying to solve this, the question is to know wether we can assume that HA is a single box. I personnally would prefer assume the IKEv2 responder is only for HA and add a note in the document about this problem. Any comments ? Julien _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Oct 07 04:12:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW7IM-00008X-RR; Sat, 07 Oct 2006 04:12:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW7IL-00008S-J1 for dime@ietf.org; Sat, 07 Oct 2006 04:12:29 -0400 Received: from mail125.messagelabs.com ([85.158.136.35]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GW7IJ-0000kx-5r for dime@ietf.org; Sat, 07 Oct 2006 04:12:29 -0400 X-VirusChecked: Checked X-Env-Sender: in1236c@motorola.com X-Msg-Ref: server-3.tower-125.messagelabs.com!1160208745!16622485!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 31647 invoked from network); 7 Oct 2006 08:12:25 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-125.messagelabs.com with SMTP; 7 Oct 2006 08:12:25 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k978COlI017590 for ; Sat, 7 Oct 2006 01:12:24 -0700 (MST) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k978CNHd012617 for ; Sat, 7 Oct 2006 03:12:24 -0500 (CDT) Received: from A21224-01.migv.mot.com ([10.232.35.38]) by ZMY16EXM67.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2499); Sat, 7 Oct 2006 16:12:22 +0800 From: Satendra To: dime@ietf.org Content-Type: text/plain Date: Sat, 07 Oct 2006 13:40:48 +0530 Message-Id: <1160208648.14184.58.camel@bigmountain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Oct 2006 08:12:22.0577 (UTC) FILETIME=[50E90210:01C6E9E8] X-Spam-Score: 1.8 (+) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Dime] Issue 23 updated: Predictive loop avoidance 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've updated issue 23 with the proposed text. Please review the text, if it is appropriate or if other folks has other opinions. Regards, Satendra _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Oct 07 13:50:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWGJV-0004AA-J6; Sat, 07 Oct 2006 13:50:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWGJS-0004A0-QG for dime@ietf.org; Sat, 07 Oct 2006 13:50:15 -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 1GWGJP-0004oC-DU for dime@ietf.org; Sat, 07 Oct 2006 13:50:14 -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 k97Hk9KT018953; Sat, 7 Oct 2006 13:46:10 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4527E7DC.2040709@tari.toshiba.com> Date: Sat, 07 Oct 2006 13:46:04 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.5 (X11/20060812) MIME-Version: 1.0 To: Satendra References: <1160208648.14184.58.camel@bigmountain> In-Reply-To: <1160208648.14184.58.camel@bigmountain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: dime@ietf.org Subject: [Dime] Re: Issue 23 updated: Predictive loop avoidance 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 Satendra, Looks ok to me. I think it maybe good to add this to the bis. regards, victor > I've updated issue 23 with the proposed text. > Please review the text, if it is appropriate or if other folks has other > opinions. > > Regards, > Satendra > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Oct 08 23:23:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWljW-0005vx-8B; Sun, 08 Oct 2006 23:23:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWljV-0005vo-HZ for dime@ietf.org; Sun, 08 Oct 2006 23:23:13 -0400 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWljT-0003va-0V for dime@ietf.org; Sun, 08 Oct 2006 23:23:13 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 2A40D205ED for ; Mon, 9 Oct 2006 08:48:16 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 1370F205E6 for ; Mon, 9 Oct 2006 08:48:16 +0530 (IST) Received: from blr-m2-msg.wipro.com ([10.116.50.99]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 08:53:04 +0530 Received: from laptop-11929.wipro.com ([10.116.8.11]) by blr-m2-msg.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 08:53:02 +0530 Subject: Re: [Dime] Re: Issue 23 updated: Predictive loop avoidance From: venkatesh devalapura nagabhushana To: Victor Fajardo In-Reply-To: <4527E7DC.2040709@tari.toshiba.com> References: <1160208648.14184.58.camel@bigmountain> <4527E7DC.2040709@tari.toshiba.com> Content-Type: text/plain Date: Mon, 09 Oct 2006 08:55:22 +0530 Message-Id: <1160364322.3262.5.camel@wipro-9354e4f26> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2006 03:23:02.0773 (UTC) FILETIME=[3A7CA250:01C6EB52] 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 where can I find the updated text ? Thanks, Venkatesh On Sat, 2006-10-07 at 13:46 -0400, Victor Fajardo wrote: > Hi Satendra, > > Looks ok to me. I think it maybe good to add this to the bis. > > regards, > victor > > > I've updated issue 23 with the proposed text. > > Please review the text, if it is appropriate or if other folks has other > > opinions. > > > > Regards, > > Satendra > > > > > > > > > > > > > > > > _______________________________________________ > 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 Sun Oct 08 23:41:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWm18-0007lX-S7; Sun, 08 Oct 2006 23:41:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWm17-0007kC-HM for dime@ietf.org; Sun, 08 Oct 2006 23:41:25 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GWlnG-0005RC-Ib for dime@ietf.org; Sun, 08 Oct 2006 23:27:07 -0400 X-VirusChecked: Checked X-Env-Sender: vishnu@motorola.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1160364425!9632976!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 21454 invoked from network); 9 Oct 2006 03:27:05 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-119.messagelabs.com with SMTP; 9 Oct 2006 03:27:05 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k993R1cY019793 for ; Sun, 8 Oct 2006 20:27:05 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k993QxJP010291 for ; Sun, 8 Oct 2006 22:27:00 -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 Subject: RE: [Dime] Re: Issue 23 updated: Predictive loop avoidance Date: Mon, 9 Oct 2006 11:26:58 +0800 Message-ID: In-Reply-To: <1160364322.3262.5.camel@wipro-9354e4f26> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: Issue 23 updated: Predictive loop avoidance Thread-Index: AcbrUosHUFaogOcaSom/DNX5PEbpLwAAAo2A From: "Ram O V Vishnu-A14676" To: "venkatesh devalapura nagabhushana" , "Victor Fajardo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 Venkatesh, You can find all issue's updated text in: http://www.tschofenig.priv.at:8080/diameter-interop/ Specifically this is in=20 http://www.tschofenig.priv.at:8080/diameter-interop/issue23 Regards, Vishnu. Motorola +91 9844178052 [*] General [*] Motorola Internal Use Only -----Original Message----- From: venkatesh devalapura nagabhushana [mailto:venkatesh.nag@wipro.com] Sent: Monday, October 09, 2006 8:55 AM To: Victor Fajardo Cc: dime@ietf.org Subject: Re: [Dime] Re: Issue 23 updated: Predictive loop avoidance where can I find the updated text ? Thanks, Venkatesh On Sat, 2006-10-07 at 13:46 -0400, Victor Fajardo wrote: > Hi Satendra, >=20 > Looks ok to me. I think it maybe good to add this to the bis. >=20 > regards, > victor >=20 > > I've updated issue 23 with the proposed text. > > Please review the text, if it is appropriate or if other folks has other > > opinions. > > > > Regards, > > Satendra > > > > > > > > > > > > =20 >=20 >=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 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 09 21:25:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX6NJ-00025S-DV; Mon, 09 Oct 2006 21:25:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX6NJ-00025N-4L for dime@ietf.org; Mon, 09 Oct 2006 21:25:41 -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 1GX6NI-0007Hn-Rm for dime@ietf.org; Mon, 09 Oct 2006 21:25:41 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k9A1OvwI028561; Mon, 9 Oct 2006 21:25:01 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Mon, 9 Oct 2006 21:24:55 -0400 To: Julien Bournelle Subject: Re: [Dime] HA-to-AAAH/need for a auth. token ? Message-ID: <20061010012455.GB31067@steelhead> References: <20061006103920.GA27220@ipv6-3.int-evry.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <20061006103920.GA27220@ipv6-3.int-evry.fr> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 42 X-Spam-Score: -2.4 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Julien, Authorization token is intended for use among NAS/HA, authentication server and authorization server. The token is totally transparent to MN. Thus, I don't understand linkage between authorization token and IKEv2 AUTH payload stuff. Can you elaborate? Yoshihiro Ohba On Fri, Oct 06, 2006 at 12:39:20PM +0200, Julien Bournelle wrote: > Hi all, > > I start a new thread on the auth. token issue. > > The issue is to know if the AAA-MIP6 needs a way to know > if the MN has been authenticated by the AAA-EAP before > authorizing (or not) the mip6 service. One way to do this > could be to add a "token" in the authorization request. This > token would be a proof that the MN has been correctly > authenticated. > > However, as noted by Monica, the AUTH payload in the IKEv2 > exchange is computed by relying on the EAP keying. So, the > HA can't compute the AUTH payload if it does not authenticate > the MN with 4072. If it can't compute this AUTH payload, IPsec SAs > won't be setup between the MN and HA and thus the mip6 service > can't be offered. > > This is just a first step in the analysis but it seems that we > finally not need such a token mechanism. > > Any comments on this ? > > Julien > > _______________________________________________ > 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 Oct 10 04:59:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXDSR-0005rw-GJ; Tue, 10 Oct 2006 04:59:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXDSQ-0005rp-Ql for dime@ietf.org; Tue, 10 Oct 2006 04:59:26 -0400 Received: from wx-out-0506.google.com ([66.249.82.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXDSP-0004jQ-IW for dime@ietf.org; Tue, 10 Oct 2006 04:59:26 -0400 Received: by wx-out-0506.google.com with SMTP id t4so1896500wxc for ; Tue, 10 Oct 2006 01:59:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=q10WUMyTExfgHrhbSPOeLhatJTENUrHF+bNXmZq+r86E/Fgwc7N+1VytbOzrogTtXLy6RcPRQ0nsQpvPcICW9reNgaa9YHu7S7hSvOlz8mF7IV7JBB8W+syH8fQueztLP0z+MHA7R/hNVkxrmaOU/464yWYoIN33YpJut5Wa3ww= Received: by 10.90.54.20 with SMTP id c20mr3358122aga; Tue, 10 Oct 2006 01:59:25 -0700 (PDT) Received: by 10.90.84.9 with HTTP; Tue, 10 Oct 2006 01:59:25 -0700 (PDT) Message-ID: <5e2406980610100159h1ff9cae7mfd78cde0a1e39e7a@mail.gmail.com> Date: Tue, 10 Oct 2006 10:59:25 +0200 From: "Julien Bournelle" To: "Yoshihiro Ohba" Subject: Re: [Dime] HA-to-AAAH/need for a auth. token ? In-Reply-To: <20061010012455.GB31067@steelhead> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061006103920.GA27220@ipv6-3.int-evry.fr> <20061010012455.GB31067@steelhead> X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 yoshi, basically the question was: does the AAA-MIP6 need to know that the MN has been authenticated by AAA-EAP ? Then, as we are separating Authentication from Authorization and Accounting, we may have think that it was not necessary. But madjid said that the HA could be compromised and thus the HA could bypass authentication. But, the new question is: is it a realistic scenario since we are using IKEv2 and that the HA must contact the AAA-EAP to get the key for AUTH payload computation. regards, Julien On 10/10/06, Yoshihiro Ohba wrote: > Julien, > > Authorization token is intended for use among NAS/HA, authentication > server and authorization server. The token is totally transparent to > MN. Thus, I don't understand linkage between authorization token and > IKEv2 AUTH payload stuff. Can you elaborate? > > Yoshihiro Ohba > > > > On Fri, Oct 06, 2006 at 12:39:20PM +0200, Julien Bournelle wrote: > > Hi all, > > > > I start a new thread on the auth. token issue. > > > > The issue is to know if the AAA-MIP6 needs a way to know > > if the MN has been authenticated by the AAA-EAP before > > authorizing (or not) the mip6 service. One way to do this > > could be to add a "token" in the authorization request. This > > token would be a proof that the MN has been correctly > > authenticated. > > > > However, as noted by Monica, the AUTH payload in the IKEv2 > > exchange is computed by relying on the EAP keying. So, the > > HA can't compute the AUTH payload if it does not authenticate > > the MN with 4072. If it can't compute this AUTH payload, IPsec SAs > > won't be setup between the MN and HA and thus the mip6 service > > can't be offered. > > > > This is just a first step in the analysis but it seems that we > > finally not need such a token mechanism. > > > > Any comments on this ? > > > > Julien > > > > _______________________________________________ > > 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 Oct 10 15:27:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXNGO-0002sc-2r; Tue, 10 Oct 2006 15:27:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXNGM-0002sP-LI; Tue, 10 Oct 2006 15:27:38 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXNGL-0004z4-Nh; Tue, 10 Oct 2006 15:27:38 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6X00EG2PWVG9@usaga01-in.huawei.com>; Tue, 10 Oct 2006 12:24:31 -0700 (PDT) Received: from huawei6cc10c70 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J6X00FL9PWOL4@usaga01-in.huawei.com>; Tue, 10 Oct 2006 12:24:31 -0700 (PDT) Date: Tue, 10 Oct 2006 12:27:30 -0700 From: Madjid Nakhjiri Subject: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 In-reply-to: To: 'Gerardo Giaretta' , dime@ietf.org, mip6@ietf.org Message-id: <001c01c6eca2$215232d0$2f01a8c0@huawei6cc10c70> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acbm/x6JOiS47psmR8qr340RUmeLWAFojryQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d1100b36d83fed07afbc292d8848e10 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 folks, I was asked to review and comment on the MIP6-AAA-HA-goals-03. Please find the comments below, I cut out the sections I did not have comments on. Hope this helps, Regards, Madjid AAA Goals for Mobile IPv6 draft-ietf-mip6-aaa-ha-goals-03 Status of this Memo Giaretta, et al. Expires March 16, 2007 [Page 2] Internet-Draft AAA Goals for Mobile IPv6 September 2006 1. Introduction Mobile IPv6 [1] was originally designed as a protocol without any integration with the AAA infrastructure. Nonetheless, in some environments it might be desirable to authenticate the user based on existing credentials stored at the AAA server to authorize protocol operations, to enable accounting and credit control. Madjid>>I would suggest rewording: /Nonetheless, in some environment it might be desirable to refer to the AAA infrastructure and servers for authentication of user identity, authorization of Mobile IPv6 service to the user, bootstrapping Mobile IPv6 parameters, and accounting and credit control services. Due to this requirement, Mobile IPv6 might require the interaction with the AAA infrastructure. Madjid>>"requirement" is a strong word here. We know 3775 stands on its own. Suggestion: Therefore, it is desired that the interaction of Mobile IPv6 with the AAA infrastructure to obtain these services is designed in a more structured manner. Integrating the AAA infrastructure offers also a solution component for Mobile IPv6 bootstrapping [2] in split [3] and integrated [4] scenarios. This document describes various scenarios where a AAA interface is required. Additionally, it lists design goals and requirements for such an interface. This document only describes requirements, goals and scenarios. It does not provide solutions. Notice that this document builds on the security model of the AAA infrastructure. As such, the end host/user shares credentials with the home AAA server and the communication between the AAA server and the AAA client may be protected. Madjid>>the notion of home server needs to be explained better. I am guessing this is the AAA server of the home MSP. (and when we go into authn versus authz, then you even may have AAA_EAP for authentication purposes, while its MIP-AAA for authorization, both with MSP I guess). Also "may" in "may be protected" is a bit too weak, given that this is a "goal/requirement" doc. If the AAA server and the AAA client are not part of the same administrative domain, then some sort of contractual relationship between the involved administrative domains is typically in place in form of roaming agreements. Madjid>> I hope these agreements are between AAA servers of the two domains. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5]. Some of the terms are also extracted from [2]. 3. Motivation Mobile IPv6 specification [1] requires that Mobile Nodes (MNs) are provisioned with a set of configuration parameters, namely the Home Address and the Home Agent Address, in order to accomplish a home registration. Moreover, MNs and Home Agents (HAs) must share the cryptographic material needed in order to setup IPsec security associations to protect Mobile IPv6 signaling (e.g. shared keys or certificates). One approach is to statically provision the necessary configuration Giaretta, et al. Expires March 16, 2007 [Page 3] Internet-Draft AAA Goals for Mobile IPv6 September 2006 parameters at MNs and HAs. This solution is sub-optimal from a deployment perspective, especially in large networks with a lot of users (e.g., a mobile operator network). For this reason the Mobile IPv6 bootstrapping problem was investigated and is described in [2]. Based on the analysed scenarios, two solutions were developed. The solution for the split scenario is described in [3] and the one for the integrated scenario can be found at [4]. A key point behind these scenarios is that, whenever static provisioning is not feasible, the AAA infrastructure of the MSP can be used as the central element to enable dynamic Mobile IPv6 bootstrapping. In this case the AAA infrastructure can be exploited to offload the end host's authentication to the AAA server as well as to deliver the necessary configuration parameters to the HA. Moreover, in case Mobile IPv6 is a service offered by a Mobility Service Provider (MSP), all protocol operations (e.g., home registrations) may need to be explicitly authorized and monitored (e.g., for accounting purposes). This can be accomplished relying on the AAA infrastructure of the MSP that stores user profiles and credentials. In the split scenario, the deployment of this service model requires the availability of an interface between the Home Agent and the AAA infrastructure. The core capabilities that should be supported by this interface include Mobile IPv6 service authorization and maintenance (e.g. asynchronous service termination) as well as the exchange of accounting data. This basic set of features is needed in any Mobile IPv6 bootstrapping scenario. In the integrated scenario, the AAA server also delivers some Mobile IPv6 parameters to the NAS. Madjid>>This is an editorial/organizational comment: I don't think the paragraph above belong here for two reasons: 1) it comes before description of bootstrapping scenarios, while making very key statements about those 2) I don't see this as "motivation". I don't have a good suggestion, but it seems that beginning of section 5 is better place for this. Finally, there seems to be an explicit assumption about taking the authentication out of the AAA function for split case. The way I understand it, split case does have an authentication with the MSP-AAAH, it is just not part of the Diameter-MIP6 application. So this text should explain why all of the sudden from the text in the intro (including all 3 As in AAA) we are down to two. 4. Bootstrapping Scenarios This section describes some bootstrapping scenarios in which a communication between the AAA infrastructure of the Mobility Service Provider and the Home Agent is needed. 4.1. Split Scenario In the split scenario [3], there is the assumption that the mobility service and network access service are not provided by the same administrative entity. This implies that the mobility service can be authorized by a different entity deploying its own AAA infrastructure. The entity offering the mobility service is called Mobility Service Provider (MSP) while the entity authorizing the service is the Mobility Service Authorizer (MSA). Madjid>>Again, the text above is very confusing. It talks about MSP and ASP and their AAA server without showing any of the acronyms. Then it goes into MSP versus MSA and looses the mention of AAA server again. If this document is about HA-AAA goals, then we should really be clear about where the AAA servers are, for instance say that MSA is home MIP-AAA server. Here is my suggestion for rewording (still not perfect, but less confusing): In the split scenario [3], there is the assumption that the mobility service and network access service are not provided by the same administrative entity. This implies that the mobility service can be provided by a provider (MSP) that is different from the operator providing access service (ASP). Each of the MSP and ASP may be deploying its own AAA infrastructure, and authorizers (MSA and ASA, respectively). Furthermore, the entity offering the mobility service (Mobility Service Provider, MSP) may be different from the user's home mobility service provider (home-MSP). Since user's home mobility service provider is the entity authorizing the Mobility service for the user (performing home AAA function for the user's Mobile IP functions), this entity is seen as the Mobility Service Authorizer (MSA). In this scenario, the Mobile Node discovers the Home Agent Address Giaretta, et al. Expires March 16, 2007 [Page 4] Internet-Draft AAA Goals for Mobile IPv6 September 2006 using the Domain Name Service (DNS). It queries the address based on the Home Agent name or by service name. In the former case, the Mobile Node is configured with the Fully Qualified Domain Name (FDQN) of the Home Agent. In the latter case, [3] defines a new service resource record (SRV RR). Then the Mobile Node performs an IKEv2 [6] exchange with the HA to setup IPsec SAs (to protect Mobile IPv6 signaling) and to configure its Home Address (HoA). The IKEv2 Mobile Node to Home Agent authentication can be done using either public key signatures or the Extensible Authentication Protocol (EAP). If EAP is used for authentication, the operator can choose any available EAP methods. Note that even if EAP is used, the MN authenticates the HA using public key based authentication. Madjid>>I believe you need to say "MN may authenticate the HA using public key..." Or are you saying that MN always authenticates HA with public keys. Based on IKEv2, the HA may rely on a remote EAP server. In this case, a AAA protocol such as RADIUS EAP [7]/Diameter EAP [8] must be used between the HA and the home EAP server. This allows a pool of HAs to rely on the same EAP server to authenticate Mobile Nodes. It also allows the roaming mobility case in which the Mobile Node obtains the mobility service in a different administrative domain (MSP != MSA). The Mobile Node may also want to update its FQDN in the DNS with the newly allocated Home Address. [3] recommends that the HA performs the DNS entry update on behalf of the Mobile Node. For that purpose, the Mobile Node indicates its FDQN in the IKEv2 exchange (IDii field in IKE_AUTH) and adds a DNS Update Option in the Binding Update message sent to the HA. When the Mobile Node uses a Home Agent belonging to a different administrative domain (MSP != MSA), the local HA may not share a security association with the home DNS server. Madjid>>Administrative domain refers to AAAs. Again, the text above is confusing MSP=!MSA is very confusing, since it mixes several orthogonal concepts: 1) operators and their AAA/ admin domain 2) home and visited concepts. The introduced terminology is simply replacing well known AAA terms: in AAA terminology this is simply called Home versus visited operators and home versus visited AAAs. I would simply say that the HA belongs to a visited MSP, while MIP service to MN is authorized by home MSP-AAA. In this case, [3] suggests that the home AAA server is responsible for the update. Thus, the HA should send to the home AAA server the (FDQN, HoA) pair. Note that the AAA exchange between the HA and the AAA server is normally terminated before the HA receives the Binding Update message. The reason is that the authentication has succeeded if the Mobile Node is able to send the BU. 4.2. Integrated Scenario In the integrated scenario [4], the assumption is that the user is authenticated and authorized by the same authorizer than network access service. Madjid>>suggestion for rewording: "user is authenticated and authorized for Mobility service by the same authorizer (AAA server/ infrastructure) that used for network access service. In other words, " The Mobility Service Authorizer (MSA) and the Access Service Authorizer (ASA) are the same entity. Two scenarios are possible. In the first case, the Home Agent is allocated by the user's home domain. In the second case it is Giaretta, et al. Expires March 16, 2007 [Page 5] Internet-Draft AAA Goals for Mobile IPv6 September 2006 allocated by an entity in the visited domain. In both cases, it is assumed that the AAA server in the home domain (AAAH) authorizes both network access service and mobility service. Madjid>> the last sentence above, should be moved to the end of the first paragraph for this section. In this scenario, Mobile Node discovers the Home Agent Address using DHCPv6. During network access service authentication and authorization, AAAH also verifies if authenticating user is authorized to use mobility service. In affirmative case, the AAAH sends the information about the assigned home agent to the Network Access Server (NAS) where the Mobile Node is currently attached. Then, the NAS stores the received information. To request home agent data, the Mobile Node sends a DHCPv6 Information Request to the All_DHCP_Relay_Agents_and_Servers multicast address. With this request, the Mobile Node can specify if it wants a home agent provided by the visited domain (ASP/MSP) or by the home domain (ASA/ MSA). Madjid>>again this should say "visited domain (visited ASP/MSP) or by the home domain (home ASA/MSA). The text is confusing domains/ providers/AAA servers... In both cases, the NAS acts a DHCPv6 relay. When the NAS receives the DHCPv6 Information Request then it sends home agent information received from AAAH in a new DHC Relay Agent Option as defined in [9]. In case the Mobile Node cannot acquire home agent information via DHCPv6, it can try the default mechanism based on DNS described in [3]. After the Mobile Node has acquired the home agent information, the mechanism used to bootstrap the HoA, IPsec Security Association, and Authentication and Authorization with the MSA is the same described in the bootstrapping solution for split scenario [3]. 5. Goals for the Split Scenario Section 4 raises the need to define extensions for the AAA protocol used between the AAAH server and the HA. The following sections list a set of goals. 5.1. General goals G1.1 The AAAH server and the HA MUST be able to authenticate each other (mutual authentication) in order to prevent the installation of unauthorized state on the HA. In some deployment scenarios, it may not be feasible for HA and AAAH to mutually authenticate each other. For example, let us consider the case where MSP is not the MSA. In such a case, several AAA intermediate proxies could forward MIP6 bootstrapping information back and forth between HA and AAA. Thus, to prevent the installation of unauthorized state on the HA, the path between HA and AAAH should be trustworthy>/ Madjid>>again MSP versus MSA terminology issue. Plus the text is venturing into something that is more of a AAA infrastructure issue than an HA-AAAH issue. Also the text is mixing end point authentication and AAA signaling security all in one requirement. Mutual authentication of HA and home AAA is one thing, protecting bootstrapping info over AAA messaging is another. This should be broken into two requirements. I believe you have text on confidentiality in G1.4. The AAA signaling security issue is that of a AAA client in visited AAA domain dealing with a home AAA domain are well known. for instance if you don't like the transitive trust provided by the hop by hop security in RADIUS, so you need external ways to cure the transitive trust problem. On the other hand providing a mutual authentication procedure between HA and home AAA server without intervention of AAA intermediaries in a whole different problem. So we need to be careful, otherwise we may end up ruling RADIUS out of here. Is that the intention? I would simply state the well known issues in the security consideration section. Giaretta, et al. Expires March 16, 2007 [Page 6] Internet-Draft AAA Goals for Mobile IPv6 September 2006 G1.2 The AAA-HA interface MUST provide integrity protection in order to prevent any alteration of exchanged data (e.g., Mobile IPv6 configuration parameters). G1.3 The AAA-HA interface MUST provide replay protection. G1.4 The AAA-HA interface SHOULD provide confidentiality since it may be used to transfer keying material (e.g., shared key generated during EAP method authentication). Madjid>>same comment as that on security in G1.1. G1.5 The AAA-HA interface SHOULD support inactive peer detection. This functionality can be used by the AAAH server to maintain a list of active HAs. 5.2. Service Authorization Madjid>>Typically authorization follows a successful authentication. It seems that the burden of the making sure the MN is authenticated falls into the lap of the HA, should we not have a requirement on this? G2.1 The AAA-HA interface SHOULD allow the use of Network Access Identifier (NAI) to identify the user. Madjid>>I believe for the split scenario. We were saying that the Diameter_EAP and Diameter-MIP need to use the same ID. does this cover that? Is NAI always the ID used for EAP? G2.2 The HA SHOULD be able to query the AAAH server to verify Mobile IPv6 service authorization for the mobile node. G2.3 The AAAH server MAY assign explicit operational limitations and authorization restrictions on the HA (e.g., packet filters, QoS parameters). G2.4 The AAAH server MUST be able to send an authorization lifetime to the HA to limit Mobile IPv6 session duration for the MN. G2.5 The HA MUST be able to request to the AAAH server an extension of the authorization lifetime granted to the MN. G2.6 The AAAH server MUST be able to force the HA to terminate an active Mobile IPv6 session for authorization policy reasons (e.g., credit exhaustion). 5.3. Accounting G3.1 The AAA-HA interface MUST support the transfer of accounting records needed for service control and charging. These include (but may not be limited to): time of binding cache entry creation and deletion, octets sent and received by the mobile node in bi- directional tunneling, etc. Giaretta, et al. Expires March 16, 2007 [Page 7] Internet-Draft AAA Goals for Mobile IPv6 September 2006 5.4. Mobile Node Authentication G4.1 The AAA-HA interface MUST support pass-through EAP authentication with the HA working as EAP authenticator operating in pass-through mode and the AAAH server working as back-end authentication server. Madjid>>Does this really have to be a MUST? 5.5. Provisioning of Configuration Parameters G5.1 The HA SHOULD be able to communicate to the AAAH server the Home Address allocated to the MN (e.g., for allowing the AAAH server to perform a DNS update on behalf of the MN). G5.2 The AAAH SHOULD be able to indicate to the HA if the MN is authorized to autoconfigure its Home Address. 6. Goals for the Integrated Scenario In the integrated scenario, the AAA server provides the HA information to the NAS as part of the whole AAA operations for network access. Next goals are considered in addition to those described in section Section 5. G6.1 The AAAH server MUST be able to communicate the Home Agent Information (IP Address or FQDN) to the NAS. G6.2 The NAS SHOULD be able to notify that it supports the functionalities described in [4]. G6.3 The ASP/MSP SHOULD be able to indicate to the MSA if it can allocate a Home Agent to the MN. G6.4 The AAA server of the MSA MUST be able to indicate to the NAS whether the MN is authorized to use a local Home Agent (i.e. a Home Agent in the ASP/MSP) Giaretta, et al. Expires March 16, 2007 [Page 8] Internet-Draft AAA Goals for Mobile IPv6 September 2006 8. Security Considerations As stated in Section 5.1 the AAA-HA interface must provide mutual authentication, integrity and replay protection. Furthermore, if security parameters (e.g., IKE pre-shared key) are transferred through this interface, confidentiality is strongly recommended to be supported. However note that AAA protocols does not support this unless it exists a direct connection between corresponding entities. Madjid>> Diameter supports this. should say "some AAA protocols". -----Original Message----- From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] Sent: Tuesday, October 03, 2006 8:13 AM To: dime@ietf.org Subject: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 FYI, please review the document. --Gerardo ---------- Forwarded message ---------- From: Basavaraj Patil Date: Oct 3, 2006 4:49 PM Subject: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 To: mip6@ietf.org Hello, This is a Working group last call for the WG I-D: AAA Goals for Mobile IPv6 (draft-ietf-mip6-aaa-ha-goals-03). The draft is intended to serve as the AAA requirements for Mobile IPv6. Please review the I-D and submit your comments to the authors or to the list directly. The WGLC expires on Oct 18th, 06. The I-D is intended to be published as an Informational RFC. -Raj _______________________________________________ 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 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 11 09:44:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXeNd-00044O-W2; Wed, 11 Oct 2006 09:44:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXeNc-00044J-B8 for dime@ietf.org; Wed, 11 Oct 2006 09:44:16 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXeNZ-0002cw-Lj for dime@ietf.org; Wed, 11 Oct 2006 09:44:16 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k9BDi9r3009863; Wed, 11 Oct 2006 22:44:09 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k9BDiAY2010372; Wed, 11 Oct 2006 22:44:10 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with ESMTP id YAA10371; Wed, 11 Oct 2006 22:44:10 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k9BDi8D0017274; Wed, 11 Oct 2006 22:44:08 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k9BDi8Pu022576; Wed, 11 Oct 2006 22:44:08 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J6Z00ILL4TFKDA0@mail.po.toshiba.co.jp>; Wed, 11 Oct 2006 22:44:08 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GXeNK-0002Nl-8D; Wed, 11 Oct 2006 06:43:58 -0700 Date: Wed, 11 Oct 2006 09:43:58 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] HA-to-AAAH/need for a auth. token ? In-reply-to: <5e2406980610100159h1ff9cae7mfd78cde0a1e39e7a@mail.gmail.com> To: Julien Bournelle Message-id: <20061011134357.GD7576@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20061006103920.GA27220@ipv6-3.int-evry.fr> <20061010012455.GB31067@steelhead> <5e2406980610100159h1ff9cae7mfd78cde0a1e39e7a@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 Julien, On Tue, Oct 10, 2006 at 10:59:25AM +0200, Julien Bournelle wrote: > hi yoshi, > > basically the question was: does the AAA-MIP6 need to know that the > MN has been authenticated by AAA-EAP ? > Then, as we are separating Authentication from Authorization and > Accounting, we may have think that it was not necessary. But madjid > said that the HA could be compromised and thus the HA could bypass > authentication. > > But, the new question is: is it a realistic scenario since we are > using IKEv2 and that the HA must contact the AAA-EAP to get the key > for AUTH payload computation. A compromized HA may contact to attacker's AAA-EAP instead of legitimate AAA-EAP (in this case MN has an account on attacker's AAA-EAP) or may run IKEv2 without EAP, and then contact to AAA-MIP6 to obtain MIPv6 parameters. AAA-MIP6 may not want to give MIPv6 parameters without knowing how and to whom the MN authenticated. Yoshihiro Ohba > > regards, > > Julien > > > On 10/10/06, Yoshihiro Ohba wrote: > >Julien, > > > >Authorization token is intended for use among NAS/HA, authentication > >server and authorization server. The token is totally transparent to > >MN. Thus, I don't understand linkage between authorization token and > >IKEv2 AUTH payload stuff. Can you elaborate? > > > >Yoshihiro Ohba > > > > > > > >On Fri, Oct 06, 2006 at 12:39:20PM +0200, Julien Bournelle wrote: > >> Hi all, > >> > >> I start a new thread on the auth. token issue. > >> > >> The issue is to know if the AAA-MIP6 needs a way to know > >> if the MN has been authenticated by the AAA-EAP before > >> authorizing (or not) the mip6 service. One way to do this > >> could be to add a "token" in the authorization request. This > >> token would be a proof that the MN has been correctly > >> authenticated. > >> > >> However, as noted by Monica, the AUTH payload in the IKEv2 > >> exchange is computed by relying on the EAP keying. So, the > >> HA can't compute the AUTH payload if it does not authenticate > >> the MN with 4072. If it can't compute this AUTH payload, IPsec SAs > >> won't be setup between the MN and HA and thus the mip6 service > >> can't be offered. > >> > >> This is just a first step in the analysis but it seems that we > >> finally not need such a token mechanism. > >> > >> Any comments on this ? > >> > >> Julien > >> > >> _______________________________________________ > >> 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 Wed Oct 11 19:04:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXn7W-0000DZ-3C; Wed, 11 Oct 2006 19:04:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXn7V-0000D1-8w for dime@ietf.org; Wed, 11 Oct 2006 19:04:13 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXn7F-0004ML-S6 for dime@ietf.org; Wed, 11 Oct 2006 19:04:13 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 01:03:05 +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] HA-to-AAAH support/When ? HoA allocation considerations Date: Thu, 12 Oct 2006 01:03:02 +0200 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E030135A313@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] HA-to-AAAH support/When ? HoA allocation considerations Thread-Index: AcboUwbim1hT/d1CTYiPzLuNM2HcbQFL8WQg From: To: , X-OriginalArrivalTime: 11 Oct 2006 23:03:05.0944 (UTC) FILETIME=[694AA580:01C6ED89] X-Spam-Score: 0.2 (/) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b 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,=20 > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com]=20 > Sent: 5. lokakuuta 2006 10:51 > To: Chowdhury, Kuntal > Cc: dime@ietf.org > Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation=20 > considerations >=20 > Hi Kuntal, >=20 > > I am not sure why we are bringing scenarios that are=20 > outside the scope > > of MIP6. In MIP6 IPsec/IKEv2 happens between the MN and the=20 > HA. PDG/VPN > > etc. are outside the scope of what we are defining here i.e. HA-HAAA > > Diameter interface, IMHO. > > >=20 > Indeed I just asked the question: do we all agree that the we can > assume the HA acts only as HA and not as any other IKEv2 responder? >=20 > I think that from a deployment perspective there may be cases where > the IKEv2 responder may be a HA but also a VPN server. But if > everybody agrees to restrict the case where the HA acts just as HA, I > may be fine with that. I'm just raising a possible deployment issue. I'm not guite sure whether restrictic that a HA cannot be a VPN server as well is a good idea. As you said, there might deploymnet scenarios where a HA is also a VPN server. /Jouni > --Gerardo >=20 >=20 > > -Kuntal > > > > > > > -----Original Message----- > > > From: Rafa Marin Lopez [mailto:rafa@dif.um.es] > > > Sent: Wednesday, October 04, 2006 1:14 PM > > > To: Gerardo Giaretta > > > Cc: dime@ietf.org > > > Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation > > > considerations > > > > > > Hi Gerardo, > > > > > > > > > > > My original thought was that the MIP6 Authorization=20 > Application can > > be > > > > started and used at the reception of the first BU since=20 > it is from > > > > that moment that the MN begins using MIP6 service. Based on this > > > > consideration, I'm wondering if we can leave the HoA=20 > assignment to > > the > > > > Diameter EAP part, but this seems not so clean. > > > > > > But in that case, you are already receiving MIP6 authorization > > > information within Diameter EAP... correct? > > > > > > > > > > > The other issue is that the IKEv2 responder may be a=20 > HA, but may be > > > > also a combined HA/PDG/VPN concentrator. Are we=20 > assuming that the > > > > IKEv2 responder acts only as HA? If so, the MIPv6 authorization > > > > application can start during IKEv2 exchange. But if not, how the > > IKEv2 > > > > responder (i.e. HA/PDG/ VPN concentrator) knows that=20 > the user is a > > MIP > > > > user or not? > > > > > > I have a question: is the assumption here that HA/PDG/VPN=20 > may need to > > > ask authorization about different services (e.g. VPN=20 > parameters or/and > > > MIP6 parameters) depending on MN requires? > > > > > > Another question: how would HA/PDG/VPN know it has to use RFC 4072 > > with > > > AUTHENTICATE_ONLY for MIP6 service? > > > Initially, it looks that the a simple answer would be=20 > that HA/PDG/VPN > > is > > > configured to send AUTHENTICATE_ONLY no matter the service. > > > > > > Thanks. > > > > > > > > > > > --Gerardo > > > > > > > > On 10/4/06, Chowdhury, Kuntal > > wrote: > > > > > > > >> Hi Gerardo, > > > >> > > > >> Regarding your comment: > > > >> > > > >> > I think what is important from an operator=20 > perspective is that > > the > > > >> > address may be allocated by either AAA or HA. However, to get > > this, > > > we > > > >> > do not need to start mip6-authz during EAP exchange,=20 > since it is > > a > > > >> > generic IKEv2 address assignment issue and not a MIP specific > > one. > > > >> > > > >> I think it is important to verify whether the user is=20 > allowed to > > use a > > > >> particular HoA. For example, the user may intentionally or > > accidentally > > > >> set the INTERNAL_IP6_ADDRESS to someone else's=20 > statically assigned > > HoA. > > > >> The HA may not keep track of the statically assigned=20 > HoAs of all > > the > > > >> users belonging to an MSA. If the HA does not verify=20 > with the MSA > > (AAA) > > > >> the user will get an address which actually belongs to someone > > else. > > > >> > > > >> To circumvent the problem, in some deployments the=20 > prefix that can > > be > > > >> used to auto-configure HoAs by MNs is kept separate=20 > from the ones > > used > > > >> for static HoA assignment. The HA should have this=20 > knowledge either > > via > > > >> local config or via AAA transaction. > > > >> > > > >> -Kuntal > > > >> > > > >> > > > >> > -----Original Message----- > > > >> > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > >> > Sent: Wednesday, October 04, 2006 7:23 AM > > > >> > To: Julien Bournelle > > > >> > Cc: dime@ietf.org > > > >> > Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation > > > >> > considerations > > > >> > > > > >> > Hi Julien and Jouni, > > > >> > > > > >> > > > > However, we also have to consider the=20 > Home-Address (HoA) > > > >> > > > > allocation. As you may know the MN may=20 > auto-assign its HoA > > > >> > > > > or requests one. (cf. > > > >> > > > > draft-ietf-mip6-bootstrapping-split-02.txt) > > > >> > > > > > > > >> > > > > If it wants to auto-assign its HoA, it has 2 > > possibilities: > > > >> > > > > > > > >> > > > > 1/ It autoassignes its HoA and includes it in the > > CFG_REQUEST > > > >> > > > > (INTERNAL_IP6_ADDRESS)i in the first=20 > IKE_AUTH message. > > > >> > > > > If the HA is ok, it replies with the CFG_REPLY > > > >> > > > > with the same address. > > > >> > > > > > > > >> > > > > 2/ The MN asks for the Home Prefix (CFG_REQUEST with > > > >> > > > > MIP6_HOME_PREFIX). The HA sends the Home=20 > prefix in the > > > >> CFG_REPLY. > > > >> > > > > Then > > > >> > > > > the MN uses a CREATE_CHILD_SA. > > > >> > > > > > > > >> > > > > This raises some questions: > > > >> > > > > > > > >> > > > > 1/ Do we consider that it is the HA which=20 > decides if the > > MN > > > >> > > > > is authorized to configure its HoA (policy=20 > configuration > > at > > > >> > > > > the HA) ? or do we consider that it is a=20 > per-MN policy and > > > >> > > > > thus that the HA should request that to the MSA ? > > > >> > > > > > > >> > > > Imho both.. depends on operator's deployment. > > > >> > > > > > >> > > if we want both. This implies that the mip6-authz process > > occurs > > > >> during > > > >> > > the EAP authentication process (probably when the=20 > HA receives > > the > > > >> > > result of the EAP authentication from the AAAH). > > > >> > > > > > >> > > > > >> > This is needed only for autoconfiguration. But=20 > autoconfiguration > > has > > > >> > been introduced in mip6-split for rfc3041 addresses=20 > and CGAs. Do > > we > > > >> > want the AAA to decide if theMN can use CGA? I'm not=20 > sure this is > > the > > > >> > case. > > > >> > > > > >> > I think what is important from an operator=20 > perspective is that > > the > > > >> > address may be allocated by either AAA or HA. However, to get > > this, > > > we > > > >> > do not need to start mip6-authz during EAP exchange,=20 > since it is > > a > > > >> > generic IKEv2 address assignment issue and not a MIP specific > > one. > > > >> > > > > >> > --Gerardo > > > >> > > > > >> > > I'm also in favor of that but then we have the=20 > issue raised by > > > >> gerardo > > > >> > > concerning the fact that the IKEv2 responder may=20 > play 2 roles > > (VPN > > > >> > > concentrator and HA). How do the IKEv2-R know that the MN > > wants to > > > >> use > > > >> > > mip6 ? > > > >> > > > > > >> > > > > > > >> > > > > If we consider that the MSA should decide=20 > this, as the HoA > > > >> > > > > is sent after the MN being authenticated by EAP. This > > > >> > > > > implies that the mip6-authz app should be=20 > used before this > > > >> > > > > last IKEv2 message. > > > >> > > > > > > > >> > > > > If the MN requests a HoA to the HA, we also have the > > following > > > >> > > > > question: > > > >> > > > > > > > >> > > > > 1/ do we allow the AAA server to allocate=20 > this address ? > > or > > > >> > > > > do we need an AVP to carry the HoA from the=20 > AAA to the HA > > ? > > > >> > > > > > > >> > > > I'm not entirely sure what the above is supposed=20 > to mean.. > > but > > > >> > > > imho again depending on the operator's=20 > deployment either HA > > or > > > >> > > > AAA should be able to allocate the HoA. > > > >> > > > > > >> > > I also agree with you. It also implies that the=20 > mip6-Authz App > > > >> should > > > >> > > be used during EAP authentication process. > > > >> > > > > > >> > > Julien > > > >> > > > > > >> > > > > > > >> > > > Cheers, > > > >> > > > Jouni > > > >> > > > > > > >> > > > > > > >> > > > > > > > >> > > > > regards, > > > >> > > > > > > > >> > > > > Julien > > > >> > > > > > > > >> > > > > > > > >> > > > > _______________________________________________ > > > >> > > > > DiME mailing list > > > >> > > > > DiME@ietf.org > > > >> > > > > https://www1.ietf.org/mailman/listinfo/dime > > > >> > > > > > > > >> > > > > > >> > > -- > > > >> > > julien.bournelle at int-evry.fr > > > >> > > > > > >> > > _______________________________________________ > > > >> > > 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 > > > >> > > > >> > > > >> "This email message and any attachments are confidential > > information > > > >> of Starent Networks, Corp. The information transmitted=20 > may not be > > > >> used to create or change any contractual obligations of Starent > > > >> Networks, Corp. Any review, retransmission,=20 > dissemination or other > > > >> use of, or taking of any action in reliance upon this=20 > e-mail and > > its > > > >> attachments by persons or entities other than the intended > > recipient > > > >> is prohibited. If you are not the intended recipient,=20 > please notify > > > >> the sender immediately -- by replying to this message=20 > or by sending > > > >> an email to postmaster@starentnetworks.com -- and destroy all > > copies > > > >> of this message and any attachments without reading or=20 > disclosing > > > >> their contents. Thank you." > > > >> > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > -- > > > ------------------------------------------------------ > > > Rafael Marin Lopez > > > Faculty of Computer Science-University of Murcia > > > 30071 Murcia - Spain > > > Telf: +34968367645 e-mail: rafa@dif.um.es > > > ------------------------------------------------------ > > > > > > > > > _______________________________________________ > > > 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 Wed Oct 11 20:09:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXo8k-0001JA-9R; Wed, 11 Oct 2006 20:09:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXo8j-0001J2-G5 for dime@ietf.org; Wed, 11 Oct 2006 20:09:33 -0400 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXo8i-0006Uh-3N for dime@ietf.org; Wed, 11 Oct 2006 20:09:33 -0400 Received: from [10.1.201.0] ([66.92.223.6]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 17:07:00 -0700 Message-ID: <452D86C0.5040200@azairenet.com> Date: Wed, 11 Oct 2006 17:05:20 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.5 (X11/20060812) MIME-Version: 1.0 To: Gerardo Giaretta Subject: Re: [Dime] Some thoughts about Diameter MIPv6 Application References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2006 00:07:00.0091 (UTC) FILETIME=[569F0CB0:01C6ED92] X-Spam-Score: 0.1 (/) 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 apologies for the late reply. Gerardo Giaretta wrote: > Hi all, > > I would like to share with you some considerations about the Diameter > Application for MIPv6. Some questions also follow. > > - first of all I think the proposal made by Yoshi to use rfc4072 in > AUTHENTICATION_ONLY mode and define another MIP6-specific application > for authorization is the right one. Indeed, this would let separate > clearly the authentication procedure from the authorization step and I > think this is really needed in case IKEv2 is used. Suppose for example > a node acts as both VPN concentrator and HA (or 3GPP PDG and HA): it > supports IKEv2 signaling and acts as EAP pass-through authenticator in > order to setup the IPsec SA with the peer. If a MN starts an IKEv2 > exchange with this node, this node has no way to know if the MN is > going to use MIPv6 service or not (since the MN could be just setting > up the SA for remore access). Therefore, we need to take into account > that the HA is not sure that the MN is going to use MIPv6 service > untill it receives a BU. In my view, this is a valid reason to keep > authentication and authorization separated: the former is based on > rfc4072 and occurs during IKEv2 exchange, the latter is mip6-specific > and can be done later it should be possible to combine the two AAA round trips when the VPN gateway and the MIP6 HA are co-located and if it is known beforehand that the MS is going to be using MIPv6 after the IPsec tunnel is setup. we shouldn't _require_ two round trips. > - based on what stated above, the first authorization request should > be sent by the HA upon the receipt of the first BU. However, this will > increase the latency of the first registration, since the AAA of the > MSA will be involved. Notice that in case the MN is moving from the > home link to a visited link, the first registration has low handoff > latency requirements. that is fine. RFC 3775 has defined a longer timer for the initial BU to allow for DAD for the home address to happen. > - based on draft-ietf-mip6-aaa-ha-goals the AAA server may send an > Abort Session Request to the HA in order to stop the MIPv6 service for > a MN. This message may be very similar to the ASR in NASREQ. One > question is: from a MIPv6 perspective, is there any signaling the HA > will send to the MN to communicate that the session is over for a > specific reason? Or the MN is just blocked? the HA switch message from the HA to the MN can be used. http://www.ietf.org/internet-drafts/draft-ietf-mip6-ha-switch-00.txt > - I guess, as in NASREQ, the AAA-MSA sends an authorization lifetime > to the HA and this lifetime will be renewed later. Is this > authorization lifetime related with the BU/BA lifetime? Are they equal > or orthogonal? The HA may set the binding lifetime in the BA equal to > the authorization lifetime. Is this approach useful? they should be orthogonal. > - on the identities used by the MN: which identity is used by the HA > to identify the MN in the authorization phase? There is no identity in > the BU, unless we use the HoA as the identity. Otherwise the HA must > keep the identity used in IKEv2 by the MN. Any thought? identity used in IKEv2 should be used. if there is a need for a separate identifier for MIPv6, RFC 4283 defines an MN identifier option to carry, for e.g. an NAI. Vijay _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 11 20:14:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXoDX-0003g2-HZ; Wed, 11 Oct 2006 20:14:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXoDW-0003fp-3W for dime@ietf.org; Wed, 11 Oct 2006 20:14:30 -0400 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXoDU-0007Ca-OL for dime@ietf.org; Wed, 11 Oct 2006 20:14:30 -0400 Received: from [10.1.201.0] ([66.92.223.6]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 17:11:57 -0700 Message-ID: <452D87ED.2000409@azairenet.com> Date: Wed, 11 Oct 2006 17:10:21 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.5 (X11/20060812) MIME-Version: 1.0 To: Julien Bournelle Subject: Re: [Dime] HA-to-AAAH/HA as a single box ? References: <20061006105832.GA27260@ipv6-3.int-evry.fr> In-Reply-To: <20061006105832.GA27260@ipv6-3.int-evry.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2006 00:11:57.0152 (UTC) FILETIME=[07AEF600:01C6ED93] X-Spam-Score: 0.1 (/) 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 Julien Bournelle wrote: > Hi all, > > I also prefer start a new thread on this subject. > > Gerardo raised an issue concerning the fact that > the IKEv2 Responder of the HA may also act as a VPN concentrator. IMO, this must be supported. > > The issue is that the IKEv2 responder has (a priori) no way to know > if the IKEv2 Initiator wants mip6 service or VPN. there are many ways of doing this. some deployments use the IDr field to indicate that you are going to use a certain service. Vijay > > If it wants mip6 service, it should use 4072 in > AUTHENTICATE_ONLY mode and then use the mip6 Authorization > application. If it wants VPN, I guess 4072 would be used > in a different way. > > So before trying to solve this, the question is to know wether > we can assume that HA is a single box. > > I personnally would prefer assume the IKEv2 responder is only for > HA and add a note in the document about this problem. > > Any comments ? > > Julien > > _______________________________________________ > 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 Oct 12 04:35:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXw1n-0000LD-Hm; Thu, 12 Oct 2006 04:34:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXw1m-0000L8-9g for dime@ietf.org; Thu, 12 Oct 2006 04:34:54 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXw1k-0000bI-VF for dime@ietf.org; Thu, 12 Oct 2006 04:34:54 -0400 Received: by ug-out-1314.google.com with SMTP id 72so235134ugd for ; Thu, 12 Oct 2006 01:34:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=K7CjG5o0c2xmiU2ZmxGtUXpDz8/YRdVQw8CwB4KCDCpHDGzrkmKb/pnx9+iCgf4zeAaWKOzJqnAiBdiFsRaU1Q0fQeAOEse7SeyAdlKXVaD8UUyuD8z4xCoEXwxtnbBFYidswK4jVkijs3kW/8AcX8S9vAewb76pwegeuUAGIYg= Received: by 10.67.105.19 with SMTP id h19mr2329915ugm; Thu, 12 Oct 2006 01:34:52 -0700 (PDT) Received: by 10.66.237.2 with HTTP; Thu, 12 Oct 2006 01:34:52 -0700 (PDT) Message-ID: Date: Thu, 12 Oct 2006 10:34:52 +0200 From: "Gerardo Giaretta" To: "Vijay Devarapalli" Subject: Re: [Dime] HA-to-AAAH/HA as a single box ? In-Reply-To: <452D87ED.2000409@azairenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061006105832.GA27260@ipv6-3.int-evry.fr> <452D87ED.2000409@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 > > I also prefer start a new thread on this subject. > > > > Gerardo raised an issue concerning the fact that > > the IKEv2 Responder of the HA may also act as a VPN concentrator. > > IMO, this must be supported. > Agree (this is obvious since I raised the issue) > > > > The issue is that the IKEv2 responder has (a priori) no way to know > > if the IKEv2 Initiator wants mip6 service or VPN. > > there are many ways of doing this. some deployments use > the IDr field to indicate that you are going to use a > certain service. > based on this approach, the IDi (isn't the initiator's ID and not the reponder's?) must be chosen based on the service. This means that the MN needs to have different permanent long-lived identities for different services. This is doable but it seems it introduces an extra identity management effort. Obviously another approach would be to identify the service in IKEv2 exchange (e.g. using different CONFIG attributes for different services), but I'm not sure this can be acceptable for IPsec people. Some more suggestions? --Gerardo > Vijay > > > > > If it wants mip6 service, it should use 4072 in > > AUTHENTICATE_ONLY mode and then use the mip6 Authorization > > application. If it wants VPN, I guess 4072 would be used > > in a different way. > > > > So before trying to solve this, the question is to know wether > > we can assume that HA is a single box. > > > > I personnally would prefer assume the IKEv2 responder is only for > > HA and add a note in the document about this problem. > > > > Any comments ? > > > > Julien > > > > _______________________________________________ > > 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 Oct 12 04:49:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXwFL-0000QS-Kj; Thu, 12 Oct 2006 04:48:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXwFK-0000QN-UV for dime@ietf.org; Thu, 12 Oct 2006 04:48:54 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXwFJ-00047v-Hi for dime@ietf.org; Thu, 12 Oct 2006 04:48:54 -0400 Received: by ug-out-1314.google.com with SMTP id 72so236133ugd for ; Thu, 12 Oct 2006 01:48:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BTTVKYRTEoJOYehbDC/9pXZCwZIvF/AqXEY5q0GUwA5A3GwoaHyF8b/yiDUwZKg+3qTBVpJcBoy4bYGH6CFdh3Xfy8tx/DvuL5pJ2Ng3RjqnC93RcgG2jqMKZQ/DU92SdA2nNTvEb3rwjk9Dmm23+TYYWRtLYzvTVpRqyjOdYEo= Received: by 10.67.24.13 with SMTP id b13mr2370304ugj; Thu, 12 Oct 2006 01:48:52 -0700 (PDT) Received: by 10.66.237.2 with HTTP; Thu, 12 Oct 2006 01:48:52 -0700 (PDT) Message-ID: Date: Thu, 12 Oct 2006 10:48:52 +0200 From: "Gerardo Giaretta" To: "Vijay Devarapalli" Subject: Re: [Dime] Some thoughts about Diameter MIPv6 Application In-Reply-To: <452D86C0.5040200@azairenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <452D86C0.5040200@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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 Vijay, thanks for your comments. Please see inline... > > > > - first of all I think the proposal made by Yoshi to use rfc4072 in > > AUTHENTICATION_ONLY mode and define another MIP6-specific application > > for authorization is the right one. Indeed, this would let separate > > clearly the authentication procedure from the authorization step and I > > think this is really needed in case IKEv2 is used. Suppose for example > > a node acts as both VPN concentrator and HA (or 3GPP PDG and HA): it > > supports IKEv2 signaling and acts as EAP pass-through authenticator in > > order to setup the IPsec SA with the peer. If a MN starts an IKEv2 > > exchange with this node, this node has no way to know if the MN is > > going to use MIPv6 service or not (since the MN could be just setting > > up the SA for remore access). Therefore, we need to take into account > > that the HA is not sure that the MN is going to use MIPv6 service > > untill it receives a BU. In my view, this is a valid reason to keep > > authentication and authorization separated: the former is based on > > rfc4072 and occurs during IKEv2 exchange, the latter is mip6-specific > > and can be done later > > it should be possible to combine the two AAA round trips > when the VPN gateway and the MIP6 HA are co-located and > if it is known beforehand that the MS is going to be > using MIPv6 after the IPsec tunnel is setup. we shouldn't > _require_ two round trips. > Agree, if we can solve the issue about HA and VPN server co-location. But it seems to me that the correct design is to have the two AAA round trips as separated; obviously we can allow an optimization to have them combined if this is possible. > > - based on what stated above, the first authorization request should > > be sent by the HA upon the receipt of the first BU. However, this will > > increase the latency of the first registration, since the AAA of the > > MSA will be involved. Notice that in case the MN is moving from the > > home link to a visited link, the first registration has low handoff > > latency requirements. > > that is fine. RFC 3775 has defined a longer timer for > the initial BU to allow for DAD for the home address to > happen. > ok > > - based on draft-ietf-mip6-aaa-ha-goals the AAA server may send an > > Abort Session Request to the HA in order to stop the MIPv6 service for > > a MN. This message may be very similar to the ASR in NASREQ. One > > question is: from a MIPv6 perspective, is there any signaling the HA > > will send to the MN to communicate that the session is over for a > > specific reason? Or the MN is just blocked? > > the HA switch message from the HA to the MN can be used. > http://www.ietf.org/internet-drafts/draft-ietf-mip6-ha-switch-00.txt > Based on HA switch draft the MN MUST perform HA discovery if no HA addresses are provided in the HA switch message. However, in this scenario, the AAA server may just want to tear down the service. The MN should stop trying to access mobility service. We may use the HA switch message with a flag set in order to indicate that the service will be torn down. > > - I guess, as in NASREQ, the AAA-MSA sends an authorization lifetime > > to the HA and this lifetime will be renewed later. Is this > > authorization lifetime related with the BU/BA lifetime? Are they equal > > or orthogonal? The HA may set the binding lifetime in the BA equal to > > the authorization lifetime. Is this approach useful? > > they should be orthogonal. > any particular reason to not bind them? > > - on the identities used by the MN: which identity is used by the HA > > to identify the MN in the authorization phase? There is no identity in > > the BU, unless we use the HoA as the identity. Otherwise the HA must > > keep the identity used in IKEv2 by the MN. Any thought? > > identity used in IKEv2 should be used. if there is a need > for a separate identifier for MIPv6, RFC 4283 defines an > MN identifier option to carry, for e.g. an NAI. > good, agree that identity used in IKEv2 should be used. --Gerardo > Vijay > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 12 11:03:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY25h-0005xk-CX; Thu, 12 Oct 2006 11:03:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY25f-0005sQ-Ol for dime@ietf.org; Thu, 12 Oct 2006 11:03:19 -0400 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY25d-0006Jg-Er for dime@ietf.org; Thu, 12 Oct 2006 11:03:19 -0400 Received: from [10.1.210.8] ([66.92.223.6]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 08:00:43 -0700 Message-ID: <452E588C.7030604@azairenet.com> Date: Thu, 12 Oct 2006 08:00:28 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Gerardo Giaretta Subject: Re: [Dime] HA-to-AAAH/HA as a single box ? References: <20061006105832.GA27260@ipv6-3.int-evry.fr> <452D87ED.2000409@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2006 15:00:43.0450 (UTC) FILETIME=[30A249A0:01C6EE0F] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Gerardo Giaretta wrote: >> > >> > The issue is that the IKEv2 responder has (a priori) no way to know >> > if the IKEv2 Initiator wants mip6 service or VPN. >> >> there are many ways of doing this. some deployments use >> the IDr field to indicate that you are going to use a >> certain service. >> > > based on this approach, the IDi (isn't the initiator's ID and not the > reponder's?) must be chosen based on the service. This means that the > MN needs to have different permanent long-lived identities for > different services. This is doable but it seems it introduces an extra > identity management effort. > > Obviously another approach would be to identify the service in IKEv2 > exchange (e.g. using different CONFIG attributes for different > services), but I'm not sure this can be acceptable for IPsec people. > > Some more suggestions? do you want to find a solution for this on this mailing list or assume it would be possible to get an indication at the IKEv2 responder somehow? ;) Vijay _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 12 11:07:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY29x-0007LR-1i; Thu, 12 Oct 2006 11:07:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY29w-0007LJ-J6 for dime@ietf.org; Thu, 12 Oct 2006 11:07:44 -0400 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY29v-0007wP-5q for dime@ietf.org; Thu, 12 Oct 2006 11:07:44 -0400 Received: from [10.1.210.8] ([66.92.223.6]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 08:05:09 -0700 Message-ID: <452E59D8.8060203@azairenet.com> Date: Thu, 12 Oct 2006 08:06:00 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Gerardo Giaretta Subject: Re: [Dime] Some thoughts about Diameter MIPv6 Application References: <452D86C0.5040200@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2006 15:05:09.0310 (UTC) FILETIME=[CF194DE0:01C6EE0F] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 Gerardo Giaretta wrote: > Hi Vijay, > > thanks for your comments. Please see inline... > >> > >> > - first of all I think the proposal made by Yoshi to use rfc4072 in >> > AUTHENTICATION_ONLY mode and define another MIP6-specific application >> > for authorization is the right one. Indeed, this would let separate >> > clearly the authentication procedure from the authorization step and I >> > think this is really needed in case IKEv2 is used. Suppose for example >> > a node acts as both VPN concentrator and HA (or 3GPP PDG and HA): it >> > supports IKEv2 signaling and acts as EAP pass-through authenticator in >> > order to setup the IPsec SA with the peer. If a MN starts an IKEv2 >> > exchange with this node, this node has no way to know if the MN is >> > going to use MIPv6 service or not (since the MN could be just setting >> > up the SA for remore access). Therefore, we need to take into account >> > that the HA is not sure that the MN is going to use MIPv6 service >> > untill it receives a BU. In my view, this is a valid reason to keep >> > authentication and authorization separated: the former is based on >> > rfc4072 and occurs during IKEv2 exchange, the latter is mip6-specific >> > and can be done later >> >> it should be possible to combine the two AAA round trips >> when the VPN gateway and the MIP6 HA are co-located and >> if it is known beforehand that the MS is going to be >> using MIPv6 after the IPsec tunnel is setup. we shouldn't >> _require_ two round trips. >> > > Agree, if we can solve the issue about HA and VPN server co-location. > But it seems to me that the correct design is to have the two AAA > round trips as separated; obviously we can allow an optimization to > have them combined if this is possible. right. >> > - based on draft-ietf-mip6-aaa-ha-goals the AAA server may send an >> > Abort Session Request to the HA in order to stop the MIPv6 service for >> > a MN. This message may be very similar to the ASR in NASREQ. One >> > question is: from a MIPv6 perspective, is there any signaling the HA >> > will send to the MN to communicate that the session is over for a >> > specific reason? Or the MN is just blocked? >> >> the HA switch message from the HA to the MN can be used. >> http://www.ietf.org/internet-drafts/draft-ietf-mip6-ha-switch-00.txt >> > > Based on HA switch draft the MN MUST perform HA discovery if no HA > addresses are provided in the HA switch message. However, in this > scenario, the AAA server may just want to tear down the service. The > MN should stop trying to access mobility service. > > We may use the HA switch message with a flag set in order to indicate > that the service will be torn down. it would be good to discuss this on the MIP6 mailing list. the HA Switch message can have a flag to say MIPv6 service is not available anymore. >> > - I guess, as in NASREQ, the AAA-MSA sends an authorization lifetime >> > to the HA and this lifetime will be renewed later. Is this >> > authorization lifetime related with the BU/BA lifetime? Are they equal >> > or orthogonal? The HA may set the binding lifetime in the BA equal to >> > the authorization lifetime. Is this approach useful? >> >> they should be orthogonal. >> > any particular reason to not bind them? the BU lifetime is proposed by the MN and the HA normally agrees to it (unless it is larger than the maximum binding lifetime on the HA). the authorization lifetime is decided by the AAA-MSA. I don't see an advantage in trying to bind them. Vijay _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 12 11:11:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY2Do-0001ok-K1; Thu, 12 Oct 2006 11:11:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY2Dn-0001ir-ED for dime@ietf.org; Thu, 12 Oct 2006 11:11:43 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY2Dk-00010w-OT for dime@ietf.org; Thu, 12 Oct 2006 11:11:43 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k9CFBWEa026687; Fri, 13 Oct 2006 00:11:32 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k9CFBXwi006304; Fri, 13 Oct 2006 00:11:33 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with ESMTP id AAA06302; Fri, 13 Oct 2006 00:11:33 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k9CFBVx1011093; Fri, 13 Oct 2006 00:11:31 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k9CFBVvu011502; Fri, 13 Oct 2006 00:11:31 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J71002SA3J21J20@mail.po.toshiba.co.jp>; Fri, 13 Oct 2006 00:11:31 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GY2DY-0004iv-Bo; Thu, 12 Oct 2006 08:11:28 -0700 Date: Thu, 12 Oct 2006 11:11:28 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] HA-to-AAAH/HA as a single box ? In-reply-to: To: Gerardo Giaretta Message-id: <20061012151128.GE16571@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20061006105832.GA27260@ipv6-3.int-evry.fr> <452D87ED.2000409@azairenet.com> User-Agent: Mutt/1.5.13 (2006-08-11) 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 On Thu, Oct 12, 2006 at 10:34:52AM +0200, Gerardo Giaretta wrote: (snip) > > Obviously another approach would be to identify the service in IKEv2 > exchange (e.g. using different CONFIG attributes for different > services), but I'm not sure this can be acceptable for IPsec people. It seems that identification of service within IKEv2 can be a rat hole because of ambiguity of the term "service" in IKEv2. I believe this approach is difficult to succeed. Yoshihiro Ohba > > Some more suggestions? > > --Gerardo > > >Vijay > > > >> > >> If it wants mip6 service, it should use 4072 in > >> AUTHENTICATE_ONLY mode and then use the mip6 Authorization > >> application. If it wants VPN, I guess 4072 would be used > >> in a different way. > >> > >> So before trying to solve this, the question is to know wether > >> we can assume that HA is a single box. > >> > >> I personnally would prefer assume the IKEv2 responder is only for > >> HA and add a note in the document about this problem. > >> > >> Any comments ? > >> > >> Julien > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > > > > > >_______________________________________________ > >DiME mailing list > >DiME@ietf.org > >https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 12 11:14:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY2Gn-0004hs-8Z; Thu, 12 Oct 2006 11:14:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY2Gl-0004hm-OT for dime@ietf.org; Thu, 12 Oct 2006 11:14:48 -0400 Received: from wr-out-0506.google.com ([64.233.184.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY2Gk-0001oB-Gl for dime@ietf.org; Thu, 12 Oct 2006 11:14:47 -0400 Received: by wr-out-0506.google.com with SMTP id i32so117929wra for ; Thu, 12 Oct 2006 08:14:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PIiZr99kY5XKt+2Bs/st91CWqQRmNZbGoH/WUsrFIWfAMiyFEVwX91CYyzlzXNaL4lvanNbRtBNXOq3F7Kg9mDMebCaxyS/VY3HVa3W3wY7yw/Ls+CbzYrTGKjRQAlx1vLJtRRGKZp2CvyV5oGRoXHfwZnCCiRXT8UiC4aD3tVE= Received: by 10.90.90.3 with SMTP id n3mr1358187agb; Thu, 12 Oct 2006 08:14:46 -0700 (PDT) Received: by 10.90.84.9 with HTTP; Thu, 12 Oct 2006 08:14:46 -0700 (PDT) Message-ID: <5e2406980610120814s28b2cf14s1afa439aaef6a038@mail.gmail.com> Date: Thu, 12 Oct 2006 17:14:46 +0200 From: "Julien Bournelle" To: "Vijay Devarapalli" Subject: Re: [Dime] HA-to-AAAH/HA as a single box ? In-Reply-To: <452E588C.7030604@azairenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061006105832.GA27260@ipv6-3.int-evry.fr> <452D87ED.2000409@azairenet.com> <452E588C.7030604@azairenet.com> X-Spam-Score: 0.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 Hi vijay, all, On 10/12/06, Vijay Devarapalli wrote: > Gerardo Giaretta wrote: > > >> > > >> > The issue is that the IKEv2 responder has (a priori) no way to know > >> > if the IKEv2 Initiator wants mip6 service or VPN. > >> > >> there are many ways of doing this. some deployments use > >> the IDr field to indicate that you are going to use a > >> certain service. > >> > > > > based on this approach, the IDi (isn't the initiator's ID and not the > > reponder's?) must be chosen based on the service. This means that the > > MN needs to have different permanent long-lived identities for > > different services. This is doable but it seems it introduces an extra > > identity management effort. > > > > Obviously another approach would be to identify the service in IKEv2 > > exchange (e.g. using different CONFIG attributes for different > > services), but I'm not sure this can be acceptable for IPsec people. > > > > Some more suggestions? > > do you want to find a solution for this on this > mailing list or assume it would be possible to get > an indication at the IKEv2 responder somehow? ;) I personnaly would prefer assume that the IKEV2 responder has a way to differentiate but not deal with that in the document (however we may add a quick note on this) Julien > > Vijay > > _______________________________________________ > 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 Oct 12 14:19:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY59N-0007sa-SP; Thu, 12 Oct 2006 14:19:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY59M-0007s3-76; Thu, 12 Oct 2006 14:19:20 -0400 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY59K-00062i-UG; Thu, 12 Oct 2006 14:19:20 -0400 Received: from [10.1.201.0] ([66.92.223.6]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 11:19:18 -0700 Message-ID: <452E862E.7010809@azairenet.com> Date: Thu, 12 Oct 2006 11:15:10 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.5 (X11/20060812) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Dime] Impact of RFC 4285 for Diameter MIP6 Bootstrapping Work References: <451B7EC0.70801@gmx.net> In-Reply-To: <451B7EC0.70801@gmx.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2006 18:19:18.0229 (UTC) FILETIME=[EE654850:01C6EE2A] X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 looks like nobody replied to this email. :) Hannes Tschofenig wrote: > Hi all, > > in the DIME working group we are currently producing documents that > relate to the backend solution of the > > * Integrated Scenario > draft-ietf-mip6-bootstrapping-integrated-dhc-01 > > * Split Scenario > draft-ietf-mip6-bootstrapping-split-02 > > Now, the question came up whether we have to consider RFC 4285 > ('Authentication Protocol for Mobile IPv6') for our work as well. currently it is not clear if we are going to do any further work on RFC 4285 in the MIP6 WG. so my suggestion is to assume only the use of IKEv2 (with and without EAP). but it would be good to keep the solution flexible so that it can be extended later for 4285 if required. Vijay _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 13 00:00:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYEDs-0000NG-5M; Fri, 13 Oct 2006 00:00:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYEDr-0000NA-95 for dime@ietf.org; Fri, 13 Oct 2006 00:00:35 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYEDo-00017I-QP for dime@ietf.org; Fri, 13 Oct 2006 00:00:35 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id CB655900D7 for ; Fri, 13 Oct 2006 00:00:28 -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 01721-05 for ; Fri, 13 Oct 2006 00:00:28 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 13 Oct 2006 00:00:28 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 00:00:28 -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] HA-to-AAAH/HA as a single box ? Date: Fri, 13 Oct 2006 00:00:27 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD3C4@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] HA-to-AAAH/HA as a single box ? Thread-Index: Acbtk2rxsYJlmYH1R2SjJW1zR1nSPAA6F8KQ From: "Chowdhury, Kuntal" To: "Vijay Devarapalli" , "Julien Bournelle" X-OriginalArrivalTime: 13 Oct 2006 04:00:28.0052 (UTC) FILETIME=[1E6E0540:01C6EE7C] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Wednesday, October 11, 2006 7:10 PM > To: Julien Bournelle > Cc: dime@ietf.org > Subject: Re: [Dime] HA-to-AAAH/HA as a single box ? >=20 > Julien Bournelle wrote: > > Hi all, > > > > I also prefer start a new thread on this subject. > > > > Gerardo raised an issue concerning the fact that > > the IKEv2 Responder of the HA may also act as a VPN concentrator. >=20 > IMO, this must be supported. >=20 [KC>] Not sure why you say so. We are talking about Diameter MIP6 support here. Having a VPN concentrator in the HA is an implementation choice, albeit quite common. But within the context of MIP6, it seems irrelevant.=20 > > > > The issue is that the IKEv2 responder has (a priori) no way to know > > if the IKEv2 Initiator wants mip6 service or VPN. >=20 > there are many ways of doing this. some deployments use > the IDr field to indicate that you are going to use a > certain service. >=20 [KC>] Hmmm...which deployments? As far as 3GPP2 (X.P0028-200) is concerned, service identifier in IDr is history. > Vijay >=20 > > > > If it wants mip6 service, it should use 4072 in > > AUTHENTICATE_ONLY mode and then use the mip6 Authorization > > application. If it wants VPN, I guess 4072 would be used > > in a different way. > > > > So before trying to solve this, the question is to know wether > > we can assume that HA is a single box. > > > > I personnally would prefer assume the IKEv2 responder is only for > > HA and add a note in the document about this problem. > > > > Any comments ? > > > > Julien > > > > _______________________________________________ > > 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 Fri Oct 13 00:06:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYEJP-00049U-Hb; Fri, 13 Oct 2006 00:06:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYEJN-00046c-ML for dime@ietf.org; Fri, 13 Oct 2006 00:06:17 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYEJJ-0001fo-1I for dime@ietf.org; Fri, 13 Oct 2006 00:06:17 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id A360A90019 for ; Fri, 13 Oct 2006 00:06:09 -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 01866-01 for ; Fri, 13 Oct 2006 00:06:08 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 13 Oct 2006 00:06:08 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 00:06:08 -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] HA-to-AAAH/HA as a single box ? Date: Fri, 13 Oct 2006 00:06:08 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD3C5@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] HA-to-AAAH/HA as a single box ? Thread-Index: Acbt2WN7Ttg5g700ShC5uR6n24bQLgAoyjxA From: "Chowdhury, Kuntal" To: "Gerardo Giaretta" , "Vijay Devarapalli" X-OriginalArrivalTime: 13 Oct 2006 04:06:08.0864 (UTC) FILETIME=[E991CE00:01C6EE7C] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 Vijay/Gerardo, I think you are complicating the Diameter based HA-HAAA interface by introducing this orthogonal VPN concept here. IMHO, if the MN tries to establish IPsec/IKEv2 with the HA it is assumed to initiate MIP6. Otherwise, why would the HA contact the MSA for EAP authorization? I am sure a VPN concentrator has no idea about MSA. -Kuntal =20 > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Thursday, October 12, 2006 3:35 AM > To: Vijay Devarapalli > Cc: dime@ietf.org > Subject: Re: [Dime] HA-to-AAAH/HA as a single box ? >=20 > > > I also prefer start a new thread on this subject. > > > > > > Gerardo raised an issue concerning the fact that > > > the IKEv2 Responder of the HA may also act as a VPN concentrator. > > > > IMO, this must be supported. > > >=20 > Agree (this is obvious since I raised the issue) >=20 > > > > > > The issue is that the IKEv2 responder has (a priori) no way to know > > > if the IKEv2 Initiator wants mip6 service or VPN. > > > > there are many ways of doing this. some deployments use > > the IDr field to indicate that you are going to use a > > certain service. > > >=20 > based on this approach, the IDi (isn't the initiator's ID and not the > reponder's?) must be chosen based on the service. This means that the > MN needs to have different permanent long-lived identities for > different services. This is doable but it seems it introduces an extra > identity management effort. >=20 > Obviously another approach would be to identify the service in IKEv2 > exchange (e.g. using different CONFIG attributes for different > services), but I'm not sure this can be acceptable for IPsec people. >=20 > Some more suggestions? >=20 > --Gerardo >=20 > > Vijay > > > > > > > > If it wants mip6 service, it should use 4072 in > > > AUTHENTICATE_ONLY mode and then use the mip6 Authorization > > > application. If it wants VPN, I guess 4072 would be used > > > in a different way. > > > > > > So before trying to solve this, the question is to know wether > > > we can assume that HA is a single box. > > > > > > I personnally would prefer assume the IKEv2 responder is only for > > > HA and add a note in the document about this problem. > > > > > > Any comments ? > > > > > > Julien > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 13 01:25:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYFXq-0007fM-9a; Fri, 13 Oct 2006 01:25:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYFXo-0007eY-Ue for dime@ietf.org; Fri, 13 Oct 2006 01:25:16 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYFXm-0004xN-Fe for dime@ietf.org; Fri, 13 Oct 2006 01:25:16 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 07:25:00 +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] HA-to-AAAH/HA as a single box ? Date: Fri, 13 Oct 2006 07:24:58 +0200 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E030135A364@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] HA-to-AAAH/HA as a single box ? Thread-Index: Acbtk2rxsYJlmYH1R2SjJW1zR1nSPAA6F8KQAALl+7A= From: To: , , X-OriginalArrivalTime: 13 Oct 2006 05:25:00.0799 (UTC) FILETIME=[EE05C8F0:01C6EE87] X-Spam-Score: 0.2 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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 Kuntal,=20 See a comment below. > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 > Sent: 13. lokakuuta 2006 7:00 > To: Vijay Devarapalli; Julien Bournelle > Cc: dime@ietf.org > Subject: RE: [Dime] HA-to-AAAH/HA as a single box ? >=20 >=20 >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > Sent: Wednesday, October 11, 2006 7:10 PM > > To: Julien Bournelle > > Cc: dime@ietf.org > > Subject: Re: [Dime] HA-to-AAAH/HA as a single box ? > >=20 > > Julien Bournelle wrote: > > > Hi all, > > > > > > I also prefer start a new thread on this subject. > > > > > > Gerardo raised an issue concerning the fact that > > > the IKEv2 Responder of the HA may also act as a VPN=20 > concentrator. > >=20 > > IMO, this must be supported. > >=20 > [KC>] Not sure why you say so. We are talking about Diameter MIP6 > support here. Having a VPN concentrator in the HA is an implementation > choice, albeit quite common. But within the context of MIP6, it seems > irrelevant.=20 >=20 > > > > > > The issue is that the IKEv2 responder has (a priori) no way to > know > > > if the IKEv2 Initiator wants mip6 service or VPN. > >=20 > > there are many ways of doing this. some deployments use > > the IDr field to indicate that you are going to use a > > certain service. > >=20 > [KC>] Hmmm...which deployments? As far as 3GPP2 (X.P0028-200) is > concerned, service identifier in IDr is history. E.g. 3GPP I-WLAN does W-APN selection in this way. Cheers, Jouni >=20 >=20 > > Vijay > >=20 > > > > > > If it wants mip6 service, it should use 4072 in > > > AUTHENTICATE_ONLY mode and then use the mip6 Authorization > > > application. If it wants VPN, I guess 4072 would be used > > > in a different way. > > > > > > So before trying to solve this, the question is to know wether > > > we can assume that HA is a single box. > > > > > > I personnally would prefer assume the IKEv2 responder=20 > is only for > > > HA and add a note in the document about this problem. > > > > > > Any comments ? > > > > > > Julien > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 13 03:36:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYHav-0004NK-8s; Fri, 13 Oct 2006 03:36:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYHat-0004H4-PL for dime@ietf.org; Fri, 13 Oct 2006 03:36:35 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYHas-0003Mo-Eh for dime@ietf.org; Fri, 13 Oct 2006 03:36:35 -0400 Received: by ug-out-1314.google.com with SMTP id 72so380428ugd for ; Fri, 13 Oct 2006 00:36:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FaF0OOdCMT5OIuFXVGcinmsfZXMUovGbJyvsp0FlM7QwQVzYdhV04ijFGkBXsiJuNwMaU1WXnt4Ro6j/nd/+5LYTHnDVsJry/fDkE8tui7wWypSsacXDoeByS/Baul+vsdF6zFL6O06e5cn5KfmgmlxoWevEdErLY24pL0To5GM= Received: by 10.67.100.12 with SMTP id c12mr3953512ugm; Fri, 13 Oct 2006 00:36:33 -0700 (PDT) Received: by 10.66.243.16 with HTTP; Fri, 13 Oct 2006 00:36:33 -0700 (PDT) Message-ID: Date: Fri, 13 Oct 2006 09:36:33 +0200 From: "Gerardo Giaretta" To: "Vijay Devarapalli" Subject: Re: [Dime] Impact of RFC 4285 for Diameter MIP6 Bootstrapping Work In-Reply-To: <452E862E.7010809@azairenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <451B7EC0.70801@gmx.net> <452E862E.7010809@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 > > in the DIME working group we are currently producing documents that > > relate to the backend solution of the > > > > * Integrated Scenario > > draft-ietf-mip6-bootstrapping-integrated-dhc-01 > > > > * Split Scenario > > draft-ietf-mip6-bootstrapping-split-02 > > > > Now, the question came up whether we have to consider RFC 4285 > > ('Authentication Protocol for Mobile IPv6') for our work as well. > > currently it is not clear if we are going to do any > further work on RFC 4285 in the MIP6 WG. so my > suggestion is to assume only the use of IKEv2 (with > and without EAP). > Agree with Vijay, this is also the assumption for the AAA goals draft. --Gerardo > but it would be good to keep the solution flexible > so that it can be extended later for 4285 if required. > > Vijay > > _______________________________________________ > 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 Oct 19 16:02:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gae61-0006pY-0b; Thu, 19 Oct 2006 16:02:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gae5y-0006kK-Ji; Thu, 19 Oct 2006 16:02:26 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gae5x-0000Cx-2l; Thu, 19 Oct 2006 16:02:26 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7E007NQFIT3D@usaga01-in.huawei.com>; Thu, 19 Oct 2006 12:59:18 -0700 (PDT) Received: from huawei6cc10c70 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7E0007RFIPRQ@usaga01-in.huawei.com>; Thu, 19 Oct 2006 12:59:17 -0700 (PDT) Date: Thu, 19 Oct 2006 13:02:19 -0700 From: Madjid Nakhjiri Subject: RE: [Mip6] Re: [Dime] Impact of RFC 4285 for Diameter MIP6 Bootstrapping Work In-reply-to: <452E862E.7010809@azairenet.com> To: 'Vijay Devarapalli' , 'Hannes Tschofenig' Message-id: <001501c6f3b9$7be40c00$2f01a8c0@huawei6cc10c70> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbuLV5RCJ2MDyrDTKO2btQNWvJufwFiWlSw X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 I would agree with Vijay as well. But, we need to see if we have the process in place for this to happen and what the consequences for inserting that process is. These specs are being produced addressing the set of requirements in HA-AAAH document (not sure if other requirement docs are in place). The way I understand it that requirement documents were not written to address the 4285 requirements specifically. If my understanding incorrect and people think the requirement docs include 4285-related requirements, then, that is fine and hopefully the specs will address most of the 4285 needs (except possibly some AVPs that may be added later) either initially or through revisions. However, if my understanding is correct and the requirements docs do not include 4285 requirements, why would we expect the design specs will automatically? Does the group feel it want to spend time issuing a set of requirements to meet 4285 needs and then design accordingly? If not, then I think we should just accept that the outcoming specs simply MAY support 4285. I am sure the two WGs do not appreciate this issue being raised two years down the road. What I am missing here? R, Madjid -----Original Message----- From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] Sent: Thursday, October 12, 2006 11:15 AM To: Hannes Tschofenig Cc: mip6@ietf.org; dime@ietf.org Subject: [Mip6] Re: [Dime] Impact of RFC 4285 for Diameter MIP6 Bootstrapping Work looks like nobody replied to this email. :) Hannes Tschofenig wrote: > Hi all, > > in the DIME working group we are currently producing documents that > relate to the backend solution of the > > * Integrated Scenario > draft-ietf-mip6-bootstrapping-integrated-dhc-01 > > * Split Scenario > draft-ietf-mip6-bootstrapping-split-02 > > Now, the question came up whether we have to consider RFC 4285 > ('Authentication Protocol for Mobile IPv6') for our work as well. currently it is not clear if we are going to do any further work on RFC 4285 in the MIP6 WG. so my suggestion is to assume only the use of IKEv2 (with and without EAP). but it would be good to keep the solution flexible so that it can be extended later for 4285 if required. Vijay _______________________________________________ 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 Oct 19 16:04:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gae80-0000cb-BN; Thu, 19 Oct 2006 16:04:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gae7g-000081-MT; Thu, 19 Oct 2006 16:04:12 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gae7d-0000zi-Ka; Thu, 19 Oct 2006 16:04:12 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7E0070HFLQ3D@usaga01-in.huawei.com>; Thu, 19 Oct 2006 13:01:03 -0700 (PDT) Received: from huawei6cc10c70 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7E006PHFLM0D@usaga01-in.huawei.com>; Thu, 19 Oct 2006 13:01:02 -0700 (PDT) Date: Thu, 19 Oct 2006 13:04:04 -0700 From: Madjid Nakhjiri Subject: RE: [Dime] Impact of RFC 4285 for Diameter MIP6 Bootstrapping Work In-reply-to: To: 'Gerardo Giaretta' , 'Vijay Devarapalli' Message-id: <001601c6f3b9$bab56ff0$2f01a8c0@huawei6cc10c70> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acbumw6p3zT0zAqJTneSA123Ge3v5wFHn+Cw X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Ok, so I see I spend a long email without reading the rest of the thread. Do we feel the AAA goal draft efficiently captures the 4285 requirements? If yes, sorry for clogging your mailboxes.. R, Madjid -----Original Message----- From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] Sent: Friday, October 13, 2006 12:37 AM To: Vijay Devarapalli Cc: mip6@ietf.org; dime@ietf.org Subject: Re: [Dime] Impact of RFC 4285 for Diameter MIP6 Bootstrapping Work > > in the DIME working group we are currently producing documents that > > relate to the backend solution of the > > > > * Integrated Scenario > > draft-ietf-mip6-bootstrapping-integrated-dhc-01 > > > > * Split Scenario > > draft-ietf-mip6-bootstrapping-split-02 > > > > Now, the question came up whether we have to consider RFC 4285 > > ('Authentication Protocol for Mobile IPv6') for our work as well. > > currently it is not clear if we are going to do any > further work on RFC 4285 in the MIP6 WG. so my > suggestion is to assume only the use of IKEv2 (with > and without EAP). > Agree with Vijay, this is also the assumption for the AAA goals draft. --Gerardo > but it would be good to keep the solution flexible > so that it can be extended later for 4285 if required. > > Vijay > > _______________________________________________ > 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 Oct 19 16:33:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaeZZ-0000wO-I5; Thu, 19 Oct 2006 16:33:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaeZY-0000v5-H5; Thu, 19 Oct 2006 16:33:00 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaeZO-0005We-K6; Thu, 19 Oct 2006 16:33:00 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k9JKWeeG020052; Fri, 20 Oct 2006 05:32:40 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k9JKWepU001656; Fri, 20 Oct 2006 05:32:40 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with ESMTP id FAA01655; Fri, 20 Oct 2006 05:32:40 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k9JKWd00019452; Fri, 20 Oct 2006 05:32:39 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k9JKWdod007994; Fri, 20 Oct 2006 05:32:39 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J7E00FZ1H29EQK0@mail.po.toshiba.co.jp>; Fri, 20 Oct 2006 05:32:38 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GaeZ6-0000LK-NX; Thu, 19 Oct 2006 13:32:32 -0700 Date: Thu, 19 Oct 2006 16:32:32 -0400 From: Yoshihiro Ohba Subject: Re: [Mip6] RE: [Dime] Impact of RFC 4285 for Diameter MIP6 Bootstrapping Work In-reply-to: <001601c6f3b9$bab56ff0$2f01a8c0@huawei6cc10c70> To: Madjid Nakhjiri Message-id: <20061019203232.GF30464@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <001601c6f3b9$bab56ff0$2f01a8c0@huawei6cc10c70> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 Madjid, On Thu, Oct 19, 2006 at 01:04:04PM -0700, Madjid Nakhjiri wrote: > Ok, so I see I spend a long email without reading the rest of the thread. > Do we feel the AAA goal draft efficiently captures the 4285 requirements? > If yes, sorry for clogging your mailboxes.. That is my feeling and is why I had the following comment on aaa-ha-goals draft: " YO: This document seems to assume the use of IPsec between MN and HA for securing Mobile IPv6 signaling. But the AAA interface could also be used for RFC 4285. So I think it might be good to mention in this section that the document may not preclude the use of alternative methods for securing Mobile IPv6 signaling between MN and HA while this document focuses on the use of IPsec between MN and HA. " Yoshihiro Ohba > > R, > > Madjid > > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Friday, October 13, 2006 12:37 AM > To: Vijay Devarapalli > Cc: mip6@ietf.org; dime@ietf.org > Subject: Re: [Dime] Impact of RFC 4285 for Diameter MIP6 Bootstrapping Work > > > > in the DIME working group we are currently producing documents that > > > relate to the backend solution of the > > > > > > * Integrated Scenario > > > draft-ietf-mip6-bootstrapping-integrated-dhc-01 > > > > > > * Split Scenario > > > draft-ietf-mip6-bootstrapping-split-02 > > > > > > Now, the question came up whether we have to consider RFC 4285 > > > ('Authentication Protocol for Mobile IPv6') for our work as well. > > > > currently it is not clear if we are going to do any > > further work on RFC 4285 in the MIP6 WG. so my > > suggestion is to assume only the use of IKEv2 (with > > and without EAP). > > > > Agree with Vijay, this is also the assumption for the AAA goals draft. > > --Gerardo > > > but it would be good to keep the solution flexible > > so that it can be extended later for 4285 if required. > > > > Vijay > > > > _______________________________________________ > > 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 > > > > _______________________________________________ > 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 Oct 19 17:15:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GafEZ-0001qH-Bl; Thu, 19 Oct 2006 17:15:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GafEY-0001of-9T; Thu, 19 Oct 2006 17:15:22 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GafEV-0003lY-UD; Thu, 19 Oct 2006 17:15:22 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7E007N6IWD3D@usaga01-in.huawei.com>; Thu, 19 Oct 2006 14:12:13 -0700 (PDT) Received: from huawei6cc10c70 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7E000SIIW8CJ@usaga01-in.huawei.com>; Thu, 19 Oct 2006 14:12:13 -0700 (PDT) Date: Thu, 19 Oct 2006 14:15:14 -0700 From: Madjid Nakhjiri Subject: RE: [Mip6] RE: [Dime] Impact of RFC 4285 for Diameter MIP6 Bootstrapping Work In-reply-to: <20061019203232.GF30464@steelhead> To: 'Yoshihiro Ohba' Message-id: <002f01c6f3c3$aba66960$2f01a8c0@huawei6cc10c70> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbzvlwH1HPrrrslT/+MNONAfYCxEQAA1Jwg X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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 Yoshi, I agree, no point on insisting that solutions would support 4285, if 4285 requirements are not included. I can think of aspects of 4285 that can be problematic, but won't mention them now, since I don't want to be accused of opening the pandora's box while aaa-ha-goals is going through last call or the dime docs are underway :) We should not make claims we cannot back up later as that might derail the standardization process two years from now. As Persians say (after a lousy marketing translation) "A small quarrel in the beginning better than a bloody peace at the end" R, Madjid -----Original Message----- From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] Sent: Thursday, October 19, 2006 1:33 PM To: Madjid Nakhjiri Cc: 'Gerardo Giaretta'; 'Vijay Devarapalli'; mip6@ietf.org; dime@ietf.org Subject: Re: [Mip6] RE: [Dime] Impact of RFC 4285 for Diameter MIP6 Bootstrapping Work Madjid, On Thu, Oct 19, 2006 at 01:04:04PM -0700, Madjid Nakhjiri wrote: > Ok, so I see I spend a long email without reading the rest of the thread. > Do we feel the AAA goal draft efficiently captures the 4285 requirements? > If yes, sorry for clogging your mailboxes.. That is my feeling and is why I had the following comment on aaa-ha-goals draft: " YO: This document seems to assume the use of IPsec between MN and HA for securing Mobile IPv6 signaling. But the AAA interface could also be used for RFC 4285. So I think it might be good to mention in this section that the document may not preclude the use of alternative methods for securing Mobile IPv6 signaling between MN and HA while this document focuses on the use of IPsec between MN and HA. " Yoshihiro Ohba > > R, > > Madjid > > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Friday, October 13, 2006 12:37 AM > To: Vijay Devarapalli > Cc: mip6@ietf.org; dime@ietf.org > Subject: Re: [Dime] Impact of RFC 4285 for Diameter MIP6 Bootstrapping Work > > > > in the DIME working group we are currently producing documents that > > > relate to the backend solution of the > > > > > > * Integrated Scenario > > > draft-ietf-mip6-bootstrapping-integrated-dhc-01 > > > > > > * Split Scenario > > > draft-ietf-mip6-bootstrapping-split-02 > > > > > > Now, the question came up whether we have to consider RFC 4285 > > > ('Authentication Protocol for Mobile IPv6') for our work as well. > > > > currently it is not clear if we are going to do any > > further work on RFC 4285 in the MIP6 WG. so my > > suggestion is to assume only the use of IKEv2 (with > > and without EAP). > > > > Agree with Vijay, this is also the assumption for the AAA goals draft. > > --Gerardo > > > but it would be good to keep the solution flexible > > so that it can be extended later for 4285 if required. > > > > Vijay > > > > _______________________________________________ > > 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 > > > > _______________________________________________ > 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 Fri Oct 20 04:09:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GapPc-0005xZ-8Y; Fri, 20 Oct 2006 04:07:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GapPX-0005sC-3Y for dime@ietf.org; Fri, 20 Oct 2006 04:07:23 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GapKe-0001Zl-3S for dime@ietf.org; Fri, 20 Oct 2006 04:02:21 -0400 Received: by ug-out-1314.google.com with SMTP id 72so610068ugd for ; Fri, 20 Oct 2006 01:02:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UuuWl5rs+cklGm8lD+9VejwoWQEI5DOIQUrjCtLF05weekl2IMRjN202yV5jB1iIcZBn6gW9NxtKSO1XyZZSIJgHTrTXgf7GRpFbbQHh5OV1fAlrrnyWjdw+q/3u67lVzUfG4NoPWWbRlDBe6UjBxatGWfSB+dzcZxIkX3OKL/k= Received: by 10.67.89.5 with SMTP id r5mr1423430ugl; Fri, 20 Oct 2006 01:02:18 -0700 (PDT) Received: by 10.66.243.16 with HTTP; Fri, 20 Oct 2006 01:02:18 -0700 (PDT) Message-ID: Date: Fri, 20 Oct 2006 10:02:18 +0200 From: "Gerardo Giaretta" To: "Madjid Nakhjiri" , "Yoshihiro Ohba" Subject: Re: [Mip6] RE: [Dime] Impact of RFC 4285 for Diameter MIP6 Bootstrapping Work In-Reply-To: <002f01c6f3c3$aba66960$2f01a8c0@huawei6cc10c70> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061019203232.GF30464@steelhead> <002f01c6f3c3$aba66960$2f01a8c0@huawei6cc10c70> X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab 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 Yoshi and Madjid, the AAA goals draft does not include any specific goal for rfc4285. This issue was raised in Montreal and during MIP6 re-chartering discussion. The outcome of the discussion was that there is no a clear interest now in the IETF to standardize a bootstrapping solution for rfc4285 and a Diameter Application that supports rfc4285. MIP6 chairs and Jari mentioned that they may ask for rfc4285 support if significant interest will be raised. Remember also that rfc4285 is informational and the Diameter Application will be PS: not sure how to this difference would be handled. Having said that, I think that the approach taken so far in the design of the Diameter Application is flexible enough to include rfc4285 later without any big change: the authorization application does not need to be changed for rfc4285 support and we may define another application for authentication purposes. Therefore the authentication/authorization split seems a correct approach in order to introduce rfc4285 support later. --Gerardo On 10/19/06, Madjid Nakhjiri wrote: > Hi Yoshi, > > I agree, no point on insisting that solutions would support 4285, if 4285 > requirements are not included. I can think of aspects of 4285 that can be > problematic, but won't mention them now, since I don't want to be accused of > opening the pandora's box while aaa-ha-goals is going through last call or > the dime docs are underway :) > > We should not make claims we cannot back up later as that might derail the > standardization process two years from now. As Persians say (after a lousy > marketing translation) "A small quarrel in the beginning better than a > bloody peace at the end" > > > > R, > > Madjid > > > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Thursday, October 19, 2006 1:33 PM > To: Madjid Nakhjiri > Cc: 'Gerardo Giaretta'; 'Vijay Devarapalli'; mip6@ietf.org; dime@ietf.org > Subject: Re: [Mip6] RE: [Dime] Impact of RFC 4285 for Diameter MIP6 > Bootstrapping Work > > Madjid, > > On Thu, Oct 19, 2006 at 01:04:04PM -0700, Madjid Nakhjiri wrote: > > Ok, so I see I spend a long email without reading the rest of the thread. > > Do we feel the AAA goal draft efficiently captures the 4285 requirements? > > If yes, sorry for clogging your mailboxes.. > > That is my feeling and is why I had the following comment on aaa-ha-goals > draft: > > " > YO: This document seems to assume the use of IPsec between MN and HA > for securing Mobile IPv6 signaling. But the AAA interface could > also be used for RFC 4285. So I think it might be good to mention > in this section that the document may not preclude the use of > alternative methods for securing Mobile IPv6 signaling between MN > and HA while this document focuses on the use of IPsec between MN > and HA. > " > > Yoshihiro Ohba > > > > > > R, > > > > Madjid > > > > -----Original Message----- > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > Sent: Friday, October 13, 2006 12:37 AM > > To: Vijay Devarapalli > > Cc: mip6@ietf.org; dime@ietf.org > > Subject: Re: [Dime] Impact of RFC 4285 for Diameter MIP6 Bootstrapping > Work > > > > > > in the DIME working group we are currently producing documents that > > > > relate to the backend solution of the > > > > > > > > * Integrated Scenario > > > > draft-ietf-mip6-bootstrapping-integrated-dhc-01 > > > > > > > > * Split Scenario > > > > draft-ietf-mip6-bootstrapping-split-02 > > > > > > > > Now, the question came up whether we have to consider RFC 4285 > > > > ('Authentication Protocol for Mobile IPv6') for our work as well. > > > > > > currently it is not clear if we are going to do any > > > further work on RFC 4285 in the MIP6 WG. so my > > > suggestion is to assume only the use of IKEv2 (with > > > and without EAP). > > > > > > > Agree with Vijay, this is also the assumption for the AAA goals draft. > > > > --Gerardo > > > > > but it would be good to keep the solution flexible > > > so that it can be extended later for 4285 if required. > > > > > > Vijay > > > > > > _______________________________________________ > > > 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 > > > > > > > > _______________________________________________ > > 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 Fri Oct 20 05:30:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaqhk-0005UC-Un; Fri, 20 Oct 2006 05:30:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaqhj-0005Tw-BZ for dime@ietf.org; Fri, 20 Oct 2006 05:30:15 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gaqhh-0004pN-PU for dime@ietf.org; Fri, 20 Oct 2006 05:30:15 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1444475nfc for ; Fri, 20 Oct 2006 02:30:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UHhr5fqoIhOEV1HlCUXXh0hfhlRWBcG56QcsM+f07CT9vsw2ohr/t3NUSvPgPgB+eKiGNErkgytU8BiHDn53N6bOjhlHU9f2R44PFY4NjCmdtGHaQhM4sXf1LcHWtc502cHRXn5DSskxZiwJ1jysg9mENWWAXZ1a0RD8qut6qaE= Received: by 10.82.139.17 with SMTP id m17mr387921bud; Fri, 20 Oct 2006 02:30:12 -0700 (PDT) Received: by 10.82.98.7 with HTTP; Fri, 20 Oct 2006 02:30:12 -0700 (PDT) Message-ID: <5e2406980610200230x7d7f9345l176b576627791f74@mail.gmail.com> Date: Fri, 20 Oct 2006 11:30:12 +0200 From: "Julien Bournelle" To: "Gerardo Giaretta" Subject: Re: [Mip6] RE: [Dime] Impact of RFC 4285 for Diameter MIP6 Bootstrapping Work In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061019203232.GF30464@steelhead> <002f01c6f3c3$aba66960$2f01a8c0@huawei6cc10c70> X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f 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 all, concerning support for rfc4285, I think we'll need messages to carry the BU from the HA to the AAAH for the authentifcation. As such, a new application may be necessary. As a consequence, the authorization and accounting part may be handled by the same application. This application would be similar to the RFC4004 (without FA...). Just my 2 cents, Julien On 10/20/06, Gerardo Giaretta wrote: > Hi Yoshi and Madjid, > > the AAA goals draft does not include any specific goal for rfc4285. > This issue was raised in Montreal and during MIP6 re-chartering > discussion. The outcome of the discussion was that there is no a clear > interest now in the IETF to standardize a bootstrapping solution for > rfc4285 and a Diameter Application that supports rfc4285. MIP6 chairs > and Jari mentioned that they may ask for rfc4285 support if > significant interest will be raised. Remember also that rfc4285 is > informational and the Diameter Application will be PS: not sure how to > this difference would be handled. > > Having said that, I think that the approach taken so far in the design > of the Diameter Application is flexible enough to include rfc4285 > later without any big change: the authorization application does not > need to be changed for rfc4285 support and we may define another > application for authentication purposes. Therefore the > authentication/authorization split seems a correct approach in order > to introduce rfc4285 support later. > > --Gerardo > > On 10/19/06, Madjid Nakhjiri wrote: > > Hi Yoshi, > > > > I agree, no point on insisting that solutions would support 4285, if 4285 > > requirements are not included. I can think of aspects of 4285 that can be > > problematic, but won't mention them now, since I don't want to be accused of > > opening the pandora's box while aaa-ha-goals is going through last call or > > the dime docs are underway :) > > > > We should not make claims we cannot back up later as that might derail the > > standardization process two years from now. As Persians say (after a lousy > > marketing translation) "A small quarrel in the beginning better than a > > bloody peace at the end" > > > > > > > > R, > > > > Madjid > > > > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Thursday, October 19, 2006 1:33 PM > > To: Madjid Nakhjiri > > Cc: 'Gerardo Giaretta'; 'Vijay Devarapalli'; mip6@ietf.org; dime@ietf.org > > Subject: Re: [Mip6] RE: [Dime] Impact of RFC 4285 for Diameter MIP6 > > Bootstrapping Work > > > > Madjid, > > > > On Thu, Oct 19, 2006 at 01:04:04PM -0700, Madjid Nakhjiri wrote: > > > Ok, so I see I spend a long email without reading the rest of the thread. > > > Do we feel the AAA goal draft efficiently captures the 4285 requirements? > > > If yes, sorry for clogging your mailboxes.. > > > > That is my feeling and is why I had the following comment on aaa-ha-goals > > draft: > > > > " > > YO: This document seems to assume the use of IPsec between MN and HA > > for securing Mobile IPv6 signaling. But the AAA interface could > > also be used for RFC 4285. So I think it might be good to mention > > in this section that the document may not preclude the use of > > alternative methods for securing Mobile IPv6 signaling between MN > > and HA while this document focuses on the use of IPsec between MN > > and HA. > > " > > > > Yoshihiro Ohba > > > > > > > > > > R, > > > > > > Madjid > > > > > > -----Original Message----- > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > Sent: Friday, October 13, 2006 12:37 AM > > > To: Vijay Devarapalli > > > Cc: mip6@ietf.org; dime@ietf.org > > > Subject: Re: [Dime] Impact of RFC 4285 for Diameter MIP6 Bootstrapping > > Work > > > > > > > > in the DIME working group we are currently producing documents that > > > > > relate to the backend solution of the > > > > > > > > > > * Integrated Scenario > > > > > draft-ietf-mip6-bootstrapping-integrated-dhc-01 > > > > > > > > > > * Split Scenario > > > > > draft-ietf-mip6-bootstrapping-split-02 > > > > > > > > > > Now, the question came up whether we have to consider RFC 4285 > > > > > ('Authentication Protocol for Mobile IPv6') for our work as well. > > > > > > > > currently it is not clear if we are going to do any > > > > further work on RFC 4285 in the MIP6 WG. so my > > > > suggestion is to assume only the use of IKEv2 (with > > > > and without EAP). > > > > > > > > > > Agree with Vijay, this is also the assumption for the AAA goals draft. > > > > > > --Gerardo > > > > > > > but it would be good to keep the solution flexible > > > > so that it can be extended later for 4285 if required. > > > > > > > > Vijay > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > > > > _______________________________________________ > > > 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 > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 20 13:27:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gay9x-00070J-3t; Fri, 20 Oct 2006 13:27:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gay9v-00070B-Sj; Fri, 20 Oct 2006 13:27:51 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gay9t-0000FY-C6; Fri, 20 Oct 2006 13:27:51 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7G008XO3176Z@usaga01-in.huawei.com>; Fri, 20 Oct 2006 10:24:44 -0700 (PDT) Received: from huawei6cc10c70 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7G009CM3128A@usaga01-in.huawei.com>; Fri, 20 Oct 2006 10:24:43 -0700 (PDT) Date: Fri, 20 Oct 2006 10:27:42 -0700 From: Madjid Nakhjiri Subject: RE: [Mip6] RE: [Dime] Impact of RFC 4285 for Diameter MIP6 Bootstrapping Work In-reply-to: <5e2406980610200230x7d7f9345l176b576627791f74@mail.gmail.com> To: 'Julien Bournelle' , 'Gerardo Giaretta' Message-id: <000d01c6f46d$0d29be90$2f01a8c0@huawei6cc10c70> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acb0KvfPL1bG87fiRSe/6aV0315s9wAPdrUA X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba 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 Julien Your 2 cents are part of the nickel (5 cents) that I did not want to bring up:) I said this once before, 4285 is a lot like MIP4 key bootstrapping process. You can look at the combination of 4004 and Nakhjiri-radius-mip4-02 to see all kinds of things needed. Gerardo, here are the issues: 1) We don't have a set of requirements on 4285 (read non-existing 4285 requirement). 2) We don't even know we want to meet these requirement, even if they existed?? I.e. MUST or SHOULD the AAA goals include those requirements? That translates into MUST we or SHOULD the solutions meet the requirements, once they are developed? Personally, I think, we don't have any answer to issue 1 and we have already said the answer to question 2 is no. I think without a thorough analysis of the 4285 requirements and without a MUST/SHOULD meet requirements, we should just move on, without rubber stamping the solution document as something that supports 4285? The solution MAY support for 4285, but it is not a requirement. Your statement on > Having said that, I think that the approach taken so far in the design > of the Diameter Application is flexible enough to include rfc4285 > later without any big change Sounds like a MAY meet the requirements to me! Any other solution may or may not do it:) As engineers we design based on requirements, no? R, Madjid -----Original Message----- From: Julien Bournelle [mailto:julien.bournelle@gmail.com] Sent: Friday, October 20, 2006 2:30 AM To: Gerardo Giaretta Cc: Madjid Nakhjiri; Yoshihiro Ohba; mip6@ietf.org; dime@ietf.org Subject: Re: [Mip6] RE: [Dime] Impact of RFC 4285 for Diameter MIP6 Bootstrapping Work Hi all, concerning support for rfc4285, I think we'll need messages to carry the BU from the HA to the AAAH for the authentifcation. As such, a new application may be necessary. As a consequence, the authorization and accounting part may be handled by the same application. This application would be similar to the RFC4004 (without FA...). Just my 2 cents, Julien On 10/20/06, Gerardo Giaretta wrote: > Hi Yoshi and Madjid, > > the AAA goals draft does not include any specific goal for rfc4285. > This issue was raised in Montreal and during MIP6 re-chartering > discussion. The outcome of the discussion was that there is no a clear > interest now in the IETF to standardize a bootstrapping solution for > rfc4285 and a Diameter Application that supports rfc4285. MIP6 chairs > and Jari mentioned that they may ask for rfc4285 support if > significant interest will be raised. Remember also that rfc4285 is > informational and the Diameter Application will be PS: not sure how to > this difference would be handled. > > Having said that, I think that the approach taken so far in the design > of the Diameter Application is flexible enough to include rfc4285 > later without any big change: the authorization application does not > need to be changed for rfc4285 support and we may define another > application for authentication purposes. Therefore the > authentication/authorization split seems a correct approach in order > to introduce rfc4285 support later. > > --Gerardo > > On 10/19/06, Madjid Nakhjiri wrote: > > Hi Yoshi, > > > > I agree, no point on insisting that solutions would support 4285, if 4285 > > requirements are not included. I can think of aspects of 4285 that can be > > problematic, but won't mention them now, since I don't want to be accused of > > opening the pandora's box while aaa-ha-goals is going through last call or > > the dime docs are underway :) > > > > We should not make claims we cannot back up later as that might derail the > > standardization process two years from now. As Persians say (after a lousy > > marketing translation) "A small quarrel in the beginning better than a > > bloody peace at the end" > > > > > > > > R, > > > > Madjid > > > > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Thursday, October 19, 2006 1:33 PM > > To: Madjid Nakhjiri > > Cc: 'Gerardo Giaretta'; 'Vijay Devarapalli'; mip6@ietf.org; dime@ietf.org > > Subject: Re: [Mip6] RE: [Dime] Impact of RFC 4285 for Diameter MIP6 > > Bootstrapping Work > > > > Madjid, > > > > On Thu, Oct 19, 2006 at 01:04:04PM -0700, Madjid Nakhjiri wrote: > > > Ok, so I see I spend a long email without reading the rest of the thread. > > > Do we feel the AAA goal draft efficiently captures the 4285 requirements? > > > If yes, sorry for clogging your mailboxes.. > > > > That is my feeling and is why I had the following comment on aaa-ha-goals > > draft: > > > > " > > YO: This document seems to assume the use of IPsec between MN and HA > > for securing Mobile IPv6 signaling. But the AAA interface could > > also be used for RFC 4285. So I think it might be good to mention > > in this section that the document may not preclude the use of > > alternative methods for securing Mobile IPv6 signaling between MN > > and HA while this document focuses on the use of IPsec between MN > > and HA. > > " > > > > Yoshihiro Ohba > > > > > > > > > > R, > > > > > > Madjid > > > > > > -----Original Message----- > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > Sent: Friday, October 13, 2006 12:37 AM > > > To: Vijay Devarapalli > > > Cc: mip6@ietf.org; dime@ietf.org > > > Subject: Re: [Dime] Impact of RFC 4285 for Diameter MIP6 Bootstrapping > > Work > > > > > > > > in the DIME working group we are currently producing documents that > > > > > relate to the backend solution of the > > > > > > > > > > * Integrated Scenario > > > > > draft-ietf-mip6-bootstrapping-integrated-dhc-01 > > > > > > > > > > * Split Scenario > > > > > draft-ietf-mip6-bootstrapping-split-02 > > > > > > > > > > Now, the question came up whether we have to consider RFC 4285 > > > > > ('Authentication Protocol for Mobile IPv6') for our work as well. > > > > > > > > currently it is not clear if we are going to do any > > > > further work on RFC 4285 in the MIP6 WG. so my > > > > suggestion is to assume only the use of IKEv2 (with > > > > and without EAP). > > > > > > > > > > Agree with Vijay, this is also the assumption for the AAA goals draft. > > > > > > --Gerardo > > > > > > > but it would be good to keep the solution flexible > > > > so that it can be extended later for 4285 if required. > > > > > > > > Vijay > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > > > > _______________________________________________ > > > 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 > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Oct 21 10:21:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbHip-0004iA-7b; Sat, 21 Oct 2006 10:21:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbHio-0004hv-2o for dime@ietf.org; Sat, 21 Oct 2006 10:21:10 -0400 Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbHim-0007p4-DB for dime@ietf.org; Sat, 21 Oct 2006 10:21:10 -0400 Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Sat, 21 Oct 2006 23:24:53 +0900 Priority: normal X-ReadCheckName: dime%40ietf.org Thread-Topic: Re: [Mip6] RE: [Dime] Impact of RFC 4285 for Diameter MIP6Bootstrapping Work X-ReadCheckMessageID: thread-index: Acb1HKyr1NUiuWXXRKWXTWauasW09w== From: =?ks_c_5601-1987?B?wfbBpMjG?= To: "Julien Bournelle" , "Gerardo Giaretta" Bcc: Subject: RE: Re: [Mip6] RE: [Dime] Impact of RFC 4285 for Diameter MIP6Bootstrapping Work Date: Sat, 21 Oct 2006 23:24:53 +0900 Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCDAzLW/xeu9xSDHpcHY?= =?ks_c_5601-1987?B?v6yxuMbALCC047Tn?= Message-ID: <106201c6f51c$acb2b480$8310fe81@etri.info> MIME-Version: 1.0 X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-OriginalArrivalTime: 21 Oct 2006 14:24:53.0442 (UTC) FILETIME=[ACD8DA20:01C6F51C] X-Spam-Score: 3.2 (+++) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: mip6@ietf.org, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ks_c_5601-1987?B?wfbBpMjG?= List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0263283416==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0263283416== Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----=_NextPart_000_1053_01C6F568.1C95A190" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_1053_01C6F568.1C95A190 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 ------=_NextPart_000_1053_01C6F568.1C95A190 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiy Ij4NCjxESVY+SGkgSnVsaWVuLDwvRElWPg0KPERJVj5Eb2VzIHlvdXIgdGhvdWdodCBpbXBseSB0 aGF0IHRoZSBwaWdneWJhY2tpbmcgdGhlIE1JUHY2IEJVIHRvIHRoZSBBQUEgbWVzc2FnZXM/PC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4tSnVuZ2hvb248L0RJVj4NCjxESVY+PEJSPi0t LS0tv/i6uyC43r3DwfYtLS0tLTxCUj48Qj66uLO9ILvntvc6PC9CPiAiSnVsaWVuIEJvdXJuZWxs ZSIgJmx0O2p1bGllbi5ib3VybmVsbGVAZ21haWwuY29tJmd0OzxCUj48Qj66uLO9ILOvwqU6PC9C PiAyMDA2LTEwLTIwIL/AyMQgNjozMDoxMjxCUj48Qj653rTCILvntvc6PC9CPiAiR2VyYXJkbyBH aWFyZXR0YSIgJmx0O2dlcmFyZG8uZ2lhcmV0dGFAZ21haWwuY29tJmd0OzxCUj48Qj7C/MG2Ojwv Qj4gIm1pcDZAaWV0Zi5vcmciICZsdDttaXA2QGlldGYub3JnJmd0OywgImRpbWVAaWV0Zi5vcmci ICZsdDtkaW1lQGlldGYub3JnJmd0OzxCUj48Qj7BprjxOjwvQj4gUmU6IFtNaXA2XSBSRTogW0Rp bWVdIEltcGFjdCBvZiBSRkMgNDI4NSBmb3IgRGlhbWV0ZXIgTUlQNkJvb3RzdHJhcHBpbmcgV29y azxCUj48QlI+PC9ESVY+DQo8RElWPjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3Jt YXQgLS0+PEJSPg0KPFA+PEZPTlQgc2l6ZT0yPkhpIGFsbCw8QlI+PEJSPiZuYnNwO2NvbmNlcm5p bmcgc3VwcG9ydCBmb3IgcmZjNDI4NSwgSSB0aGluayB3ZSdsbCBuZWVkIG1lc3NhZ2VzIHRvIGNh cnJ5IHRoZSBCVTxCUj4mbmJzcDtmcm9tIHRoZSBIQSB0byB0aGUgQUFBSCBmb3IgdGhlIGF1dGhl bnRpZmNhdGlvbi4gQXMgc3VjaCwgYSBuZXcgYXBwbGljYXRpb248QlI+Jm5ic3A7bWF5IGJlIG5l Y2Vzc2FyeS4gQXMgYSBjb25zZXF1ZW5jZSwgdGhlIGF1dGhvcml6YXRpb24gYW5kIGFjY291bnRp bmcgcGFydDxCUj4mbmJzcDttYXkgYmUgaGFuZGxlZCBieSB0aGUgc2FtZSBhcHBsaWNhdGlvbi48 QlI+PEJSPiZuYnNwO1RoaXMgYXBwbGljYXRpb24gd291bGQgYmUgc2ltaWxhciB0byB0aGUgUkZD NDAwNCAod2l0aG91dCBGQS4uLikuPEJSPjxCUj4mbmJzcDtKdXN0IG15IDIgY2VudHMsPEJSPjxC Uj4mbmJzcDtKdWxpZW48QlI+PEJSPk9uIDEwLzIwLzA2LCBHZXJhcmRvIEdpYXJldHRhICZsdDtn ZXJhcmRvLmdpYXJldHRhQGdtYWlsLmNvbSZndDsgd3JvdGU6PEJSPiZndDsgSGkgWW9zaGkgYW5k IE1hZGppZCw8QlI+Jmd0OzxCUj4mZ3Q7IHRoZSBBQUEgZ29hbHMgZHJhZnQgZG9lcyBub3QgaW5j bHVkZSBhbnkgc3BlY2lmaWMgZ29hbCBmb3IgcmZjNDI4NS48QlI+Jmd0OyBUaGlzIGlzc3VlIHdh cyByYWlzZWQgaW4gTW9udHJlYWwgYW5kIGR1cmluZyBNSVA2IHJlLWNoYXJ0ZXJpbmc8QlI+Jmd0 OyBkaXNjdXNzaW9uLiBUaGUgb3V0Y29tZSBvZiB0aGUgZGlzY3Vzc2lvbiB3YXMgdGhhdCB0aGVy ZSBpcyBubyBhIGNsZWFyPEJSPiZndDsgaW50ZXJlc3Qgbm93IGluIHRoZSBJRVRGIHRvIHN0YW5k YXJkaXplIGEgYm9vdHN0cmFwcGluZyBzb2x1dGlvbiBmb3I8QlI+Jmd0OyByZmM0Mjg1IGFuZCBh IERpYW1ldGVyIEFwcGxpY2F0aW9uIHRoYXQgc3VwcG9ydHMgcmZjNDI4NS4gTUlQNiBjaGFpcnM8 QlI+Jmd0OyBhbmQgSmFyaSBtZW50aW9uZWQgdGhhdCB0aGV5IG1heSBhc2sgZm9yIHJmYzQyODUg c3VwcG9ydCBpZjxCUj4mZ3Q7IHNpZ25pZmljYW50IGludGVyZXN0IHdpbGwgYmUgcmFpc2VkLiBS ZW1lbWJlciBhbHNvIHRoYXQgcmZjNDI4NSBpczxCUj4mZ3Q7IGluZm9ybWF0aW9uYWwgYW5kIHRo ZSBEaWFtZXRlciBBcHBsaWNhdGlvbiB3aWxsIGJlIFBTOiBub3Qgc3VyZSBob3cgdG88QlI+Jmd0 OyB0aGlzIGRpZmZlcmVuY2Ugd291bGQgYmUgaGFuZGxlZC48QlI+Jmd0OzxCUj4mZ3Q7IEhhdmlu ZyBzYWlkIHRoYXQsIEkgdGhpbmsgdGhhdCB0aGUgYXBwcm9hY2ggdGFrZW4gc28gZmFyIGluIHRo ZSBkZXNpZ248QlI+Jmd0OyBvZiB0aGUgRGlhbWV0ZXIgQXBwbGljYXRpb24gaXMgZmxleGlibGUg ZW5vdWdoIHRvIGluY2x1ZGUgcmZjNDI4NTxCUj4mZ3Q7IGxhdGVyIHdpdGhvdXQgYW55IGJpZyBj aGFuZ2U6IHRoZSBhdXRob3JpemF0aW9uIGFwcGxpY2F0aW9uIGRvZXMgbm90PEJSPiZndDsgbmVl ZCB0byBiZSBjaGFuZ2VkIGZvciByZmM0Mjg1IHN1cHBvcnQgYW5kIHdlIG1heSBkZWZpbmUgYW5v dGhlcjxCUj4mZ3Q7IGFwcGxpY2F0aW9uIGZvciBhdXRoZW50aWNhdGlvbiBwdXJwb3Nlcy4gVGhl cmVmb3JlIHRoZTxCUj4mZ3Q7IGF1dGhlbnRpY2F0aW9uL2F1dGhvcml6YXRpb24gc3BsaXQgc2Vl bXMgYSBjb3JyZWN0IGFwcHJvYWNoIGluIG9yZGVyPEJSPiZndDsgdG8gaW50cm9kdWNlIHJmYzQy ODUgc3VwcG9ydCBsYXRlci48QlI+Jmd0OzxCUj4mZ3Q7IC0tR2VyYXJkbzxCUj4mZ3Q7PEJSPiZn dDsgT24gMTAvMTkvMDYsIE1hZGppZCBOYWtoamlyaSAmbHQ7bW5ha2hqaXJpQGh1YXdlaS5jb20m Z3Q7IHdyb3RlOjxCUj4mZ3Q7ICZndDsgSGkgWW9zaGksPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZn dDsgSSBhZ3JlZSwgbm8gcG9pbnQgb24gaW5zaXN0aW5nIHRoYXQgc29sdXRpb25zIHdvdWxkIHN1 cHBvcnQgNDI4NSwgaWYgNDI4NTxCUj4mZ3Q7ICZndDsgcmVxdWlyZW1lbnRzIGFyZSBub3QgaW5j bHVkZWQuIEkgY2FuIHRoaW5rIG9mIGFzcGVjdHMgb2YgNDI4NSB0aGF0IGNhbiBiZTxCUj4mZ3Q7 ICZndDsgcHJvYmxlbWF0aWMsIGJ1dCB3b24ndCBtZW50aW9uIHRoZW0gbm93LCBzaW5jZSBJIGRv bid0IHdhbnQgdG8gYmUgYWNjdXNlZCBvZjxCUj4mZ3Q7ICZndDsgb3BlbmluZyB0aGUgcGFuZG9y YSdzIGJveCB3aGlsZSBhYWEtaGEtZ29hbHMgaXMgZ29pbmcgdGhyb3VnaCBsYXN0IGNhbGwgb3I8 QlI+Jmd0OyAmZ3Q7IHRoZSBkaW1lIGRvY3MgYXJlIHVuZGVyd2F5IDopPEJSPiZndDsgJmd0OzxC Uj4mZ3Q7ICZndDsgV2Ugc2hvdWxkIG5vdCBtYWtlIGNsYWltcyB3ZSBjYW5ub3QgYmFjayB1cCBs YXRlciBhcyB0aGF0IG1pZ2h0IGRlcmFpbCB0aGU8QlI+Jmd0OyAmZ3Q7IHN0YW5kYXJkaXphdGlv biBwcm9jZXNzIHR3byB5ZWFycyBmcm9tIG5vdy4gQXMgUGVyc2lhbnMgc2F5IChhZnRlciBhIGxv dXN5PEJSPiZndDsgJmd0OyBtYXJrZXRpbmcgdHJhbnNsYXRpb24pICJBIHNtYWxsIHF1YXJyZWwg aW4gdGhlIGJlZ2lubmluZyBiZXR0ZXIgdGhhbiBhPEJSPiZndDsgJmd0OyBibG9vZHkgcGVhY2Ug YXQgdGhlIGVuZCI8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0 OyAmZ3Q7IFIsPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgTWFkamlkPEJSPiZndDsgJmd0OzxC Uj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPiZn dDsgJmd0OyBGcm9tOiBZb3NoaWhpcm8gT2hiYSBbPEEgaHJlZj0ibWFpbHRvOnlvaGJhQHRhcmku dG9zaGliYS5jb20iIHRhcmdldD1fYmxhbms+bWFpbHRvOnlvaGJhQHRhcmkudG9zaGliYS5jb208 L0E+XTxCUj4mZ3Q7ICZndDsgU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTksIDIwMDYgMTozMyBQ TTxCUj4mZ3Q7ICZndDsgVG86IE1hZGppZCBOYWtoamlyaTxCUj4mZ3Q7ICZndDsgQ2M6ICdHZXJh cmRvIEdpYXJldHRhJzsgJ1ZpamF5IERldmFyYXBhbGxpJzsgbWlwNkBpZXRmLm9yZzsgZGltZUBp ZXRmLm9yZzxCUj4mZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtNaXA2XSBSRTogW0RpbWVdIEltcGFj dCBvZiBSRkMgNDI4NSBmb3IgRGlhbWV0ZXIgTUlQNjxCUj4mZ3Q7ICZndDsgQm9vdHN0cmFwcGlu ZyBXb3JrPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgTWFkamlkLDxCUj4mZ3Q7ICZndDs8QlI+ Jmd0OyAmZ3Q7IE9uIFRodSwgT2N0IDE5LCAyMDA2IGF0IDAxOjA0OjA0UE0gLTA3MDAsIE1hZGpp ZCBOYWtoamlyaSB3cm90ZTo8QlI+Jmd0OyAmZ3Q7ICZndDsgT2ssIHNvIEkgc2VlIEkgc3BlbmQg YSBsb25nIGVtYWlsIHdpdGhvdXQgcmVhZGluZyB0aGUgcmVzdCBvZiB0aGUgdGhyZWFkLjxCUj4m Z3Q7ICZndDsgJmd0OyBEbyB3ZSBmZWVsIHRoZSBBQUEgZ29hbCBkcmFmdCBlZmZpY2llbnRseSBj YXB0dXJlcyB0aGUgNDI4NSByZXF1aXJlbWVudHM/PEJSPiZndDsgJmd0OyAmZ3Q7IElmIHllcywg c29ycnkgZm9yIGNsb2dnaW5nIHlvdXIgbWFpbGJveGVzLi48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsg Jmd0OyBUaGF0IGlzIG15IGZlZWxpbmcgYW5kIGlzIHdoeSBJIGhhZCB0aGUgZm9sbG93aW5nIGNv bW1lbnQgb24gYWFhLWhhLWdvYWxzPEJSPiZndDsgJmd0OyBkcmFmdDo8QlI+Jmd0OyAmZ3Q7PEJS PiZndDsgJmd0OyAiPEJSPiZndDsgJmd0OyZuYnNwOyZuYnNwOyBZTzogVGhpcyBkb2N1bWVudCBz ZWVtcyB0byBhc3N1bWUgdGhlIHVzZSBvZiBJUHNlYyBiZXR3ZWVuIE1OIGFuZCBIQTxCUj4mZ3Q7 ICZndDsmbmJzcDsmbmJzcDsgZm9yIHNlY3VyaW5nIE1vYmlsZSBJUHY2IHNpZ25hbGluZy4mbmJz cDsgQnV0IHRoZSBBQUEgaW50ZXJmYWNlIGNvdWxkPEJSPiZndDsgJmd0OyZuYnNwOyZuYnNwOyBh bHNvIGJlIHVzZWQgZm9yIFJGQyA0Mjg1LiZuYnNwOyBTbyBJIHRoaW5rIGl0IG1pZ2h0IGJlIGdv b2QgdG8gbWVudGlvbjxCUj4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsgaW4gdGhpcyBzZWN0aW9uIHRo YXQgdGhlIGRvY3VtZW50IG1heSBub3QgcHJlY2x1ZGUgdGhlIHVzZSBvZjxCUj4mZ3Q7ICZndDsm bmJzcDsmbmJzcDsgYWx0ZXJuYXRpdmUgbWV0aG9kcyBmb3Igc2VjdXJpbmcgTW9iaWxlIElQdjYg c2lnbmFsaW5nIGJldHdlZW4gTU48QlI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7IGFuZCBIQSB3aGls ZSB0aGlzIGRvY3VtZW50IGZvY3VzZXMgb24gdGhlIHVzZSBvZiBJUHNlYyBiZXR3ZWVuIE1OPEJS PiZndDsgJmd0OyZuYnNwOyZuYnNwOyBhbmQgSEEuPEJSPiZndDsgJmd0OyAiPEJSPiZndDsgJmd0 OzxCUj4mZ3Q7ICZndDsgWW9zaGloaXJvIE9oYmE8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OzxC Uj4mZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyBSLDxCUj4mZ3Q7ICZndDsgJmd0OzxC Uj4mZ3Q7ICZndDsgJmd0OyBNYWRqaWQ8QlI+Jmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZn dDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+Jmd0OyAmZ3Q7ICZndDsgRnJvbTogR2Vy YXJkbyBHaWFyZXR0YSBbPEEgaHJlZj0ibWFpbHRvOmdlcmFyZG8uZ2lhcmV0dGFAZ21haWwuY29t IiB0YXJnZXQ9X2JsYW5rPm1haWx0bzpnZXJhcmRvLmdpYXJldHRhQGdtYWlsLmNvbTwvQT5dPEJS PiZndDsgJmd0OyAmZ3Q7IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAxMywgMjAwNiAxMjozNyBBTTxC Uj4mZ3Q7ICZndDsgJmd0OyBUbzogVmlqYXkgRGV2YXJhcGFsbGk8QlI+Jmd0OyAmZ3Q7ICZndDsg Q2M6IG1pcDZAaWV0Zi5vcmc7IGRpbWVAaWV0Zi5vcmc8QlI+Jmd0OyAmZ3Q7ICZndDsgU3ViamVj dDogUmU6IFtEaW1lXSBJbXBhY3Qgb2YgUkZDIDQyODUgZm9yIERpYW1ldGVyIE1JUDYgQm9vdHN0 cmFwcGluZzxCUj4mZ3Q7ICZndDsgV29yazxCUj4mZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgaW4gdGhlIERJTUUgd29ya2luZyBncm91cCB3ZSBhcmUgY3VycmVudGx5 IHByb2R1Y2luZyBkb2N1bWVudHMgdGhhdDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgcmVs YXRlIHRvIHRoZSBiYWNrZW5kIHNvbHV0aW9uIG9mIHRoZTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICogSW50ZWdyYXRlZCBTY2VuYXJpbzxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsgZHJhZnQtaWV0Zi1taXA2LWJv b3RzdHJhcHBpbmctaW50ZWdyYXRlZC1kaGMtMDE8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAqIFNwbGl0IFNjZW5hcmlvPEJSPiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyBkcmFmdC1pZXRmLW1pcDYtYm9vdHN0cmFwcGlu Zy1zcGxpdC0wMjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7IE5vdywgdGhlIHF1ZXN0aW9uIGNhbWUgdXAgd2hldGhlciB3ZSBoYXZlIHRvIGNv bnNpZGVyIFJGQyA0Mjg1PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAoJ0F1dGhlbnRpY2F0 aW9uIFByb3RvY29sIGZvciBNb2JpbGUgSVB2NicpIGZvciBvdXIgd29yayBhcyB3ZWxsLjxCUj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgY3VycmVudGx5IGl0IGlz IG5vdCBjbGVhciBpZiB3ZSBhcmUgZ29pbmcgdG8gZG8gYW55PEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgZnVydGhlciB3b3JrIG9uIFJGQyA0Mjg1IGluIHRoZSBNSVA2IFdHLiBzbyBteTxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7IHN1Z2dlc3Rpb24gaXMgdG8gYXNzdW1lIG9ubHkgdGhlIHVzZSBvZiBJ S0V2MiAod2l0aDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGFuZCB3aXRob3V0IEVBUCkuPEJSPiZn dDsgJmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgQWdy ZWUgd2l0aCBWaWpheSwgdGhpcyBpcyBhbHNvIHRoZSBhc3N1bXB0aW9uIGZvciB0aGUgQUFBIGdv YWxzIGRyYWZ0LjxCUj4mZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAtLUdlcmFyZG88 QlI+Jmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBidXQgaXQgd291bGQgYmUg Z29vZCB0byBrZWVwIHRoZSBzb2x1dGlvbiBmbGV4aWJsZTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IHNvIHRoYXQgaXQgY2FuIGJlIGV4dGVuZGVkIGxhdGVyIGZvciA0Mjg1IGlmIHJlcXVpcmVkLjxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgVmlqYXk8QlI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgRGlN RSBtYWlsaW5nIGxpc3Q8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBEaU1FQGlldGYub3JnPEJSPiZn dDsgJmd0OyAmZ3Q7ICZndDsgPEEgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGltZSIgdGFyZ2V0PV9ibGFuaz5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kaW1lPC9BPjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAm Z3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPEJSPiZndDsgJmd0OyAmZ3Q7IERpTUUgbWFpbGluZyBsaXN0PEJSPiZndDsg Jmd0OyAmZ3Q7IERpTUVAaWV0Zi5vcmc8QlI+Jmd0OyAmZ3Q7ICZndDsgPEEgaHJlZj0iaHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZSIgdGFyZ2V0PV9ibGFuaz5odHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9BPjxCUj4mZ3Q7ICZndDsg Jmd0OzxCUj4mZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4mZ3Q7 ICZndDsgJmd0OyBNaXA2IG1haWxpbmcgbGlzdDxCUj4mZ3Q7ICZndDsgJmd0OyBNaXA2QGlldGYu b3JnPEJSPiZndDsgJmd0OyAmZ3Q7IDxBIGhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21pcDYiIHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbWlwNjwvQT48QlI+Jmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJS PiZndDsgJmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OzxCUj4mZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPiZndDsgRGlNRSBtYWlsaW5nIGxpc3Q8 QlI+Jmd0OyBEaU1FQGlldGYub3JnPEJSPiZndDsgPEEgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZGltZSIgdGFyZ2V0PV9ibGFuaz5odHRwczovL3d3dzEuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9BPjxCUj4mZ3Q7PEJSPjxCUj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5EaU1FIG1haWxpbmcgbGlz dDxCUj5EaU1FQGlldGYub3JnPEJSPjxBIGhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RpbWUiIHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZGltZTwvQT48QlI+PC9GT05UPjwvUD48L0RJVj48L0RJVj48aW1nIHN0 eWxlPSJkaXNwbGF5Om5vbmUiIHdpZHRoPTAgaGVpZ2h0PTAgc3JjPSJodHRwOi8vdW1haWwuZXRy aS5yZS5rci9FeHRlcm5hbF9SZWFkQ2hlY2suYXNweD9lbWFpbD1kaW1lQGlldGYub3JnJm5hbWU9 ZGltZSU0MGlldGYub3JnJmZyb21lbWFpbD1qaGplZUBldHJpLnJlLmtyJm1lc3NhZ2VpZD0lM0Nl OGNmNjE4OC0wYWRmLTQyZmMtYTI4OS04ZjMzZmYwOGE2MTRAZXRyaS5yZS5rciUzRSI+ ------=_NextPart_000_1053_01C6F568.1C95A190-- --===============0263283416== 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 --===============0263283416==-- From dime-bounces@ietf.org Mon Oct 23 07:17:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbxoJ-0005sN-I9; Mon, 23 Oct 2006 07:17:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbxoI-0005rL-4G for dime@ietf.org; Mon, 23 Oct 2006 07:17:38 -0400 Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbxci-0000Ss-Gw for dime@ietf.org; Mon, 23 Oct 2006 07:05:42 -0400 Received: by nf-out-0910.google.com with SMTP id n15so2494343nfc for ; Mon, 23 Oct 2006 04:05:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rvAkpdEV7a86GWRUqno/Xr80bS3qCTEEL8xUg/Y/cjLswjXUS33n6WYlX+B3jzzqwvfmmJUPk374DBfYPKVs3k9YDjPcuAFGUmAd1CeFbsya4Uh8pzeWyOuV9Dq3J+w+DFSobn2wOqlXpojPnN7G6hz/qWno+IIfZogBa8I90D4= Received: by 10.82.98.13 with SMTP id v13mr1267597bub; Mon, 23 Oct 2006 04:05:39 -0700 (PDT) Received: by 10.82.130.20 with HTTP; Mon, 23 Oct 2006 04:05:38 -0700 (PDT) Message-ID: <5e2406980610230405r402a23cbj71937ec220de6db0@mail.gmail.com> Date: Mon, 23 Oct 2006 13:05:39 +0200 From: "Julien Bournelle" To: "=?EUC-KR?B?wfbBpMjG?=" Subject: Re: Re: [Mip6] RE: [Dime] Impact of RFC 4285 for Diameter MIP6Bootstrapping Work In-Reply-To: <105201c6f51c$acadf990$8310fe81@etri.info> MIME-Version: 1.0 References: <105201c6f51c$acadf990$8310fe81@etri.info> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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: , Content-Type: multipart/mixed; boundary="===============1587347878==" Errors-To: dime-bounces@ietf.org --===============1587347878== Content-Type: text/plain; charset=EUC-KR; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGkganVuZ2hvb24sIGFsbCwKCk9uIDEwLzIxLzA2LCDB9sGkyMYgPGpoamVlQGV0cmkucmUua3I+ IHdyb3RlOgo+Cj4KPiBIaSBKdWxpZW4sCj4gRG9lcyB5b3VyIHRob3VnaHQgaW1wbHkgdGhhdCB0 aGUgcGlnZ3liYWNraW5nIHRoZSBNSVB2NiBCVSB0byB0aGUgQUFBIG1lc3NhZ2VzPwoKIElmIHRo ZSBNTiB1c2VzIHRoZSBNTi1BQUEgQXV0aGVudGljYXRpb24gb3B0aW9uLCBJIGd1ZXNzIHRoZSBC VSBtYXkKYmUgcGlnZ3liYWNrZWQuCgogSnVsaWVuCgo+Cj4gLUp1bmdob29uCj4KPiAtLS0tLb/4 ursguN69w8H2LS0tLS0KPiC6uLO9ILvntvc6ICJKdWxpZW4gQm91cm5lbGxlIiA8anVsaWVuLmJv dXJuZWxsZUBnbWFpbC5jb20+Cj4gurizvSCzr8KlOiAyMDA2LTEwLTIwIL/AyMQgNjozMDoxMgo+ ILnetMIgu+e29zogIkdlcmFyZG8gR2lhcmV0dGEiIDxnZXJhcmRvLmdpYXJldHRhQGdtYWlsLmNv bT4KPiDC/MG2OiAibWlwNkBpZXRmLm9yZyIgPG1pcDZAaWV0Zi5vcmc+LCAiZGltZUBpZXRmLm9y ZyIgPGRpbWVAaWV0Zi5vcmc+Cj4gwaa48TogUmU6IFtNaXA2XSBSRTogW0RpbWVdIEltcGFjdCBv ZiBSRkMgNDI4NSBmb3IgRGlhbWV0ZXIgTUlQNkJvb3RzdHJhcHBpbmcgV29yawo+Cj4KPgo+Cj4K Pgo+IEhpIGFsbCwKPgo+ICBjb25jZXJuaW5nIHN1cHBvcnQgZm9yIHJmYzQyODUsIEkgdGhpbmsg d2UnbGwgbmVlZCBtZXNzYWdlcyB0byBjYXJyeSB0aGUgQlUKPiAgZnJvbSB0aGUgSEEgdG8gdGhl IEFBQUggZm9yIHRoZSBhdXRoZW50aWZjYXRpb24uIEFzIHN1Y2gsIGEgbmV3IGFwcGxpY2F0aW9u Cj4gIG1heSBiZSBuZWNlc3NhcnkuIEFzIGEgY29uc2VxdWVuY2UsIHRoZSBhdXRob3JpemF0aW9u IGFuZCBhY2NvdW50aW5nIHBhcnQKPiAgbWF5IGJlIGhhbmRsZWQgYnkgdGhlIHNhbWUgYXBwbGlj YXRpb24uCj4KPiAgVGhpcyBhcHBsaWNhdGlvbiB3b3VsZCBiZSBzaW1pbGFyIHRvIHRoZSBSRkM0 MDA0ICh3aXRob3V0IEZBLi4uKS4KPgo+ICBKdXN0IG15IDIgY2VudHMsCj4KPiAgSnVsaWVuCj4K PiBPbiAxMC8yMC8wNiwgR2VyYXJkbyBHaWFyZXR0YSA8Z2VyYXJkby5naWFyZXR0YUBnbWFpbC5j b20+IHdyb3RlOgo+ID4gSGkgWW9zaGkgYW5kIE1hZGppZCwKPiA+Cj4gPiB0aGUgQUFBIGdvYWxz IGRyYWZ0IGRvZXMgbm90IGluY2x1ZGUgYW55IHNwZWNpZmljIGdvYWwgZm9yIHJmYzQyODUuCj4g PiBUaGlzIGlzc3VlIHdhcyByYWlzZWQgaW4gTW9udHJlYWwgYW5kIGR1cmluZyBNSVA2IHJlLWNo YXJ0ZXJpbmcKPiA+IGRpc2N1c3Npb24uIFRoZSBvdXRjb21lIG9mIHRoZSBkaXNjdXNzaW9uIHdh cyB0aGF0IHRoZXJlIGlzIG5vIGEgY2xlYXIKPiA+IGludGVyZXN0IG5vdyBpbiB0aGUgSUVURiB0 byBzdGFuZGFyZGl6ZSBhIGJvb3RzdHJhcHBpbmcgc29sdXRpb24gZm9yCj4gPiByZmM0Mjg1IGFu ZCBhIERpYW1ldGVyIEFwcGxpY2F0aW9uIHRoYXQgc3VwcG9ydHMgcmZjNDI4NS4gTUlQNiBjaGFp cnMKPiA+IGFuZCBKYXJpIG1lbnRpb25lZCB0aGF0IHRoZXkgbWF5IGFzayBmb3IgcmZjNDI4NSBz dXBwb3J0IGlmCj4gPiBzaWduaWZpY2FudCBpbnRlcmVzdCB3aWxsIGJlIHJhaXNlZC4gUmVtZW1i ZXIgYWxzbyB0aGF0IHJmYzQyODUgaXMKPiA+IGluZm9ybWF0aW9uYWwgYW5kIHRoZSBEaWFtZXRl ciBBcHBsaWNhdGlvbiB3aWxsIGJlIFBTOiBub3Qgc3VyZSBob3cgdG8KPiA+IHRoaXMgZGlmZmVy ZW5jZSB3b3VsZCBiZSBoYW5kbGVkLgo+ID4KPiA+IEhhdmluZyBzYWlkIHRoYXQsIEkgdGhpbmsg dGhhdCB0aGUgYXBwcm9hY2ggdGFrZW4gc28gZmFyIGluIHRoZSBkZXNpZ24KPiA+IG9mIHRoZSBE aWFtZXRlciBBcHBsaWNhdGlvbiBpcyBmbGV4aWJsZSBlbm91Z2ggdG8gaW5jbHVkZSByZmM0Mjg1 Cj4gPiBsYXRlciB3aXRob3V0IGFueSBiaWcgY2hhbmdlOiB0aGUgYXV0aG9yaXphdGlvbiBhcHBs aWNhdGlvbiBkb2VzIG5vdAo+ID4gbmVlZCB0byBiZSBjaGFuZ2VkIGZvciByZmM0Mjg1IHN1cHBv cnQgYW5kIHdlIG1heSBkZWZpbmUgYW5vdGhlcgo+ID4gYXBwbGljYXRpb24gZm9yIGF1dGhlbnRp Y2F0aW9uIHB1cnBvc2VzLiBUaGVyZWZvcmUgdGhlCj4gPiBhdXRoZW50aWNhdGlvbi9hdXRob3Jp emF0aW9uIHNwbGl0IHNlZW1zIGEgY29ycmVjdCBhcHByb2FjaCBpbiBvcmRlcgo+ID4gdG8gaW50 cm9kdWNlIHJmYzQyODUgc3VwcG9ydCBsYXRlci4KPiA+Cj4gPiAtLUdlcmFyZG8KPiA+Cj4gPiBP biAxMC8xOS8wNiwgTWFkamlkIE5ha2hqaXJpIDxtbmFraGppcmlAaHVhd2VpLmNvbT4gd3JvdGU6 Cj4gPiA+IEhpIFlvc2hpLAo+ID4gPgo+ID4gPiBJIGFncmVlLCBubyBwb2ludCBvbiBpbnNpc3Rp bmcgdGhhdCBzb2x1dGlvbnMgd291bGQgc3VwcG9ydCA0Mjg1LCBpZiA0Mjg1Cj4gPiA+IHJlcXVp cmVtZW50cyBhcmUgbm90IGluY2x1ZGVkLiBJIGNhbiB0aGluayBvZiBhc3BlY3RzIG9mIDQyODUg dGhhdCBjYW4gYmUKPiA+ID4gcHJvYmxlbWF0aWMsIGJ1dCB3b24ndCBtZW50aW9uIHRoZW0gbm93 LCBzaW5jZSBJIGRvbid0IHdhbnQgdG8gYmUgYWNjdXNlZCBvZgo+ID4gPiBvcGVuaW5nIHRoZSBw YW5kb3JhJ3MgYm94IHdoaWxlIGFhYS1oYS1nb2FscyBpcyBnb2luZyB0aHJvdWdoIGxhc3QgY2Fs bCBvcgo+ID4gPiB0aGUgZGltZSBkb2NzIGFyZSB1bmRlcndheSA6KQo+ID4gPgo+ID4gPiBXZSBz aG91bGQgbm90IG1ha2UgY2xhaW1zIHdlIGNhbm5vdCBiYWNrIHVwIGxhdGVyIGFzIHRoYXQgbWln aHQgZGVyYWlsIHRoZQo+ID4gPiBzdGFuZGFyZGl6YXRpb24gcHJvY2VzcyB0d28geWVhcnMgZnJv bSBub3cuIEFzIFBlcnNpYW5zIHNheSAoYWZ0ZXIgYSBsb3VzeQo+ID4gPiBtYXJrZXRpbmcgdHJh bnNsYXRpb24pICJBIHNtYWxsIHF1YXJyZWwgaW4gdGhlIGJlZ2lubmluZyBiZXR0ZXIgdGhhbiBh Cj4gPiA+IGJsb29keSBwZWFjZSBhdCB0aGUgZW5kIgo+ID4gPgo+ID4gPgo+ID4gPgo+ID4gPiBS LAo+ID4gPgo+ID4gPiBNYWRqaWQKPiA+ID4KPiA+ID4KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0KPiA+ID4gRnJvbTogWW9zaGloaXJvIE9oYmEgW21haWx0bzp5b2hiYUB0YXJpLnRv c2hpYmEuY29tXQo+ID4gPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxOSwgMjAwNiAxOjMzIFBN Cj4gPiA+IFRvOiBNYWRqaWQgTmFraGppcmkKPiA+ID4gQ2M6ICdHZXJhcmRvIEdpYXJldHRhJzsg J1ZpamF5IERldmFyYXBhbGxpJzsgbWlwNkBpZXRmLm9yZzsgZGltZUBpZXRmLm9yZwo+ID4gPiBT dWJqZWN0OiBSZTogW01pcDZdIFJFOiBbRGltZV0gSW1wYWN0IG9mIFJGQyA0Mjg1IGZvciBEaWFt ZXRlciBNSVA2Cj4gPiA+IEJvb3RzdHJhcHBpbmcgV29yawo+ID4gPgo+ID4gPiBNYWRqaWQsCj4g PiA+Cj4gPiA+IE9uIFRodSwgT2N0IDE5LCAyMDA2IGF0IDAxOjA0OjA0UE0gLTA3MDAsIE1hZGpp ZCBOYWtoamlyaSB3cm90ZToKPiA+ID4gPiBPaywgc28gSSBzZWUgSSBzcGVuZCBhIGxvbmcgZW1h aWwgd2l0aG91dCByZWFkaW5nIHRoZSByZXN0IG9mIHRoZSB0aHJlYWQuCj4gPiA+ID4gRG8gd2Ug ZmVlbCB0aGUgQUFBIGdvYWwgZHJhZnQgZWZmaWNpZW50bHkgY2FwdHVyZXMgdGhlIDQyODUgcmVx dWlyZW1lbnRzPwo+ID4gPiA+IElmIHllcywgc29ycnkgZm9yIGNsb2dnaW5nIHlvdXIgbWFpbGJv eGVzLi4KPiA+ID4KPiA+ID4gVGhhdCBpcyBteSBmZWVsaW5nIGFuZCBpcyB3aHkgSSBoYWQgdGhl IGZvbGxvd2luZyBjb21tZW50IG9uIGFhYS1oYS1nb2Fscwo+ID4gPiBkcmFmdDoKPiA+ID4KPiA+ ID4gIgo+ID4gPiAgIFlPOiBUaGlzIGRvY3VtZW50IHNlZW1zIHRvIGFzc3VtZSB0aGUgdXNlIG9m IElQc2VjIGJldHdlZW4gTU4gYW5kIEhBCj4gPiA+ICAgZm9yIHNlY3VyaW5nIE1vYmlsZSBJUHY2 IHNpZ25hbGluZy4gIEJ1dCB0aGUgQUFBIGludGVyZmFjZSBjb3VsZAo+ID4gPiAgIGFsc28gYmUg dXNlZCBmb3IgUkZDIDQyODUuICBTbyBJIHRoaW5rIGl0IG1pZ2h0IGJlIGdvb2QgdG8gbWVudGlv bgo+ID4gPiAgIGluIHRoaXMgc2VjdGlvbiB0aGF0IHRoZSBkb2N1bWVudCBtYXkgbm90IHByZWNs dWRlIHRoZSB1c2Ugb2YKPiA+ID4gICBhbHRlcm5hdGl2ZSBtZXRob2RzIGZvciBzZWN1cmluZyBN b2JpbGUgSVB2NiBzaWduYWxpbmcgYmV0d2VlbiBNTgo+ID4gPiAgIGFuZCBIQSB3aGlsZSB0aGlz IGRvY3VtZW50IGZvY3VzZXMgb24gdGhlIHVzZSBvZiBJUHNlYyBiZXR3ZWVuIE1OCj4gPiA+ICAg YW5kIEhBLgo+ID4gPiAiCj4gPiA+Cj4gPiA+IFlvc2hpaGlybyBPaGJhCj4gPiA+Cj4gPiA+Cj4g PiA+ID4KPiA+ID4gPiBSLAo+ID4gPiA+Cj4gPiA+ID4gTWFkamlkCj4gPiA+ID4KPiA+ID4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ID4gPiA+IEZyb206IEdlcmFyZG8gR2lhcmV0dGEg W21haWx0bzpnZXJhcmRvLmdpYXJldHRhQGdtYWlsLmNvbV0KPiA+ID4gPiBTZW50OiBGcmlkYXks IE9jdG9iZXIgMTMsIDIwMDYgMTI6MzcgQU0KPiA+ID4gPiBUbzogVmlqYXkgRGV2YXJhcGFsbGkK PiA+ID4gPiBDYzogbWlwNkBpZXRmLm9yZzsgZGltZUBpZXRmLm9yZwo+ID4gPiA+IFN1YmplY3Q6 IFJlOiBbRGltZV0gSW1wYWN0IG9mIFJGQyA0Mjg1IGZvciBEaWFtZXRlciBNSVA2IEJvb3RzdHJh cHBpbmcKPiA+ID4gV29yawo+ID4gPiA+Cj4gPiA+ID4gPiA+IGluIHRoZSBESU1FIHdvcmtpbmcg Z3JvdXAgd2UgYXJlIGN1cnJlbnRseSBwcm9kdWNpbmcgZG9jdW1lbnRzIHRoYXQKPiA+ID4gPiA+ ID4gcmVsYXRlIHRvIHRoZSBiYWNrZW5kIHNvbHV0aW9uIG9mIHRoZQo+ID4gPiA+ID4gPgo+ID4g PiA+ID4gPiAqIEludGVncmF0ZWQgU2NlbmFyaW8KPiA+ID4gPiA+ID4gICBkcmFmdC1pZXRmLW1p cDYtYm9vdHN0cmFwcGluZy1pbnRlZ3JhdGVkLWRoYy0wMQo+ID4gPiA+ID4gPgo+ID4gPiA+ID4g PiAqIFNwbGl0IFNjZW5hcmlvCj4gPiA+ID4gPiA+ICAgZHJhZnQtaWV0Zi1taXA2LWJvb3RzdHJh cHBpbmctc3BsaXQtMDIKPiA+ID4gPiA+ID4KPiA+ID4gPiA+ID4gTm93LCB0aGUgcXVlc3Rpb24g Y2FtZSB1cCB3aGV0aGVyIHdlIGhhdmUgdG8gY29uc2lkZXIgUkZDIDQyODUKPiA+ID4gPiA+ID4g KCdBdXRoZW50aWNhdGlvbiBQcm90b2NvbCBmb3IgTW9iaWxlIElQdjYnKSBmb3Igb3VyIHdvcmsg YXMgd2VsbC4KPiA+ID4gPiA+Cj4gPiA+ID4gPiBjdXJyZW50bHkgaXQgaXMgbm90IGNsZWFyIGlm IHdlIGFyZSBnb2luZyB0byBkbyBhbnkKPiA+ID4gPiA+IGZ1cnRoZXIgd29yayBvbiBSRkMgNDI4 NSBpbiB0aGUgTUlQNiBXRy4gc28gbXkKPiA+ID4gPiA+IHN1Z2dlc3Rpb24gaXMgdG8gYXNzdW1l IG9ubHkgdGhlIHVzZSBvZiBJS0V2MiAod2l0aAo+ID4gPiA+ID4gYW5kIHdpdGhvdXQgRUFQKS4K PiA+ID4gPiA+Cj4gPiA+ID4KPiA+ID4gPiBBZ3JlZSB3aXRoIFZpamF5LCB0aGlzIGlzIGFsc28g dGhlIGFzc3VtcHRpb24gZm9yIHRoZSBBQUEgZ29hbHMgZHJhZnQuCj4gPiA+ID4KPiA+ID4gPiAt LUdlcmFyZG8KPiA+ID4gPgo+ID4gPiA+ID4gYnV0IGl0IHdvdWxkIGJlIGdvb2QgdG8ga2VlcCB0 aGUgc29sdXRpb24gZmxleGlibGUKPiA+ID4gPiA+IHNvIHRoYXQgaXQgY2FuIGJlIGV4dGVuZGVk IGxhdGVyIGZvciA0Mjg1IGlmIHJlcXVpcmVkLgo+ID4gPiA+ID4KPiA+ID4gPiA+IFZpamF5Cj4g PiA+ID4gPgo+ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KPiA+ID4gPiA+IERpTUUgbWFpbGluZyBsaXN0Cj4gPiA+ID4gPiBEaU1FQGlldGYu b3JnCj4gPiA+ID4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1l Cj4gPiA+ID4gPgo+ID4gPiA+Cj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KPiA+ID4gPiBEaU1FIG1haWxpbmcgbGlzdAo+ID4gPiA+IERpTUVA aWV0Zi5vcmcKPiA+ID4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k aW1lCj4gPiA+ID4KPiA+ID4gPgo+ID4gPiA+Cj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KPiA+ID4gPiBNaXA2IG1haWxpbmcgbGlzdAo+ID4g PiA+IE1pcDZAaWV0Zi5vcmcKPiA+ID4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9taXA2Cj4gPiA+ID4KPiA+ID4KPiA+ID4KPiA+ID4KPiA+Cj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4gRGlNRSBtYWlsaW5nIGxp c3QKPiA+IERpTUVAaWV0Zi5vcmcKPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RpbWUKPiA+Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwo+IERpTUUgbWFpbGluZyBsaXN0Cj4gRGlNRUBpZXRmLm9yZwo+IGh0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUKPgo= --===============1587347878== 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 --===============1587347878==-- From dime-bounces@ietf.org Tue Oct 24 16:08:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcSZB-00081k-Bx; Tue, 24 Oct 2006 16:08:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcSZA-00081N-OE for dime@ietf.org; Tue, 24 Oct 2006 16:08:04 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcSYk-0005Q9-1U for dime@ietf.org; Tue, 24 Oct 2006 16:08:04 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k9OK7blA007907 for ; Tue, 24 Oct 2006 22:07:37 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k9OK7aHv029127 for ; Tue, 24 Oct 2006 22:07:36 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 22:07:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Oct 2006 22:07:36 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda Thread-Index: Acb3moxKouNzJHeIQgCT65vIKDsl9Q== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 24 Oct 2006 20:07:36.0799 (UTC) FILETIME=[0CCD5EF0:01C6F7A8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Dime] Agenda 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="===============1025261106==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1025261106== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F7A8.0C9F2B4A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F7A8.0C9F2B4A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 we have produced a tentative agenda for the DIME WG meeting:=20 http://www3.ietf.org/proceedings/06nov/agenda/dime.txt Please let us know if we forgot something.=20 Ciao Hannes & John ------_=_NextPart_001_01C6F7A8.0C9F2B4A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda

Hi all,

we have produced a tentative agenda for = the DIME WG meeting:
http://www3.ietf.org/proceedings/06nov/agenda/dime.txt

Please let us know if we forgot = something.

Ciao
Hannes & John

------_=_NextPart_001_01C6F7A8.0C9F2B4A-- --===============1025261106== 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 --===============1025261106==-- From dime-bounces@ietf.org Tue Oct 24 16:08:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcSZC-00082c-Gb; Tue, 24 Oct 2006 16:08:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcSZB-00081S-1x for dime@ietf.org; Tue, 24 Oct 2006 16:08:05 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcSYj-0005P1-Vw for dime@ietf.org; Tue, 24 Oct 2006 16:08:05 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k9OK7Y5U007865 for ; Tue, 24 Oct 2006 22:07:34 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k9OK7TFV029088 for ; Tue, 24 Oct 2006 22:07:34 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 22:07:33 +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: Tue, 24 Oct 2006 22:07:09 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter Tutorial Thread-Index: Acb3p3yRrAgHp6bKS/qmrq2SqAHeiA== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 24 Oct 2006 20:07:33.0377 (UTC) FILETIME=[0AC33710:01C6F7A8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Dime] Diameter Tutorial 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,=20 in a discussion with John we came up with the idea of scheduling a tutorial about Diameter, accounting, and credit control.=20 WHEN? Monday, starting at 8pm for about 1 1/2 or 2 hours (after the afternoon session iii) WHERE? Room yet to be defined; depending on the number of participants WHY? With the recent work on mobility and Quality of Service we noticed that we have experts in specific problem domains but there is room for improvement regarding the Diameter knowledge.=20 WHO: Focus: Authors of Diameter applications.=20 But: Everyone with interest in Diameter is welcome. Please send a note to the chairs with the Subject line "diameter-tutorial" if you plan to attend the tutorial.=20 Ciao Hannes & John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 24 23:05:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcZ56-0002UT-Aj; Tue, 24 Oct 2006 23:05:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcZ53-0002UN-TA for dime@ietf.org; Tue, 24 Oct 2006 23:05:25 -0400 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcZ52-0006FN-DO for dime@ietf.org; Tue, 24 Oct 2006 23:05:25 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id BAAEA2063E for ; Wed, 25 Oct 2006 08:30:06 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 93D0620609 for ; Wed, 25 Oct 2006 08:30:06 +0530 (IST) Received: from blr-m2-msg.wipro.com ([10.116.50.99]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 08:35:18 +0530 Received: from wipro-nitin.wipro.com ([10.116.8.7]) by blr-m2-msg.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 08:35:17 +0530 Subject: Re: [Dime] Diameter Tutorial From: venkatesh devalapura nagabhushana To: "Tschofenig, Hannes" In-Reply-To: References: Content-Type: text/plain Date: Wed, 25 Oct 2006 08:37:48 +0530 Message-Id: <1161745668.3260.1.camel@ec4laptop12197.wipro.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2006 03:05:17.0247 (UTC) FILETIME=[65FE44F0:01C6F7E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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, Is it possible to share the tutorial ppt for the benefit of those who can't be physically present ?? Thanks, Venkatesh On Tue, 2006-10-24 at 22:07 +0200, Tschofenig, Hannes wrote: > Hi all, > > in a discussion with John we came up with the idea of scheduling a > tutorial about Diameter, accounting, and credit control. > > WHEN? Monday, starting at 8pm for about 1 1/2 or 2 hours (after the > afternoon session iii) > > WHERE? Room yet to be defined; depending on the number of participants > > WHY? With the recent work on mobility and Quality of Service we noticed > that we have experts in specific problem domains but there is room for > improvement regarding the Diameter knowledge. > > WHO: Focus: Authors of Diameter applications. > But: Everyone with interest in Diameter is welcome. > > Please send a note to the chairs with the Subject line > "diameter-tutorial" if you plan to attend the tutorial. > > Ciao > Hannes & John > > > _______________________________________________ > 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 Oct 25 01:34:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcbPC-00089a-RD; Wed, 25 Oct 2006 01:34:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcbPB-00089K-V7 for dime@ietf.org; Wed, 25 Oct 2006 01:34:21 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GcbP9-0002Vi-Gp for dime@ietf.org; Wed, 25 Oct 2006 01:34:21 -0400 X-VirusChecked: Checked X-Env-Sender: vishnu@motorola.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1161754453!11856322!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 20518 invoked from network); 25 Oct 2006 05:34:13 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-119.messagelabs.com with SMTP; 25 Oct 2006 05:34:13 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k9P5Y9l1021696 for ; Tue, 24 Oct 2006 22:34:13 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k9P5Y7Wn007009 for ; Wed, 25 Oct 2006 00:34:08 -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: Wed, 25 Oct 2006 13:34:05 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-vishnu-diameter-location-update-common-msg-00.txt Thread-Index: AcbvAdoz8SKjXcZfSouoA7QA+IctGwI9PStA From: "Ram O V Vishnu-A14676" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: [Dime] FW: draft-vishnu-diameter-location-update-common-msg-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, We have a new draft (please see http://www.ietf.org/internet-drafts/draft-vishnu-diameter-location-updat e-common-msg-00.txt),=20 which describes a location update mechanism using Diameter (please see http://www.tschofenig.priv.at:8080/diameter-interop/issue22 too). Comments are welcome. Regards, Vishnu. Motorola +91 9844178052 [*] General [] Motorola Internal Use Only -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Saturday, October 14, 2006 1:20 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-vishnu-diameter-location-update-common-msg-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : Diameter Location-Update common message=20 Author(s) : V. Ram, S. Gera Filename : draft-vishnu-diameter-location-update-common-msg-00.txt Pages : 9 Date : 2006-10-13 =09 The Diameter base protocol which is intended to provide =20 Authentication, Authorization and Accounting (AAA) framework for =20 applications (such as network access) is specified in [RFC 3588]. [RFC 3588] specifies a number of reusable common messages which can =20 be used across applications. =20 =20 This draft adds to the list of common messages by adding a location =20 update message which can be used in different existing and potential authentication ,authorization and accounting scenarios. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vishnu-diameter-location-updat e-common-msg-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-vishnu-diameter-location-update-common-msg-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-vishnu-diameter-location-update-common-msg-00.txt ". =09 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. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 25 02:35:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GccMI-0005Sb-MC; Wed, 25 Oct 2006 02:35:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GccMH-0005Rz-12 for dime@ietf.org; Wed, 25 Oct 2006 02:35:25 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GccMF-0002l5-KE for dime@ietf.org; Wed, 25 Oct 2006 02:35:25 -0400 Received: (qmail invoked by alias); 25 Oct 2006 06:35:22 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp002) with SMTP; 25 Oct 2006 08:35:22 +0200 X-Authenticated: #29516787 Message-ID: <453F05A9.1090200@gmx.net> Date: Wed, 25 Oct 2006 08:35:21 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: venkatesh devalapura nagabhushana Subject: Re: [Dime] Diameter Tutorial References: <1161745668.3260.1.camel@ec4laptop12197.wipro.com> In-Reply-To: <1161745668.3260.1.camel@ec4laptop12197.wipro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: dime@ietf.org, "Tschofenig, Hannes" 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 Sure, but so far we don't have the slides. You will, however, loose the benefit of the discussions. Ciao Hannes PS: In the future we might also be able to distribute these tutorials as podcasts. venkatesh devalapura nagabhushana wrote: > Hi, > > Is it possible to share the tutorial ppt for the benefit of > those who can't be physically present ?? > > Thanks, > Venkatesh > > On Tue, 2006-10-24 at 22:07 +0200, Tschofenig, Hannes wrote: >> Hi all, >> >> in a discussion with John we came up with the idea of scheduling a >> tutorial about Diameter, accounting, and credit control. >> >> WHEN? Monday, starting at 8pm for about 1 1/2 or 2 hours (after the >> afternoon session iii) >> >> WHERE? Room yet to be defined; depending on the number of participants >> >> WHY? With the recent work on mobility and Quality of Service we noticed >> that we have experts in specific problem domains but there is room for >> improvement regarding the Diameter knowledge. >> >> WHO: Focus: Authors of Diameter applications. >> But: Everyone with interest in Diameter is welcome. >> >> Please send a note to the chairs with the Subject line >> "diameter-tutorial" if you plan to attend the tutorial. >> >> Ciao >> Hannes & John >> >> >> _______________________________________________ >> 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 Wed Oct 25 03:13:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GccxC-0005km-9S; Wed, 25 Oct 2006 03:13:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GccxA-0005kh-6Z for dime@ietf.org; Wed, 25 Oct 2006 03:13:33 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gccx8-000240-Q9 for dime@ietf.org; Wed, 25 Oct 2006 03:13:32 -0400 X-VirusChecked: Checked X-Env-Sender: vishnu@motorola.com X-Msg-Ref: server-3.tower-128.messagelabs.com!1161760088!4736265!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 14645 invoked from network); 25 Oct 2006 07:08:08 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-128.messagelabs.com with SMTP; 25 Oct 2006 07:08:08 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k9P787iW015455 for ; Wed, 25 Oct 2006 00:08:07 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k9P786kC026374 for ; Wed, 25 Oct 2006 02:08:06 -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: Wed, 25 Oct 2006 15:08:02 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW:draft-kamble-dime-mip6-ha-aaa-00.txt Thread-Index: AcbzCIEG5gB67xgETey7Kor/LOrKYwE7teew From: "Ram O V Vishnu-A14676" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, We have put together some thoughts on the HA-AAA interface for mip6 (http://www.ietf.org/internet-drafts/draft-kamble-dime-mip6-ha-aaa-00.tx t). Please take a look & comment. Regards, Vishnu. Motorola +91 9844178052 [*] General [] Motorola Internal Use Only -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Thursday, October 19, 2006 4:20 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-kamble-dime-mip6-ha-aaa-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : HA-AAA Diameter interface for MIP6=20 Author(s) : V. Kamble Filename : draft-kamble-dime-mip6-ha-aaa-00.txt Pages : 10 Date : 2006-10-18 =09 This document specifies a Diameter application between AAAH and HA=20 that allows authentication, authorization and accounting for Mobile=20 IPv6 services. Further, this interface could also be used for=20 bootstrapping of MIPv6.=20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kamble-dime-mip6-ha-aaa-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-kamble-dime-mip6-ha-aaa-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-kamble-dime-mip6-ha-aaa-00.txt". =09 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. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 25 03:13:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GccxS-0006Rp-1k; Wed, 25 Oct 2006 03:13:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GccxQ-0006LM-Q5 for dime@ietf.org; Wed, 25 Oct 2006 03:13:48 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GccxP-00025r-AF for dime@ietf.org; Wed, 25 Oct 2006 03:13:48 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9P7DZ6D019880; Wed, 25 Oct 2006 10:13:46 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 10:13:46 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 10:13:45 +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] Diameter Tutorial Date: Wed, 25 Oct 2006 10:13:45 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Tutorial Thread-Index: Acb3p3yRrAgHp6bKS/qmrq2SqAHeiAAXYxdg From: To: , X-OriginalArrivalTime: 25 Oct 2006 07:13:45.0394 (UTC) FILETIME=[1BF0F920:01C6F805] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Also, it might be good if people sent in some areas that they would like to understand better. If you have a topic you'd like discussed, just ask. John >-----Original Message----- >From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 >Sent: 24 October, 2006 23:07 >To: dime@ietf.org >Subject: [Dime] Diameter Tutorial > >Hi all,=20 > >in a discussion with John we came up with the idea of=20 >scheduling a tutorial about Diameter, accounting, and credit control.=20 > >WHEN? Monday, starting at 8pm for about 1 1/2 or 2 hours=20 >(after the afternoon session iii) > >WHERE? Room yet to be defined; depending on the number of participants > >WHY? With the recent work on mobility and Quality of Service=20 >we noticed that we have experts in specific problem domains=20 >but there is room for improvement regarding the Diameter knowledge.=20 > >WHO: Focus: Authors of Diameter applications.=20 > But: Everyone with interest in Diameter is welcome. > >Please send a note to the chairs with the Subject line=20 >"diameter-tutorial" if you plan to attend the tutorial.=20 > >Ciao >Hannes & John > > >_______________________________________________ >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 Oct 25 03:35:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcdIE-0002RS-2I; Wed, 25 Oct 2006 03:35:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcdIC-0002RB-Ra for dime@ietf.org; Wed, 25 Oct 2006 03:35:16 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcdIB-000638-Bs for dime@ietf.org; Wed, 25 Oct 2006 03:35:16 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 09:35:09 +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 Tutorial Date: Wed, 25 Oct 2006 09:35:08 +0200 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E03014DF6A0@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Tutorial Thread-Index: Acb3p3yRrAgHp6bKS/qmrq2SqAHeiAAXYxdgAAAmBQA= From: To: , , X-OriginalArrivalTime: 25 Oct 2006 07:35:09.0380 (UTC) FILETIME=[1941B040:01C6F808] X-Spam-Score: 0.2 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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, Well two obvious topics ;-) o in depth prez on use/allocation of Application-Ids o in depth prez on request routing (including proxies, relays, different app-ids, decorated NAIs, ..) at=20 and maybe also something on other things we lately had lengthy discussions like 'correct' use/allocations of nas-port-type and=20 service-type vs applications.. /Jouni > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Sent: 25. lokakuuta 2006 10:14 > To: hannes.tschofenig@siemens.com; dime@ietf.org > Subject: RE: [Dime] Diameter Tutorial >=20 > Also, it might be good if people sent in some areas that they=20 > would like to understand better. If you have a topic you'd=20 > like discussed, just ask. >=20 > John >=20 > >-----Original Message----- > >From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > >Sent: 24 October, 2006 23:07 > >To: dime@ietf.org > >Subject: [Dime] Diameter Tutorial > > > >Hi all, > > > >in a discussion with John we came up with the idea of scheduling a=20 > >tutorial about Diameter, accounting, and credit control. > > > >WHEN? Monday, starting at 8pm for about 1 1/2 or 2 hours (after the=20 > >afternoon session iii) > > > >WHERE? Room yet to be defined; depending on the number of=20 > participants > > > >WHY? With the recent work on mobility and Quality of Service=20 > we noticed=20 > >that we have experts in specific problem domains but there=20 > is room for=20 > >improvement regarding the Diameter knowledge. > > > >WHO: Focus: Authors of Diameter applications.=20 > > But: Everyone with interest in Diameter is welcome. > > > >Please send a note to the chairs with the Subject line=20 > >"diameter-tutorial" if you plan to attend the tutorial. > > > >Ciao > >Hannes & John > > > > > >_______________________________________________ > >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 Wed Oct 25 03:43:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcdQS-0008BT-I5; Wed, 25 Oct 2006 03:43:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcdQR-0008BO-Rg for dime@ietf.org; Wed, 25 Oct 2006 03:43:47 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcdQQ-00082S-6r for dime@ietf.org; Wed, 25 Oct 2006 03:43:47 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k9P7hg20000788 for ; Wed, 25 Oct 2006 09:43:43 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k9P7hgfG028351 for ; Wed, 25 Oct 2006 09:43:42 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 09:43:41 +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 Subject: AW: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt Date: Wed, 25 Oct 2006 09:42:39 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt Thread-Index: AcbzCIEG5gB67xgETey7Kor/LOrKYwE7teewAARvrDA= From: "Tschofenig, Hannes" To: "Ram O V Vishnu-A14676" , X-OriginalArrivalTime: 25 Oct 2006 07:43:41.0952 (UTC) FILETIME=[4AC5F800:01C6F809] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 Vishnu,=20 how does your draft relate to the ongoing Diameter mobility work? Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com]=20 > Gesendet: Mittwoch, 25. Oktober 2006 09:08 > An: dime@ietf.org > Betreff: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt=20 >=20 > Hi, >=20 > We have put together some thoughts on the HA-AAA interface for mip6 > (http://www.ietf.org/internet-drafts/draft-kamble-dime-mip6-ha > -aaa-00.tx > t). >=20 > Please take a look & comment. >=20 > Regards, > Vishnu. >=20 > Motorola > +91 9844178052 > [*] General > [] Motorola Internal Use Only >=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Thursday, October 19, 2006 4:20 AM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-kamble-dime-mip6-ha-aaa-00.txt=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 >=20 > Title : HA-AAA Diameter interface for MIP6=20 > Author(s) : V. Kamble > Filename : draft-kamble-dime-mip6-ha-aaa-00.txt > Pages : 10 > Date : 2006-10-18 > =09 > This document specifies a Diameter application between AAAH and HA=20 > that allows authentication, authorization and accounting=20 > for Mobile=20 > IPv6 services. Further, this interface could also be used for=20 > bootstrapping of MIPv6.=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kamble-dime-mip6-ha- > aaa-00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > the message.=20 > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then=20 > "get draft-kamble-dime-mip6-ha-aaa-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or 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-kamble-dime-mip6-ha-aaa-00.txt". > =09 > 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. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 25 04:14:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcdtv-0002gf-C8; Wed, 25 Oct 2006 04:14:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcdsW-0002Bp-Fe for dime@ietf.org; Wed, 25 Oct 2006 04:12:49 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcdib-0002Xi-DH for dime@ietf.org; Wed, 25 Oct 2006 04:02:34 -0400 Received: by ug-out-1314.google.com with SMTP id 72so28395ugd for ; Wed, 25 Oct 2006 01:02:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gg8VizCo/pd8UYddAJgsQyjb+F12hYXbzxwvXSaszxLRCT5LqxlfDE2NzEcpKCn6tH/clvupvGoxwI1AE8//zkekGkJEPqj2gP5JdiQGmcvKfItsOIH+GdH1pjKtS/gk3GpC85RYLaJOWwRxpqxeXD5Nnyhg8UifbJUMmq9Utu8= Received: by 10.67.89.5 with SMTP id r5mr379259ugl; Wed, 25 Oct 2006 01:02:31 -0700 (PDT) Received: by 10.66.243.16 with HTTP; Wed, 25 Oct 2006 01:02:31 -0700 (PDT) Message-ID: Date: Wed, 25 Oct 2006 17:02:31 +0900 From: "Gerardo Giaretta" To: "Ram O V Vishnu-A14676" Subject: Re: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 Vishnu, how does your draft relate with draft-ietf-mip6-aaa-ha-goals that is in WGLC in MIP6 WG? Thanks, --Gerardo On 10/25/06, Ram O V Vishnu-A14676 wrote: > Hi, > > We have put together some thoughts on the HA-AAA interface for mip6 > (http://www.ietf.org/internet-drafts/draft-kamble-dime-mip6-ha-aaa-00.tx > t). > > Please take a look & comment. > > Regards, > Vishnu. > > Motorola > +91 9844178052 > [*] General > [] Motorola Internal Use Only > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Thursday, October 19, 2006 4:20 AM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-kamble-dime-mip6-ha-aaa-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : HA-AAA Diameter interface for MIP6 > Author(s) : V. Kamble > Filename : draft-kamble-dime-mip6-ha-aaa-00.txt > Pages : 10 > Date : 2006-10-18 > > This document specifies a Diameter application between AAAH and HA > that allows authentication, authorization and accounting for Mobile > IPv6 services. Further, this interface could also be used for > bootstrapping of MIPv6. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kamble-dime-mip6-ha-aaa-00.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-kamble-dime-mip6-ha-aaa-00.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-kamble-dime-mip6-ha-aaa-00.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. > > _______________________________________________ > 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 Oct 25 09:33:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gciss-0000T0-VX; Wed, 25 Oct 2006 09:33:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcisr-0000Si-Na for dime@ietf.org; Wed, 25 Oct 2006 09:33:29 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gcisq-0006sw-CD for dime@ietf.org; Wed, 25 Oct 2006 09:33:29 -0400 X-VirusChecked: Checked X-Env-Sender: vishnu@motorola.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1161782961!10388000!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 30898 invoked from network); 25 Oct 2006 13:29:21 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-119.messagelabs.com with SMTP; 25 Oct 2006 13:29: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 k9PDTJD0025741 for ; Wed, 25 Oct 2006 06:29:19 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k9PDTIYc006965 for ; Wed, 25 Oct 2006 08:29:19 -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 Subject: RE: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt Date: Wed, 25 Oct 2006 21:29:17 +0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt Thread-Index: Acb4DMATAqs5QCxsQCWxkHpkaBHDPwAIgrAg From: "Ram O V Vishnu-A14676" To: "Gerardo Giaretta" X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 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, I think it relates well. We can discuss more (if you are interested) during IETF67. -------------- Some notes which we made are: 5.1. General goals: These General goals are satisfied by Diameter protocol.=20 5.2. Service Authorization G2.1, G2.2, G2.3, G2.4, 2.5, 2.6 : looks ok. Unless you have specific comments. 5.3. Accounting G3.1 currently we are not handling accounting. Will add. 5.4. Mobile Node Authentication G4.1: I think we are currently independant of EAP. I dont think we will have any problem with HA as pass through authenticator. 5.5. Provisioning of Configuration Parameters G5.1: done,=20 G5.2: will add. 6. Goals for the Integrated Scenario As I was telling Hannes, we would probably rely on "push" scenario in draft-tschofenig-dime-mip6-integrated-00.txt, whereas we define a "pull" scenario between HA-AAA. =20 Regards, Vishnu. Motorola +91 9844178052 [*] General [] Motorola Internal Use Only -----Original Message----- From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com]=20 Sent: Wednesday, October 25, 2006 1:33 PM To: Ram O V Vishnu-A14676 Cc: dime@ietf.org Subject: Re: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt Hi Vishnu, how does your draft relate with draft-ietf-mip6-aaa-ha-goals that is in WGLC in MIP6 WG? Thanks, --Gerardo On 10/25/06, Ram O V Vishnu-A14676 wrote: > Hi, > > We have put together some thoughts on the HA-AAA interface for mip6=20 > (http://www.ietf.org/internet-drafts/draft-kamble-dime-mip6-ha-aaa-00. > tx > t). > > Please take a look & comment. > > Regards, > Vishnu. > > Motorola > +91 9844178052 > [*] General > [] Motorola Internal Use Only > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Thursday, October 19, 2006 4:20 AM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-kamble-dime-mip6-ha-aaa-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > > > Title : HA-AAA Diameter interface for MIP6 > Author(s) : V. Kamble > Filename : draft-kamble-dime-mip6-ha-aaa-00.txt > Pages : 10 > Date : 2006-10-18 > > This document specifies a Diameter application between AAAH and HA > that allows authentication, authorization and accounting for Mobile > IPv6 services. Further, this interface could also be used for > bootstrapping of MIPv6. > > > A URL for this Internet-Draft is:=20 > http://www.ietf.org/internet-drafts/draft-kamble-dime-mip6-ha-aaa-00.t > xt > > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. You can also visit=20 > 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=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then "get=20 > draft-kamble-dime-mip6-ha-aaa-00.txt". > > 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 > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-kamble-dime-mip6-ha-aaa-00.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=20 > 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=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. > > _______________________________________________ > 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 Oct 25 09:41:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcj0a-0003rp-En; Wed, 25 Oct 2006 09:41:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcj0Y-0003ne-UV for dime@ietf.org; Wed, 25 Oct 2006 09:41:26 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gcj0U-00009h-Ch for dime@ietf.org; Wed, 25 Oct 2006 09:41:26 -0400 Received: (qmail invoked by alias); 25 Oct 2006 13:41:20 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp018) with SMTP; 25 Oct 2006 15:41:20 +0200 X-Authenticated: #29516787 Message-ID: <453F697F.8000305@gmx.net> Date: Wed, 25 Oct 2006 15:41:19 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Ram O V Vishnu-A14676 Subject: Re: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt 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: 848ed35f2a4fc0638fa89629cb640f48 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 Vishnu, I think I found the confusion. You read draft-tschofenig-dime-mip6-integrated-00.txt but we are, however, already working on draft-ietf-dime-mip6-split-01.txt & draft-ietf-dime-mip6-integrated-01.txt. Ciao Hannes Ram O V Vishnu-A14676 wrote: > Hi Gerardo, > > I think it relates well. We can discuss more (if you are interested) > during IETF67. > -------------- > Some notes which we made are: > > 5.1. General goals: These General goals are satisfied by Diameter > protocol. > > 5.2. Service Authorization > > G2.1, G2.2, G2.3, G2.4, 2.5, 2.6 : looks ok. Unless you have specific > comments. > > 5.3. Accounting > > G3.1 currently we are not handling accounting. Will add. > > 5.4. Mobile Node Authentication > > G4.1: I think we are currently independant of EAP. I dont think we > will have any problem with HA as pass through authenticator. > > 5.5. Provisioning of Configuration Parameters > > G5.1: done, > G5.2: will add. > > 6. Goals for the Integrated Scenario > > As I was telling Hannes, we would probably rely on "push" scenario in > draft-tschofenig-dime-mip6-integrated-00.txt, whereas we define a "pull" > scenario between HA-AAA. > > > Regards, > Vishnu. > > Motorola > +91 9844178052 > [*] General > [] Motorola Internal Use Only > > > > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Wednesday, October 25, 2006 1:33 PM > To: Ram O V Vishnu-A14676 > Cc: dime@ietf.org > Subject: Re: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt > > > Hi Vishnu, > > how does your draft relate with draft-ietf-mip6-aaa-ha-goals that is in > WGLC in MIP6 WG? > > Thanks, > --Gerardo > > On 10/25/06, Ram O V Vishnu-A14676 wrote: >> Hi, >> >> We have put together some thoughts on the HA-AAA interface for mip6 >> (http://www.ietf.org/internet-drafts/draft-kamble-dime-mip6-ha-aaa-00. >> tx >> t). >> >> Please take a look & comment. >> >> Regards, >> Vishnu. >> >> Motorola >> +91 9844178052 >> [*] General >> [] Motorola Internal Use Only >> >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: Thursday, October 19, 2006 4:20 AM >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-kamble-dime-mip6-ha-aaa-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : HA-AAA Diameter interface for MIP6 >> Author(s) : V. Kamble >> Filename : draft-kamble-dime-mip6-ha-aaa-00.txt >> Pages : 10 >> Date : 2006-10-18 >> >> This document specifies a Diameter application between AAAH and HA >> that allows authentication, authorization and accounting for Mobile >> IPv6 services. Further, this interface could also be used for >> bootstrapping of MIPv6. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-kamble-dime-mip6-ha-aaa-00.t >> xt >> >> 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-kamble-dime-mip6-ha-aaa-00.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-kamble-dime-mip6-ha-aaa-00.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. >> >> _______________________________________________ >> 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 Wed Oct 25 17:50:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcqdi-0001dq-2H; Wed, 25 Oct 2006 17:50:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcqdg-0001bJ-9D for dime@ietf.org; Wed, 25 Oct 2006 17:50:20 -0400 Received: from [194.71.127.149] (helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcqdd-0006Y5-O8 for dime@ietf.org; Wed, 25 Oct 2006 17:50:20 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id k9PKZjqj007127; Wed, 25 Oct 2006 22:35:46 +0200 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <92059C34-A690-4B9F-8A64-F4F1A3C96E0B@acm.org> Content-Transfer-Encoding: 7bit From: Avri Doria Date: Wed, 25 Oct 2006 23:49:58 +0200 To: dime@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Ulf Bodin Subject: [Dime] I-D ACTION:draft-bodin-dime-auditing-reqs-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 Hi, A little later then I projected. I would like to ask the WG to consider this as a work item at this point. thanks a. -------- Original Message -------- Subject: I-D ACTION:draft-bodin-dime-auditing-reqs-01.txt Date: Wed, 25 Oct 2006 15:50:04 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirement for the addition of Auditing Functionality to Diameter Author(s) : U. Bodin, et al. Filename : draft-bodin-dime-auditing-reqs-01.txt Pages : 8 Date : 2006-10-25 Diameter is being increasingly included in the work of other standards organizations and has become a key protocol in many architectures. One of the uses of Diameter includes setting and maintaining hard-state and soft-state during failover and in the event of delayed refresh messages respectively. Often there is a need to query for information on active sessions for backup or synchronization purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bodin-dime-auditing- reqs-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-bodin-dime-auditing-reqs-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-bodin-dime-auditing-reqs-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. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 25 18:50:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcrZT-0002iC-Ki; Wed, 25 Oct 2006 18:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcrZS-0002hn-HY; Wed, 25 Oct 2006 18:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcrZS-00063o-7r; Wed, 25 Oct 2006 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 33B6126DEA; Wed, 25 Oct 2006 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GcrZS-00032L-2x; Wed, 25 Oct 2006 18: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: Wed, 25 Oct 2006 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-mip6-integrated-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 : The NAS - HAAA Interface for MIPv6 Bootstrapping Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-integrated-01.txt Pages : 21 Date : 2006-10-25 A Mobile IPv6 node requires a home agent address, a home address, and IPsec security association with its home agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these parameters are statically configured. Ongoing Mobile IPv6 bootstrapping work aims to make this information dynamically available to the mobile node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes the usage of Diameter to facilitate Mobile IPv6 bootstrapping for the NAS - HAAA interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-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-mip6-integrated-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-mip6-integrated-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: <2006-10-25152849.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-integrated-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-integrated-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-25152849.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 Oct 25 18:51:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcrbI-0003Sg-Bg; Wed, 25 Oct 2006 18:51:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcrbH-0003SV-Cw for dime@ietf.org; Wed, 25 Oct 2006 18:51:55 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcrbG-0006Pg-2l for dime@ietf.org; Wed, 25 Oct 2006 18:51:55 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7P00A2KRDBZB@usaga01-in.huawei.com> for dime@ietf.org; Wed, 25 Oct 2006 15:48:47 -0700 (PDT) Received: from N737011 ([10.124.12.90]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7P006QTRD7LW@usaga01-in.huawei.com> for dime@ietf.org; Wed, 25 Oct 2006 15:48:47 -0700 (PDT) Date: Wed, 25 Oct 2006 15:51:47 -0700 From: Madjid Nakhjiri Subject: RE: [Dime] Agenda In-reply-to: To: "'Tschofenig, Hannes'" , dime@ietf.org Message-id: <002401c6f888$26e52530$5a0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acb3moxKouNzJHeIQgCT65vIKDsl9QA7Ywqw X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f 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: , Content-Type: multipart/mixed; boundary="===============0576328900==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0576328900== Content-type: multipart/alternative; boundary="Boundary_(ID_IoR06HUkqQmC1YRQsEH7bg)" This is a multi-part message in MIME format. --Boundary_(ID_IoR06HUkqQmC1YRQsEH7bg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT No room for any other presentations? Madjid _____ From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] Sent: Tuesday, October 24, 2006 1:08 PM To: dime@ietf.org Subject: [Dime] Agenda Hi all, we have produced a tentative agenda for the DIME WG meeting: http://www3.ietf.org/proceedings/06nov/agenda/dime.txt Please let us know if we forgot something. Ciao Hannes & John --Boundary_(ID_IoR06HUkqQmC1YRQsEH7bg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Agenda

No room for any other presentations?

 

Madjid

 

From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]
Sent: Tuesday, October 24, 2006 1:08 PM
To: dime@ietf.org
Subject: [Dime] Agenda

 

Hi all,

we have produced a tentative agenda for the DIME WG meeting:
http://www3.ietf.org/proceedings/06nov/agenda/dime.txt

Please let us know if we forgot something.

Ciao
Hannes & John

--Boundary_(ID_IoR06HUkqQmC1YRQsEH7bg)-- --===============0576328900== 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 --===============0576328900==-- From dime-bounces@ietf.org Wed Oct 25 19:56:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcsbT-0003kG-G8; Wed, 25 Oct 2006 19:56:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcsbR-0003jn-UH; Wed, 25 Oct 2006 19:56:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcsbR-0006pT-Rf; Wed, 25 Oct 2006 19:56:09 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GcsbP-0005EA-H0; Wed, 25 Oct 2006 19:56:09 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 678392ACD9; Wed, 25 Oct 2006 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GcrZS-00032b-65; Wed, 25 Oct 2006 18: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: Wed, 25 Oct 2006 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-mip6-split-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 : Diameter Mobile IPv6: HA-to-AAAH support Author(s) : J. Bournelle Filename : draft-ietf-dime-mip6-split-01.txt Pages : 15 Date : 2006-10-25 In a Mobile IPv6 deployment the need for an interaction between the Home Agent, the AAA infrastructure of the Mobile Service Provider (MSP) and the Mobility Service Authorizer (MSA) has been identified. This document describes a new Diameter application, called Mobile IPv6 Authorization Application, used in conjunction with the Diameter EAP Application is used to perform the necessary AAA functions before executing Mobile IPv6 services. This document also specifies the role of the Home Agent as part of the AAA infrastructure supporting the Diameter Mobile IPv6 Authorization Application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-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-mip6-split-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-mip6-split-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: <2006-10-25154809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-split-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-split-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-25154809.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Thu Oct 26 05:37:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd1gE-0006s2-Dl; Thu, 26 Oct 2006 05:37:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd1gD-0006rh-El for dime@ietf.org; Thu, 26 Oct 2006 05:37:41 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd1gB-00005i-Ux for dime@ietf.org; Thu, 26 Oct 2006 05:37:41 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9Q9bVUh029265; Thu, 26 Oct 2006 12:37:39 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 12:37:32 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 12:37:32 +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] Diameter Tutorial Date: Thu, 26 Oct 2006 12:37:31 +0300 Message-ID: In-Reply-To: <5D25AEFB114D034FBDC8B156FCA78E03014DF6A0@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Tutorial Thread-Index: Acb3p3yRrAgHp6bKS/qmrq2SqAHeiAAXYxdgAAAmBQAAMdlkEA== From: To: , , X-OriginalArrivalTime: 26 Oct 2006 09:37:32.0077 (UTC) FILETIME=[5C4215D0:01C6F8E2] X-Spam-Score: 0.2 (/) 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 Sure, that could be useful. You want to present it? John=20 >-----Original Message----- >From: ext jouni.korhonen@teliasonera.com=20 >[mailto:jouni.korhonen@teliasonera.com]=20 >Sent: 25 October, 2006 10:35 >To: Loughney John (Nokia-NRC/Helsinki);=20 >hannes.tschofenig@siemens.com; dime@ietf.org >Subject: RE: [Dime] Diameter Tutorial > >Hi, > >Well two obvious topics ;-) > > o in depth prez on use/allocation of Application-Ids o in=20 >depth prez on request routing (including proxies, > relays, different app-ids, decorated NAIs, ..) at=20 > >and maybe also something on other things we lately had lengthy=20 >discussions like 'correct' use/allocations of nas-port-type=20 >and service-type vs applications.. > >/Jouni > > >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Sent: 25. lokakuuta 2006 10:14 >> To: hannes.tschofenig@siemens.com; dime@ietf.org >> Subject: RE: [Dime] Diameter Tutorial >>=20 >> Also, it might be good if people sent in some areas that they would=20 >> like to understand better. If you have a topic you'd like=20 >discussed,=20 >> just ask. >>=20 >> John >>=20 >> >-----Original Message----- >> >From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] >> >Sent: 24 October, 2006 23:07 >> >To: dime@ietf.org >> >Subject: [Dime] Diameter Tutorial >> > >> >Hi all, >> > >> >in a discussion with John we came up with the idea of scheduling a=20 >> >tutorial about Diameter, accounting, and credit control. >> > >> >WHEN? Monday, starting at 8pm for about 1 1/2 or 2 hours (after the=20 >> >afternoon session iii) >> > >> >WHERE? Room yet to be defined; depending on the number of >> participants >> > >> >WHY? With the recent work on mobility and Quality of Service >> we noticed >> >that we have experts in specific problem domains but there >> is room for >> >improvement regarding the Diameter knowledge. >> > >> >WHO: Focus: Authors of Diameter applications.=20 >> > But: Everyone with interest in Diameter is welcome. >> > >> >Please send a note to the chairs with the Subject line=20 >> >"diameter-tutorial" if you plan to attend the tutorial. >> > >> >Ciao >> >Hannes & John >> > >> > >> >_______________________________________________ >> >DiME mailing list >> >DiME@ietf.org >> >https://www1.ietf.org/mailman/listinfo/dime >> > >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >>=20 > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 26 07:11:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd393-0007jK-7i; Thu, 26 Oct 2006 07:11:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd392-0007iy-8j for dime@ietf.org; Thu, 26 Oct 2006 07:11:32 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcjfK-0001ZO-9G for dime@ietf.org; Wed, 25 Oct 2006 10:23:34 -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 1Gcjcl-0004Rj-OW for dime@ietf.org; Wed, 25 Oct 2006 10:20:59 -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 k9PEF38x005932; Wed, 25 Oct 2006 10:15:03 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <453F70FF.5000403@tari.toshiba.com> Date: Wed, 25 Oct 2006 10:13:19 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.5 (X11/20060812) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com Subject: Re: [Dime] Diameter Tutorial References: <5D25AEFB114D034FBDC8B156FCA78E03014DF6A0@SEHAN021MB.tcad.telia.se> In-Reply-To: <5D25AEFB114D034FBDC8B156FCA78E03014DF6A0@SEHAN021MB.tcad.telia.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: dime@ietf.org, hannes.tschofenig@siemens.com 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, > o in depth prez on use/allocation of Application-Ids > o in depth prez on request routing (including proxies, > relays, different app-ids, decorated NAIs, ..) at > sounds good. > and maybe also something on other things we lately had lengthy > discussions like 'correct' use/allocations of nas-port-type and > service-type vs applications.. > Ok. We can also publish a skeleton of the topics we plan to include so we have a starting point. regards, victor > /Jouni > > > >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Sent: 25. lokakuuta 2006 10:14 >> To: hannes.tschofenig@siemens.com; dime@ietf.org >> Subject: RE: [Dime] Diameter Tutorial >> >> Also, it might be good if people sent in some areas that they >> would like to understand better. If you have a topic you'd >> like discussed, just ask. >> >> John >> >> >>> -----Original Message----- >>> From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] >>> Sent: 24 October, 2006 23:07 >>> To: dime@ietf.org >>> Subject: [Dime] Diameter Tutorial >>> >>> Hi all, >>> >>> in a discussion with John we came up with the idea of scheduling a >>> tutorial about Diameter, accounting, and credit control. >>> >>> WHEN? Monday, starting at 8pm for about 1 1/2 or 2 hours (after the >>> afternoon session iii) >>> >>> WHERE? Room yet to be defined; depending on the number of >>> >> participants >> >>> WHY? With the recent work on mobility and Quality of Service >>> >> we noticed >> >>> that we have experts in specific problem domains but there >>> >> is room for >> >>> improvement regarding the Diameter knowledge. >>> >>> WHO: Focus: Authors of Diameter applications. >>> But: Everyone with interest in Diameter is welcome. >>> >>> Please send a note to the chairs with the Subject line >>> "diameter-tutorial" if you plan to attend the tutorial. >>> >>> Ciao >>> Hannes & John >>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 26 08:12:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd460-0004GZ-Oh; Thu, 26 Oct 2006 08:12:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd460-0004F6-7F for dime@ietf.org; Thu, 26 Oct 2006 08:12:28 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gd42Y-0000bj-Ay for dime@ietf.org; Thu, 26 Oct 2006 08:08:57 -0400 X-VirusChecked: Checked X-Env-Sender: vishnu@motorola.com X-Msg-Ref: server-3.tower-128.messagelabs.com!1161864379!4958180!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 19638 invoked from network); 26 Oct 2006 12:06:19 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-3.tower-128.messagelabs.com with SMTP; 26 Oct 2006 12:06:19 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id k9QC6JQI003409 for ; Thu, 26 Oct 2006 07:06:19 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k9QC6H6r024133 for ; Thu, 26 Oct 2006 07:06:18 -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 Subject: RE: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt Date: Thu, 26 Oct 2006 20:06:16 +0800 Message-ID: In-Reply-To: <453F697F.8000305@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt Thread-Index: Acb4O01acPG7Z0jSQEGaFn/hshZ/JwAuv9Fg From: "Ram O V Vishnu-A14676" To: "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 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 Hannes, Thanks for sending the updated drafts. Sorry, but interestingly, I got the I-D announce for these drafts (and hence the access to these drafts) much after your email!! As it stands, draft-ietf-dime-mip6-split-01.txt section 10.4 is where our draft relates to. Regards, Vishnu. Motorola +91 9844178052 [*] General [] Motorola Internal Use Only -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Wednesday, October 25, 2006 7:11 PM To: Ram O V Vishnu-A14676 Cc: Gerardo Giaretta; dime@ietf.org Subject: Re: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt Hi Vishnu, I think I found the confusion. You read=20 draft-tschofenig-dime-mip6-integrated-00.txt but we are, however,=20 already working on draft-ietf-dime-mip6-split-01.txt &=20 draft-ietf-dime-mip6-integrated-01.txt. Ciao Hannes Ram O V Vishnu-A14676 wrote: > Hi Gerardo, >=20 > I think it relates well. We can discuss more (if you are interested)=20 > during IETF67. > -------------- > Some notes which we made are: >=20 > 5.1. General goals: These General goals are satisfied by Diameter=20 > protocol. >=20 > 5.2. Service Authorization >=20 > G2.1, G2.2, G2.3, G2.4, 2.5, 2.6 : looks ok. Unless you have=20 > specific comments. >=20 > 5.3. Accounting >=20 > G3.1 currently we are not handling accounting. Will add. >=20 > 5.4. Mobile Node Authentication >=20 > G4.1: I think we are currently independant of EAP. I dont think we > will have any problem with HA as pass through authenticator. >=20 > 5.5. Provisioning of Configuration Parameters >=20 > G5.1: done,=20 > G5.2: will add. >=20 > 6. Goals for the Integrated Scenario >=20 > As I was telling Hannes, we would probably rely on "push" scenario=20 > in draft-tschofenig-dime-mip6-integrated-00.txt, whereas we define a=20 > "pull" scenario between HA-AAA. > =20 >=20 > Regards, > Vishnu. >=20 > Motorola > +91 9844178052 > [*] General > [] Motorola Internal Use Only >=20 >=20 >=20 > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Wednesday, October 25, 2006 1:33 PM > To: Ram O V Vishnu-A14676 > Cc: dime@ietf.org > Subject: Re: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt >=20 >=20 > Hi Vishnu, >=20 > how does your draft relate with draft-ietf-mip6-aaa-ha-goals that is=20 > in WGLC in MIP6 WG? >=20 > Thanks, > --Gerardo >=20 > On 10/25/06, Ram O V Vishnu-A14676 wrote: >> Hi, >> >> We have put together some thoughts on the HA-AAA interface for mip6 >> (http://www.ietf.org/internet-drafts/draft-kamble-dime-mip6-ha-aaa-00. >> tx >> t). >> >> Please take a look & comment. >> >> Regards, >> Vishnu. >> >> Motorola >> +91 9844178052 >> [*] General >> [] Motorola Internal Use Only >> >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: Thursday, October 19, 2006 4:20 AM >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-kamble-dime-mip6-ha-aaa-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : HA-AAA Diameter interface for MIP6 >> Author(s) : V. Kamble >> Filename : draft-kamble-dime-mip6-ha-aaa-00.txt >> Pages : 10 >> Date : 2006-10-18 >> >> This document specifies a Diameter application between AAAH and HA >> that allows authentication, authorization and accounting for Mobile >> IPv6 services. Further, this interface could also be used for >> bootstrapping of MIPv6. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-kamble-dime-mip6-ha-aaa-00.t >> xt >> >> 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 >=20 >> 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=20 >> logging in, type "cd internet-drafts" and then "get=20 >> draft-kamble-dime-mip6-ha-aaa-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html or=20 >> 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-kamble-dime-mip6-ha-aaa-00.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=20 >> Internet-Draft. >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 26 08:13:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd479-0005nO-6N; Thu, 26 Oct 2006 08:13:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd477-0005mD-9Q for dime@ietf.org; Thu, 26 Oct 2006 08:13:37 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gd474-00025G-RN for dime@ietf.org; Thu, 26 Oct 2006 08:13:37 -0400 Received: (qmail invoked by alias); 26 Oct 2006 12:13:34 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp036) with SMTP; 26 Oct 2006 14:13:34 +0200 X-Authenticated: #29516787 Message-ID: <4540A66F.8020308@gmx.net> Date: Thu, 26 Oct 2006 14:13:35 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Madjid Nakhjiri Subject: Re: [Dime] Agenda References: <002401c6f888$26e52530$5a0c7c0a@china.huawei.com> In-Reply-To: <002401c6f888$26e52530$5a0c7c0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: dime@ietf.org, "'Tschofenig, Hannes'" 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 What would you like to present? To make it easier for us please indicate - Title of the presentation - Required time - Presenter - Draft filename Ciao Hannes Madjid Nakhjiri wrote: > No room for any other presentations? > > > > Madjid > > > > ------------------------------------------------------------------------ > > *From:* Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > *Sent:* Tuesday, October 24, 2006 1:08 PM > *To:* dime@ietf.org > *Subject:* [Dime] Agenda > > > > Hi all, > > we have produced a tentative agenda for the DIME WG meeting: > http://www3.ietf.org/proceedings/06nov/agenda/dime.txt > > Please let us know if we forgot something. > > Ciao > Hannes & John > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Oct 26 08:21:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd4EZ-0002Fp-Ae; Thu, 26 Oct 2006 08:21:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd4EX-0002EL-Iu for dime@ietf.org; Thu, 26 Oct 2006 08:21:17 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd4ET-0003DV-UZ for dime@ietf.org; Thu, 26 Oct 2006 08:21:17 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 384D32FE9B; Thu, 26 Oct 2006 14:21:07 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1Gd4G0-0007Ch-9x; Thu, 26 Oct 2006 14:22:48 +0200 Date: Thu, 26 Oct 2006 14:22:48 +0200 From: Julien Bournelle To: Ram O V Vishnu-A14676 Subject: Re: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt Message-ID: <20061026122248.GA27677@ipv6-3.int-evry.fr> References: <453F697F.8000305@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 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, On Thu, Oct 26, 2006 at 08:06:16PM +0800, Ram O V Vishnu-A14676 wrote: > Hannes, > > Thanks for sending the updated drafts. Sorry, but interestingly, I got > the I-D announce for these drafts (and hence the access to these drafts) > much after your email!! > > As it stands, draft-ietf-dime-mip6-split-01.txt section 10.4 is where > our draft relates to. if this is the case, maybe you should rename your draft to avoid confusion :). (As I said earlier, i tend to think that we should deal with 4285 in another document). regards, Julien > > Regards, > Vishnu. > > Motorola > +91 9844178052 > [*] General > [] Motorola Internal Use Only > > > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, October 25, 2006 7:11 PM > To: Ram O V Vishnu-A14676 > Cc: Gerardo Giaretta; dime@ietf.org > Subject: Re: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt > > > Hi Vishnu, > > I think I found the confusion. You read > draft-tschofenig-dime-mip6-integrated-00.txt but we are, however, > already working on draft-ietf-dime-mip6-split-01.txt & > draft-ietf-dime-mip6-integrated-01.txt. > > Ciao > Hannes > > > Ram O V Vishnu-A14676 wrote: > > Hi Gerardo, > > > > I think it relates well. We can discuss more (if you are interested) > > during IETF67. > > -------------- > > Some notes which we made are: > > > > 5.1. General goals: These General goals are satisfied by Diameter > > protocol. > > > > 5.2. Service Authorization > > > > G2.1, G2.2, G2.3, G2.4, 2.5, 2.6 : looks ok. Unless you have > > specific comments. > > > > 5.3. Accounting > > > > G3.1 currently we are not handling accounting. Will add. > > > > 5.4. Mobile Node Authentication > > > > G4.1: I think we are currently independant of EAP. I dont think we > > > will have any problem with HA as pass through authenticator. > > > > 5.5. Provisioning of Configuration Parameters > > > > G5.1: done, > > G5.2: will add. > > > > 6. Goals for the Integrated Scenario > > > > As I was telling Hannes, we would probably rely on "push" scenario > > in draft-tschofenig-dime-mip6-integrated-00.txt, whereas we define a > > "pull" scenario between HA-AAA. > > > > > > Regards, > > Vishnu. > > > > Motorola > > +91 9844178052 > > [*] General > > [] Motorola Internal Use Only > > > > > > > > -----Original Message----- > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > Sent: Wednesday, October 25, 2006 1:33 PM > > To: Ram O V Vishnu-A14676 > > Cc: dime@ietf.org > > Subject: Re: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt > > > > > > Hi Vishnu, > > > > how does your draft relate with draft-ietf-mip6-aaa-ha-goals that is > > in WGLC in MIP6 WG? > > > > Thanks, > > --Gerardo > > > > On 10/25/06, Ram O V Vishnu-A14676 wrote: > >> Hi, > >> > >> We have put together some thoughts on the HA-AAA interface for mip6 > >> > (http://www.ietf.org/internet-drafts/draft-kamble-dime-mip6-ha-aaa-00. > >> tx > >> t). > >> > >> Please take a look & comment. > >> > >> Regards, > >> Vishnu. > >> > >> Motorola > >> +91 9844178052 > >> [*] General > >> [] Motorola Internal Use Only > >> > >> -----Original Message----- > >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >> Sent: Thursday, October 19, 2006 4:20 AM > >> To: i-d-announce@ietf.org > >> Subject: I-D ACTION:draft-kamble-dime-mip6-ha-aaa-00.txt > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> > >> > >> Title : HA-AAA Diameter interface for MIP6 > >> Author(s) : V. Kamble > >> Filename : draft-kamble-dime-mip6-ha-aaa-00.txt > >> Pages : 10 > >> Date : 2006-10-18 > >> > >> This document specifies a Diameter application between AAAH and HA > >> that allows authentication, authorization and accounting for > Mobile > >> IPv6 services. Further, this interface could also be used for > >> bootstrapping of MIPv6. > >> > >> > >> A URL for this Internet-Draft is: > >> > http://www.ietf.org/internet-drafts/draft-kamble-dime-mip6-ha-aaa-00.t > >> xt > >> > >> 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-kamble-dime-mip6-ha-aaa-00.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-kamble-dime-mip6-ha-aaa-00.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. > >> > >> _______________________________________________ > >> 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 -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 26 08:46:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd4cz-0007lo-Al; Thu, 26 Oct 2006 08:46:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd4cx-0007k8-A6 for dime@ietf.org; Thu, 26 Oct 2006 08:46:31 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd4Y0-0007sb-CU for dime@ietf.org; Thu, 26 Oct 2006 08:41:28 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k9QCfIfn007252; Thu, 26 Oct 2006 14:41:18 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k9QCfHML001396; Thu, 26 Oct 2006 14:41:17 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 14:41:17 +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 Subject: AW: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt Date: Thu, 26 Oct 2006 14:40:51 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt Thread-Index: Acb4O01acPG7Z0jSQEGaFn/hshZ/JwAuv9FgAADhAPA= From: "Tschofenig, Hannes" To: "Ram O V Vishnu-A14676" , "Hannes Tschofenig" X-OriginalArrivalTime: 26 Oct 2006 12:41:17.0471 (UTC) FILETIME=[07E7B2F0:01C6F8FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd 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 Vishnu,=20 thank you for your response. It clarifies a few things.=20 The reason why draft-ietf-dime-mip6-split-01.txt does not provide a lot = of info with respect this RFC 4285 is that the DIME work on MIPv6 = bootstrapping is very much driven by the MIP6 working group: We develop = the backend story of their frontend solution. The MIPv6 working group = has compiled a document that describes what we should do (see = draft-ietf-mip6-aaa-ha-goals, as indicated by Gerardo). We are supposed = to work on the IPsec/IKEv2-based security mechanisms.=20 We obviously came across RFC 4285 in this context and we wheren't quite = sure whether additional aspects need to be addressed. In fact I have = asked the MIP6 working group whether they see a need to cover RFC 4285: http://www1.ietf.org/mail-archive/web/dime/current/msg00815.html http://www1.ietf.org/mail-archive/web/mip6/current/msg05312.html http://www1.ietf.org/mail-archive/web/dime/current/msg00884.html There was very little response hinting that no work is demanded.=20 I don't know if they have changed their mind already. If they did then = we need to discuss and address this aspect as well where your draft = would certainly be a very valuable contribution to this work.=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com]=20 > Gesendet: Donnerstag, 26. Oktober 2006 14:06 > An: Hannes Tschofenig > Cc: dime@ietf.org > Betreff: RE: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt >=20 > Hannes, >=20 > Thanks for sending the updated drafts. Sorry, but interestingly, I got > the I-D announce for these drafts (and hence the access to=20 > these drafts) > much after your email!! >=20 > As it stands, draft-ietf-dime-mip6-split-01.txt section 10.4 is where > our draft relates to. >=20 > Regards, > Vishnu. >=20 > Motorola > +91 9844178052 > [*] General > [] Motorola Internal Use Only >=20 >=20 >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Wednesday, October 25, 2006 7:11 PM > To: Ram O V Vishnu-A14676 > Cc: Gerardo Giaretta; dime@ietf.org > Subject: Re: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt >=20 >=20 > Hi Vishnu, >=20 > I think I found the confusion. You read=20 > draft-tschofenig-dime-mip6-integrated-00.txt but we are, however,=20 > already working on draft-ietf-dime-mip6-split-01.txt &=20 > draft-ietf-dime-mip6-integrated-01.txt. >=20 > Ciao > Hannes >=20 >=20 > Ram O V Vishnu-A14676 wrote: > > Hi Gerardo, > >=20 > > I think it relates well. We can discuss more (if you are=20 > interested)=20 > > during IETF67. > > -------------- > > Some notes which we made are: > >=20 > > 5.1. General goals: These General goals are satisfied by Diameter=20 > > protocol. > >=20 > > 5.2. Service Authorization > >=20 > > G2.1, G2.2, G2.3, G2.4, 2.5, 2.6 : looks ok. Unless you have=20 > > specific comments. > >=20 > > 5.3. Accounting > >=20 > > G3.1 currently we are not handling accounting. Will add. > >=20 > > 5.4. Mobile Node Authentication > >=20 > > G4.1: I think we are currently independant of EAP. I=20 > dont think we >=20 > > will have any problem with HA as pass through authenticator. > >=20 > > 5.5. Provisioning of Configuration Parameters > >=20 > > G5.1: done,=20 > > G5.2: will add. > >=20 > > 6. Goals for the Integrated Scenario > >=20 > > As I was telling Hannes, we would probably rely on=20 > "push" scenario=20 > > in draft-tschofenig-dime-mip6-integrated-00.txt, whereas we=20 > define a=20 > > "pull" scenario between HA-AAA. > > =20 > >=20 > > Regards, > > Vishnu. > >=20 > > Motorola > > +91 9844178052 > > [*] General > > [] Motorola Internal Use Only > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > Sent: Wednesday, October 25, 2006 1:33 PM > > To: Ram O V Vishnu-A14676 > > Cc: dime@ietf.org > > Subject: Re: [Dime] FW:draft-kamble-dime-mip6-ha-aaa-00.txt > >=20 > >=20 > > Hi Vishnu, > >=20 > > how does your draft relate with=20 > draft-ietf-mip6-aaa-ha-goals that is=20 > > in WGLC in MIP6 WG? > >=20 > > Thanks, > > --Gerardo > >=20 > > On 10/25/06, Ram O V Vishnu-A14676 wrote: > >> Hi, > >> > >> We have put together some thoughts on the HA-AAA interface for mip6 > >> > (http://www.ietf.org/internet-drafts/draft-kamble-dime-mip6-ha-aaa-00. > >> tx > >> t). > >> > >> Please take a look & comment. > >> > >> Regards, > >> Vishnu. > >> > >> Motorola > >> +91 9844178052 > >> [*] General > >> [] Motorola Internal Use Only > >> > >> -----Original Message----- > >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >> Sent: Thursday, October 19, 2006 4:20 AM > >> To: i-d-announce@ietf.org > >> Subject: I-D ACTION:draft-kamble-dime-mip6-ha-aaa-00.txt > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> > >> > >> Title : HA-AAA Diameter interface for MIP6 > >> Author(s) : V. Kamble > >> Filename : draft-kamble-dime-mip6-ha-aaa-00.txt > >> Pages : 10 > >> Date : 2006-10-18 > >> > >> This document specifies a Diameter application between=20 > AAAH and HA > >> that allows authentication, authorization and accounting for > Mobile > >> IPv6 services. Further, this interface could also be used for > >> bootstrapping of MIPv6. > >> > >> > >> A URL for this Internet-Draft is: > >> > http://www.ietf.org/internet-drafts/draft-kamble-dime-mip6-ha-aaa-00.t > >> xt > >> > >> To remove yourself from the I-D Announcement list, send a=20 > message to > >> i-d-announce-request@ietf.org with the word unsubscribe in the body > of > >=20 > >> 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=20 > >> logging in, type "cd internet-drafts" and then "get=20 > >> draft-kamble-dime-mip6-ha-aaa-00.txt". > >> > >> A list of Internet-Drafts directories can be found in > >> http://www.ietf.org/shadow.html or=20 > >> 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=20 > /internet-drafts/draft-kamble-dime-mip6-ha-aaa-00.txt". > >> > >> NOTE: The mail server at ietf.org can return the document in > >> MIME-encoded form by using the "mpack" utility. =20 > To use this > >> feature, insert the command "ENCODING mime" before=20 > the "FILE" > >> command. To decode the response(s), you will need=20 > "munpack" > > or > >> a MIME-compliant mail reader. Different=20 > 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=20 > 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=20 > >> Internet-Draft. > >> > >> _______________________________________________ > >> 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 >=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 Oct 26 08:52:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd4iu-0001UC-VZ; Thu, 26 Oct 2006 08:52:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd4dG-0007p4-0f for dime@ietf.org; Thu, 26 Oct 2006 08:46:50 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gd4SK-0005m9-UC for dime@ietf.org; Thu, 26 Oct 2006 08:35:36 -0400 X-VirusChecked: Checked X-Env-Sender: vishnu@motorola.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1161865732!4831060!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 16128 invoked from network); 26 Oct 2006 12:28:52 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-128.messagelabs.com with SMTP; 26 Oct 2006 12:28:52 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k9QCSpW2002145 for ; Thu, 26 Oct 2006 05:28:51 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k9QCSo9S016043 for ; Thu, 26 Oct 2006 07:28:51 -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 Subject: RE: [Dime] Diameter Tutorial Date: Thu, 26 Oct 2006 20:28:49 +0800 Message-ID: In-Reply-To: <453F70FF.5000403@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Tutorial Thread-Index: Acb48kPb5j3G0+p3QDmbrjx0J4YOlgABPkmg From: "Ram O V Vishnu-A14676" To: "Victor Fajardo" , X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: dime@ietf.org, hannes.tschofenig@siemens.com 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, Its better to see the following covered: 1) possible approaches to interface with Diameter applications <-> base. 2) failover failback (interesting to see a comparison with traditional redundancy mechanisms) 3) loop detection 4) duplicate detection=20 5) agent & proxies (stateful vs. stateless?) 6) dynamic discovery 7) use of session id. 8) diameter usage examples: ims, credit control, eap. 9) improvements over radius & interworking to radius. Regards, Vishnu. Motorola +91 9844178052 [*] General [] Motorola Internal Use Only -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 Sent: Wednesday, October 25, 2006 7:43 PM To: jouni.korhonen@teliasonera.com Cc: dime@ietf.org; hannes.tschofenig@siemens.com Subject: Re: [Dime] Diameter Tutorial Hi Jouni, > o in depth prez on use/allocation of Application-Ids > o in depth prez on request routing (including proxies, > relays, different app-ids, decorated NAIs, ..) at > =20 sounds good. > and maybe also something on other things we lately had lengthy > discussions like 'correct' use/allocations of nas-port-type and=20 > service-type vs applications.. > =20 Ok. We can also publish a skeleton of the topics we plan to include so=20 we have a starting point. regards, victor > /Jouni > > > =20 >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 >> Sent: 25. lokakuuta 2006 10:14 >> To: hannes.tschofenig@siemens.com; dime@ietf.org >> Subject: RE: [Dime] Diameter Tutorial >> >> Also, it might be good if people sent in some areas that they=20 >> would like to understand better. If you have a topic you'd=20 >> like discussed, just ask. >> >> John >> >> =20 >>> -----Original Message----- >>> From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] >>> Sent: 24 October, 2006 23:07 >>> To: dime@ietf.org >>> Subject: [Dime] Diameter Tutorial >>> >>> Hi all, >>> >>> in a discussion with John we came up with the idea of scheduling a=20 >>> tutorial about Diameter, accounting, and credit control. >>> >>> WHEN? Monday, starting at 8pm for about 1 1/2 or 2 hours (after the=20 >>> afternoon session iii) >>> >>> WHERE? Room yet to be defined; depending on the number of=20 >>> =20 >> participants >> =20 >>> WHY? With the recent work on mobility and Quality of Service=20 >>> =20 >> we noticed=20 >> =20 >>> that we have experts in specific problem domains but there=20 >>> =20 >> is room for=20 >> =20 >>> improvement regarding the Diameter knowledge. >>> >>> WHO: Focus: Authors of Diameter applications.=20 >>> But: Everyone with interest in Diameter is welcome. >>> >>> Please send a note to the chairs with the Subject line=20 >>> "diameter-tutorial" if you plan to attend the tutorial. >>> >>> Ciao >>> Hannes & John >>> >>> >>> _______________________________________________ >>> 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 > > > > =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 Oct 26 09:19:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd598-0001EK-R7; Thu, 26 Oct 2006 09:19:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd598-0001E7-AM; Thu, 26 Oct 2006 09:19:46 -0400 Received: from [193.234.218.130] (helo=p130.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd58z-0007KG-Um; Thu, 26 Oct 2006 09:19:46 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 36AE1898C5; Thu, 26 Oct 2006 16:18:45 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id EB3A7898C4; Thu, 26 Oct 2006 16:18:44 +0300 (EEST) Message-ID: <4540B5B5.9040409@piuha.net> Date: Thu, 26 Oct 2006 16:18:45 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: Hannes Tschofenig References: <451B7EC0.70801@gmx.net> <4540ACC1.5010707@web.de> In-Reply-To: <4540ACC1.5010707@web.de> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: gdommety@cisco.com, mip6@ietf.org, dime@ietf.org, basavaraj.patil@nokia.com Subject: [Dime] Re: Important: Impact of RFC 4285 for Diameter MIP6 Bootstrapping Work 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 believe you should do the work based on the WG draft. (But I don't think anyone minds if the solution happens to support or be easily adoptable for RFC 4285 too. But don't go out of your way to achieve that.) --Jari _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 26 09:37:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5QM-0000q5-5B; Thu, 26 Oct 2006 09:37:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5QL-0000py-53 for dime@ietf.org; Thu, 26 Oct 2006 09:37:33 -0400 Received: from smtpout1438.sc1.he.tucows.com ([64.97.157.138] helo=n034.sc1.cp.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd5QH-0003HN-OP for dime@ietf.org; Thu, 26 Oct 2006 09:37:33 -0400 Received: from fh1037.dia.cp.net (64.97.139.2) by n034.sc1.cp.net (7.2.069.1) id 45406B3800010A18 for dime@ietf.org; Thu, 26 Oct 2006 13:37:02 +0000 Received: from 192.80.211.11 (authenticated as user david@mitton.com) by 64.97.168.47 with HTTP; Thu, 26 Oct 2006 13:37:02 UTC Message-ID: <8045547.1161869822506.JavaMail.?@fh1037.dia.cp.net> Date: Thu, 26 Oct 2006 13:37:02 +0000 (UTC) From: "david@mitton.com" To: Subject: RE: [Dime] Diameter Tutorial MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "david@mitton.com" 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 will not be at this coming IETF meeting, but if this meeting is in a audio supported room, I may be able to "attend". In any case, it would be nice if any presentations made or even minutes were published. Dave. ----Original Message---- From: vishnu@motorola.com Date: Oct 26, 2006 8:28 To: "Victor Fajardo", Cc: , Subj: RE: [Dime] Diameter Tutorial Hi, Its better to see the following covered: 1) possible approaches to interface with Diameter applications <-> base. 2) failover failback (interesting to see a comparison with traditional redundancy mechanisms) 3) loop detection 4) duplicate detection 5) agent & proxies (stateful vs. stateless?) 6) dynamic discovery 7) use of session id. 8) diameter usage examples: ims, credit control, eap. 9) improvements over radius & interworking to radius. Regards, Vishnu. Motorola +91 9844178052 [*] General [] Motorola Internal Use Only -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] Sent: Wednesday, October 25, 2006 7:43 PM To: jouni.korhonen@teliasonera.com Cc: dime@ietf.org; hannes.tschofenig@siemens.com Subject: Re: [Dime] Diameter Tutorial Hi Jouni, > o in depth prez on use/allocation of Application-Ids > o in depth prez on request routing (including proxies, > relays, different app-ids, decorated NAIs, ..) at > sounds good. > and maybe also something on other things we lately had lengthy > discussions like 'correct' use/allocations of nas-port-type and > service-type vs applications.. > Ok. We can also publish a skeleton of the topics we plan to include so we have a starting point. regards, victor > /Jouni > > > >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Sent: 25. lokakuuta 2006 10:14 >> To: hannes.tschofenig@siemens.com; dime@ietf.org >> Subject: RE: [Dime] Diameter Tutorial >> >> Also, it might be good if people sent in some areas that they >> would like to understand better. If you have a topic you'd >> like discussed, just ask. >> >> John >> >> >>> -----Original Message----- >>> From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@siemens. com] >>> Sent: 24 October, 2006 23:07 >>> To: dime@ietf.org >>> Subject: [Dime] Diameter Tutorial >>> >>> Hi all, >>> >>> in a discussion with John we came up with the idea of scheduling a >>> tutorial about Diameter, accounting, and credit control. >>> >>> WHEN? Monday, starting at 8pm for about 1 1/2 or 2 hours (after the >>> afternoon session iii) >>> >>> WHERE? Room yet to be defined; depending on the number of >>> >> participants >> >>> WHY? With the recent work on mobility and Quality of Service >>> >> we noticed >> >>> that we have experts in specific problem domains but there >>> >> is room for >> >>> improvement regarding the Diameter knowledge. >>> >>> WHO: Focus: Authors of Diameter applications. >>> But: Everyone with interest in Diameter is welcome. >>> >>> Please send a note to the chairs with the Subject line >>> "diameter-tutorial" if you plan to attend the tutorial. >>> >>> Ciao >>> Hannes & John >>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org 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 Oct 26 09:56:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5iZ-0001Us-MG; Thu, 26 Oct 2006 09:56:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5iA-0000t8-4I for dime@ietf.org; Thu, 26 Oct 2006 09:55:58 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd5aP-0005Mg-4i for dime@ietf.org; Thu, 26 Oct 2006 09:47:57 -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 1Gd5aN-0005tN-NW for dime@ietf.org; Thu, 26 Oct 2006 09:47:57 -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 k9QDg4Qb010889; Thu, 26 Oct 2006 09:42:05 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4540BAC4.7000105@tari.toshiba.com> Date: Thu, 26 Oct 2006 09:40:20 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.5 (X11/20060812) MIME-Version: 1.0 To: Ram O V Vishnu-A14676 Subject: Re: [Dime] Diameter Tutorial References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: hannes.tschofenig@siemens.com, 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 Vishnu, > Its better to see the following covered: > > 1) possible approaches to interface with Diameter applications <-> base. > 2) failover failback (interesting to see a comparison with traditional > redundancy mechanisms) > 3) loop detection > 4) duplicate detection > 5) agent & proxies (stateful vs. stateless?) > 6) dynamic discovery > 7) use of session id. > 8) diameter usage examples: ims, credit control, eap. > 9) improvements over radius & interworking to radius. > Looks ok to me. Though, I hope we can cover a lot of the suggested topics given the time. regards, victor > Regards, > Vishnu. > > Motorola > +91 9844178052 > [*] General > [] Motorola Internal Use Only > > > > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Wednesday, October 25, 2006 7:43 PM > To: jouni.korhonen@teliasonera.com > Cc: dime@ietf.org; hannes.tschofenig@siemens.com > Subject: Re: [Dime] Diameter Tutorial > > > Hi Jouni, > > >> o in depth prez on use/allocation of Application-Ids >> o in depth prez on request routing (including proxies, >> relays, different app-ids, decorated NAIs, ..) at >> >> > > sounds good. > > >> and maybe also something on other things we lately had lengthy >> discussions like 'correct' use/allocations of nas-port-type and >> service-type vs applications.. >> >> > > Ok. We can also publish a skeleton of the topics we plan to include so > we have a starting point. > > regards, > victor > > >> /Jouni >> >> >> >> >>> -----Original Message----- >>> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >>> Sent: 25. lokakuuta 2006 10:14 >>> To: hannes.tschofenig@siemens.com; dime@ietf.org >>> Subject: RE: [Dime] Diameter Tutorial >>> >>> Also, it might be good if people sent in some areas that they >>> would like to understand better. If you have a topic you'd >>> like discussed, just ask. >>> >>> John >>> >>> >>> >>>> -----Original Message----- >>>> From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] >>>> Sent: 24 October, 2006 23:07 >>>> To: dime@ietf.org >>>> Subject: [Dime] Diameter Tutorial >>>> >>>> Hi all, >>>> >>>> in a discussion with John we came up with the idea of scheduling a >>>> tutorial about Diameter, accounting, and credit control. >>>> >>>> WHEN? Monday, starting at 8pm for about 1 1/2 or 2 hours (after the >>>> afternoon session iii) >>>> >>>> WHERE? Room yet to be defined; depending on the number of >>>> >>>> >>> participants >>> >>> >>>> WHY? With the recent work on mobility and Quality of Service >>>> >>>> >>> we noticed >>> >>> >>>> that we have experts in specific problem domains but there >>>> >>>> >>> is room for >>> >>> >>>> improvement regarding the Diameter knowledge. >>>> >>>> WHO: Focus: Authors of Diameter applications. >>>> But: Everyone with interest in Diameter is welcome. >>>> >>>> Please send a note to the chairs with the Subject line >>>> "diameter-tutorial" if you plan to attend the tutorial. >>>> >>>> Ciao >>>> Hannes & John >>>> >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>>> >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> >> >> >> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 26 09:57:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5jv-0002KT-H1; Thu, 26 Oct 2006 09:57:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5iD-000141-Kn for dime@ietf.org; Thu, 26 Oct 2006 09:56:01 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd5Zm-0005BF-7l for dime@ietf.org; Thu, 26 Oct 2006 09:47:22 -0400 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail2.lucent.com (8.13.8/IER-o) with ESMTP id k9QDlD0b026883 for ; Thu, 26 Oct 2006 08:47:13 -0500 (CDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id <4Y7QMMCT>; Thu, 26 Oct 2006 09:47:13 -0400 Message-ID: <1B8C2E08B21B8743A2B3AED07407DA7612D5881A@nj7460exch002u.ho.lucent.com> From: "Sun, Dong (Dong)" To: dime@ietf.org Date: Thu, 26 Oct 2006 09:47:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-15" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Dime] A new I-D on Diameter application for resource control 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, Attached is a new I-D for Diameter application for resource control. The I-D describes the gaps in the ongoing Diameter QoS application work in order to support some other scenarios, for example, when the endpoints and/or networks do not support the path coupled network signaling to request the network QoS authorization on a per flow basis, which is commonly used in certain netowrks, such as Cable, DSL, Ethernet and MPLS. This draft is intended for extending the QoS application into the resource control application and formulating a universal functional model to support various network technologies and endpoints. In particular, additional mechanism - Push mode is proposed to support aforementioned scenario; in addition, a pair of new commands and a few new AVPs are defined in support of Push mode. The I-D can be downloaded from the following website: ftp://ftp.lucent.com/incoming/Ud3l1ver/sun/draft-sun-dime-diameter-resource-control-requirements-00.txt understood this is a late I-D for the meeting, but still wondering (and hope) if a time slot could be allocated to introduce the basic idea briefly. Or alternatively, it can be combined with QoS application presentation. Any comments are welcome. Thanks, Dong Sun Bell Laboratories, Lucent Technologies Voice: +1 732-949-8873 Fax: +1 732-949-9464 Email: dongsun@lucent.com _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 26 09:59:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5lj-0003ID-Q5; Thu, 26 Oct 2006 09:59:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5iN-00012v-BZ for dime@ietf.org; Thu, 26 Oct 2006 09:56:11 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd5Vo-0004N5-MM for dime@ietf.org; Thu, 26 Oct 2006 09:43:21 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9QDgwQ5024498; Thu, 26 Oct 2006 16:43:11 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 16:43:02 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 16:43:02 +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] Diameter Tutorial Date: Thu, 26 Oct 2006 16:43:01 +0300 Message-ID: In-Reply-To: <8045547.1161869822506.JavaMail.?@fh1037.dia.cp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Tutorial Thread-Index: Acb5BDsjDR8E9oT3QP202qMm5QZ2QAAAGFUQ From: To: , X-OriginalArrivalTime: 26 Oct 2006 13:43:02.0126 (UTC) FILETIME=[A80D30E0:01C6F904] X-Spam-Score: 0.2 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff 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 jabber can always be provided. We will provide minutes and presentations. john=20 >-----Original Message----- >From: ext david@mitton.com [mailto:david@mitton.com]=20 >Sent: 26 October, 2006 16:37 >To: dime@ietf.org >Subject: RE: [Dime] Diameter Tutorial > >I will not be at this coming IETF meeting, but if this meeting=20 >is in a audio supported room, I may be able to "attend". > >In any case, it would be nice if any presentations made or=20 >even minutes were published. > >Dave. > >----Original Message---- >From: vishnu@motorola.com >Date: Oct 26, 2006 8:28 >To: "Victor Fajardo", korhonen@teliasonera.com> >Cc: , >Subj: RE: [Dime] Diameter Tutorial > >Hi, > >Its better to see the following covered: > >1) possible approaches to interface with Diameter applications=20 ><-> base. >2) failover failback (interesting to see a comparison with=20 >traditional redundancy mechanisms) >3) loop detection >4) duplicate detection >5) agent & proxies (stateful vs. stateless?) >6) dynamic discovery >7) use of session id. >8) diameter usage examples: ims, credit control, eap. >9) improvements over radius & interworking to radius. > >Regards, >Vishnu. > >Motorola >+91 9844178052 >[*] General >[] Motorola Internal Use Only > > > >-----Original Message----- >From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >Sent: Wednesday, October 25, 2006 7:43 PM >To: jouni.korhonen@teliasonera.com >Cc: dime@ietf.org; hannes.tschofenig@siemens.com >Subject: Re: [Dime] Diameter Tutorial > > >Hi Jouni, > >> o in depth prez on use/allocation of Application-Ids >> o in depth prez on request routing (including proxies, >> relays, different app-ids, decorated NAIs, ..) at >> =20 > >sounds good. > >> and maybe also something on other things we lately had lengthy >> discussions like 'correct' use/allocations of nas-port-type and=20 >> service-type vs applications.. >> =20 > >Ok. We can also publish a skeleton of the topics we plan to include=20 >so=20 >we have a starting point. > >regards, >victor > >> /Jouni >> >> >> =20 >>> -----Original Message----- >>> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 >>> Sent: 25. lokakuuta 2006 10:14 >>> To: hannes.tschofenig@siemens.com; dime@ietf.org >>> Subject: RE: [Dime] Diameter Tutorial >>> >>> Also, it might be good if people sent in some areas that they=20 >>> would like to understand better. If you have a topic you'd=20 >>> like discussed, just ask. >>> >>> John >>> >>> =20 >>>> -----Original Message----- >>>> From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@siemens. >com] >>>> Sent: 24 October, 2006 23:07 >>>> To: dime@ietf.org >>>> Subject: [Dime] Diameter Tutorial >>>> >>>> Hi all, >>>> >>>> in a discussion with John we came up with the idea of scheduling=20 >a=20 >>>> tutorial about Diameter, accounting, and credit control. >>>> >>>> WHEN? Monday, starting at 8pm for about 1 1/2 or 2 hours (after=20 >the=20 >>>> afternoon session iii) >>>> >>>> WHERE? Room yet to be defined; depending on the number of=20 >>>> =20 >>> participants >>> =20 >>>> WHY? With the recent work on mobility and Quality of Service=20 >>>> =20 >>> we noticed=20 >>> =20 >>>> that we have experts in specific problem domains but there=20 >>>> =20 >>> is room for=20 >>> =20 >>>> improvement regarding the Diameter knowledge. >>>> >>>> WHO: Focus: Authors of Diameter applications.=20 >>>> But: Everyone with interest in Diameter is welcome. >>>> >>>> Please send a note to the chairs with the Subject line=20 >>>> "diameter-tutorial" if you plan to attend the tutorial. >>>> >>>> Ciao >>>> Hannes & John >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> >> >> =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 > > > > >_______________________________________________ >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 Oct 26 10:50:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd6ZE-0006Ed-LA; Thu, 26 Oct 2006 10:50:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd6ZC-0006EW-Ts for dime@ietf.org; Thu, 26 Oct 2006 10:50:46 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd6Z4-00086B-Oe for dime@ietf.org; Thu, 26 Oct 2006 10:50:46 -0400 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail2.lucent.com (8.13.8/IER-o) with ESMTP id k9QEoaiL014948; Thu, 26 Oct 2006 09:50:36 -0500 (CDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id <4Y7QMQ1M>; Thu, 26 Oct 2006 10:50:36 -0400 Message-ID: <1B8C2E08B21B8743A2B3AED07407DA7612D5881D@nj7460exch002u.ho.lucent.com> From: "Sun, Dong (Dong)" To: dime@ietf.org Subject: RE: [Dime] A new I-D on Diameter application for resource control Date: Thu, 26 Oct 2006 10:50:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-15" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 all, Just like to let you know, thanks to kindly offer from Hannes, the same file is also avaiable on his website now (in case you cannot download it from the ftp site): http://www.tschofenig.priv.at/TEMP/draft-sun-dime-diameter-resource-control-requirements-00.txt Dong -----Original Message----- From: Sun, Dong (Dong) [mailto:dongsun@lucent.com] Sent: Thursday, October 26, 2006 9:47 AM To: dime@ietf.org Subject: [Dime] A new I-D on Diameter application for resource control Hi all, Attached is a new I-D for Diameter application for resource control. The I-D describes the gaps in the ongoing Diameter QoS application work in order to support some other scenarios, for example, when the endpoints and/or networks do not support the path coupled network signaling to request the network QoS authorization on a per flow basis, which is commonly used in certain netowrks, such as Cable, DSL, Ethernet and MPLS. This draft is intended for extending the QoS application into the resource control application and formulating a universal functional model to support various network technologies and endpoints. In particular, additional mechanism - Push mode is proposed to support aforementioned scenario; in addition, a pair of new commands and a few new AVPs are defined in support of Push mode. The I-D can be downloaded from the following website: ftp://ftp.lucent.com/incoming/Ud3l1ver/sun/draft-sun-dime-diameter-resource-control-requirements-00.txt understood this is a late I-D for the meeting, but still wondering (and hope) if a time slot could be allocated to introduce the basic idea briefly. Or alternatively, it can be combined with QoS application presentation. Any comments are welcome. Thanks, Dong Sun Bell Laboratories, Lucent Technologies Voice: +1 732-949-8873 Fax: +1 732-949-9464 Email: dongsun@lucent.com _______________________________________________ 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 Oct 26 14:55:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdANx-0002sQ-A8; Thu, 26 Oct 2006 14:55:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdANw-0002sD-4d for dime@ietf.org; Thu, 26 Oct 2006 14:55:24 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GdANu-0001QX-Rb for dime@ietf.org; Thu, 26 Oct 2006 14:55:24 -0400 Received: (qmail invoked by alias); 26 Oct 2006 18:55:21 -0000 Received: from p549851A5.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.81.165] by mail.gmx.net (mp044) with SMTP; 26 Oct 2006 20:55:21 +0200 X-Authenticated: #29516787 Message-ID: <45410498.3070603@gmx.net> Date: Thu, 26 Oct 2006 20:55:20 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) 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.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Dime] Diameter Tutorial: Some Planning 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 created a wiki page to indicate - Possible Presenters & topics - Interested Participants - Suggested Topics for the Diameter tutorial. You can find the wiki here: http://www.tschofenig.priv.at/cgi-bin/tutorial/wiki.pl?Organization Please add your info if you are interest to participate (actively or passively) by using the "Edit text of this page" link. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 26 15:44:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdB9B-0006iV-TY; Thu, 26 Oct 2006 15:44:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdB7a-000562-1P for dime@ietf.org; Thu, 26 Oct 2006 15:42:34 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GdAwc-0005zo-Hq for dime@ietf.org; Thu, 26 Oct 2006 15:31:15 -0400 Received: (qmail invoked by alias); 26 Oct 2006 19:31:13 -0000 Received: from p549851A5.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.81.165] by mail.gmx.net (mp039) with SMTP; 26 Oct 2006 21:31:13 +0200 X-Authenticated: #29516787 Message-ID: <45410CFF.1060903@gmx.net> Date: Thu, 26 Oct 2006 21:31:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jari Arkko References: <451B7EC0.70801@gmx.net> <4540ACC1.5010707@web.de> <4540B5B5.9040409@piuha.net> In-Reply-To: <4540B5B5.9040409@piuha.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: gdommety@cisco.com, mip6@ietf.org, dime@ietf.org, basavaraj.patil@nokia.com Subject: [Dime] Re: [Mip6] Re: Important: Impact of RFC 4285 for Diameter MIP6 Bootstrapping Work 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 Jari, Jari Arkko wrote: > I believe you should do the work based on the WG draft. > (But I don't think anyone minds if the solution happens > to support or be easily adoptable for RFC 4285 too. But > don't go out of your way to achieve that.) Thanks for the quick response. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 27 13:44:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdVlG-0002IE-Bq; Fri, 27 Oct 2006 13:44:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdVlF-0002I8-P5 for dime@ietf.org; Fri, 27 Oct 2006 13:44:53 -0400 Received: from webmail2.ptinovacao.pt ([194.65.138.21] helo=inoavrex07.ptin.corpPT.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdVlB-0003UZ-7U for dime@ietf.org; Fri, 27 Oct 2006 13:44:53 -0400 Received: from INOAVREX05.ptin.corpPT.com ([10.112.15.67]) by inoavrex07.ptin.corpPT.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 18:44:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 27 Oct 2006 18:44:41 +0100 Message-ID: <711EBBFA1DE9C64FB3CF8053A261C6FC0C57C3@INOAVREX05.ptin.corpPT.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter Event-Timestamp Thread-Index: Acb575SwKY41MpuHRJWMFBFuVgeCGA== From: "Paulo Rolo" To: X-OriginalArrivalTime: 27 Oct 2006 17:44:05.0734 (UTC) FILETIME=[7F726060:01C6F9EF] X-Spam-Score: 0.1 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Subject: [Dime] Diameter Event-Timestamp 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="===============0734650377==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0734650377== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F9EF.94D86478" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F9EF.94D86478 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, =20 I have a question concerning Diameter Event-Timestamp AVP data type.=20 RFC 3588 states that its type is Time, and the same rfc presents Time as derived from OctectString. However, I have found that several Diameter implementations use Unsigned32 type.=20 =20 Thanks in advance, Paulo Rolo =20 =20 =20 ------_=_NextPart_001_01C6F9EF.94D86478 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

I have a question concerning Diameter = Event-Timestamp AVP data type.

RFC 3588 states that its type is Time, and the same = rfc presents Time as derived from OctectString. However, I have found that = several Diameter implementations use Unsigned32 type.

 

Thanks in advance,

Paulo Rolo

 

 

 

------_=_NextPart_001_01C6F9EF.94D86478-- --===============0734650377== 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 --===============0734650377==-- From dime-bounces@ietf.org Sun Oct 29 22:55:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeOEv-000387-KY; Sun, 29 Oct 2006 22:55:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeO4X-0004ou-4V for dime@ietf.org; Sun, 29 Oct 2006 22:44:25 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeO4V-0004yR-SO for dime@ietf.org; Sun, 29 Oct 2006 22:44:25 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7X00MYXJKR3O@usaga01-in.huawei.com> for dime@ietf.org; Sun, 29 Oct 2006 19:41:15 -0800 (PST) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7X005AAJKQTD@usaga01-in.huawei.com> for dime@ietf.org; Sun, 29 Oct 2006 19:41:15 -0800 (PST) Received: from [172.24.1.24] (Forwarded-For: [10.164.5.61]) by szxmc01-in.huawei.com (mshttpd); Mon, 30 Oct 2006 11:44:23 +0800 Date: Mon, 30 Oct 2006 11:44:23 +0800 From: lijijun 41867 Subject: [Dime] Redirecting a Diameter Message ?? To: dime@ietf.org Message-id: <7f1a7a7f1c92.7f1c927f1a7a@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 RFC3588 2.8.3. Redirect Agents Since redirect agents do not relay messages, and only return an answer with the information necessary for Diameter agents to communicate directly, they do not modify messages. Since redirect agents do not receive answer messages, they cannot maintain session state. Further, since redirect agents never relay requests, they are not required to maintain transaction state. +------+ | | | DRD | | | +------+ ^ | 2. Request | | 3. Redirection | | Notification | v +------+ ---------> +------+ ---------> +------+ | | 1. Request | | 4. Request | | | NAS | | DRL | | HMS | | | 6. Answer | | 5. Answer | | +------+ <--------- +------+ <--------- +------+ example.net example.net example.com Figure 3: Redirecting a Diameter Message I have a question about : since redirect agents never relay requests, they are not required to maintain transaction state. If this means that the connection of DRD and DRL will be closed after once communication ? Transaction state is the same word with the connection ? I think the connection(TCP/SCTP) of DRD and DRL should be linked for next communication. another question: If it is likelihood that DRD send a message to DRL first, then DRL answer to DRD? any comments are highly appreciated. Thanks, lijijun _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 30 05:53:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeUlV-000464-La; Mon, 30 Oct 2006 05:53:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeUfa-0007gQ-I6 for dime@ietf.org; Mon, 30 Oct 2006 05:47:06 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeUfY-0007gl-Ng for dime@ietf.org; Mon, 30 Oct 2006 05:47:06 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9UAikp1022326 for ; Mon, 30 Oct 2006 12:47:02 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 12:46:48 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 12:46:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Oct 2006 12:46:47 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter Interop Thread-Index: Acb0XbVR/O5LAT5PSfCrThudM3FVlQHsrdqw From: To: X-OriginalArrivalTime: 30 Oct 2006 10:46:47.0940 (UTC) FILETIME=[B2FF7440:01C6FC10] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e Subject: [Dime] Diameter Interop 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="===============1987676441==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1987676441== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FC10.B2A69BBF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FC10.B2A69BBF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We have a sponsor for the next Diameter interop. Are people interested and willing to participate. Some details below. =20 Thanks, John & Hannes =20 We have identified a venue in Orlando, Florida.=20 =20 This is similar to the previous interop site, which was at the Enterprise Center of the Burlington County College campus. It is at the Valencia County College Enterprise Center. This is in a very central location.=20 =20 The room is about as big as the previous one, which can seat about 30 participants and has power and wired-IP at every seat. There is wireless-LAN also available. I am of the opinion to use the wired LAN for the testing, which can be made private for the group and use wireless for internet connectivity. =20 We have also looked at a hotel within one mile of the venue, which is quite attractive and is co-located with one of Orlando's biggest shopping mall. Both the venue and the hotel are about 6-7 miles from the airport. =20 =09 We are looking at suitable dates between 20th Jan - 10th Feb. The Weather in Florida will be sunny and in the 50s. =20 Please let me know your opinion. =20 I have also some other questions.. =20 a. In terms of network connectivity, I am assuming that static IP addresses should suffice. We will allocate and prepare the participants a list, so that it will save time. For realm-based routing, I assume that folks will be able to use their own mechanism such as the /etc/resolv.conf /etc/hosts to resolve the hostname to IP and no DNS is required.=20 =20 b. We have looked at options for remote connectivity. It is possible, but the remote side will have to install a Cisco VPN client, because this network has a Cisco VPN support. Do you think that it will be useful and viable?=20 =20 c. In the registration, we will enquire about the participant's interests and can be better prepared. The areas of interest are=20 3GPP and TISPAN applications - Cx, Dx etc.. MobileIP, EAP, NASREQ=20 DiameterSIP TLS ..Would you like to add to this list. =20 d. How about the duration of the event. Last time, it was scheduled for five days. Most people left by the fourth day. Should we plan for a three day event instead?=20 =20 e. In addition to putting up the web-page for the registration, we will plan to send an invite to our previous participant list and also some additional implementations that we have been interacting with. =20 ------_=_NextPart_001_01C6FC10.B2A69BBF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,

We have a=20 sponsor for the next Diameter interop.  Are people interested and = willing=20 to participate.  Some details below.
 
Thanks,
John=20 & Hannes

 

We have identified a = venue in=20 Orlando, = Florida. =

 

This is similar to the = previous=20 interop site, which was at the Enterprise Center of the Burlington County College campus. It is at the = Valencia = County College Enterprise Center. This is in a very = central=20 location.

 

The room is about as big = as the=20 previous one, which can seat about 30 participants and has power and = wired-IP=20 at every seat. There is wireless-LAN also available. I am of the = opinion to=20 use the wired LAN for the testing, which can be made private for the = group and=20 use wireless for internet connectivity.

 

We have also looked at a = hotel=20 within one mile of the venue, which is quite attractive and is = co-located with=20 one of Orlando’s biggest shopping = mall. Both the=20 venue and the hotel are about 6-7 miles from the=20 airport.

 

We are looking at = suitable dates=20 between 20th Jan – 10th Feb. The Weather = in Florida = will be sunny=20 and in the 50s.

 

Please let me know your=20 opinion.

 

I have also some other=20 questions..

 

  1. In = terms of network=20 connectivity, I am assuming that static IP addresses should suffice. = We will=20 allocate and prepare the participants a list, so that it will save = time. For=20 realm-based routing, I assume that folks will be able to use their = own=20 mechanism such as the /etc/resolv.conf /etc/hosts to resolve the = hostname to=20 IP and no DNS is required.

 

  1. We have = looked at=20 options for remote connectivity. It is possible, but the remote side = will=20 have to install a Cisco VPN client, because this network has a Cisco = VPN=20 support. Do you think that it will be useful and=20 viable?

 

  1. In the=20 registration, we will enquire about the participant’s = interests and can be=20 better prepared. The areas of interest are =

3GPP and TISPAN = applications – Cx,=20 Dx etc..

MobileIP, EAP, NASREQ=20

DiameterSIP

TLS

..Would you like to add = to this=20 list.

 

  1. How = about the=20 duration of the event. Last time, it was scheduled for five days. = Most=20 people left by the fourth day. Should we plan for a three day event=20 instead?

 

e. In addition to = putting up the=20 web-page for the registration, we will plan to send an invite to our = previous=20 participant list and also some additional implementations that we have = been=20 interacting with.

 

------_=_NextPart_001_01C6FC10.B2A69BBF-- --===============1987676441== 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 --===============1987676441==-- From dime-bounces@ietf.org Mon Oct 30 17:51:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gefyr-0008F0-9X; Mon, 30 Oct 2006 17:51:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gefyp-0008Eu-Vi for dime@ietf.org; Mon, 30 Oct 2006 17:51:43 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gefyn-0007Qg-G7 for dime@ietf.org; Mon, 30 Oct 2006 17:51:43 -0500 Received: (qmail invoked by alias); 30 Oct 2006 22:51:39 -0000 Received: from p54985FB3.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.95.179] by mail.gmx.net (mp028) with SMTP; 30 Oct 2006 23:51:39 +0100 X-Authenticated: #29516787 Message-ID: <454681F5.8010503@gmx.net> Date: Mon, 30 Oct 2006 23:51:33 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: john.loughney@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: dime@ietf.org Subject: [Dime] Diameter Interop + Test Cases => Input Required 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, we need todo some homework for the interop. At the previous interop we have roughly followed the test cases described in: http://tools.ietf.org/wg/dime/draft-fajardo-dime-interop-test-suite-01.txt To have a more structured way of testing we would like to follow the tests more closely. This also allows a better preparation for the interop event. Hence, if you plan to participate then you should contribute to the above document to ensure that your test cases are covered. We need to know if you think that something is missing or should be described in a different way. We, however, need help from working group members with the document editing. Please volunteer. To make sure that the document is good enough for the interop event we would also schedule phone and/or chat conferences. Ciao Hannes john.loughney@nokia.com wrote: > Hi all, > > We have a sponsor for the next Diameter interop. Are people interested > and willing to participate. Some details below. > > Thanks, > John & Hannes > > > > We have identified a venue in Orlando, Florida. > > > > This is similar to the previous interop site, which was at the > Enterprise Center of the Burlington County College campus. It is at > the Valencia County College Enterprise Center. This is in a very > central location. > > > > The room is about as big as the previous one, which can seat about > 30 participants and has power and wired-IP at every seat. There is > wireless-LAN also available. I am of the opinion to use the wired > LAN for the testing, which can be made private for the group and use > wireless for internet connectivity. > > > > We have also looked at a hotel within one mile of the venue, which > is quite attractive and is co-located with one of Orlando’s biggest > shopping mall. Both the venue and the hotel are about 6-7 miles from > the airport. > > > > We are looking at suitable dates between 20^th Jan – 10^th Feb. The > Weather in Florida will be sunny and in the 50s. > > > > Please let me know your opinion. > > > > I have also some other questions.. > > > > 1. In terms of network connectivity, I am assuming that static IP > addresses should suffice. We will allocate and prepare the > participants a list, so that it will save time. For > realm-based routing, I assume that folks will be able to use > their own mechanism such as the /etc/resolv.conf /etc/hosts to > resolve the hostname to IP and no DNS is required. > > > > 2. We have looked at options for remote connectivity. It is > possible, but the remote side will have to install a Cisco VPN > client, because this network has a Cisco VPN support. Do you > think that it will be useful and viable? > > > > 3. In the registration, we will enquire about the participant’s > interests and can be better prepared. The areas of interest are > > 3GPP and TISPAN applications – Cx, Dx etc.. > > MobileIP, EAP, NASREQ > > DiameterSIP > > TLS > > ..Would you like to add to this list. > > > > 4. How about the duration of the event. Last time, it was > scheduled for five days. Most people left by the fourth day. > Should we plan for a three day event instead? > > > > e. In addition to putting up the web-page for the registration, we > will plan to send an invite to our previous participant list and > also some additional implementations that we have been interacting with. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Oct 30 18:20:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GegQP-00050s-9g; Mon, 30 Oct 2006 18:20:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GegQO-0004yb-Gi; Mon, 30 Oct 2006 18:20:12 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GegQI-0003YD-Vr; Mon, 30 Oct 2006 18:20:12 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9UNJYoZ016346; Tue, 31 Oct 2006 01:19:59 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 01:19:36 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 17:19:34 -0600 Received: from 172.19.244.134 ([172.19.244.134]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 30 Oct 2006 23:19:33 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Mon, 30 Oct 2006 17:21:45 -0600 From: Basavaraj Patil To: ext Hannes Tschofenig , Gopal Dommety Message-ID: Thread-Topic: Important: Impact of RFC 4285 for Diameter MIP6 Bootstrapping Work Thread-Index: Acb8eiomaK/bOGhtEduBwwARJNUNiA== In-Reply-To: <4540ACC1.5010707@web.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Oct 2006 23:19:34.0151 (UTC) FILETIME=[DC285170:01C6FC79] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061031012002-3B3FEBB0-78F953D8/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: mip6@ietf.org, dime@ietf.org Subject: [Dime] Re: Important: Impact of RFC 4285 for Diameter MIP6 Bootstrapping Work 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, We will try and get some more input to the work in DIME w.r.t the bootstrapping requirements. The bootstrapping solution in MIP6 (until now) has been based on the assumption that the security for signaling between the MN and HA is via IPsec. We have not really considered RFC4285 in the bootstrapping work. However there is a draft (by Vijay Devarapalli) that proposes a solution for bootstrapping with RFC4285. I would suggest that you focus on the WG I-D ( draft-ietf-mip6-aaa-ha-goals-03.txt) but as Jari said if you can cover the other case, i.e RFC4285 as well without extra effort that would be good. -Raj On 10/26/06 7:40 AM, "ext Hannes Tschofenig" wrote: > Hi Raj, > Hi Gopal, > > some time back I have posted the attached mail to the list soliciting > guidance for the Diameter MIP6 bootstrapping work. > Unfortunately, we haven't received a lot of feedback and guidance on > this issue. > > We are making progress with our work and we would like to know ahead of > time whether we should develop a backend solution based on > (a) > http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals-03.txt, or > (b) > http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals-03.txt > and http://www.ietf.org/rfc/rfc4285.txt. > > Ciao > Hannes > > Hannes Tschofenig wrote: >> Hi all, >> >> in the DIME working group we are currently producing documents that >> relate to the backend solution of the >> >> * Integrated Scenario >> draft-ietf-mip6-bootstrapping-integrated-dhc-01 >> >> * Split Scenario >> draft-ietf-mip6-bootstrapping-split-02 >> >> Now, the question came up whether we have to consider RFC 4285 >> ('Authentication Protocol for Mobile IPv6') for our work as well. >> >> Thoughts? >> >> Ciao >> Hannes >> >> > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 31 04:12:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GepfO-0005V9-Ht; Tue, 31 Oct 2006 04:12:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GepfN-0005V4-Qx for dime@ietf.org; Tue, 31 Oct 2006 04:12:17 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GepfM-0001dr-94 for dime@ietf.org; Tue, 31 Oct 2006 04:12:17 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k9V9CF1u011685 for ; Tue, 31 Oct 2006 10:12:15 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k9V9CEJo022175 for ; Tue, 31 Oct 2006 10:12:14 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 10:12:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 31 Oct 2006 10:12:13 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Finalizing the Diameter API Document Thread-Index: Acb8y9TNJs1+X5bLR6qV2T+lrvp/dg== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 31 Oct 2006 09:12:14.0092 (UTC) FILETIME=[A788B4C0:01C6FCCC] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [Dime] Finalizing the Diameter API Document 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="===============0427546639==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0427546639== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FCCC.A7544C46" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FCCC.A7544C46 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 we would like to know what Diameter APIs have been implemented and how they relate to the document in our charter: http://tools.ietf.org/wg/dime/draft-ietf-dime-diameter-api/draft-ietf-di me-diameter-api-00.txt Is the above-mentioned document complete?=20 The lack of responses indicates that the draft-ietf-dime-diameter-api-00.txt is complete and we should send it to the IESG.=20 Ciao Hannes & John ------_=_NextPart_001_01C6FCCC.A7544C46 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finalizing the Diameter API Document

Hi all,

we would like to know what Diameter = APIs have been implemented and how they relate to the document in our = charter:

http://tools.ietf.org/wg/dime/draft-ietf-dime-diameter-api= /draft-ietf-dime-diameter-api-00.txt

Is the above-mentioned document = complete?

The lack of responses indicates that = the draft-ietf-dime-diameter-api-00.txt is complete and we should send = it to the IESG.

Ciao
Hannes & John

------_=_NextPart_001_01C6FCCC.A7544C46-- --===============0427546639== 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 --===============0427546639==-- From dime-bounces@ietf.org Tue Oct 31 07:15:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GesWo-0006st-T4; Tue, 31 Oct 2006 07:15:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GesWn-0006sj-QE for dime@ietf.org; Tue, 31 Oct 2006 07:15:37 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GesWj-0000i5-AJ for dime@ietf.org; Tue, 31 Oct 2006 07:15:37 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9VCFSOU011944; Tue, 31 Oct 2006 14:15:30 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 14:15:29 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 14:15:29 +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: Tue, 31 Oct 2006 14:15:28 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 3588 "aaas" Scheme: Feedback Needed! Thread-Index: Acb8zVRqXFbplntCRmi5KbrO3BeS0wAF6InA From: To: X-OriginalArrivalTime: 31 Oct 2006 12:15:29.0304 (UTC) FILETIME=[4130E980:01C6FCE6] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061031141531-2A2DEBB0-32A6D390/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Dime] FW: RFC 3588 "aaas" Scheme: Feedback Needed! 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, Hannes has asked some implementors about aaas scheme. Does anyone else have any info on implementations of this feature? John >I would like to solicit some feedback regarding the usage of=20 >AAAS as defined in Section 4.3. of http://www.ietf.org/rfc/rfc3588.txt: > >" > "aaas://" FQDN [ port ] [ transport ] [ protocol ] " > >Questions: > >a) Who has implemented the "aaas" scheme? >b) Who is using the "aaas" scheme? > >Ciao >Hannes > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 31 08:07:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GetL6-0002QP-3D; Tue, 31 Oct 2006 08:07:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GepgN-0005mm-UT for dime@ietf.org; Tue, 31 Oct 2006 04:13:19 -0500 Received: from fmmailgate03.web.de ([217.72.192.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GepgM-0001hi-Jn for dime@ietf.org; Tue, 31 Oct 2006 04:13:19 -0500 Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate03.web.de (Postfix) with ESMTP id BBEDB309B08D; Tue, 31 Oct 2006 10:11:13 +0100 (CET) Received: from [192.35.17.26] (helo=[192.35.17.26]) by smtp05.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.107 #114) id 1GepeL-0000qs-00; Tue, 31 Oct 2006 10:11:13 +0100 Message-ID: <4547132F.60801@web.de> Date: Tue, 31 Oct 2006 10:11:11 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: dime@ietf.org References: <445688CF.80806@gmx.net> <44E37697.8060804@gmx.net> <45057FE4.9030101@gmx.net> In-Reply-To: <45057FE4.9030101@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sender: HannesTschofenig@web.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-Mailman-Approved-At: Tue, 31 Oct 2006 08:07:33 -0500 Cc: ivelin@mobicents.org, stephen.furlong@openet-telecom.com, magnus.hyttsten@digitalroute.com, tpanda@intellinet-india.com, karsten.rackwitz@siemens.com, Kuntal Chowdhury , ycosmado@bea.com, ahanda@intellinet-tech.com, daniel.karlsson@ericsson.com, cschroll@us.ibm.com, erkki.riekkola@nokia.com Subject: [Dime] RFC 3588 "aaas" Scheme: Feedback Needed! 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 would like to solicit some feedback regarding the usage of AAAS as defined in Section 4.3. of http://www.ietf.org/rfc/rfc3588.txt: " "aaas://" FQDN [ port ] [ transport ] [ protocol ] " Questions: a) Who has implemented the "aaas" scheme? b) Who is using the "aaas" scheme? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 31 09:13:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeuMZ-0006nf-Uh; Tue, 31 Oct 2006 09:13:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeuMY-0006nW-Hz for dime@ietf.org; Tue, 31 Oct 2006 09:13:10 -0500 Received: from grerelbas03.net.external.hp.com ([192.6.111.87] helo=grerelbas03.bastion.europe.hp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeuMM-0003n3-Nc for dime@ietf.org; Tue, 31 Oct 2006 09:13:10 -0500 Received: from IDAEXG12.emea.cpqcorp.net (idaexg12.emea.cpqcorp.net [16.16.5.39]) by grerelbas03.bastion.europe.hp.com (Postfix) with ESMTP id DCCCB340C5; Tue, 31 Oct 2006 15:12:54 +0100 (CET) Received: from idaexc02.emea.cpqcorp.net ([16.16.5.40]) by IDAEXG12.emea.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 15:12:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] RFC 3588 "aaas" Scheme: Feedback Needed! Date: Tue, 31 Oct 2006 15:12:52 +0100 Message-ID: <6E74A51363EBE84381CD11B13AAF44A003E48EAE@idaexc02.emea.cpqcorp.net> In-Reply-To: <4547132F.60801@web.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RFC 3588 "aaas" Scheme: Feedback Needed! Thread-Index: Acb87aV4HoPY35TRSrm3k8SlZhquqgAA/LRQ From: "Forissier, Jerome" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 31 Oct 2006 14:12:53.0993 (UTC) FILETIME=[A8272590:01C6FCF6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Hannes Tschofenig wrote: > Hi all, Hello Hannes, > I would like to solicit some feedback regarding the usage of AAAS as > defined in Section 4.3. of http://www.ietf.org/rfc/rfc3588.txt:=20 >=20 > " > "aaas://" FQDN [ port ] [ transport ] [ protocol ] " >=20 > Questions: >=20 > a) Who has implemented the "aaas" scheme? We have. Our Diameter API takes peer URIs, and the "aaas" scheme is what will trigger a connection over TLS. However, we have *not* implemented any processing of the "aaas" scheme in any Diameter AVP (such as Redirect-Host). --=20 Jerome _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 31 09:13:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeuMj-0006pm-4F; Tue, 31 Oct 2006 09:13:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeuMh-0006pI-Jd for dime@ietf.org; Tue, 31 Oct 2006 09:13:19 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeuMd-0003qR-An for dime@ietf.org; Tue, 31 Oct 2006 09:13:19 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 90FA41F213 for ; Tue, 31 Oct 2006 09:13:12 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k9VEDBL8025403 for ; Tue, 31 Oct 2006 09:13:11 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] FW: RFC 3588 "aaas" Scheme: Feedback Needed! Date: Tue, 31 Oct 2006 09:11:02 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org a) We did not implement it yet b) I don't know anybody using it And one more question: c) Is it usefull? Like Hannes pointed out before, it is quite similar to "sips" and has all of the associated problems. Overall, the idea is to demand security on each hop, but I am not sure whether a machanism where I can demand but not verify this is much of a use. P.S. : Currently there is a debate going on about "sips" in SIP mailing list. Thanks, Tolga > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Tuesday, October 31, 2006 7:15 AM > To: dime@ietf.org > Subject: [Dime] FW: RFC 3588 "aaas" Scheme: Feedback Needed! > > > Hi all, > > Hannes has asked some implementors about aaas scheme. Does anyone else > have any info on implementations of this feature? > > John > > >I would like to solicit some feedback regarding the usage of > >AAAS as defined in Section 4.3. of http://www.ietf.org/rfc/rfc3588.txt: > > > >" > > "aaas://" FQDN [ port ] [ transport ] [ protocol ] " > > > >Questions: > > > >a) Who has implemented the "aaas" scheme? > >b) Who is using the "aaas" scheme? > > > >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 Oct 31 09:38:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeulA-0003B9-4M; Tue, 31 Oct 2006 09:38:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geul8-0003B3-LY for dime@ietf.org; Tue, 31 Oct 2006 09:38:34 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geukx-0007Sw-T8 for dime@ietf.org; Tue, 31 Oct 2006 09:38:34 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 9999152F30 for ; Tue, 31 Oct 2006 09:38:15 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k9VEcEfv028276 for ; Tue, 31 Oct 2006 09:38:14 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] FW: RFC 3588 "aaas" Scheme: Feedback Needed! Date: Tue, 31 Oct 2006 09:36:04 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 One more point: Considering some type of transmission-level security is a MUST for diameter implementations (according to RFC3588 13), I think "aaas" has not much use/meaning. Thanks, Tolga > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com] > Sent: Tuesday, October 31, 2006 9:11 AM > To: dime@ietf.org > Subject: RE: [Dime] FW: RFC 3588 "aaas" Scheme: Feedback Needed! > > > a) We did not implement it yet > b) I don't know anybody using it > > And one more question: > > c) Is it usefull? > Like Hannes pointed out before, it is quite similar to "sips" and > has all of > the associated problems. Overall, the idea is to demand security on each > hop, but I am not sure whether a machanism where I can demand but > not verify > this is much of a use. > > P.S. : Currently there is a debate going on about "sips" in SIP mailing > list. > > Thanks, > Tolga > > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: Tuesday, October 31, 2006 7:15 AM > > To: dime@ietf.org > > Subject: [Dime] FW: RFC 3588 "aaas" Scheme: Feedback Needed! > > > > > > Hi all, > > > > Hannes has asked some implementors about aaas scheme. Does anyone else > > have any info on implementations of this feature? > > > > John > > > > >I would like to solicit some feedback regarding the usage of > > >AAAS as defined in Section 4.3. of http://www.ietf.org/rfc/rfc3588.txt: > > > > > >" > > > "aaas://" FQDN [ port ] [ transport ] [ protocol ] " > > > > > >Questions: > > > > > >a) Who has implemented the "aaas" scheme? > > >b) Who is using the "aaas" scheme? > > > > > >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