From mext-bounces@ietf.org Mon Oct 01 04:27:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcGXM-0005Mc-8O; Mon, 01 Oct 2007 04:21:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcGXL-0005MX-Kh for mext@ietf.org; Mon, 01 Oct 2007 04:21:55 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcGXK-0003Ff-L6 for mext@ietf.org; Mon, 01 Oct 2007 04:21:55 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 644001986B9; Mon, 1 Oct 2007 11:21:53 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 04009198658; Mon, 1 Oct 2007 11:21:52 +0300 (EEST) Message-ID: <4700A05C.3070905@piuha.net> Date: Mon, 01 Oct 2007 10:23:08 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Jouni Korhonen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org Subject: [MEXT] AD review of draft-korhonen-mip6-service-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Jouni asked me to AD sponsor this document. Here's my review. I support the extension proposed in the document, but there are a number of issues relating to how these values are defaulted, tight coupling to MN-NAI, whether these options appear in the first or all messages, and a few other things. I expect a revised ID. I proposed text for some of the issues that below, in some cases you need to still work on it. Substantial: > o In absence of the Service Selection option the home agent may > provide, based on operator policies, a default service. For > example, a plain Internet access could be an operator's default > mobility service. > The fact that there is no standard "default" and the proliferation of various operator conventions and policies has caused significant problems in GPRS and UMTS data access. I would not like to repeat this mistake here. One of way of avoiding this problem is to mandate that you do have a default. Suggested edit: OLD: In absence of the Service Selection option the home agent may provide, based on operator policies, a default service. For example, a plain Internet access could be an operator's default mobility service. NEW: In absence of the Service Selection option the home agent MUST act as if the default service, plain Internet access had been requested. There is no absolute requirement that this default service be allowed to all customers, but it is highly RECOMMENDED in order to avoid having normal users employ operator-specific configuration values in order to get basic service. > The Service Selection option should be used in > combination with the Mobile Node Identifier option during the initial > Binding Update at the beginning of the mobility session. I do not see a reason to make this MNID specific. Also, the concept of a mobility session isn't necessarily well-defined, if home agents can reboot, etc. Reformulated: OLD: The Service Selection option should be used in combination with the Mobile Node Identifier option during the initial Binding Update at the beginning of the mobility session. NEW: The Service Selection option should be used in every Binding Update that makes a registration to the home agent. And then you should probably add text somewhere to talk about the case where the service id suddenly changes and this no longer fits with the home address allocation, etc. > The Service Selection mobility option can be included in any Mobile > IPv6 Mobility Header message. This is inconsistent with Section 2. I'm not sure I see a need for this option to appear in other messages than the BU. Please reformulate. > This option MAY be included in the initial Binding Update message > when registering to a home agent at the beginning of the mobility > session. The MN-NAI option SHOULD be included in the Binding Update > message when the Service Selection option is used. Sending the > Service Selection option in any Binding Update message is not > prohibited. See above for tight coupling to MN-NAI option or the initial BUs. > It should be noted that sending this option to > correspondent nodes makes little or no sense unless the home agent > and the correspondent nodes share the same knowledge of provided > mobility services. Be more specific. SHOULD NOT be sent? Presumably, depending on what kind of service you got, you will or will be able to reach the CNs directly. In either case, it should be OK to attempt RO. > o Identifier: A variable length service identifier string used to > identify the requested service. The Identifier string is encoded > as a host name or a fully qualified domain name as defined in [4] > and [5]. The Identifier MAY be resolveable by DNS. > > 'internet', 'internet.example.com', 'voip.example.com' and > 'voip.companyxyz.example.com' are valid examples of Service > Selection option Identifier strings. At minimum the Identifier > must be unique among the home agents the mobile node is authorized > to register to. > Something like "internet" would not be unique among the home agents, if I the mobile node is allowed to use two different operators, for instance. Are there existing APN conventions in GPRS networks that are based on domain names? Or are you inventing a convention here? Another alternative might be to just say "UTF-8" and that the value is up to a local policy. And unique within a particular home agent. > The Service > Selection option is intended to be used with the MN-NAI option, but > it is also possible to use Home Address to identify the mobile node > as defined in [1]. See above about the coupling to MN-NAI. Editorial: > Mobile IPv6 [1] has a Mobile Node Identifier option (MN-NAI) [6] that > provides a flexible way to identify mobile nodes using other > identifiers than IPv6 addresses. Example of such identifier is a > Network Access Identifier (NAI) [2]. There are multiple ways of identifying the mobile node, and the NAI is just one of them. Suggested rewrite: OLD: Mobile IPv6 [1] has a Mobile Node Identifier option (MN-NAI) [6] that provides a flexible way to identify mobile nodes using other identifiers than IPv6 addresses. Example of such identifier is a Network Access Identifier (NAI) [2]. NEW: Mobile IPv6 [1] can identify mobile nodes in various ways, including home addresses [1], Network Access Identifiers (NAIs) [2, 3], and credentials suitable for IKEv2 [RFC 4877]. > The service selection may affect home > agent routing decisions and Home Address or Home Network Prefix > assignment policies. Or firewall and security policies. Suggested edit: OLD: The service selection may affect home agent routing decisions and Home Address or Home Network Prefix assignment policies. NEW: The service selection may affect home agent routing decisions, Home Address or Home Network Prefix assignment policies, firewall settings, and security policies. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mip6-bounces@ietf.org Mon Oct 01 06:30:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcIVJ-0001Py-9c; Mon, 01 Oct 2007 06:27:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcIVF-0001Fa-7z for mip6@ietf.org; Mon, 01 Oct 2007 06:27:53 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IcIUx-00071e-C2 for mip6@ietf.org; Mon, 01 Oct 2007 06:27:36 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1191234454!23840600!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 20470 invoked from network); 1 Oct 2007 10:27:34 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-8.tower-119.messagelabs.com with SMTP; 1 Oct 2007 10:27:34 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l91AROvI012105; Mon, 1 Oct 2007 03:27:28 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l91ARNWP007344; Mon, 1 Oct 2007 05:27:23 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l91ARKNG007273; Mon, 1 Oct 2007 05:27:21 -0500 (CDT) Message-ID: <4700CB84.4070707@gmail.com> Date: Mon, 01 Oct 2007 12:27:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Catering for IPv4-only home networks. A proposal. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000777-4, 30/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, Karen.Nielsen@tietoenator.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hesham Soliman wrote: > One more thing to add here. A MIPv6 BU is not an accumulative > operation, a new BU overwrites the old one. Right... > So if you included one option in BU_1 and you want to remove it, then > you send BU_2 without that option. But I'm not convinced your > scenario can take place anyway. I think there surely are scenarios where the home network is IPv4 only. As much as there are scenarios where the home network is IPv6 only. Ie some deployments have the HA must run only IPv4, others only IPv6; yet the MN should be able to attach to both IPv4 and IPv6 networks. (but you probably meant by 'scenario' Christian's sequence of BUs?) Alex > > Hesham > >> -----Original Message----- From: Hesham Soliman >> [mailto:Hesham@elevatemobile.com] Sent: Saturday, September 29, >> 2007 1:15 AM To: Christian.Kaas-Petersen@tietoenator.com; >> mip6@ietf.org; Karen.Nielsen@tietoenator.com Subject: RE: [Mip6] >> Catering for IPv4-only home networks. A proposal. >> >> >> >>> Even though the end goal is clear: ubiquitous IPv6 with >> Mobile IPv6 >>> (RFC 3775) as the mobility solution, DSMIPv6 is offered as an >>> interim solution allowing IPv4 addresses, both as home addresses >>> and care-of addresses. Still, the home network must be IPv6 >>> enabled. Is there a way to allow IPv4-only home networks? >> >> => Sure, everything works as described in DSMIPv6 today, the only >> node that needs to be IPv6-enabled is the HA. The returning home >> problem you mention can be solved by decoupling the lifetimes for >> the v4 and v6 addresses as you suggest. We never considered the >> decoupling because this scenario was not seen as a big issue. >> Meaning, if your HA is IPv6-enabled, which is required by DSMIPv6, >> it will send RAs, so it should be able to route IPv6 on the local >> link. If there is an IPv6 HoA then the home network must ensure >> that IPv6 packets can be routed to the HA anyway, so it's not clear >> how you would end up requiring to to de-register one address but >> not the other. Can you explain the scenario a bit more? What does >> this network look like? Also, did you consider DSMIPv4? >> >> Hesham >> >>> The need for a solution relates to early transition from >> 3G network >>> to 4G networks. We think there is a simple solution. >>> >>> The idea is that the home agent only defends the IPv6 home >>> address when the mobile node is in the IPv4-only home network, >>> but defends both IPv6 and IPv4 home addresses on any IPv4-only >>> foreign networks. The difficult part is returning home, because >>> currently it is not possible to remove the binding cache for the >>> IPv4 home address without at the same time removing the IPv6 >>> home address. Thus both home addresses must be removed, and >>> shortly after, one of them must be re-established. This has the >>> unwanted side-effect of moving the IKE session twice. >> >> >>> >>> The following is a sketch of what happens when the mobile node >>> (a) boots on an IPv4-only home network, (b) moves to an IPv4-only >>> foreign network, and (c) returns home. Case (c) can be handled >>> with the current DSMIPv6 functionality, but could be made >>> simpler with a slight change in DSMIPv6. It is this sligth >>> change we should like to discuss. >>> >>> (a) The mobile node boots on the IPv4-only home network; assume >>> 172.1.1.0/24 is the prefix for this home network, and the mobile >>> node has address 172.1.1.1 and the home agent has addresses >>> 172.1.1.2 and 3ffe::2. Because the network is >> IPv4-only, >>> it is just as if the mobile node has only an IPv6 home address, >>> 3ffe::1, and now appears on an IPv4-only foreign network. IKE is >>> established between the IPv4 addresses, (ie between 172.1.1.1 >>> and 172.1.1.2) and after the ESP transport has been established, >>> a BU/BA exchange is made, where the mobile node reports its IPv6 >>> home address (3ffe::1) and its IPv4 care-of address (172.1.1.1), >>> specifying some non-zero lifetime. All IPv6 packets to and from >>> 3ffe::1 are subsequently tunneled between the mobile node and the >>> home agent, because the home agent defends the IPv6 home >>> address. The home agent does not defend the IPv4 home address >>> (172.1.1.1), so IPv4 packets pass directly to and from the mobile >>> node. >>> >>> (b) The mobile node moves to an IPv4-only foreign network, assume >>> with 200.1.1.0/24 as prefix. First a BU/BA >> exchange is made. >>> In the BU, the mobile node reports its IPv6 home address >> (3ffe::1), >>> its IPv4 home address (172.1.1.1), and its IPv4 care-of address >>> (assume it is 200.1.1.5), specifying some non-zero lifetime. As >>> a consequence the home agent and the mobile node move the IKE >>> session, now between the 172.1.1.2 and 200.1.1.5 addresses. Then >>> the home agent adds the IPv4 home address (172.1.1.1) in its >>> binding cache and starts defending the IPv4 home address. >>> >>> (c) The mobile node returns home. In the BU, the mobile node >>> sends the IPv6 home address (3ffe::1) and the IPv4 home address >>> (172.1.1.1) with a zero lifetime. Thus the home agent clears the >>> entries in the binding cache. According to RFC 4877, when the >>> binding cache is cleared, the IKE end points are moved, and must >>> have 3ffe::1 and 3ffe::2 as end points. Shortly after, a new BU >>> is sent, where the IPv6 home address (3ffe::1) is registered >> and using >>> 172.1.1.1 as care-of address specifying some non-zero lifetime. >>> The IKE session is moved again so it is now between 172.1.1.2 and >>> 172.1.1.1. >>> >>> But why send two BUs? A small change to the IPv4 home address >>> option could be made in order to indicate the IPv4 home address >>> should no longer be defended. One way is to reserve a bit in the >>> IPv4 home address option indicating the IPv4 address should have >>> lifetime zero, ie be deleted. Another way would be to add an >>> additional two bytes to the IPv4 home address option reporting a >>> lifetime. Such a lifetime should then be override the lifetime >>> found in the BU header for the IPv4 address only. In either >>> case, the home agent would first stop defending the 172.1.1.1 >>> address, then move the IKE session once. >>> >>> In the sketch above it was assumed the mobile node had some >>> non-IP way of being assigned its IPv4 home address when on the >>> IPv4-only home network, particularly important when returning >>> home, because in that case the home agent defends that address so >>> DHCP cannot be used to hand out that same address. It is also >>> assumed the home agent in some way connects (IPv6-in-IPv4 tunnel) >>> to the IPv6 internet. We have not identified any problems with >>> the destination cache maintained by neighbor discovery as the >>> 3ffe::2 is expected assigned to a loopback interface. Further, >>> no neighbor solicitations will ever be sent asking for 3ffe::1. >>> Because the loopback is reachable, the mobile node can also visit >>> IPv6 enabled foreign network. >>> >>> Karen Christian >>> >>> _______________________________________________ Mip6 mailing list >>> Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 >>> >> >> >> >> _______________________________________________ Mip6 mailing list >> Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 >> > > > > _______________________________________________ Mip6 mailing list > Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 01 11:23:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcN5N-0001Po-Qo; Mon, 01 Oct 2007 11:21:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcN5M-0001Mr-QP for mip6@ietf.org; Mon, 01 Oct 2007 11:21:28 -0400 Received: from datnt07.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcN5G-0003kP-A4 for mip6@ietf.org; Mon, 01 Oct 2007 11:21:28 -0400 X-AuditID: c26e2f18-00001d00000022d0-9b-470110402f2d Received: from stingray.eu.tieto.com ([192.176.143.13]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 18:20:32 +0300 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 17:20:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Catering for IPv4-only home networks. A proposal. Date: Mon, 1 Oct 2007 17:20:51 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Catering for IPv4-only home networks. A proposal. Thread-Index: AcgB2TU8XBw8QI0mRjub9L2uZ320cQACFMzwABjusfAAeyvloA== References: From: To: , , X-OriginalArrivalTime: 01 Oct 2007 15:20:53.0336 (UTC) FILETIME=[A803BD80:01C8043E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham, All To clarify the scenario: For the long term evolution of 3GPP system (LTE), DSMIPv6 is the chosen protocol to handle mobility and handover in between 3GPP "native" access and non-3GPP access. The usage of DSMIPv6 is motivated by the fact=20 that dual stack and dual (IPv6, IPv4) connectivity is the long term goal. Slowly moving from a dominantly IPv4 network to=20 a dual stack network, and perhaps, once, to a Ipv6-only network=20 with IPv4 usage only for rare occasions (if ever). Indeed in this scenario, DSMIPv6 is a good future proof solution. BUT ... IPv6 connectivity isn't there yet. The problem is that the mobility problem must be solved, also in a transition period where Ipv6 connectivity isn't there (yet),=20 not even in the Home Network. Rather than looking to deploy a different protocol in the transition period,=20 it would be easiest if DSMIPv6 could handle also the situation where=20 home network IPv6 connectivity isn't available (yet). The characteristics of the scenarios are: * The MN carries both an IPv6 and an IPv4 home address * The MN and the HA are dual stack * MIP signaling is carried over Ipv6. IPSec and IKE usage as described in 3775 and DSMIPv6 (with new clarifications). * The MN is never at home Ipv6 wise * The MN may be at home Ipv4 wise * When at home Ipv4 wise, the MN uses its IPv4 HoA for all IPv4 communication=20 whereas all Ipv6 communication (if any) is tunneled from HA in Ipv6 in IPv4 to IPv4 care-of-address. This care-of-address may be the same as the IPv4 HoA or it may be a different Ipv4 address (in which case the MN would hold two home-link Ipv4 addresses). Ipv6 communication via tunnel to HA requires the HA to have external Ipv6 connectivity. * When not at home IPv4 wise, everything is as described in DSMIPv6. * The HA does not have a true Ipv6 home-link. Perhaps one can think of the conceptual Ipv6 network as a virtual network. As such the links on which the HA serves as Home Agent for Ipv4 and IPv6, respectively, are DIFFERENT. * How the MN discovers that it is on its Home Network link Ipv4 wise is out of scope of the HA functionality. In the LTE this, as movement detection in general, will be handled by means outside of IP. This fits very well with the fact that movement detection on IPv4 is out of scope of DSMIPv6. Now these are basically the demands of LTE. We have been looking into how to fulfill them using DSMIPv6 and what we lack is the possibility to return home at the IPv4 level without being at home Ipv6 wise. Why do we want to be able to return home Ipv4 wise, you might ask - well because we want to eliminate=20 the Ipv4 in Ipv4 tunnel (as well as the in-path HA) when conceptually at home (i.e. attached to 3GPP network). To clarify the possibly solutions: In fact, it seems this may be solved by DSMIPv6, as is, by the exchange of BUs as described in a previous mail. As follows: 1a. When the MN discovers that it may use its Ipv4 HoA directly, it sends a BU to the HA with lifetime zero and with DSMIP Ipv4 home address option carrying the IPv4 HoA [OR is the latter superfluous ?] The BU is sent from the IPv4 care-of-address (which may be its IPv4 HoA). --> Result: Both Ipv6 as well as Ipv4 bindings are removed. The HA will, if K bit is set, move IKE SA to=20 IPv6 address of it-self and Ipv6 HoA of MN (as specified by RFC 3775). Presumably, the BACK would be tunneled to the address from which the BU was sent. The MN has IPv4 connectivity by means of its Ipv4 HoA, but no Ipv6 connectivity. 2a. The MN sends a new BU with non-zero lifetime and with Ipv4 care-of-address in DSMIPv6 Ipv4 care-of-address option of BU. (and no DSMIPv6 Ipv4 Home address option). --> Result: A new binding cache entry is created for the Ipv6 HoA of MN. IKE SA is moved to Ipv4 address of HA to Ipv4 Care-of-address of MN. The MN, now, in addition has Ipv6 connectivity via tunnel to HA. The disadvantage of this is that it requires 2 BU/Back exchanges as well as the IKE SA is moved twice. In DSMIP it is clearly stated that a DSMIP BU with an Ipv4 home address option results in two (!) binding cache entries, one for Ipv6 HoA and one for Ipv4 HoA.=20 Therefore we suggest to enforce this split also in the DSMIP BU, by introducing a lifetime in the Ipv4 home address option (or a flag which indicates that the binding for this address should be deleted). Doing that it would be possible to de-register the IPv4 HoA as well as updating the Ipv6 registration at the same time by sending: 1b. MIPv6 BU with non-zero lifetime in header, an DSMIP Ipv4 care-of-address option and a DSMIP Ipv4 home-address option with zero-lifetime. --> Result: Ipv4 binding cache entry is removed, Ipv6 binding cache entry is created/updated with new Ipv4 care-of-address. However it is also clear that the latter suggestion opens up for things to consider, how about error handling, when only one of the items checks out, but than I suppose this issue is there already - when moving and updating both Ipv6 and Ipv4 binding cache entries - ?=20 This could be used to tunnel Ipv4 over Ipv6 in Ipv6 only home-network - should it,=20 or should that be banned ? Question: What do you think ? Is this scenario within the scope of DSMIPv6 ? no :-(=20 yes: is 1a, 2a then the right choice, or could 1b be an option ?=20 /Karen > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Saturday, September 29, 2007 5:05 AM > To: 'Hesham Soliman'; Kaas-Petersen Christian; mip6@ietf.org;=20 > Nielsen Karen E > Subject: RE: [Mip6] Catering for IPv4-only home networks. A proposal. >=20 > One more thing to add here. A MIPv6 BU is not an accumulative=20 > operation, a > new BU overwrites the old one. So if you included one option=20 > in BU_1 and you > want to remove it, then you send BU_2 without that option. But I'm not > convinced your scenario can take place anyway.=20 >=20 > Hesham=20 >=20 > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > > Sent: Saturday, September 29, 2007 1:15 AM > > To: Christian.Kaas-Petersen@tietoenator.com; mip6@ietf.org;=20 > > Karen.Nielsen@tietoenator.com > > Subject: RE: [Mip6] Catering for IPv4-only home networks.=20 > A proposal. > >=20 > >=20 > >=20 > > > Even though the end goal is clear: ubiquitous IPv6 with=20 > > Mobile IPv6 > > > (RFC 3775) as the mobility solution, DSMIPv6 is offered as an > > > interim solution allowing IPv4 addresses, both as home addresses > > > and care-of addresses. Still, the home network must be IPv6 > > > enabled. Is there a way to allow IPv4-only home networks? > >=20 > > =3D> Sure, everything works as described in DSMIPv6 today, the=20 > > only node that > > needs to be IPv6-enabled is the HA. The returning home=20 > > problem you mention > > can be solved by decoupling the lifetimes for the v4 and v6=20 > > addresses as you > > suggest. We never considered the decoupling because this=20 > > scenario was not > > seen as a big issue. Meaning, if your HA is IPv6-enabled,=20 > > which is required > > by DSMIPv6, it will send RAs, so it should be able to route=20 > > IPv6 on the > > local link. If there is an IPv6 HoA then the home network=20 > > must ensure that > > IPv6 packets can be routed to the HA anyway, so it's not=20 > > clear how you would > > end up requiring to to de-register one address but not the=20 > > other. Can you > > explain the scenario a bit more? What does this network look like?=20 > > Also, did you consider DSMIPv4?=20 > >=20 > > Hesham > >=20 > > > The need for a solution relates to early transition from=20 > > 3G network > > > to 4G networks. We think there is a simple solution. > > >=20 > > > The idea is that the home agent only defends the IPv6=20 > home address > > > when the mobile node is in the IPv4-only home network, but > > > defends both IPv6 and IPv4 home addresses on any IPv4-only > > > foreign networks. The difficult part is returning home, because > > > currently it is not possible to remove the binding cache for > > > the IPv4 home address without at the same time removing > > > the IPv6 home address. Thus both home addresses must=20 > be removed, > > > and shortly after, one of them must be re-established. =20 > This has=20 > > > the unwanted side-effect of moving the IKE session twice. > >=20 > >=20 > > >=20 > > > The following is a sketch of what happens when the mobile node > > > (a) boots on an IPv4-only home network, (b) moves to an=20 > IPv4-only > > > foreign network, and (c) returns home. Case (c) can be handled > > > with the current DSMIPv6 functionality, but could be=20 > made simpler > > > with a slight change in DSMIPv6. It is this sligth change we > > > should like to discuss. > > >=20 > > > (a) The mobile node boots on the IPv4-only home network; assume > > > 172.1.1.0/24 is the prefix for this home network, and the > > > mobile node has address 172.1.1.1 and the home agent has > > > addresses 172.1.1.2 and 3ffe::2. Because the network is=20 > > IPv4-only,=20 > > > it is just as if the mobile node has only an IPv6 home address,=20 > > > 3ffe::1, and now appears on an IPv4-only foreign network. IKE=20 > > > is established between the IPv4 addresses, (ie between=20 > 172.1.1.1=20 > > > and 172.1.1.2) and after the ESP transport has been=20 > established,=20 > > > a BU/BA exchange is made, where the mobile node reports its > > > IPv6 home address (3ffe::1) and its IPv4 care-of address > > > (172.1.1.1), specifying some non-zero lifetime. All=20 > IPv6 packets > > > to and from 3ffe::1 are subsequently tunneled between the mobile > > > node and the home agent, because the home agent defends the > > > IPv6 home address. The home agent does not defend the IPv4 home > > > address (172.1.1.1), so IPv4 packets pass directly to and from > > > the mobile node. > > >=20 > > > (b) The mobile node moves to an IPv4-only foreign network, > > > assume with 200.1.1.0/24 as prefix. First a BU/BA=20 > > exchange is made. > > > In the BU, the mobile node reports its IPv6 home address=20 > > (3ffe::1), > > > its IPv4 home address (172.1.1.1), and its IPv4 care-of address > > > (assume it is 200.1.1.5), specifying some non-zero=20 > lifetime. As a > > > consequence the home agent and the mobile node move the IKE > > > session, now between the 172.1.1.2 and 200.1.1.5 addresses. > > > Then the home agent adds the IPv4 home address (172.1.1.1) > > > in its binding cache and starts defending the IPv4 home address. > > >=20 > > > (c) The mobile node returns home. In the BU, the mobile node > > > sends the IPv6 home address (3ffe::1) and the IPv4 home address > > > (172.1.1.1) with a zero lifetime. Thus the home agent=20 > clears the > > > entries in the binding cache. According to RFC 4877, when the > > > binding cache is cleared, the IKE end points are moved, and must > > > have 3ffe::1 and 3ffe::2 as end points. Shortly after,=20 > a new BU is > > > sent, where the IPv6 home address (3ffe::1) is registered=20 > > and using > > > 172.1.1.1 as care-of address specifying some non-zero lifetime. > > > The IKE session is moved again so it is now between=20 > 172.1.1.2 and > > > 172.1.1.1. > > >=20 > > > But why send two BUs? A small change to the IPv4 home address > > > option could be made in order to indicate the IPv4 home address > > > should no longer be defended. One way is to reserve a=20 > bit in the > > > IPv4 home address option indicating the IPv4 address should > > > have lifetime zero, ie be deleted. Another way would be > > > to add an additional two bytes to the IPv4 home address option > > > reporting a lifetime. Such a lifetime should then be > > > override the lifetime found in the BU header for the IPv4 > > > address only. In either case, the home agent would first stop > > > defending the 172.1.1.1 address, then move the IKE session once. > > >=20 > > > In the sketch above it was assumed the mobile node had=20 > some non-IP > > > way of being assigned its IPv4 home address when on the=20 > IPv4-only > > > home network, particularly important when returning=20 > home, because > > > in that case the home agent defends that address so DHCP cannot > > > be used to hand out that same address. It is also assumed the > > > home agent in some way connects (IPv6-in-IPv4 tunnel) to > > > the IPv6 internet. We have not identified any problems with > > > the destination cache maintained by neighbor discovery as the > > > 3ffe::2 is expected assigned to a loopback interface. Further, > > > no neighbor solicitations will ever be sent asking for 3ffe::1. > > > Because the loopback is reachable, the mobile node can also > > > visit IPv6 enabled foreign network. > > >=20 > > > Karen > > > Christian > > >=20 > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > >=20 >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mext-bounces@ietf.org Mon Oct 01 13:12:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOm7-00085v-VL; Mon, 01 Oct 2007 13:09:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOm6-000828-Dq for mext@ietf.org; Mon, 01 Oct 2007 13:09:42 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcOm6-0007vd-1G for mext@ietf.org; Mon, 01 Oct 2007 13:09:42 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 10:09:41 -0700 Message-ID: <470129D4.8090403@azairenet.com> Date: Mon, 01 Oct 2007 10:09:40 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt References: <4700A05C.3070905@piuha.net> In-Reply-To: <4700A05C.3070905@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Oct 2007 17:09:41.0325 (UTC) FILETIME=[DAFFCFD0:01C8044D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Jari, A couple of comments. Jari Arkko wrote: >> o In absence of the Service Selection option the home agent may >> provide, based on operator policies, a default service. For >> example, a plain Internet access could be an operator's default >> mobility service. >> > > The fact that there is no standard "default" and the proliferation > of various operator conventions and policies has caused significant > problems in GPRS and UMTS data access. I would not like to repeat > this mistake here. > > One of way of avoiding this problem is to mandate that you do > have a default. Suggested edit: > > OLD: > In absence of the Service Selection option the home agent may > provide, based on operator policies, a default service. For > example, a plain Internet access could be an operator's default > mobility service. > NEW: > In absence of the Service Selection option the home agent MUST > act as if the default service, plain Internet access had been > requested. There is no absolute requirement that this default service be > allowed to all customers, but it is highly RECOMMENDED in > order to avoid having normal users employ operator-specific > configuration values in order to get basic service. This is a good idea. Completely agree. >> The Service Selection mobility option can be included in any Mobile >> IPv6 Mobility Header message. > This is inconsistent with Section 2. I'm not sure I see a need > for this option to appear in other messages than the BU. > Please reformulate. We should probably not say anything here. There is no need to restrict it to the Binding Update and at the same time no need to claim that it can be used in any mobility header message. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Oct 01 16:53:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcSCm-00057a-Bl; Mon, 01 Oct 2007 16:49:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcSCl-000579-2d for mext@ietf.org; Mon, 01 Oct 2007 16:49:27 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcSCk-0005Q5-Nj for mext@ietf.org; Mon, 01 Oct 2007 16:49:26 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1887E198677; Mon, 1 Oct 2007 23:49:26 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id ACD91198646; Mon, 1 Oct 2007 23:49:25 +0300 (EEST) Message-ID: <47015D55.1050602@piuha.net> Date: Mon, 01 Oct 2007 23:49:25 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt References: <4700A05C.3070905@piuha.net> <470129D4.8090403@azairenet.com> In-Reply-To: <470129D4.8090403@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Vijay, >> This is inconsistent with Section 2. I'm not sure I see a need >> for this option to appear in other messages than the BU. >> Please reformulate. > > We should probably not say anything here. There is no need to restrict > it to the Binding Update and at the same time no need to claim that it > can be used in any mobility header message. I think you need to define what the behaviour should be when you receive this. I'm not sure its obvious. What should you do if you receive this in a BA or BE, for instance? Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Oct 02 04:20:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IccvI-0005rF-61; Tue, 02 Oct 2007 04:16:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IccvH-0005kD-5S for mext@ietf.org; Tue, 02 Oct 2007 04:16:07 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iccv6-0001Iz-8K for mext@ietf.org; Tue, 02 Oct 2007 04:16:07 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Oct 2007 10:15: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Oct 2007 10:15:40 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222D260@SEHAN021MB.tcad.telia.se> In-Reply-To: <4700A05C.3070905@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-korhonen-mip6-service-03.txt Thread-Index: AcgEBCFn7W9wurwISgKpm9fN88A1ZgAvuKnQ References: <4700A05C.3070905@piuha.net> From: To: X-OriginalArrivalTime: 02 Oct 2007 08:15:41.0330 (UTC) FILETIME=[6C164F20:01C804CC] X-Spam-Score: -4.0 (----) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org Subject: [MEXT] RE: AD review of draft-korhonen-mip6-service-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Jari, Thanks for the extensive review. Some comments inline. > Sent: Monday, October 01, 2007 10:23 AM >=20 > Jouni asked me to AD sponsor this document. Here's my review. >=20 > I support the extension proposed in the document, but there=20 > are a number of issues relating to how these values are=20 > defaulted, tight coupling to MN-NAI, whether these options=20 > appear in the first or all messages, and a few other things. >=20 > I expect a revised ID. I proposed text for some of the issues=20 > that below, in some cases you need to still work on it. >=20 > Substantial: >=20 > > o In absence of the Service Selection option the home agent may > > provide, based on operator policies, a default service. For > > example, a plain Internet access could be an=20 > operator's default > > mobility service. > > =20 >=20 > The fact that there is no standard "default" and the=20 > proliferation of various operator conventions and policies=20 > has caused significant problems in GPRS and UMTS data access.=20 > I would not like to repeat this mistake here. Agree on this. This actually has given headache in several occasions e.g. in our services deployments. Dunno how we managed to repeat it in this I-D in the first place... > One of way of avoiding this problem is to mandate that you do=20 > have a default. Suggested edit: >=20 > OLD: > In absence of the Service Selection option the home agent may=20 > provide, based on operator policies, a default service. For=20 > example, a plain Internet access could be an operator's=20 > default mobility service. > NEW: > In absence of the Service Selection option the home agent=20 > MUST act as if the default service, plain Internet access had=20 > been requested. There is no absolute requirement that this=20 > default service be allowed to all customers, but it is highly=20 > RECOMMENDED in order to avoid having normal users employ=20 > operator-specific configuration values in order to get basic service. OK by me. > > The Service Selection option should be used in > > combination with the Mobile Node Identifier option=20 > during the initial > > Binding Update at the beginning of the mobility session. > I do not see a reason to make this MNID specific. Also, the=20 > concept of a mobility session isn't necessarily well-defined,=20 > if home agents can reboot, etc. Reformulated: Hmmm.. right. "should" is not exactly mandating the use of MNID. Agree on the mobility session ambiguity. > OLD: > The Service Selection option should be used in combination=20 > with the Mobile Node Identifier option during the initial=20 > Binding Update at the beginning of the mobility session. > NEW: > The Service Selection option should be used in every Binding=20 > Update that makes a registration to the home agent. OK. > And then you should probably add text somewhere to talk about=20 > the case where the service id suddenly changes and this no=20 > longer fits with the home address allocation, etc. Good point. I actually had some thoughts to write a bit about this scenario. My initial thinking was that if the service id changes mid session and the HA cannot agree with the new service, the HA would reject the binding and send back a BA with an error code indicating the administrative decision. > > The Service Selection mobility option can be included in=20 > any Mobile > > IPv6 Mobility Header message.=20 > This is inconsistent with Section 2. I'm not sure I see a=20 > need for this option to appear in other messages than the BU. > Please reformulate. Right. Agree. > > This option MAY be included in the initial Binding Update message > > when registering to a home agent at the beginning of the mobility > > session. The MN-NAI option SHOULD be included in the=20 > Binding Update > > message when the Service Selection option is used. Sending the > > Service Selection option in any Binding Update message is not > > prohibited.=20 >=20 > See above for tight coupling to MN-NAI option or the initial BUs. Ack. > > It should be noted that sending this option to > > correspondent nodes makes little or no sense unless the=20 > home agent > > and the correspondent nodes share the same knowledge of provided > > mobility services. > Be more specific. SHOULD NOT be sent? Presumably, depending=20 > on what kind of service you got, you will or will be able to=20 > reach the CNs directly. In either case, it should be OK to attempt RO. Yes, attempting RO should be ok in all cases. I should probably only say here: The service selection option SHOULD NOT be send to a correspondent node. The mobile node cannot assume that the correspondent node has any knowledge about a specific service selection done between the mobile node and the home agent. > > o Identifier: A variable length service identifier=20 > string used to > > identify the requested service. The Identifier=20 > string is encoded > > as a host name or a fully qualified domain name as=20 > defined in [4] > > and [5]. The Identifier MAY be resolveable by DNS. > > > > 'internet', 'internet.example.com', 'voip.example.com' and > > 'voip.companyxyz.example.com' are valid examples of Service > > Selection option Identifier strings. At minimum the=20 > Identifier > > must be unique among the home agents the mobile node=20 > is authorized > > to register to. > > =20 >=20 > Something like "internet" would not be unique among the home=20 > agents, if I the mobile node is allowed to use two different=20 > operators, for instance. IMHO that falls to roaming contract arrangement part and in that case something like "internet" can definitely be agreed on to be unique among operators the mobile node is allowed to roam with. Bad choice of example, I can change that. > Are there existing APN conventions in GPRS networks that are=20 > based on domain names? Or are you inventing a convention here? APNs are have two parts: the Netword Identified (NI) and the Operator Identifier (OI). The NI is mandatory e.g. plain "voip" in the above example and the optional OI is the domain name e.g. "example.com". Of cource GPRS APN domain name convention are more akward than in the above example. So no inventing a convention here. =20 > Another alternative might be to just say "UTF-8" and that the=20 > value is up to a local policy. And unique within a particular=20 > home agent. Hmmm.. could be ok. Need to think about this. > > The Service > > Selection option is intended to be used with the MN-NAI=20 > option, but > > it is also possible to use Home Address to identify the=20 > mobile node > > as defined in [1]. > See above about the coupling to MN-NAI. Ack. > Editorial: >=20 > > Mobile IPv6 [1] has a Mobile Node Identifier option=20 > (MN-NAI) [6] that > > provides a flexible way to identify mobile nodes using other > > identifiers than IPv6 addresses. Example of such identifier is a > > Network Access Identifier (NAI) [2]. > There are multiple ways of identifying the mobile node, and=20 > the NAI is just one of them. Suggested rewrite: >=20 > OLD: > Mobile IPv6 [1] has a Mobile Node Identifier option (MN-NAI)=20 > [6] that provides a flexible way to identify mobile nodes=20 > using other identifiers than IPv6 addresses. Example of such=20 > identifier is a Network Access Identifier (NAI) [2]. > NEW: > Mobile IPv6 [1] can identify mobile nodes in various ways,=20 > including home addresses [1], Network Access Identifiers=20 > (NAIs) [2, 3], and credentials suitable for IKEv2 [RFC 4877]. Good. Thanks. > > The service selection may affect home > > agent routing decisions and Home Address or Home Network Prefix > > assignment policies.=20 > Or firewall and security policies. Suggested edit: >=20 > OLD: > The service selection may affect home > agent routing decisions and Home Address or Home Network=20 > Prefix assignment policies. > NEW: > The service selection may affect home > agent routing decisions, Home Address or Home Network Prefix=20 > assignment policies, firewall settings, and security policies. OK. Thanks, Cheers, Jouni >=20 > Jari >=20 >=20 >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mip6-bounces@ietf.org Tue Oct 02 04:36:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDZ-0003GZ-FY; Tue, 02 Oct 2007 04:35:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDY-0003Fw-FS for mip6@ietf.org; Tue, 02 Oct 2007 04:35:00 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IcdDN-0001qT-4f for mip6@ietf.org; Tue, 02 Oct 2007 04:34:56 -0400 Received: (qmail invoked by alias); 02 Oct 2007 08:34:28 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp051) with SMTP; 02 Oct 2007 10:34:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Yk8sxg6qYl7uggKtDDjOHDf9qJsIKQA4a8eiamz 2NiwDCVnwU5Kpi Message-ID: <47020294.1010506@gmx.net> Date: Tue, 02 Oct 2007 10:34:28 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org, Mobile IPv6 Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Mip6] WGLC for draft-ietf-dime-mip6-split-05 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi all, this message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction" (draft-ietf-dime-mip6-split-05). You may view this document at http://tools.ietf.org/html/draft-ietf-dime-mip6-split-05 Please post comments and questions to the DIME mailing list (or to the authors) no later than 16 October 2007. Ciao Hannes & Dave _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mext-bounces@ietf.org Tue Oct 02 05:35:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ice7d-0000IH-M4; Tue, 02 Oct 2007 05:32:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ice7c-0000IC-FV for mext@ietf.org; Tue, 02 Oct 2007 05:32:56 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ice7b-0005qX-Tr for mext@ietf.org; Tue, 02 Oct 2007 05:32:56 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CBBE3198677; Tue, 2 Oct 2007 12:32:54 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9675D198670; Tue, 2 Oct 2007 12:32:54 +0300 (EEST) Message-ID: <47021046.1070100@piuha.net> Date: Tue, 02 Oct 2007 12:32:54 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com References: <4700A05C.3070905@piuha.net> <59D7431DE2527D4CB0F1EFEDA5683ED30222D260@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30222D260@SEHAN021MB.tcad.telia.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org Subject: [MEXT] Re: AD review of draft-korhonen-mip6-service-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > Good point. I actually had some thoughts to write a bit about this > scenario. My initial thinking was that if the service id changes mid > session and the HA cannot agree with the new service, the HA > would reject the binding and send back a BA with an error code > indicating the administrative decision. > This is fine. > Yes, attempting RO should be ok in all cases. I should probably > only say here: > > The service selection option SHOULD NOT be send to a correspondent > node. The mobile node cannot assume that the correspondent node > has any knowledge about a specific service selection done between > the mobile node and the home agent. > Ok. >> Something like "internet" would not be unique among the home >> agents, if I the mobile node is allowed to use two different >> operators, for instance. >> > > IMHO that falls to roaming contract arrangement part and in that > case something like "internet" can definitely be agreed on to > be unique among operators the mobile node is allowed to roam > with. Bad choice of example, I can change that. > > >> Are there existing APN conventions in GPRS networks that are >> based on domain names? Or are you inventing a convention here? >> > > APNs are have two parts: the Netword Identified (NI) and the Operator > Identifier (OI). The NI is mandatory e.g. plain "voip" in the above > example and the optional OI is the domain name e.g. "example.com". > Of cource GPRS APN domain name convention are more akward than in > the above example. So no inventing a convention here. > > >> Another alternative might be to just say "UTF-8" and that the >> value is up to a local policy. And unique within a particular >> home agent. >> > > Hmmm.. could be ok. Need to think about this. > It is still unclear to me what the best choice is. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mip6-bounces@ietf.org Tue Oct 02 08:19:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icgh9-0000rP-7K; Tue, 02 Oct 2007 08:17:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icgh6-0000Sa-Ap for mip6@ietf.org; Tue, 02 Oct 2007 08:17:44 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icggm-0001kJ-10 for mip6@ietf.org; Tue, 02 Oct 2007 08:17:25 -0400 Received: from oaamta02sl.mx.bigpond.com ([124.190.106.219]) by omta01sl.mx.bigpond.com with ESMTP id <20071002121720.IEQT26650.omta01sl.mx.bigpond.com@oaamta02sl.mx.bigpond.com> for ; Tue, 2 Oct 2007 12:17:20 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta02sl.mx.bigpond.com with ESMTP id <20071002121719.YQQL20737.oaamta02sl.mx.bigpond.com@PC20005>; Tue, 2 Oct 2007 12:17:19 +0000 From: "Hesham Soliman" To: , , Subject: RE: [Mip6] Catering for IPv4-only home networks. A proposal. Date: Tue, 2 Oct 2007 22:17:14 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgB2TU8XBw8QI0mRjub9L2uZ320cQACFMzwABjusfAAeyvloAAttMxA X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > To clarify the scenario: > > For the long term evolution of 3GPP system (LTE), DSMIPv6 is > the chosen > protocol to handle mobility and handover in between 3GPP > "native" access > and > non-3GPP access. > > The usage of DSMIPv6 is motivated by the fact > that dual stack and dual (IPv6, IPv4) connectivity > is the long term goal. Slowly moving from a dominantly IPv4 > network to > a dual stack network, and perhaps, once, to a Ipv6-only network > with IPv4 usage only for rare occasions (if ever). > > Indeed in this scenario, DSMIPv6 is a good future proof solution. BUT > ... > IPv6 connectivity isn't there yet. > > The problem is that the mobility problem must be solved, > also in a transition period where Ipv6 connectivity isn't > there (yet), > not even in the Home Network. > > Rather than looking to deploy a different protocol in the transition > period, > it would be easiest if DSMIPv6 could handle also the situation where > home network IPv6 connectivity isn't available (yet). => I don't follow. Can we agree on a couple of things so we're on the same wavelength: 1. In DSMIPv6, the home link will always have IPv6 enabled simply because the HA is IPv6 enabled. 2. The rest of the network might be IPv4-only, but since the HA is offering an IPv6 HoA, which allows the MN to be *reachable*, then the home network will have to find a way to tunnel IPv6 traffic over IPv4, to the home link. 3. Of course we agree that home network != home link > > The characteristics of the scenarios are: > * The MN carries both an IPv6 and an IPv4 home address > * The MN and the HA are dual stack > * MIP signaling is carried over Ipv6. IPSec and IKE usage as > described > in 3775 and DSMIPv6 (with new clarifications). > * The MN is never at home Ipv6 wise > * The MN may be at home Ipv4 wise > > * When at home Ipv4 wise, => In order for me to proceed I need to understand how the MN can be home IPv4-wise, but not IPv6-wise. This goes back to point 1 and 2 above. I understand how you see the scenario, but I want to know how we got to this point given that IPv6 is enabled on the HA and the MN, so by definition, the home link has to have IPv6. > Question: > > What do you think ? > Is this scenario within the scope of DSMIPv6 ? no :-( => Please see my question above. Please don't get into how it can be solved, I just need to know how this problem happened in the first place. The assumption of no IPv6 in the home link makes no sense unless it is designed to do so, i.e. someone decided to make the home link a virtual link, which, again is an unnecessary action for IPv6 only. Hesham > yes: is 1a, 2a then the right choice, or could 1b be an option ? > > /Karen > > > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Saturday, September 29, 2007 5:05 AM > > To: 'Hesham Soliman'; Kaas-Petersen Christian; mip6@ietf.org; > > Nielsen Karen E > > Subject: RE: [Mip6] Catering for IPv4-only home networks. > A proposal. > > > > One more thing to add here. A MIPv6 BU is not an accumulative > > operation, a > > new BU overwrites the old one. So if you included one option > > in BU_1 and you > > want to remove it, then you send BU_2 without that option. > But I'm not > > convinced your scenario can take place anyway. > > > > Hesham > > > > > -----Original Message----- > > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > > Sent: Saturday, September 29, 2007 1:15 AM > > > To: Christian.Kaas-Petersen@tietoenator.com; mip6@ietf.org; > > > Karen.Nielsen@tietoenator.com > > > Subject: RE: [Mip6] Catering for IPv4-only home networks. > > A proposal. > > > > > > > > > > > > > Even though the end goal is clear: ubiquitous IPv6 with > > > Mobile IPv6 > > > > (RFC 3775) as the mobility solution, DSMIPv6 is offered as an > > > > interim solution allowing IPv4 addresses, both as > home addresses > > > > and care-of addresses. Still, the home network must be IPv6 > > > > enabled. Is there a way to allow IPv4-only home networks? > > > > > > => Sure, everything works as described in DSMIPv6 today, the > > > only node that > > > needs to be IPv6-enabled is the HA. The returning home > > > problem you mention > > > can be solved by decoupling the lifetimes for the v4 and v6 > > > addresses as you > > > suggest. We never considered the decoupling because this > > > scenario was not > > > seen as a big issue. Meaning, if your HA is IPv6-enabled, > > > which is required > > > by DSMIPv6, it will send RAs, so it should be able to route > > > IPv6 on the > > > local link. If there is an IPv6 HoA then the home network > > > must ensure that > > > IPv6 packets can be routed to the HA anyway, so it's not > > > clear how you would > > > end up requiring to to de-register one address but not the > > > other. Can you > > > explain the scenario a bit more? What does this network > look like? > > > Also, did you consider DSMIPv4? > > > > > > Hesham > > > > > > > The need for a solution relates to early transition from > > > 3G network > > > > to 4G networks. We think there is a simple solution. > > > > > > > > The idea is that the home agent only defends the IPv6 > > home address > > > > when the mobile node is in the IPv4-only home network, but > > > > defends both IPv6 and IPv4 home addresses on any IPv4-only > > > > foreign networks. The difficult part is returning > home, because > > > > currently it is not possible to remove the binding cache for > > > > the IPv4 home address without at the same time removing > > > > the IPv6 home address. Thus both home addresses must > > be removed, > > > > and shortly after, one of them must be re-established. > > This has > > > > the unwanted side-effect of moving the IKE session twice. > > > > > > > > > > > > > > The following is a sketch of what happens when the > mobile node > > > > (a) boots on an IPv4-only home network, (b) moves to an > > IPv4-only > > > > foreign network, and (c) returns home. Case (c) can > be handled > > > > with the current DSMIPv6 functionality, but could be > > made simpler > > > > with a slight change in DSMIPv6. It is this sligth change we > > > > should like to discuss. > > > > > > > > (a) The mobile node boots on the IPv4-only home > network; assume > > > > 172.1.1.0/24 is the prefix for this home network, and the > > > > mobile node has address 172.1.1.1 and the home agent has > > > > addresses 172.1.1.2 and 3ffe::2. Because the network is > > > IPv4-only, > > > > it is just as if the mobile node has only an IPv6 > home address, > > > > 3ffe::1, and now appears on an IPv4-only foreign > network. IKE > > > > is established between the IPv4 addresses, (ie between > > 172.1.1.1 > > > > and 172.1.1.2) and after the ESP transport has been > > established, > > > > a BU/BA exchange is made, where the mobile node reports its > > > > IPv6 home address (3ffe::1) and its IPv4 care-of address > > > > (172.1.1.1), specifying some non-zero lifetime. All > > IPv6 packets > > > > to and from 3ffe::1 are subsequently tunneled > between the mobile > > > > node and the home agent, because the home agent defends the > > > > IPv6 home address. The home agent does not defend > the IPv4 home > > > > address (172.1.1.1), so IPv4 packets pass directly > to and from > > > > the mobile node. > > > > > > > > (b) The mobile node moves to an IPv4-only foreign network, > > > > assume with 200.1.1.0/24 as prefix. First a BU/BA > > > exchange is made. > > > > In the BU, the mobile node reports its IPv6 home address > > > (3ffe::1), > > > > its IPv4 home address (172.1.1.1), and its IPv4 > care-of address > > > > (assume it is 200.1.1.5), specifying some non-zero > > lifetime. As a > > > > consequence the home agent and the mobile node move the IKE > > > > session, now between the 172.1.1.2 and 200.1.1.5 addresses. > > > > Then the home agent adds the IPv4 home address (172.1.1.1) > > > > in its binding cache and starts defending the IPv4 > home address. > > > > > > > > (c) The mobile node returns home. In the BU, the mobile node > > > > sends the IPv6 home address (3ffe::1) and the IPv4 > home address > > > > (172.1.1.1) with a zero lifetime. Thus the home agent > > clears the > > > > entries in the binding cache. According to RFC > 4877, when the > > > > binding cache is cleared, the IKE end points are > moved, and must > > > > have 3ffe::1 and 3ffe::2 as end points. Shortly after, > > a new BU is > > > > sent, where the IPv6 home address (3ffe::1) is registered > > > and using > > > > 172.1.1.1 as care-of address specifying some > non-zero lifetime. > > > > The IKE session is moved again so it is now between > > 172.1.1.2 and > > > > 172.1.1.1. > > > > > > > > But why send two BUs? A small change to the IPv4 > home address > > > > option could be made in order to indicate the IPv4 > home address > > > > should no longer be defended. One way is to reserve a > > bit in the > > > > IPv4 home address option indicating the IPv4 address should > > > > have lifetime zero, ie be deleted. Another way would be > > > > to add an additional two bytes to the IPv4 home > address option > > > > reporting a lifetime. Such a lifetime should then be > > > > override the lifetime found in the BU header for the IPv4 > > > > address only. In either case, the home agent would > first stop > > > > defending the 172.1.1.1 address, then move the IKE > session once. > > > > > > > > In the sketch above it was assumed the mobile node had > > some non-IP > > > > way of being assigned its IPv4 home address when on the > > IPv4-only > > > > home network, particularly important when returning > > home, because > > > > in that case the home agent defends that address so > DHCP cannot > > > > be used to hand out that same address. It is also > assumed the > > > > home agent in some way connects (IPv6-in-IPv4 tunnel) to > > > > the IPv6 internet. We have not identified any problems with > > > > the destination cache maintained by neighbor discovery as the > > > > 3ffe::2 is expected assigned to a loopback > interface. Further, > > > > no neighbor solicitations will ever be sent asking > for 3ffe::1. > > > > Because the loopback is reachable, the mobile node can also > > > > visit IPv6 enabled foreign network. > > > > > > > > Karen > > > > Christian > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 02 22:27:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ictv1-00005H-NB; Tue, 02 Oct 2007 22:24:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ictuz-0008VU-VH for mip6@ietf.org; Tue, 02 Oct 2007 22:24:58 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ictuu-0007v7-9G for mip6@ietf.org; Tue, 02 Oct 2007 22:24:52 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 88DA5A81E9 for ; Tue, 2 Oct 2007 22:24:48 -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 18264-02 for ; Tue, 2 Oct 2007 22:24:46 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 2 Oct 2007 22:24:46 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Oct 2007 22:24:36 -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: [Mip6] Comments for draft-ietf-mip6-rfc4285bis-00.txt Date: Tue, 2 Oct 2007 22:24:46 -0400 Message-ID: <4D35478224365146822AE9E3AD4A26663FC543@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Comments for draft-ietf-mip6-rfc4285bis-00.txt Thread-Index: Acf+soSwz4JGiI4XRo28tnSCeU+IDwGseqhw From: "Chowdhury, Kuntal" To: "Hannes Tschofenig" X-OriginalArrivalTime: 03 Oct 2007 02:24:36.0775 (UTC) FILETIME=[8B0C0B70:01C80564] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hannes, Thanks for your valuable comments. We will include your suggested texts in the I-D. BR, Kuntal > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, September 24, 2007 8:55 AM > To: Chowdhury, Kuntal > Cc: Mobile IPv6 Mailing List > Subject: Re: [Mip6] Comments for draft-ietf-mip6-rfc4285bis-00.txt >=20 > Hi Kuntal, >=20 > I wanted to be a bit more specific about the feedback regarding the > timestamp-based replay protection technique. I believe the following two > paragraphs should make everything clear. >=20 > In Section 5.2 of > http://tools.ietf.org/html/draft-ietf-mip6-rfc4285bis-00 you could write: >=20 > " >=20 > When the MN-AAA authentication mobility option is present in a BU the > mobility message replay protection in section 6 option SHOULD be used. >=20 > " >=20 >=20 > At the end of Section 6 of > http://tools.ietf.org/html/draft-ietf-mip6-rfc4285bis-00 you should > indicate: >=20 > " >=20 > If the Mobile Node receives a Binding Acknowledgement with the code > MIPV6-ID-MISMATCH, which is a response to a BU containing a MN-AAA > authentication mobility option, and the authentication of the BA > succeeds, the Mobile Node MUST resend the BU including the MN-AAA > authentication mobility option, using the updated timestamp value. >=20 > " >=20 > The text about resynchronization of the timestamp between the MN <-> HA > is already in the draft but the statement regarding the the MN-AAA usage > is missing. > This paragraph would provide that statement. >=20 > Ciao > Hannes >=20 > Hannes Tschofenig wrote: > > Hi Kuntal, > > > > Chowdhury, Kuntal wrote: > >> Hi Hannes, > >> > >> Sorry for the late follow-up on this. Please see inline... > >> > >> -Kuntal > >> > >> > >> > >>> -----Original Message----- > >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>> Sent: Saturday, September 01, 2007 3:13 PM > >>> To: Mobile IPv6 Mailing List > >>> Subject: [Mip6] Comments for draft-ietf-mip6-rfc4285bis-00.txt > >>> > >>> Re-reading draft-ietf-mip6-rfc4285bis-00.txt I noticed a couple of > >>> > >> things. > >> > >>> * The references are out of date > >>> > >>> Example: draft-ietf-mip6-mn-ident-option-03.txt become RFC 4283 in > >>> > >> 2005. > >> [KC>] Fixed. > >> > >> > >>> * RFC 3344 is a normative reference without a reason > >>> > >>> > >> [KC>] will be moved under informative references. > >> > >> > >>> * More RFC 2119 language is needed. When someone reads through the > >>> > >> text > >> > >>> then the places are pretty obvious. I could list them, if someone > >>> > >> cares. > >> [KC>] We will add RFC 2119 in the reference list. The Terminology > >> section already points to RCC 2119. What else is needed? > >> > >> > > I noticed that a couple of MUST, SHOULD and MAYs in the document need > > to be capitalized. > > I can spot them for you, if you want. > > > >>> * Replay Protection: There is no mandatory to implement replay > >>> protection technique. To me it seems that only the timestamp based > >>> replay protection really seems to be usable when used in combination > >>> with the AAA infrastructure. > >>> > >>> > >> [KC>] I am not sure why so. It is true that only timestamp based relay > >> protection scheme is specified in the current version of the I-D, but > >> that should not necessitate use of an AAA infrastructure! > > There are two separate issues regarding replay protection here. First, > > there is the replay protection between the HA and the MN and then > > there is replay protection also needed between MN and AAAS. For the > > latter you have to mandate the usage of timestamp based replay > > protection and resynchronization in order to get a working system. So > > far, only timestamp based replay protection is described for the > > interaction between MN to AAAs (unless you consider the extensions in > > draft-devarapalli-mip6-authprotocol-bootstrap-02.txt). > > > > I can provide the text for you to make it clearer for you what I > > actually mean. > > > > > >> Anyway, please refer to Appendix A (Rationale for mobility message > >> replay protection option) for further details on the reason for > >> selecting timestamp based replay protection mode. > >> > >> > > The appendix is fine with respect to the replay protection between MN > > and HA. > > > > Ciao > > Hannes > > > >>> Ciao > >>> Hannes > >>> > >>> > >>> _______________________________________________ > >>> Mip6 mailing list > >>> Mip6@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mip6 > >>> > >> > >> > >> "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." > >> > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mext-bounces@ietf.org Wed Oct 03 05:00:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id01U-0006pR-2V; Wed, 03 Oct 2007 04:56:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id01S-0006GI-BK for mext@ietf.org; Wed, 03 Oct 2007 04:56:02 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id01J-0000tC-KY for mext@ietf.org; Wed, 03 Oct 2007 04:55:53 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 10:55:52 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Oct 2007 10:55:49 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222D2D9@SEHAN021MB.tcad.telia.se> In-Reply-To: <47021046.1070100@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-korhonen-mip6-service-03.txt Thread-Index: AcgE1zbB1oqQt1HZTaenxFpveTI5AQAwq6vg References: <4700A05C.3070905@piuha.net> <59D7431DE2527D4CB0F1EFEDA5683ED30222D260@SEHAN021MB.tcad.telia.se> <47021046.1070100@piuha.net> From: To: X-OriginalArrivalTime: 03 Oct 2007 08:55:52.0569 (UTC) FILETIME=[33B5EE90:01C8059B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org Subject: [MEXT] RE: AD review of draft-korhonen-mip6-service-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > >> Are there existing APN conventions in GPRS networks that=20 > are based on=20 > >> domain names? Or are you inventing a convention here? > > > > APNs are have two parts: the Netword Identified (NI) and=20 > the Operator=20 > > Identifier (OI). The NI is mandatory e.g. plain "voip" in the above=20 > > example and the optional OI is the domain name e.g. "example.com". > > Of cource GPRS APN domain name convention are more akward=20 > than in the=20 > > above example. So no inventing a convention here. > > =20 > >> Another alternative might be to just say "UTF-8" and that=20 > the value=20 > >> is up to a local policy. And unique within a particular home agent. > > > > Hmmm.. could be ok. Need to think about this. > > =20 >=20 > It is still unclear to me what the best choice is. For a wider applicability, not just for one specific scenario, I think UTF-8 could be the way to go. Just like you proposed earlier. If some SDO or alikes need more specific definition they can do it within their own architecture specifications. Cheers,=09 jouni >=20 > Jari >=20 >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Oct 03 05:18:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0M2-0008TV-OU; Wed, 03 Oct 2007 05:17:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0M0-0008Rq-Ki for mext@ietf.org; Wed, 03 Oct 2007 05:17:17 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id0Lv-0005VU-7Q for mext@ietf.org; Wed, 03 Oct 2007 05:17:16 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 360A619866A; Wed, 3 Oct 2007 12:17:00 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id EA620198658; Wed, 3 Oct 2007 12:16:59 +0300 (EEST) Message-ID: <47035E0C.6000500@piuha.net> Date: Wed, 03 Oct 2007 12:17:00 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com References: <4700A05C.3070905@piuha.net> <59D7431DE2527D4CB0F1EFEDA5683ED30222D260@SEHAN021MB.tcad.telia.se> <47021046.1070100@piuha.net> <59D7431DE2527D4CB0F1EFEDA5683ED30222D2D9@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30222D2D9@SEHAN021MB.tcad.telia.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org Subject: [MEXT] Re: AD review of draft-korhonen-mip6-service-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Jouni, > For a wider applicability, not just for one specific scenario, I > think UTF-8 could be the way to go. Just like you proposed earlier. > If some SDO or alikes need more specific definition they can do it > within their own architecture specifications. > > That would work for me. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mip6-bounces@ietf.org Fri Oct 05 13:17:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdqmB-0004Pn-45; Fri, 05 Oct 2007 13:15:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idqm7-0004JJ-5y; Fri, 05 Oct 2007 13:15:43 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Idqm6-00048s-Pl; Fri, 05 Oct 2007 13:15:43 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 65A19175D7; Fri, 5 Oct 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IdqlR-0007MV-U2; Fri, 05 Oct 2007 13:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 05 Oct 2007 13:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-rfc4285bis-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-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 Mobility for IPv6 Working Group of the IETF. Title : Authentication Protocol for Mobile IPv6 Author(s) : A. Patel, et al. Filename : draft-ietf-mip6-rfc4285bis-01.txt Pages : 24 Date : 2007-10-5 IPsec is specified as the means of securing signaling messages between the Mobile Node and Home agent for Mobile IPv6 (MIPv6). MIPv6 signalling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home Agent. This document proposes an alternate method for securing MIPv6 signaling messages between a Mobile Nodes and Home Agents. The alternate method defined here conists of a MIPv6-specific authentication option that can be added to MIPv6 signalling messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-rfc4285bis-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-mip6-rfc4285bis-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-mip6-rfc4285bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-5121018.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-rfc4285bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-rfc4285bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-5121018.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Fri Oct 05 14:19:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idrjq-0001LR-LZ; Fri, 05 Oct 2007 14:17:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idrjo-0001Ka-AJ for mip6@ietf.org; Fri, 05 Oct 2007 14:17:24 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Idrjn-0006xV-Mx for mip6@ietf.org; Fri, 05 Oct 2007 14:17:24 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B039219866A for ; Fri, 5 Oct 2007 21:17:22 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6796619865D for ; Fri, 5 Oct 2007 21:17:22 +0300 (EEST) Message-ID: <47067FB3.4050904@piuha.net> Date: Fri, 05 Oct 2007 21:17:23 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Mobile IPv6 Mailing List References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 2.2 (++) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Mip6] FW: Posting of IPR Disclosure on RFC 3775 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org This was received today, FYI. Note that the claim is that there is a patent *application*. I wonder where such an application has been filed and how long an application can stay as an application -- the RFC is many years old, and the drafts leading to it even older. > Dear Charles Perkins, Dave Johnson, Jari Arkko: > > An IPR disclosure that pertains to your RFC entitled "Mobility Support in IPv6" > (RFC3775) was submitted to the IETF Secretariat on 2007-09-28 and has been > posted on the "IETF Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the IPR > disclosure is "Nortel Networks Statement about IPR claimed in RFC 3775." > > The IETF Secretariat > > Nortel Networks Statement about IPR claimed in RFC 3775 > Date:28 September 2007 > From: Michelle Lee > > Dear Sir, > > Nortel Networks Limited has an unpublished patent application that may > be relevant to at least a portion of this proposed IETF RFC 3775 if > implemented: > > Title: Mobility Support in IPv6 > Tag: RFC 3775 http://www.ietf.org/rfc/rfc3775.txt?number=3775 > > In the event that the technology implemented is required to comply with > RFC 3775 and such patent application of Nortel issues which contain > claim(s) that are necessary to practice such resulting adopted IETF > Standard, Nortel Networks will make available licenses under fair, > reasonable, reciprocal, and non-discriminatory terms under such > necessary patent claims it owns for full compliance with such resulting > IETF Standard. > > My contact information is set out below. > > Kind Regards, > Michelle Lee > IP Counsel > Nortel Networks Limited > 5-195 The West Mall > Toronto, Ontario Canada M9C 5K1 > Fax: 905-863-1986 > mleelaw@nortel.com _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 05 14:41:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ids5n-0007Is-UA; Fri, 05 Oct 2007 14:40:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ids5j-0006uM-BA; Fri, 05 Oct 2007 14:40:03 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ids5i-0007lR-VW; Fri, 05 Oct 2007 14:40:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id C28F82AC64; Fri, 5 Oct 2007 18:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ids5h-0001jf-N6; Fri, 05 Oct 2007 14:40:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 05 Oct 2007 14:40:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mip6@ietf.org Subject: [Mip6] I-D Action:draft-ietf-mip6-vsm-03.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-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 Mobility for IPv6 Working Group of the IETF. Title : Mobile IPv6 Vendor Specific Option Author(s) : V. Devarapalli, et al. Filename : draft-ietf-mip6-vsm-03.txt Pages : 5 Date : 2007-10-05 There is a need for vendor specific extensions to Mobility Header messages so that Mobile IPv6 vendors are able to extend the protocol for research or deployment purposes. This document defines a new vendor specific mobility option. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-vsm-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-vsm-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-vsm-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-05143305.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-vsm-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-vsm-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-05143305.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Fri Oct 05 15:01:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdsP8-0006QY-KS; Fri, 05 Oct 2007 15:00:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdsP5-0006Ej-AB; Fri, 05 Oct 2007 15:00:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdsP4-0000TK-0D; Fri, 05 Oct 2007 15:00:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id F0014329D9; Fri, 5 Oct 2007 19:00:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IdsP3-0004EP-Rn; Fri, 05 Oct 2007 15:00:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 05 Oct 2007 15:00:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: mip6@ietf.org Subject: [Mip6] I-D Action:draft-ietf-mip6-experimental-messages-03.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-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 Mobility for IPv6 Working Group of the IETF. Title : Mobile IPv6 Experimental Messages Author(s) : V. Devarapalli Filename : draft-ietf-mip6-experimental-messages-03.txt Pages : 6 Date : 2007-10-05 This document defines a new experimental Mobility Header message and a mobility option that can be used for experimental extensions to the Mobile IPv6 protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-experimental-messages-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-experimental-messages-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-experimental-messages-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-05145200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-experimental-messages-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-experimental-messages-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-05145200.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Fri Oct 05 16:31:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdtmG-0003nn-Ch; Fri, 05 Oct 2007 16:28:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdtmE-0003lh-3r; Fri, 05 Oct 2007 16:28:02 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdtmD-0003H9-Ee; Fri, 05 Oct 2007 16:28:01 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l95KRPZJ018268; Fri, 5 Oct 2007 23:27:37 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Oct 2007 23:26:54 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Oct 2007 15:26:49 -0500 Received: from 172.19.244.153 ([172.19.244.153]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 5 Oct 2007 20:26:49 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 05 Oct 2007 15:27:02 -0500 Subject: Re: [Mip6] DSMIPv6 current status From: Basavaraj Patil To: ext Hesham Soliman , , Message-ID: Thread-Topic: [Mip6] DSMIPv6 current status Thread-Index: AcgBgqIJjZqP202ZRrGw4qdcNw30CQGC3Q23 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Oct 2007 20:26:49.0851 (UTC) FILETIME=[0F00A4B0:01C8078E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham, Thanks for the update. Can we expect a revised I-D with all the LC comments addressed sometime in the next week or so? Assuming we can get the IKE issue dealt with as well. -Raj On 9/27/07 10:49 PM, "ext Hesham Soliman" wrote: > Folks, > > Just a quick progress on the draft. There is currently one issue being > discussed, which is the use of IKE in DSMIPv6. This was raised by Christian > last week. Other than that, all the comments are pretty straight forward. > > I'll send an update with one or more proposals soon. > > Hesham > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 05 16:35:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdtsF-0007fc-Ss; Fri, 05 Oct 2007 16:34:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdtsE-0007ez-Ro for mip6@ietf.org; Fri, 05 Oct 2007 16:34:14 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdtsE-0003Tj-8w for mip6@ietf.org; Fri, 05 Oct 2007 16:34:14 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l95KXm7p005903; Fri, 5 Oct 2007 23:34:12 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Oct 2007 23:33:59 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Oct 2007 15:33:55 -0500 Received: from 172.19.244.153 ([172.19.244.153]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 5 Oct 2007 20:33:55 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 05 Oct 2007 15:34:08 -0500 Subject: Re: [Mip6] rfc4285bis From: Basavaraj Patil To: Alper Yegin , "'Mobile IPv6 Mailing List'" Message-ID: Thread-Topic: [Mip6] rfc4285bis Thread-Index: AcgA7zmKlUiglfTrSBOJaKribuo2cwGn9qeh In-Reply-To: <0MKpCa-1IaqOV2tiX-0007UO@mrelay.perfora.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Oct 2007 20:33:55.0643 (UTC) FILETIME=[0CCB58B0:01C8078F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Primary scope of 4285bis is to fix the key length problem. If there are other issues in the I-D as well, we could address them as well. When you say improvements, I guess we need to see what kind of improvements you are suggesting and whether it implies new functionality or features to the I-D. Please clarify. -Basavaraj On 9/27/07 5:14 AM, "ext Alper Yegin" wrote: > What is the scope of RFC4285bis? Is it limited to fixing the key length and > some editorials, or other fixes and improvements are eligible for > consideration? > > Alper > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 05 17:54:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idv6S-0001vX-0u; Fri, 05 Oct 2007 17:53:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idv6Q-0001vR-Ne for mip6@ietf.org; Fri, 05 Oct 2007 17:52:58 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idv6K-000620-HN for mip6@ietf.org; Fri, 05 Oct 2007 17:52:58 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Oct 2007 14:52:51 -0700 Message-ID: <4706B233.3000908@azairenet.com> Date: Fri, 05 Oct 2007 14:52:51 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mip6] FW: Posting of IPR Disclosure on RFC 3775 References: <47067FB3.4050904@piuha.net> In-Reply-To: <47067FB3.4050904@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2007 21:52:51.0869 (UTC) FILETIME=[13CE14D0:01C8079A] X-Spam-Score: 2.2 (++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Jari Arkko wrote: > This was received today, FYI. Note that the claim is > that there is a patent *application*. I wonder where > such an application has been filed and how long > an application can stay as an application -- the RFC > is many years old, and the drafts leading to it even > older. This is kind of odd. Its been more than three years since RFC 3775 has been published. How can there be an "unpublished patent" application? Most patents are "published" by USPTO in 18 months. See the actual disclosure. http://www1.ietf.org/ietf/IPR/nortel-ipr-rfc-3775.txt It says it is an "unpublished patent application". Or did they mean to say "not yet granted"? Vijay > >> Dear Charles Perkins, Dave Johnson, Jari Arkko: >> >> An IPR disclosure that pertains to your RFC entitled "Mobility Support in IPv6" >> (RFC3775) was submitted to the IETF Secretariat on 2007-09-28 and has been >> posted on the "IETF Page of Intellectual Property Rights Disclosures" >> (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the IPR >> disclosure is "Nortel Networks Statement about IPR claimed in RFC 3775." >> >> The IETF Secretariat >> > >> Nortel Networks Statement about IPR claimed in RFC 3775 >> Date:28 September 2007 >> From: Michelle Lee >> >> Dear Sir, >> >> Nortel Networks Limited has an unpublished patent application that may >> be relevant to at least a portion of this proposed IETF RFC 3775 if >> implemented: >> >> Title: Mobility Support in IPv6 >> Tag: RFC 3775 http://www.ietf.org/rfc/rfc3775.txt?number=3775 >> >> In the event that the technology implemented is required to comply with >> RFC 3775 and such patent application of Nortel issues which contain >> claim(s) that are necessary to practice such resulting adopted IETF >> Standard, Nortel Networks will make available licenses under fair, >> reasonable, reciprocal, and non-discriminatory terms under such >> necessary patent claims it owns for full compliance with such resulting >> IETF Standard. >> >> My contact information is set out below. >> >> Kind Regards, >> Michelle Lee >> IP Counsel >> Nortel Networks Limited >> 5-195 The West Mall >> Toronto, Ontario Canada M9C 5K1 >> Fax: 905-863-1986 >> mleelaw@nortel.com > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 05 18:11:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdvLY-0004EV-PX; Fri, 05 Oct 2007 18:08:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdvLX-0004EA-7v for mip6@ietf.org; Fri, 05 Oct 2007 18:08:35 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdvLW-0006Xv-18 for mip6@ietf.org; Fri, 05 Oct 2007 18:08:35 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6931019866A; Sat, 6 Oct 2007 01:08:33 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1D94F19865D; Sat, 6 Oct 2007 01:08:33 +0300 (EEST) Message-ID: <4706B5E2.30901@piuha.net> Date: Sat, 06 Oct 2007 01:08:34 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] FW: Posting of IPR Disclosure on RFC 3775 References: <47067FB3.4050904@piuha.net> <4706B233.3000908@azairenet.com> In-Reply-To: <4706B233.3000908@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay, > This is kind of odd. Its been more than three years since RFC 3775 has > been published. How can there be an "unpublished patent" application? > Most patents are "published" by USPTO in 18 months. See the actual > disclosure. > > http://www1.ietf.org/ietf/IPR/nortel-ipr-rfc-3775.txt > > It says it is an "unpublished patent application". Or did they mean to > say "not yet granted"? Its hard to tell. I'm not a lawyer, but the practices are different in different countries about publication. We don't know where this patent application might be in. Granting process presumably can take varying amount of time. Still, even for a granting delay this seems long. Or maybe they meant to say "patent that we do not wish to disclose at this time". As usual, participants in the WG should draw their own conclusions about IPR claims or lack thereof. But if people come across more public information about this particular case, feel free to let others in the WG know too. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 05 22:15:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idz9o-0000PU-In; Fri, 05 Oct 2007 22:12:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idz9m-0000DW-Bu; Fri, 05 Oct 2007 22:12:42 -0400 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idz9c-0005Qc-11; Fri, 05 Oct 2007 22:12:38 -0400 Received: from oaamta06ps.mx.bigpond.com ([124.190.106.219]) by omta01ps.mx.bigpond.com with ESMTP id <20071006021148.ECKB13408.omta01ps.mx.bigpond.com@oaamta06ps.mx.bigpond.com>; Sat, 6 Oct 2007 02:11:48 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta06ps.mx.bigpond.com with ESMTP id <20071006021143.KQKZ12669.oaamta06ps.mx.bigpond.com@PC20005>; Sat, 6 Oct 2007 02:11:43 +0000 From: "Hesham Soliman" To: "'Basavaraj Patil'" , , Subject: RE: [Mip6] DSMIPv6 current status Date: Sat, 6 Oct 2007 12:11:35 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgBgqIJjZqP202ZRrGw4qdcNw30CQGC3Q23AAwAkmA= In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, Yes, all other comments are included. It would be great if we can handle the IKE issue soon, I'm trying to come up with solutions, I encourage others to do the same. Hesham > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > Sent: Saturday, October 06, 2007 6:27 AM > To: ext Hesham Soliman; mip6@ietf.org; nemo@ietf.org > Subject: Re: [Mip6] DSMIPv6 current status > > > Hi Hesham, > > Thanks for the update. Can we expect a revised I-D with all > the LC comments > addressed sometime in the next week or so? Assuming we can > get the IKE issue > dealt with as well. > > -Raj > > > On 9/27/07 10:49 PM, "ext Hesham Soliman" > wrote: > > > Folks, > > > > Just a quick progress on the draft. There is currently one > issue being > > discussed, which is the use of IKE in DSMIPv6. This was > raised by Christian > > last week. Other than that, all the comments are pretty > straight forward. > > > > I'll send an update with one or more proposals soon. > > > > Hesham > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 10 03:54:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfWMG-0006jD-2K; Wed, 10 Oct 2007 03:51:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfWMD-0006ge-Ps for mip6@ietf.org; Wed, 10 Oct 2007 03:51:53 -0400 Received: from datnt07.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfWMB-0006TB-Te for mip6@ietf.org; Wed, 10 Oct 2007 03:51:53 -0400 X-AuditID: c26e2f18-00001fb000001bdc-53-470c847f229d Received: from camaro.eu.tieto.com ([192.176.143.43]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 10:51:27 +0300 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 09:51:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 10 Oct 2007 09:51:44 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DSMIP accommodation of split of v4 and v6 home link ? Thread-Index: AcgLEmbOttYXMIEITAOVofU56smYXA== From: To: , , X-OriginalArrivalTime: 10 Oct 2007 07:51:45.0171 (UTC) FILETIME=[675FD630:01C80B12] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: 6cf0511842947ba7c2eb8ab72c43e5b6 Cc: Subject: [Mip6] DSMIP accommodation of split of v4 and v6 home link ? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1867274397==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1867274397== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80B12.676A5D8E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80B12.676A5D8E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hesham, All=20 With the aim to clarify better.=20 In the 3GPP LTE/SAE network, under final specification,=20 mobility of the user equipment (UE) is realized using=20 different IETF mechanisms: MIP, DSMIP, ProxyMIP, and=20 IPv4-ProxyMIP, all centered on a home agent (HA) functionality=20 and local mobility anchor (LMA) functionality in the packet data=20 network gateway (PDN GW), and mobile access gateway functionality=20 in the serving gateway (Serving GW), and mobile node functionality=20 in the UE. The UE can be attached to the 3GPP in the following ways.=20 * UE can have so-called 3GPP access, and this is found in two=20 variants:=20 * either the Serving GW hosts the mobile access gateway=20 functionality and the PDN GW hosts the corresponding=20 local mobility anchor functionality,=20 * or the Serving GW realizes ordinary GTP tunnels which are=20 terminated in the PDN GW and the PDN GW hosts corresponding=20 home agent functionality.=20 The UE does not know which variant is used, as it only sees a=20 PDP context. This network is denoted the AA network.=20 * UE can have non-3GPP access with network-based mobility. In=20 this instance the mobile access gateway functionality is=20 hosted in either the access gateway of the non-3GPP access network=20 or in the evolved packet data gateway (ePDG), while the corresponding local=20 mobility anchor functionality is hosted in the PDN GW. =20 This network is denoted the BB network.=20 * UE can have non-3GPP access with host-based mobility, in which=20 case the mobile node uses DSMIP while the PDN GW hosts the=20 corresponding home agent functionality. This network is=20 denoted the CC network.=20 >From a IP mobility perspective there is not much difference in between AA and BB.=20 The notably difference in between the networks are=20 * the possible usage of GTP in AA=20 * potential difference in IPv6 and IPv4 access support=20 In both networks, then from a IP mobility perspective, all user layer IP access addresses provided to=20 the UE are home addresses and the address allocation is administratively controlled by the=20 PDN GW which will ensure that the access addresses given out are the same on the two networks.=20 As addresses are carried over in between the AA and all BB networks, the UE=20 IPv6 home link spreads over potentially multiple BB networks and one AA network.=20 Likewise for the IPv4 Home link.=20 The CC network is always, IP mobility wise, a foreign network.=20 The peculiar situation that we would like to support is the situation,=20 presumably primarily a transition period, where the AA network=20 or the BB network (or both) does not support IPv6 access addresses.=20 But where still:=20 * the UE uses an IPv6 HoA for DSMIPv6 signaling (obviously, this is a MUST)=20 * the UE may roam in between AA and BB using an IPv4 HoA=20 * the UE may use DSMIPv6 to roam in and out of CC=20 * the UE may use DSMIPv6 to roam in between the AA network and BB networks with different=20 IP access (plus/minus IPv6) capabilities.=20 If neither of the networks (AA and BB) supports IPv6 access, then=20 the UE will never be at home IPv6 wise.=20 Conceptually the AA and the BB networks run network based mobility on IPv4 access=20 but when IPv6 access cannot be provided, then=20 the idea is to use DSMIPv6 in parallel to manage IPv6 mobility.=20 This represents a logical split of the IPv4 and the IPv6 home link.=20 Lack of deployment of IPv6 is one motivation for offering only=20 an IPv4 PDP context in the 3GPP access (AA network). Another motivation is=20 to limit the use of radio resources. Thus, even if the network=20 in general is IPv6 capable, full capability may only be offered=20 via non-3GPP access (BB or CC) with sufficient bandwidth.=20 Based on this overall scenario description, and looking into DSMIP and its interaction with=20 PMIPv6 and IPv4-PMIPv6, the functionality which we are after and=20 which we cannot find explicitly described anywhere, is to allow DSMIPv6 to operate more=20 independently on the v6HoA and v4HoA cache entries. Specifically so=20 that a UE may use DSMIPv6 to signal=20 * deregistration of an v4HoA registration=20 * registration(update) of v6HoA DSMIPv6 registration to care-of-address equal v4Hoa=20 in one and the same DSMIPv6 BU.=20 To go more into the details with some examples:=20 Example scenario 1:=20 An UE boots up in the CC network, then moves to the BB network.=20 We want to have IPv6 connectivity to the UE, because the PDN GW is connected to the=20 IPv6 Internet as well as in order merely to use DSMIPv6 signaling,=20 but we assume the BB and CC networks have IPv4 access connectivity only. This scenario also covers the case where the network mobility in=20 network AA is controlled using PMIP.=20 First, the UE boots up in the CC network, an IPv4-only foreign network.=20 During this booting, the UE is given an IPv4 care-of address (v4CoA),=20 later it is provided with IPv4 and IPv6 home addresses (v6HoA, v4HoA) via=20 a combination of an IKEv2 exchange to HA (v6HoA allocation) and a request for v4HoA=20 sent in a DSMIPv6 BU to HA, registrating the (v6HoA, v4CoA) relationship.=20 The binding cache of the home agent will have the following two entries=20 home address of node visited address of node=20 -----------------------------------------------=20 v4HoA v4CoA=20 v6HoA v4CoA=20 Second, the UE moves to the BB network, an IPv4-only network=20 with proxy mobility. Moving there, the mobile node is=20 provided its IPv4 home address (v4HoA as above) as care-of-address, and the=20 mobile access gateway function sends a proxy binding update=20 which rewrites the first line of the binding cache giving the=20 mobile access gateway's IPv4 address (v4PCoA) as the visited=20 address. (The MAG address could also in theory be an IPv6 address (v6PCoa),=20 but this distinction is not important here).=20 Now the cache looks as follows:=20 home address of node visited address of node=20 -----------------------------------------------=20 v4HoA v4PCoA marked as PMIPv6/IPv4-PMIPv6 controlled=20 v6HoA "old" v4CoA=20 Or would PMIPv6 also manipulate the v6HoA entry, and if so, what would it do - ?=20 Anyway, the UE knows nothing about PMIPv6/IPv4-PMIPv6 and would=20 like to send a BU de-registrating the v4HoA binding and refreshing the v6HoA binding=20 to use the v4HoA as IPv4 care-of-address.=20 With the following desired result.=20 home address of node visited address of node=20 -----------------------------------------------=20 v4HoA v4PCoA marked as PMIPv6/IPv4-PMIPv6 controlled=20 v6HoA v4HoA (DSMIPv6 controlled)=20 The issues is how this should be done. Proposed options are described further below.=20 Please note that correctly manipulating the v6HoA binding cache entry is required=20 already alone to allow the HA to return the BACK.=20 This will result in two tunnels for IPv6 traffic from HA to UE, the outer tunnel=20 from HA to MAG (v4PCoa) and the inner IPv6 in IPv4 tunnel to v4HoA and as both tunnels originates in the HA=20 this will require two consecutive look ups in the binding cache for Ivy traffic. But well, that's how thing goes.=20 Example scenario 2:=20 An UE boots up in the CC network, then moves to the AA network where host mobility is=20 not done using PMIP (instead it is done using GTP). As above we want to have IPv6=20 connectivity to the UE, because the PDN GW is connected to the=20 IPv6 Internet as well as in order merely to use DSMIPv6 signaling,=20 but we assume the AA and the CC network have IPv4 access=20 connectivity only.=20 The address allocation and binding procedures in the CC is as in Example 1.=20 With resulting Binding cache entries.=20 home address of node visited address of node=20 -----------------------------------------------=20 v4HoA v4CoA=20 v6HoA v4CoA=20 Second, the UE moves to the AA network, an IPv4-only network.=20 Moving there, the mobile node is=20 provided its IPv4 home address (v4HoA as above) as care-of-address.=20 But without the involvement of PMIPv6 and the cache entries of the HA=20 remains unaltered until the UE sends a DSMIPv6 BU. Again what the UE would like=20 is to send a BU deleting the v4HoA binding and refreshing the v6HoA binding=20 to use the v4HoA as IPv4 care-of-address.=20 With the following desired result.=20 home address of node visited address of node=20 -----------------------------------------------=20 v6HoA v4HoA =20 Again the issues is how this should be done. Proposed options are described further below.=20 Also please note that again, correctly manipulating the v6HoA binding cache entry is required=20 already alone to allow the HA to return the BACK.=20 Proposed solution in DSMIPv6:=20 The UE could send a binding update with some non-zero lifetime, reporting v6HoA=20 to be found at v4HoA (in IPv4 care-of-address option), and additionally including v4HoA (in home address option)=20 The home agent should conclude that the equality of the two IPv4 addresses means=20 removal of the v4HoA cache entry.=20 This does not imply changing any DSMIPv6 protocol messages, but it still deserves some text to say how the HA=20 should handle the situation when the v4HoA is the same as the CoA.=20 Another approach is to be explicit and set a=20 bit or a lifetime attached to the IPv4 address in the IPv4 Home Address Option.=20 Being explicit also indicates, that should a packet have=20 the home address and the visited address equal, that=20 packet is malformed.=20 It is of course worth thinking about whether this scenario=20 is relevant for the IETF to consider, but for 3GPP networks=20 it will allow gradually introduction of IPv6 without modifying the protocols.=20 Christian/Karen ------_=_NextPart_001_01C80B12.676A5D8E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DSMIP accommodation of split of v4 and v6 home link ?

Hi Hesham, All

With the aim to clarify = better.

In the 3GPP LTE/SAE network, = under final specification,
 mobility of the user = equipment (UE) is realized using
different IETF mechanisms: = MIP, DSMIP, ProxyMIP, and
IPv4-ProxyMIP, all centered = on a home agent (HA) functionality
and local mobility anchor = (LMA) functionality in the packet data
network gateway (PDN GW), = and mobile access gateway functionality
in the serving gateway = (Serving GW), and mobile node functionality
in the UE.  The UE can = be attached to the 3GPP in the following ways.

 * UE can have so-called = 3GPP access, and this is found in two
   variants: =
    * either = the Serving GW hosts the mobile access gateway
      functionality and the PDN GW hosts = the corresponding
      local mobility anchor = functionality,
    * or the = Serving GW realizes ordinary GTP tunnels which are
      terminated in the PDN GW and the = PDN GW hosts corresponding
      home agent functionality.
   The UE does not = know which variant is used, as it only sees a
   PDP = context.  This network is denoted the AA network.

 * UE can have non-3GPP = access with network-based mobility.  In
   this instance = the mobile access gateway functionality is
   hosted in = either the access gateway of the non-3GPP access network
   or in the = evolved packet data gateway (ePDG), while the corresponding local =
   mobility anchor = functionality is hosted in the PDN GW. 
   This network is = denoted the BB network.

 * UE can have non-3GPP = access with host-based mobility, in which
   case the mobile = node uses DSMIP while the PDN GW hosts the
   corresponding = home agent functionality.  This network is
   denoted the CC = network.

From a IP mobility = perspective there is not much difference in between AA and BB.
The notably difference in = between the networks are
* the possible usage of GTP = in AA
* potential difference in = IPv6 and IPv4 access support

In both networks, then from a = IP mobility perspective, all user layer IP access addresses provided to =
the UE are home addresses = and the address allocation is administratively controlled by the
PDN GW which will ensure = that the access addresses given out are the same on the two networks. =

As addresses are carried over = in between the AA and all BB networks, the UE
IPv6 home link spreads over = potentially multiple BB networks and one AA network.
Likewise for the IPv4 Home = link.

The CC network is always, IP = mobility wise, a foreign network.

The peculiar situation that = we would like to support is the situation,
presumably primarily a = transition period, where the AA network
or the BB network (or both) = does not support IPv6 access addresses.

But where still:
* the UE uses an IPv6 HoA = for DSMIPv6 signaling (obviously, this is a MUST)
* the UE may roam in between = AA and BB using an IPv4 HoA
* the UE may use DSMIPv6 to = roam in and out of CC
* the UE may use DSMIPv6 to = roam in between the AA network and BB networks with different
IP access (plus/minus IPv6) = capabilities.

If neither of the networks = (AA and BB) supports IPv6 access, then
the UE will never be at home = IPv6 wise.

Conceptually the AA and the = BB networks run network based mobility on IPv4 access
but when IPv6 access cannot = be provided, then
the idea is to use DSMIPv6 = in parallel to manage IPv6 mobility.

This represents a logical = split of the IPv4 and the IPv6 home link.

Lack of deployment of IPv6 is = one motivation for offering only
an IPv4 PDP context in the = 3GPP access (AA network).  Another motivation is
to limit the use of radio = resources.  Thus, even if the network
in general is IPv6 capable, = full capability may only be offered
via non-3GPP access (BB or = CC) with sufficient bandwidth.

Based on this overall = scenario description, and looking into DSMIP and its interaction with =
PMIPv6 and IPv4-PMIPv6, the = functionality which we are after and
which we cannot find = explicitly described anywhere, is to allow DSMIPv6 to operate more =
independently on the v6HoA = and v4HoA cache entries. Specifically so
that a UE may use DSMIPv6 to = signal
* deregistration of an v4HoA = registration
* registration(update) of = v6HoA DSMIPv6 registration to care-of-address equal v4Hoa
in one and the same DSMIPv6 = BU.

To go more into the details = with some examples:

Example scenario 1:

An UE boots up in the CC = network, then moves to the BB network.
We want to have IPv6 = connectivity to the UE, because the PDN GW is connected to the
IPv6 Internet as well as in = order merely to use DSMIPv6 signaling,
but we assume the BB and CC = networks have IPv4 access connectivity only.

This scenario also covers the = case where the network mobility in
network AA is controlled = using PMIP.

First, the UE boots up in the = CC network, an IPv4-only foreign network.
During this booting, the UE = is given an IPv4 care-of address (v4CoA),
later it is provided with = IPv4 and IPv6 home addresses (v6HoA, v4HoA) via
a combination of an IKEv2 = exchange to HA (v6HoA allocation) and a request for v4HoA
sent in a DSMIPv6 BU to HA, = registrating the (v6HoA, v4CoA) relationship.
The binding cache of the = home agent will have the following two entries

    home = address of node    visited address of node
    = -----------------------------------------------
         = v4HoA           &n= bsp;        v4CoA
         = v6HoA           &n= bsp;        v4CoA

Second, the UE moves to the = BB network, an IPv4-only network
with proxy mobility.  = Moving there, the mobile node is
provided its IPv4 home = address (v4HoA as above) as care-of-address, and the
mobile access gateway = function sends a proxy binding update
which rewrites the first = line of the binding cache giving the
mobile access gateway's IPv4 = address (v4PCoA) as the visited
address.  (The MAG = address could also in theory be an IPv6 address (v6PCoa),
but this distinction is not = important here).
Now the cache looks as = follows:

home address of = node    visited address of node
    = -----------------------------------------------
         = v4HoA           &n= bsp;        v4PCoA    = marked as PMIPv6/IPv4-PMIPv6 controlled
         = v6HoA           &n= bsp;        "old" v4CoA =

Or would PMIPv6 also = manipulate the v6HoA entry, and if so, what would it do - ?

Anyway, the UE knows nothing = about PMIPv6/IPv4-PMIPv6 and would
like to send a BU = de-registrating the v4HoA binding and refreshing the v6HoA binding =
to use the v4HoA as IPv4 = care-of-address.
With the following desired = result.

    home = address of node    visited address of node
    = -----------------------------------------------
         = v4HoA           &n= bsp;        v4PCoA marked as = PMIPv6/IPv4-PMIPv6 controlled
         = v6HoA           &n= bsp;        v4HoA  (DSMIPv6 = controlled)

The issues is how this should = be done. Proposed options are described further below.
Please note that correctly = manipulating the v6HoA binding cache entry is required
already alone to allow the = HA to return the BACK.

This will result in two = tunnels for IPv6 traffic from HA to UE, the outer tunnel
from HA to MAG (v4PCoa) and = the inner IPv6 in IPv4 tunnel to v4HoA and as both tunnels originates in = the HA
this will require two = consecutive look ups in the binding cache for Ivy traffic. But well, = that's how thing goes.

Example scenario 2:

An UE boots up in the CC = network, then moves to the AA network where host mobility is
not done using PMIP (instead = it is done using GTP). As above we want to have IPv6
connectivity to the UE, = because the PDN GW is connected to the
IPv6 Internet as well as in = order merely to use DSMIPv6 signaling,
but we assume the AA and the = CC network have IPv4 access
connectivity only.

The address allocation and = binding procedures in the CC is as in Example 1.
With resulting Binding cache = entries.

home address of = node    visited address of node
    = -----------------------------------------------
         = v4HoA           &n= bsp;        v4CoA
         = v6HoA           &n= bsp;        v4CoA

Second, the UE moves to the = AA network, an IPv4-only network.
Moving there, the mobile = node is
provided its IPv4 home = address (v4HoA as above) as care-of-address.
But without the involvement = of PMIPv6 and the cache entries of the HA
remains unaltered until the = UE sends a DSMIPv6 BU. Again what the UE would like
is to send a BU deleting the = v4HoA binding and refreshing the v6HoA binding
to use the v4HoA as IPv4 = care-of-address.
With the following desired = result.


    home = address of node    visited address of node
    = -----------------------------------------------
         = v6HoA           &n= bsp;        v4HoA 

Again the issues is how this = should be done. Proposed options are described further below.

Also please note that again, = correctly manipulating the v6HoA binding cache entry is required
already alone to allow the = HA to return the BACK.


Proposed solution in DSMIPv6: =

The UE could send a binding = update with some non-zero lifetime, reporting v6HoA
to be found at v4HoA (in = IPv4 care-of-address option), and additionally including v4HoA (in home = address option)
The home agent should = conclude that the equality of the two IPv4 addresses means
removal of the v4HoA cache = entry.
This does not imply changing = any DSMIPv6 protocol messages, but it still deserves some text to say = how the HA
should handle the situation = when the v4HoA is the same as the CoA.

Another approach is to be = explicit and set a
bit or a lifetime attached = to the IPv4 address in the IPv4 Home Address Option.
Being explicit also = indicates, that should a packet have
the home address and the = visited address equal, that
packet is malformed.

It is of course worth = thinking about whether this scenario
is relevant for the IETF to = consider, but for 3GPP networks
it will allow gradually = introduction of IPv6 without modifying the protocols.

Christian/Karen

------_=_NextPart_001_01C80B12.676A5D8E-- --===============1867274397== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1867274397==-- From mip6-bounces@ietf.org Wed Oct 10 08:53:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifb1z-0003rh-5R; Wed, 10 Oct 2007 08:51:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifb1x-0003ox-1Q for mip6@ietf.org; Wed, 10 Oct 2007 08:51:17 -0400 Received: from mail.um.es ([155.54.212.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifb1v-0002Xj-SM for mip6@ietf.org; Wed, 10 Oct 2007 08:51:16 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 29D1E477B8 for ; Wed, 10 Oct 2007 14:51:15 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at xenon3.telemat.um.es Received: from mail.um.es ([127.0.0.1]) by localhost (xenon3.telemat.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id g8hJy2zv6o8l for ; Wed, 10 Oct 2007 14:51:14 +0200 (CEST) Received: from pedro-m-ruizs-computer.local (unknown [146.48.104.88]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pedrom@smtp.um.es) by mail.um.es (Postfix) with ESMTP id 1E2F4477AF for ; Wed, 10 Oct 2007 14:51:13 +0200 (CEST) Message-ID: <470CCAB3.4050900@dif.um.es> Date: Wed, 10 Oct 2007 14:50:59 +0200 From: "Pedro M. Ruiz" User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: mip6@ietf.org Content-Type: multipart/mixed; boundary="------------070802010607000904010808" X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Subject: [Mip6] CFP MobiWorld 2008 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --------------070802010607000904010808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Apologies if you receive multiple copies of this CFP. -- --------------------------------------------------------------------- Pedro M. Ruiz, Ph.D, MIEEE. E-mail: pedrom@dif.um.es Fac. Informatica, Univ. of Murcia Phone: +34968364335 Campus de Espinardo s/n Fax: +34968364151 E-30100, Espinardo, Murcia www: ants.dif.um.es/~pedrom/ SPAIN --------------------------------------------------------------------- --------------070802010607000904010808 Content-Type: text/plain; name="MobiWorld08-CFP.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="MobiWorld08-CFP.txt" PT09PT09PT09PT09PT09CU1vYmlXb3JsZCAyMDA4IENhbGwgZm9yIFBhcGVyID09PT09PT09 PT09PT09PQ0KICAgICAgICAgICAgICAgICAgVGhlIDIwMDggSW50ZXJuYXRpb25hbCBXb3Jr c2hvcCBvbg0KIE1vYmlsZSBJUHY2IGFuZCBOZXR3b3JrLWJhc2VkIExvY2FsaXplZCBNb2Jp bGl0eSBNYW5hZ2VtZW50DQogICAgICAgICAgICAgICAgICAgICAgICAgKE1vYmlXb3JsZCAy MDA4KQ0KICAgICAgICAgICBodHRwOi8vd3d3LnNlcnNjLm9yZy9NVUUyMDA4L01vYmlXb3Js ZDA4DQoNCiAgICAgIEhhbndoYSBSZXNvcnQgSGFldW5kYWUsIEJ1c2FuLCBLb3JlYSwgQXBy aWwgMjQtMjYsIDIwMDgNCgkJKEluIENvbmp1bmN0aW9uIHdpdGggTVVFIDIwMDgpICAgICAg ICAgICAgICAgICAgIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KPT0gT3Zl cnZpZXcgPT0NCkFzIG1vYmlsZSBjb21wdXRpbmcgaXMgbW9yZSBhbmQgbW9yZSB3aWRlc3By ZWFkLCBtb2JpbGl0eSBzdXBwb3J0IGZvciBJbnRlcm5ldCBkZXZpY2VzIGJlY29tZXMgdmVy eSBpbXBvcnRhbnQuIE1vYmlsZSBJUHY2IChNSVB2NikgaXMgYSBwcm9taXNpbmcgdGVjaG5v bG9neSB0aGF0IGhhbmRsZXMgdGhlIG1vYmlsaXR5IG1hbmFnZW1lbnQgYW5kIHByb3ZpZGVz IHRoZSBzZWFtbGVzcyBtb2JpbGUgY29tbXVuaWNhdGlvbnMuIEl0IGlzIGV4cGVjdGVkIHRo YXQgTUlQdjYsIGFzIGEgc3RhbmRhcmQgZm9yIG1vYmlsZSBjb21tdW5pY2F0aW9uLCB3aWxs IG9wZW4gdGhlIE1vYmlsZSBJbnRlcm5ldCBBZ2UuIEluIE1JUHY2LCBpdCBoYXMgYmVlbiBv YnNlcnZlZCB0aGF0IG1vYmlsaXR5IGZvciBtb2JpbGUgZGV2aWNlcyBjYW4gYmUgbW9yZSBl ZmZpY2llbnRseSBoYW5kbGVkIGlmIG1vYmlsaXR5IG1hbmFnZW1lbnQgaXMgYnJva2VuIGRv d24gaW50byBsb2NhbGl6ZWQgbW9iaWxpdHkgbWFuYWdlbWVudCBhbmQgZ2xvYmFsIG1vYmls aXR5IG1hbmFnZW1lbnQuIFRoZXJlZm9yZSwgaG9zdC1iYXNlZCBhcHByb2FjaGVzIHN1Y2gg YXMgRmFzdC1IYW5kb3ZlcnMgZm9yIE1JUHY2IChGTUlQdjYpIGFuZCBIaWVyYXJjaGljYWwg TUlQdjYgKEhNSVB2NikgaGF2ZSBiZWVuIHByb3Bvc2VkIGZvciBsb2NhbGl6ZWQgbW9iaWxp dHkgbWFuYWdlbWVudC4gSW4gYWRkaXRpb24sIFByb3h5IE1JUHY2IChQTUlQdjYpIGhhcyBi ZWVuIHByZXNlbnRlZCBmb3IgdGhlIG5ldHdvcmstYmFzZWQgbG9jYWxpemVkIG1vYmlsaXR5 IG1hbmFnZW1lbnQgKE5FVExNTSksIHdoaWNoIGRvZXMgbm90IHJlcXVpcmUgbW9iaWxlIGRl dmljZXMgdG8gYmUgaW52b2x2ZWQgaW4gdGhlIHNpZ25hbGluZyBmb3IgbW9iaWxpdHkgbWFu YWdlbWVudC4gVGhpcyB3b3Jrc2hvcCB3aWxsIGZvY3VzIG9uIHRoZSBjaGFsbGVuZ2VzIGFu ZCBzb2x1dGlvbnMgZm9yIE1JUHY2IHdpdGggYW4gZW1waGFzaXMgb24gUE1JUHY2IGFuZCBO RVRMTU0sIHdoaWNoIGhhdmUgcmVjZW50bHkgZ2FpbmVkIGNvbnNpZGVyYWJsZSBhdHRlbnRp b24uDQpUaGUgTW9iaVdvcmxkIHdvcmtzaG9wIHdpbGwgcHJvdmlkZSBhbiBvcHBvcnR1bml0 eSBmb3IgYWNhZGVtaWMgYW5kIGluZHVzdHJ5IHByb2Zlc3Npb25hbHMgdG8gZGlzY3VzcyB0 aGUgbGF0ZXN0IGlzc3VlcyBhbmQgcHJvZ3Jlc3MgaW4gdGhlIGFyZWEgb2YgTUlQdjYgYW5k IE5FVExNTS4gSW4gYWRkaXRpb24sIHRoZSB3b3Jrc2hvcCB3aWxsIHB1Ymxpc2ggaGlnaCBx dWFsaXR5IHBhcGVycyB3aGljaCBhcmUgY2xvc2VseSByZWxhdGVkIHRvIHRoZSB2YXJpb3Vz IHRoZW9yaWVzIGFuZCBwcmFjdGljYWwgYXBwbGljYXRpb25zIGluIE1JUHY2IGFuZCBORVRM TU0uIEZ1cnRoZXJtb3JlLCB3ZSBleHBlY3QgdGhhdCB0aGUgd29ya3Nob3AgYW5kIGl0cyBw dWJsaWNhdGlvbnMgd2lsbCBiZSBhIHRyaWdnZXIgZm9yIGZ1cnRoZXIgcmVsYXRlZCByZXNl YXJjaCBhbmQgdGVjaG5vbG9neSBpbXByb3ZlbWVudHMgaW4gdGhpcyBpbXBvcnRhbnQgc3Vi amVjdC4NCiAgDQoNCj09IFRvcGljcyAoaW5jbHVkZWQsIGJ1dCBhcmUgbm90IGxpbWl0ZWQg dG8pPT0gDQogDQotIENvbW11bmljYXRpb25zIG5ldHdvcmsgYXJjaGl0ZWN0dXJlIGZvciBN SVB2NiBhbmQgTkVUTE1NDQotIEVmZmljaWVudCBoYW5kb3ZlciBtZWNoYW5pc20gaW4gTUlQ djYgYW5kIE5FVExNTQ0KLSBFbmhhbmNlZCByb3V0ZSBvcHRpbWl6YXRpb24gZm9yIE1JUHY2 IGFuZCBORVRMTU0NCi0gUW9TIHByb3RvY29sIGluIE1JUHY2IGFuZCBORVRMTU0NCi0gUGVy Zm9ybWFuY2UgbW9kZWwgZm9yIE1JUHY2IGFuZCBORVRMTU0NCi0gQXBwbGljYXRpb25zIGFu ZCBzZXJ2aWNlcyBiYXNlZCBvbiBNSVB2NiBhbmQgTkVUTE1NDQotIFNlY3VyaXR5IGlzc3Vl cyBhbmQgcHJvdG9jb2xzIGZvciBNSVB2NiBhbmQgTkVUTE1NDQotIFNlY3VyaXR5IHRocmVh dHMgYW5kIG1vZGVsIGZvciBNSVB2NiBhbmQgTkVUTE1NDQotIFByaXZhY3kgYW5kIHRydXN0 IGZvciBNSVB2NiBhbmQgTkVUTE1NDQotIEtleSBtYW5hZ2VtZW50IGFuZCBhdXRoZW50aWNh dGlvbiBmb3IgTUlQdjYgYW5kIE5FVExNTQ0KLSBBY2Nlc3MgY29udHJvbCBmb3IgTUlQdjYg YW5kIE5FVExNTQ0KLSBBQUEgSW5mcmFzdHJ1Y3R1cmUgZm9yIE1JUHY2IGFuZCBORVRMTU0N Ci0gRWFybHkgYmluZGluZyB1cGRhdGUgYW5kIGNyZWRpdCBiYXNlZCBhY2Nlc3MgY29udHJv bCBmb3IgTUlQdjYgYW5kIE5FVExNTQ0KLSBQZXJzb25hbCBvciBDZWxsdWxhciBjb21tdW5p Y2F0aW9ucyBzZXJ2aWNlcyBiYXNlZCBvbiBNSVB2NiBhbmQgTkVUTE1NDQotIFN1Y2Nlc3Nm dWwgTUlQdjYgYW5kIE5FVExNTSBkZXBsb3ltZW50IA0KLSBNb2JpbGl0eSBzdXBwb3J0IGZv ciB0aGUgbmV4dCBnZW5lcmF0aW9uIGludGVybmV0DQotIE1vYmlsZSBJUCBmb3IgYnVzaW5l c3MNCi0gTW9iaWxpdHkgbWFuYWdlbWVudCBmb3Igd2lyZWxlc3MgbmV0d29yaw0KLSBJbXBs ZW1lbnRpbmcgbW9iaWxlIElQIGVudGVycHJpc2UgbWFuYWdlbWVudCBzb2x1dGlvbg0KLSBJ bnRlZ3JhdGluZyBtb2JpbGUgZGF0YSBzZXJ2aWNlcyBpbnRvIGVudGVycHJpc2UgaW5mcmFz dHJ1Y3R1cmUNCi0gT3RoZXJzIGFuZCBlbWVyZ2luZyBuZXcgdG9waWNzDQoNCj09IEludGVy bmF0aW9uYWwgQ29tbWl0dGVlID09DQoNCipHZW5lcmFsIENvLUNoYWlycyANCkhhbi1DaGll aCBDaGFvIChOYXRpb25hbCBJbGFuIFVuaXZlcnNpdHksIFRhaXdhbikgDQpJbHN1biBZb3Ug KEtvcmVhbiBCaWJsZSBVbml2ZXJzaXR5LCBLb3JlYSkgDQoNCipQcm9ncmFtIENvLUNoYWly cyANCllvdW4tSGVlIEhhbiAoS29yZWEgVW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5IGFuZCBF ZHVjYXRpb24sIEtvcmVhKSANCll1aC1TaHlhbiBDaGVuIChOYXRpb25hbCBUYWlwZWkgVW5p dmVyc2l0eSwgVGFpd2FuKQ0KDQoqU3RlZXJpbmcgQ28tQ2hhaXJzDQpIc2lhby1Id2EgQ2hl biAoTmF0aW9uYWwgU3VuIFlhdC1TZW4gVW5pdmVyc2l0eSwgVGFpd2FuKQ0KUmFqZWV2IEtv b2RsaSAoTm9raWEgUmVzZWFyY2ggQ2VudGVyLCBVU0EpDQpWaWN0b3IgQy5NLiBMZXVuZyAo VGhlIFVuaXZlcnNpdHkgb2YgQnJpdGlzaCBDb2x1bWJpYSwgQ2FuYWRhKQ0KWWktQmluZyBM aW4gKE5hdGlvbmFsIENoaWFvIFR1bmcgVW5pdmVyc2l0eSxUYWl3YW4pDQoNCipQdWJsaWNp dHkgQ28tQ2hhaXJzIA0KRXVuIEt5b3VuZyBQYWlrIChLVCwgS29yZWEpDQpQZWRybyBNLiBS dWl6IChVbml2ZXJzaXR5IG9mIE11cmNpYSwgU3BhaW4pDQpSeXVqaSBXYWtpa2F3YSAoS2Vp byBVbml2ZXJzaXR5LCBKYXBhbikNClhpYW9saW4gTGkgKE9rbGFob21hIFN0YXRlIFVuaXZl cnNpdHksIFVTQSkNCg0KKkN5YmVyY2hhaXINCkJ5b3VuZy1Tb28gS29oIChEaWdpQ0FQUyBD by4sIEx0ZCwgS29yZWEpDQogDQoqUHJvZ3JhbSBDb21taXR0ZWUgIA0KQW50b25pbyBGLiBH b21lei1Ta2FybWV0YSAoVW5pdmVyc2l0eSBvZiBNdXJjaWEpDQpCeXVuZ2pvbyBQYXJrIChL VCwgS29yZWEpDQpDaGloLVl1bmcgQ2hhbmcgKFRhbWthbmcgVW5pdmVyc2l0eSwgVGFpd2Fu KQ0KRGF2aWQgU2ltcGxvdC1SeWwgKElSQ0lDQS9MSUZMLCBVbml2ZXJzaXR5IG9mIExpbGxl IDEsIEZyYW5jZSkNCkdhYnJpZWwgTW9udGVuZWdybyAoTWljcm9zb2Z0IENvcnBvcmF0aW9u LCBVU0EpDQpIYW5nYmFlIENoYW5nIChEYWVqaW4gVW5pdmVyc2l0eSwgS29yZWEpDQpIZWVK aW4gSmFuZyAoU2Ftc3VuZyBBZHZhbmNlZCBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neSwgS29y ZWEpDQpKaXlvdW5nIExpbSAoS29yZWFuIEJpYmxlIFVuaXZlcnNpdHkpDQpKb3NlcCBQYXJh ZGVsbHMgKFRlY2huaWNhbCBVbml2ZXJzaXR5IG9mIENhdGFsb25pYSkNCkp1YW4gQS4gU2Fu Y2hleiAoVW5pdmVyc2l0eSBvZiBNdXJjaWEpDQpLZWlpY2hpIFNISU1BIChJSUogUmVzZWFy Y2ggTGFib3JhdG9yeSwgSmFwYW4pDQpLaS1TaWsgS29uZyAoS29yZWEgVW5pdmVyc2l0eSwg S29yZWEpDQpMb2FubmlzIENoYXR6aWdpYW5uYWtpcyAoQ29tcHV0ZXIgVGVjaG5vbG9neSBJ bnN0aXR1dGUsIEdyZWVjZSkNCk1hZGppZCBNZXJhYnRpIChMaXZlcnBvb2wgSm9obiBNb29y ZXMgVW5pdmVyc2l0eSwgVUspDQpNYXN1Z2kgSW5vdWUgKE5JQ1QsIEphcGFuKQ0KTW9ycmlz IENoYW5nIChJb3dhIFN0YXRlIFVuaXZlcnNpdHksIFVTQSkNCk15dW5nLUtpIFNoaW4gKEVU UkksIEtvcmVhKQ0KVGluLVl1IFd1IChJLVNob3UgVW5pdmVyc2l0eSwgVGFpd2FuKQ0KVHp1 bmctU2hpIENoZW4gKE5hdGlvbmFsIFVuaXZlcnNpdHkgb2YgVGFpbmFuLCBUYWl3YW4pDQpW ZWQgUC4gS2FmbGUgKE5JQ1QsIEphcGFuKQ0KVmVua2F0ZXNoIFNhcmFuZ2FuIChPa2xhaG9t YSBTdGF0ZSBVbml2ZXJzaXR5LCBVU0EpDQpXaGFpLUVuIENoZW4gKE5hdGlvbmFsIElsYW4g VW5pdmVyc2l0eSwgVGFpd2FuKQ0KWWFvLUNodW5nIENoYW5nIChOYXRpb25hbCBUYWl0dW5n IFVuaXZlcnNpdHksIFRhaXdhbikNCg0KDQoqSW1wb3J0YW50IERhdGVzDQpQYXBlciBTdWJt aXNzaW9uIGRlYWRsaW5lOiBEZWNlbWJlciA1LCAyMDA3DQpBY2NlcHRhbmNlIG5vdGlmaWNh dGlvbjogSmFudWFyeSAxMCwgMjAwOA0KQ2FtZXJhLXJlYWR5IGR1ZTogSmFudWFyeSAzMSwg MjAwOA0KIA0KKkF1dGhvciBJbnN0cnVjdGlvbg0KQXV0aG9ycyBhcmUgaW52aXRlZCB0byBz dWJtaXQgb3JpZ2luYWwgcGFwZXJzOiB0aGV5IG11c3Qgbm90IHN1YnN0YW50aWFsbHkgZHVw bGljYXRlIHdvcmsgdGhhdCBhbnkgb2YgdGhlIGF1dGhvcnMgaGF2ZSBwdWJsaXNoZWQgZWxz ZXdoZXJlIG9yIGhhdmUgc3VibWl0dGVkIGluIHBhcmFsbGVsIHRvIGFueSBvdGhlciBjb25m ZXJlbmNlcyB0aGF0IGhhdmUgcHJvY2VlZGluZ3MuIFRoZSBzdWJtaXNzaW9uIG9mIGNvbnRy aWJ1dGlvbnMgdG8gTW9iaVdvcmxkIDIwMDggb2NjdXJzIHRocm91Z2ggdGhlIE1VRSAyMDA4 IHBhcGVyIHN1Ym1pc3Npb24gd2Vic2l0ZS4gUGFwZXIgbXVzdCBiZSBwcmVwYXJlZCB3aXRo IFBERi4gUGxlYXNlIHVzZSBJRUVFIENTIHBhcGVyIGZvcm1hdC4gU3VibWlzc2lvbnMgbXVz dCBub3QgZXhjZWVkIDYgcGFnZXMsIGluY2x1ZGluZyB0YWJsZXMgYW5kIGZpZ3VyZXMsIHdp dGggb25seSBQREYuIFN1Ym1pc3Npb24gb2YgYSBwYXBlciBpbXBsaWVzIHRoYXQgc2hvdWxk IHRoZSBwYXBlciBiZSBhY2NlcHRlZCwgYXQgbGVhc3Qgb25lIG9mIHRoZSBhdXRob3JzIHdp bGwgcmVnaXN0ZXIgYW5kIHByZXNlbnQgdGhlIHBhcGVyIGluIHRoZSBjb25mZXJlbmNlLiAN CiANCipQcm9jZWVkaW5ncyAmIFNwZWNpYWwgSXNzdWUNCkFjY2VwdGVkIHBhcGVycyB3aWxs IGJlIGluY2x1ZGVkIGluIHRoZSBjb25mZXJlbmNlIHByb2NlZWRpbmcgcHVibGlzaGVkIGJ5 IElFRUUgQ1MuIFRoZSBwcm9jZWVkaW5ncyB3aWxsIGJlIGF2YWlsYWJsZSBhdCB0aGUgY29u ZmVyZW5jZS4gQXQgbGVhc3Qgb25lIGF1dGhvciBvZiBhbiBhY2NlcHRlZCBwYXBlciBtdXN0 IHJlZ2lzdGVyIGF0IHRoZSBjb25mZXJlbmNlIHNpdGUgYW5kIHByZXNlbnQgdGhlIHBhcGVy IGF0IHRoZSB3b3Jrc2hvcC4gDQpBZnRlciBjb25mZXJlbmNlLCBvdXRzdGFuZGluZyBwYXBl cnMgd2lsbCBiZSBwdWJsaXNoZWQgZm9yIGEgU3BlY2lhbCBJc3N1ZSBvbiBXSVJFTEVTUyBD T01NVU5JQ0FUSU9OUyBBTkQgTU9CSUxFIENPTVBVVElORyAoaW5kZXhlZCBieSBTQ0ktRSku DQpGb3IgbW9yZSBkZXRhaWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHNwZWNpYWwgaXNzdWUs IHBsZWFzZSB2aXNpdDoNCmh0dHA6Ly93d3cuaW50ZXJzY2llbmNlLndpbGV5LmNvbS9qb3Vy bmFsL3dpcmVsZXNzY29tbXMNCg0KDQoqQ29udGFjdA0KRm9yIGZ1cnRoZXIgaW5mb3JtYXRp b24gcmVnYXJkaW5nIHRoZSB3b3Jrc2hvcCBhbmQgcGFwZXIgc3VibWlzc2lvbiwgcGxlYXNl IGNvbnRhY3QgTW9iaVdvcmxkIDIwMDggQ3liZXItY2hhaXIgYXQgY3liZXJjaGFpcjRtb2Jp d29ybGRAZ21haWwuY29tICANCg0KPT09PT09PT09PT09PVRoZSBFbmQgb2YgdGhlIE1vYmlX b3JsZCAyMDA4IENhbGwgZm9yIFBhcGVyPT09PT09PT09PT09PQ== --------------070802010607000904010808 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --------------070802010607000904010808-- From mip6-bounces@ietf.org Wed Oct 10 13:52:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IffiB-00055Q-Al; Wed, 10 Oct 2007 13:51:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iffi9-00051n-Dk; Wed, 10 Oct 2007 13:51:09 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iffi8-0004mO-9d; Wed, 10 Oct 2007 13:51:09 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9AHor5R023977; Wed, 10 Oct 2007 20:51:04 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 20:50:47 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 12:50:38 -0500 Received: from 172.19.244.67 ([172.19.244.67]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 10 Oct 2007 17:50:38 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 10 Oct 2007 12:50:57 -0500 From: Basavaraj Patil To: , "'Mobile IPv6 Mailing List'" Message-ID: Thread-Topic: Request to progress MIP6 WG I-D: draft-ietf-mip6-hiopt-07.txt Thread-Index: AcgLZhxVWuoadHdZEdykwAARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 Oct 2007 17:50:38.0996 (UTC) FILETIME=[119A6540:01C80B66] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: Gopal Dommety , heejin.jang@samsung.com, ext Ralph Droms Subject: [Mip6] Request to progress MIP6 WG I-D: draft-ietf-mip6-hiopt-07.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Jari, The MIP6 WG I-D: DHCP Option for Home Information Discovery in MIPv6 has completed WG last call and has been revised based on the comments received. The last call was issued in the MIP6 and DHC working groups and feedback from members in both working groups have been incorporated. The I-D is now ready for IESG review and progressing it. The document shepherding template as per RFC4858 is attached below. This I-D is intended for publication as a standards track RFC. -Basavaraj (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document shepherd: Basavaraj Patil I have reviewed this version of the I-D and believe it is ready for IESG review and publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes. The document has been reviewed extensively by MIP6 WG members. Additionally this I-D has been reviewed by members of the DHC WG as well. No concerns about the depth or breadth of review by the document shepherd exist. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? No further review from security, AAA or XML experts is needed for this I-D. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No concerns or issues about this I-D exist. This I-D has been in WG discussion for quite sometime now and has been presented and discussed at several WG meetings as well. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? WG consensus is solid. The WG as a whole understands the need for using DHCP for bootstrapping and hence I believe it is not the opinion of just a few individuals but the broader WG. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No appeals have been threatened or any other action. No serious discontent to be noted exists either. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The draft has been run through the ID-nits checker tool. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document split references into normative and informative sections. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? I have verified the IANA considerations section and it provides enough information for IANA to act on it. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document does not have any XML code, BNF or MIB specification. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home network information. New DHCP options are defined which allow a mobile node to request the home agent IP address, FQDN, or home subnet prefix and obtain it via the DHCP response. Working Group Summary The I-D initially also had the Home address (HoA) as a DHCP option. Concerns about this were expressed and subsequently deleted from the I-D. The WG has a good understanding of the use of DHCP for bootstrapping and consensus exists on publishing it. Document Quality No known implementations of the DHCP options specified in the I-D exists. However there has been interest expressed in using these options in other organizations such as WiMAX forum. Several vendors have expressed plans to implement these options for MIP6 bootstrapping. All reviewers have been acknowledged. Personnel Document shepherd: Basavaraj Patil Responsible AD: Jari Arkko _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 10 14:04:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iffss-0002Lf-Mi; Wed, 10 Oct 2007 14:02:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iffsr-0002Ka-Lo for mip6@ietf.org; Wed, 10 Oct 2007 14:02:13 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iffsr-00058N-5V for mip6@ietf.org; Wed, 10 Oct 2007 14:02:13 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9AI1eMg006688; Wed, 10 Oct 2007 21:02:09 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 21:02:02 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 13:01:51 -0500 Received: from 172.19.244.67 ([172.19.244.67]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 10 Oct 2007 18:01:51 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 10 Oct 2007 13:02:10 -0500 From: Basavaraj Patil To: "'Mobile IPv6 Mailing List'" Message-ID: Thread-Topic: Adoption of I-D: draft-haley-mip6-mh-signaling as WG document Thread-Index: AcgLZ6157A7vundaEdykwAARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 Oct 2007 18:01:51.0526 (UTC) FILETIME=[A2765460:01C80B67] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Gopal Dommety Subject: [Mip6] Adoption of I-D: draft-haley-mip6-mh-signaling as WG document X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, The WG has been asked for consensus about adopting the I-D: "Mobility Header Signaling Message" The consensus call email link is: http://www1.ietf.org/mail-archive/web/mip6/current/msg06215.html Based on the responses and the consensus at IETF68, this I-D will be adopted as a MIP6 WG document. I have asked the authors to submit the I-D as a WG document. -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 12 15:18:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPyx-0003VG-Nl; Fri, 12 Oct 2007 15:15:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPyu-0003Ut-GD; Fri, 12 Oct 2007 15:15:32 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgPyu-0003rP-4R; Fri, 12 Oct 2007 15:15:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id E36F52AC9F; Fri, 12 Oct 2007 19:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IgPyP-00054T-Mg; Fri, 12 Oct 2007 15:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 12 Oct 2007 15:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-generic-notification-message-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-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 Mobility for IPv6 Working Group of the IETF. Title : Generic Notification Message for Mobile IPv6 Author(s) : B. Haley, S. Gundavelli Filename : draft-ietf-mip6-generic-notification-message-00.txt Pages : 10 Date : 2007-10-12 This document specifies a new Mobility Header message type that allows Mobile IPv6 entities to send and receive generic notification messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-generic-notification-message-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-ietf-mip6-generic-notification-message-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-ietf-mip6-generic-notification-message-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-12145049.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-generic-notification-message-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-generic-notification-message-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-12145049.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Mon Oct 15 12:26:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhSkX-0006Pt-Qv; Mon, 15 Oct 2007 12:25:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhSkS-0006ND-7t; Mon, 15 Oct 2007 12:24:56 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhSkR-00087O-3F; Mon, 15 Oct 2007 12:24:56 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 126CD328EF; Mon, 15 Oct 2007 16:24:55 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IhSkQ-0005oY-Vm; Mon, 15 Oct 2007 12:24:54 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 15 Oct 2007 12:24:54 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: mip6 mailing list , mip6 chair , Internet Architecture Board , RFC Editor Subject: [Mip6] Protocol Action: 'Mobile IPv6 Experimental Messages' to Proposed Standard X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The IESG has approved the following document: - 'Mobile IPv6 Experimental Messages ' as a Proposed Standard This document is the product of the Mobility for IPv6 Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-experimental-messages-03.txt Technical Summary This document defines a new experimental Mobility header message and a mobility option that can be used for experimental extensions to the Mobile IPv6 protocol. Working Group Summary No controversy has been raised or identified with this document. The I-D is fairly simple and the extension useful for the MIP6 protocol. Document Quality No known implementations of the extensions being proposed here exist. Jari Arkko has reviewed this specification for the IESG. Note to RFC Editor Add to the end of last paragraph of Section 1: Experimental mechanisms should only be used for actual experimentation. By design, only a single code point is allocated for the message and another one for the option. This limits the number of experiments among a set of peers to one at a time. When experimental mechanisms are shown to be useful and there is a desire to deploy them beyond the experiment they should be standardized and given new code points. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 15 14:30:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhUgv-0006pY-9l; Mon, 15 Oct 2007 14:29:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhUgq-0006kC-KE; Mon, 15 Oct 2007 14:29:20 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhUgq-0005co-D0; Mon, 15 Oct 2007 14:29:20 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 3C4DE26E71; Mon, 15 Oct 2007 18:29:15 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IhUgl-00032D-4q; Mon, 15 Oct 2007 14:29:15 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 15 Oct 2007 14:29:15 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: mip6 mailing list , mip6 chair , Internet Architecture Board , RFC Editor Subject: [Mip6] Protocol Action: 'Mobile IPv6 Vendor Specific Option' to Proposed Standard X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The IESG has approved the following document: - 'Mobile IPv6 Vendor Specific Option ' as a Proposed Standard This document is the product of the Mobility for IPv6 Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-vsm-03.txt Technical Summary There is a need for vendor specific extensions to Mobility Header messages so that Mobile IPv6 vendors are able to extend the protocol for research or deployment purposes. This document defines a new vendor specific mobility option. Working Group Summary No controversy has been raised or identified with this spec. The I-D is fairly simple and the extension useful for the MIP6 protocol. Document Quality No known implementations of the extensions being proposed here exist. Jari Arkko has reviewed this specification for the IESG. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 16 10:32:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhnRN-000710-HY; Tue, 16 Oct 2007 10:30:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhnRL-0006xF-Jt; Tue, 16 Oct 2007 10:30:35 -0400 Received: from 33.106-14-84.ripe.coltfrance.com ([84.14.106.33] helo=proxy.6wind.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhnRC-0005li-Ui; Tue, 16 Oct 2007 10:30:27 -0400 Received: from [10.16.0.164] (unknown [10.16.0.164]) by proxy.6wind.com (Postfix) with ESMTP id 9FAD5525F84; Tue, 16 Oct 2007 16:30:25 +0200 (CEST) Message-ID: <4714CAE7.9080900@6wind.com> Date: Tue, 16 Oct 2007 16:29:59 +0200 From: Nicolas Dichtel Organization: 6WIND User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: mip6@ietf.org, ipv6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: users@tahi.org, ipv6ready-info@ipv6ready.org, mipv6_support@v6pc.jp Subject: [Mip6] DHAAD and source address selection X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nicolas.dichtel@6wind.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, I've a question about source address selection in HAAD Reply message. Here is the topology: MN1X | --------+-------+--------------- Link1X | R1 | --------+-------+----------------------- Link1 | RUT | - - - - + - - - - - - - - - - - - - - - Link0 RUT is a Home Agent and the Home Link is Link0. Let's call RUT(Link1) the unicast address sets of the interface connected to Link1 and RUT(Link0) the unicast address sets to the interface connected to Link0. MN1X sends a HAAD Request message to its home agent (RUT). The destination address of this message is an anycast address. When RUT sends the HAAD Reply message, which source address must be used ? RUT(Link1) or RUT(Link0) ? RFC3775 Section 10.5 just says: "A home agent receiving a Home Agent Address Discovery Request message that serves this subnet SHOULD return an ICMP Home Agent Address Discovery Reply message to the mobile node with the Source Address of the Reply packet set to one of the global unicast addresses of the home agent." Following RFC3484, I think that rules #5 (Prefer outgoing interface) in Section 4 is reached. But, there is some cases, like for ICMP ECHO Reply (RFC 4443 Section 4.2), where source address must be the destination address of the request message. In our case, the destination address is an anycast address (assigned to the interface attached to Link0) and, following the RFC2526 Section 1, the packet is delivered to RUT(Link0): "The anycast address may be assigned to one or more network interfaces (typically on different nodes), with the network delivering each packet addressed to this address to the "nearest" interface based on the notion of "distance" determined by the routing protocols in use." So, it's not clear which source address must/can be used. For example, the TAHI tests suite expects the use of RUT(Link0). Regards, Nicolas _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 16 17:08:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihtcz-0005RJ-41; Tue, 16 Oct 2007 17:07:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihtcy-0005NL-5t; Tue, 16 Oct 2007 17:07:00 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ihtct-0005mO-Ft; Tue, 16 Oct 2007 17:06:55 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 14:06:53 -0700 Message-ID: <471527ED.8090301@azairenet.com> Date: Tue, 16 Oct 2007 14:06:53 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nicolas.dichtel@6wind.com Subject: Re: [Mip6] DHAAD and source address selection References: <4714CAE7.9080900@6wind.com> In-Reply-To: <4714CAE7.9080900@6wind.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2007 21:06:53.0820 (UTC) FILETIME=[7A6C73C0:01C81038] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: mip6@ietf.org, users@tahi.org, ipv6@ietf.org, ipv6ready-info@ipv6ready.org, mipv6_support@v6pc.jp X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org It should be the unicast source address of the RUT on Link0. But moving forward, when we revise RFC 3775, I think the anycast address should also be allowed to be used as the source address on the DHAAD reply message. There used to be a restriction earlier that an anycast address shouldn't be used as the source address, but was removed recently. I forget which spec. Vijay Nicolas Dichtel wrote: > Hi, > > I've a question about source address selection in HAAD Reply message. > > Here is the topology: > > MN1X > | > --------+-------+--------------- Link1X > | > R1 > | > --------+-------+----------------------- Link1 > | > RUT > | > - - - - + - - - - - - - - - - - - - - - Link0 > > > RUT is a Home Agent and the Home Link is Link0. Let's call RUT(Link1) > the unicast address sets of the interface connected to Link1 and > RUT(Link0) the unicast address sets to the interface connected to Link0. > > MN1X sends a HAAD Request message to its home agent (RUT). The > destination address of this message is an anycast address. When RUT > sends the HAAD Reply message, which source address must be > used ? RUT(Link1) or RUT(Link0) ? > > RFC3775 Section 10.5 just says: > "A home agent receiving a > Home Agent Address Discovery Request message that serves this subnet > SHOULD return an ICMP Home Agent Address Discovery Reply message to > the mobile node with the Source Address of the Reply packet set to > one of the global unicast addresses of the home agent." > > Following RFC3484, I think that rules #5 (Prefer outgoing interface) in > Section 4 is reached. But, there is some cases, like for ICMP ECHO Reply > (RFC 4443 Section 4.2), where source address must be the destination > address of the request message. In our case, the destination address is > an anycast address (assigned to the interface attached to Link0) and, > following the RFC2526 Section 1, the packet is delivered to RUT(Link0): > "The anycast address may be assigned to one or more network interfaces > (typically on different nodes), with the network delivering each > packet addressed to this address to the "nearest" interface based on > the notion of "distance" determined by the routing protocols in use." > > So, it's not clear which source address must/can be used. For example, > the TAHI tests suite expects the use of RUT(Link0). > > Regards, > Nicolas > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 17 05:32:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii5ES-0004QD-BH; Wed, 17 Oct 2007 05:30:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii5EQ-0004ME-Iz; Wed, 17 Oct 2007 05:30:26 -0400 Received: from 33.106-14-84.ripe.coltfrance.com ([84.14.106.33] helo=proxy.6wind.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ii5E7-0004oL-Ks; Wed, 17 Oct 2007 05:30:08 -0400 Received: from [10.16.0.164] (unknown [10.16.0.164]) by proxy.6wind.com (Postfix) with ESMTP id 0B214525F84; Wed, 17 Oct 2007 11:30:06 +0200 (CEST) Message-ID: <4715D603.6030103@6wind.com> Date: Wed, 17 Oct 2007 11:29:39 +0200 From: Nicolas Dichtel Organization: 6WIND User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] DHAAD and source address selection References: <4714CAE7.9080900@6wind.com> <471527ED.8090301@azairenet.com> In-Reply-To: <471527ED.8090301@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: mip6@ietf.org, users@tahi.org, ipv6@ietf.org, ipv6ready-info@ipv6ready.org, mipv6_support@v6pc.jp X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nicolas.dichtel@6wind.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, thank you for the answer. Have you more details/pointers to explain your opinion ? If the HAAD is sent with RUT(Link1), is it an error ? or is it compliant with the specification ? Regards, Nicolas Vijay Devarapalli wrote: > It should be the unicast source address of the RUT on Link0. > > But moving forward, when we revise RFC 3775, I think the anycast > address should also be allowed to be used as the source address > on the DHAAD reply message. There used to be a restriction earlier > that an anycast address shouldn't be used as the source address, > but was removed recently. I forget which spec. > > Vijay > > Nicolas Dichtel wrote: >> Hi, >> >> I've a question about source address selection in HAAD Reply message. >> >> Here is the topology: >> >> MN1X >> | >> --------+-------+--------------- Link1X >> | >> R1 >> | >> --------+-------+----------------------- Link1 >> | >> RUT >> | >> - - - - + - - - - - - - - - - - - - - - Link0 >> >> >> RUT is a Home Agent and the Home Link is Link0. Let's call RUT(Link1) >> the unicast address sets of the interface connected to Link1 and >> RUT(Link0) the unicast address sets to the interface connected to Link0. >> >> MN1X sends a HAAD Request message to its home agent (RUT). The >> destination address of this message is an anycast address. When RUT >> sends the HAAD Reply message, which source address must be >> used ? RUT(Link1) or RUT(Link0) ? >> >> RFC3775 Section 10.5 just says: >> "A home agent receiving a >> Home Agent Address Discovery Request message that serves this subnet >> SHOULD return an ICMP Home Agent Address Discovery Reply message to >> the mobile node with the Source Address of the Reply packet set to >> one of the global unicast addresses of the home agent." >> >> Following RFC3484, I think that rules #5 (Prefer outgoing interface) in >> Section 4 is reached. But, there is some cases, like for ICMP ECHO Reply >> (RFC 4443 Section 4.2), where source address must be the destination >> address of the request message. In our case, the destination address is >> an anycast address (assigned to the interface attached to Link0) and, >> following the RFC2526 Section 1, the packet is delivered to RUT(Link0): >> "The anycast address may be assigned to one or more network interfaces >> (typically on different nodes), with the network delivering each >> packet addressed to this address to the "nearest" interface based on >> the notion of "distance" determined by the routing protocols in use." >> >> So, it's not clear which source address must/can be used. For example, >> the TAHI tests suite expects the use of RUT(Link0). >> >> Regards, >> Nicolas >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 17 06:23:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii603-00059l-8o; Wed, 17 Oct 2007 06:19:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii600-0004pC-9x; Wed, 17 Oct 2007 06:19:36 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ii5ze-0005v5-S1; Wed, 17 Oct 2007 06:19:21 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1192616338!729868!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29405 invoked from network); 17 Oct 2007 10:18:58 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-128.messagelabs.com with SMTP; 17 Oct 2007 10:18:58 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l9HAIkwT003824; Wed, 17 Oct 2007 03:18:50 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l9HAIke7000608; Wed, 17 Oct 2007 05:18:46 -0500 (CDT) Received: from [127.0.0.1] (ZFR01-2117.ea.mot.com [10.161.194.6]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l9HAIijc000580; Wed, 17 Oct 2007 05:18:44 -0500 (CDT) Message-ID: <4715E183.3060901@gmail.com> Date: Wed, 17 Oct 2007 12:18:43 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nicolas.dichtel@6wind.com Subject: Re: [Mip6] DHAAD and source address selection References: <4714CAE7.9080900@6wind.com> In-Reply-To: <4714CAE7.9080900@6wind.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000781-2, 15/10/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: mip6@ietf.org, users@tahi.org, ipv6@ietf.org, ipv6ready-info@ipv6ready.org, mipv6_support@v6pc.jp X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Nicolas Dichtel wrote: > Hi, > > I've a question about source address selection in HAAD Reply message. > > Here is the topology: > > MN1X > | > --------+-------+--------------- Link1X > | > R1 > | > --------+-------+----------------------- Link1 > | > RUT > | > - - - - + - - - - - - - - - - - - - - - Link0 I'd also say that RUT (your HA) should send the DHAAD Reply having the src field as its address on Link0. I think the choice on Link0 or Link1 address may have implications on how secure DHAAD works. The address in src of Reply being different than the address on the Reply payload may be not good for IPsec SA. Alex > RUT is a Home Agent and the Home Link is Link0. Let's call RUT(Link1) > the unicast address sets of the interface connected to Link1 and > RUT(Link0) the unicast address sets to the interface connected to Link0. > > MN1X sends a HAAD Request message to its home agent (RUT). The > destination address of this message is an anycast address. When RUT > sends the HAAD Reply message, which source address must be > used ? RUT(Link1) or RUT(Link0) ? > > RFC3775 Section 10.5 just says: > "A home agent receiving a > Home Agent Address Discovery Request message that serves this subnet > SHOULD return an ICMP Home Agent Address Discovery Reply message to > the mobile node with the Source Address of the Reply packet set to > one of the global unicast addresses of the home agent." > > Following RFC3484, I think that rules #5 (Prefer outgoing interface) in > Section 4 is reached. But, there is some cases, like for ICMP ECHO Reply > (RFC 4443 Section 4.2), where source address must be the destination > address of the request message. In our case, the destination address is > an anycast address (assigned to the interface attached to Link0) and, > following the RFC2526 Section 1, the packet is delivered to RUT(Link0): > "The anycast address may be assigned to one or more network interfaces > (typically on different nodes), with the network delivering each > packet addressed to this address to the "nearest" interface based on > the notion of "distance" determined by the routing protocols in use." > > So, it's not clear which source address must/can be used. For example, > the TAHI tests suite expects the use of RUT(Link0). > > Regards, > Nicolas > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 17 10:02:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii9RR-00011h-Ud; Wed, 17 Oct 2007 10:00:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii9RP-0000xG-QY; Wed, 17 Oct 2007 10:00:07 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ii9RB-0005wJ-Mn; Wed, 17 Oct 2007 09:59:59 -0400 Received: from oaamta01sl.mx.bigpond.com ([124.190.106.219]) by omta01sl.mx.bigpond.com with ESMTP id <20071017135917.PJUU26650.omta01sl.mx.bigpond.com@oaamta01sl.mx.bigpond.com>; Wed, 17 Oct 2007 13:59:17 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta01sl.mx.bigpond.com with ESMTP id <20071017135917.WFA13338.oaamta01sl.mx.bigpond.com@PC20005>; Wed, 17 Oct 2007 13:59:17 +0000 From: "Hesham Soliman" To: , Date: Wed, 17 Oct 2007 23:59:07 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgQxeIU3weagNHDSpi4Htm5SEk99A== X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: Pasi.Eronen@nokia.com Subject: [Mip6] DSMIPv6 and IKE X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Folks, We had a discussion in a smaller group about this problem, which was initially raised in one of Christain Kaas-Petersen's emails. The problem of integrating IKE and DSMIPv6 is fairly tricky because of the fact that each mechanism has its own NAT traversal method. So after discussing this with a couple of people I'll present three possible ways of solving this issue. Thanks to Pasi for writing up about 7 different options, Raj and Vidya for their input. Problem description: -------------------- DSMIPv6 obviously needs to provide a NAT traversal mechanism. The detection of a NAT relies on the BU/BA message exchange. If a NAT were detected, UDP encapsulation follows. Now, the problem is, for the BU to be sent, we need to run IKE, which has it's own ports/traversal mechanisms. So if we run IKE and send the BU over the IKE tunnel, the HA will not know what port number/address to send the MN's traffic to. Note that the MN cannot include the port number and address because clearly it doesn't know what those values are since they're allocated by the NAT. If we send the BU over port 4500 then we need to send another message (not secured) using DSMIPv6 port to the HA with every handover. I think this is unacceptable because we basically need to send two messages for handover and one of them has zero security. So the idea of using two ports (4500 and DSMIPv6 port) doesn't really work. And we don't have a way today of sending the BU separately over DSMIPv6 port. I.e., what's described in the draft is not possible today. Solution space: --------------- There are basically three ideas that were discussed in a small group: 1. Allow DSMIPv6 to look like a virtual link for IKE. Hence, IKE will simply run over IPv6 and will not be aware of IPv4 at all. 2. Run IKE over port 4500, but add "DSMIPV6_UDP_ENCAPSULATION" notification when negotiating ESP SAs 3. Add a new message in MIP6 that creates a port mapping in the NAT. The BU is still sent over 4500 and the new message is either insecure or (a long shot) secured by a crypto token exchanged in the BU/BA. Message format for solution 1: ------------------------------ IPv4 header (src=V4ADDR, dst=HA_V4ADDR) UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT) IPv6 header (src=V6HOA, dst=HAADDR) ESP header Mobility header BU [IPv4 HAO] IPv4 CoA option And IKE messages would look like: IPv4 header (src=V4ADDR, dst=HA_V4ADDR) UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT) IPv6 header (src=V6HOA, dst=HAADDR) UDP header (src=500, dst=500) IKE message... With this solution, the HA would essentially store the route information for the IKE messages (the port and address received in the outer header) and use them as dst address and port in the respose message. This information must not be stored permanently in the HA, only to respond to the messages. Obviously, if the IKE daemon in the HA silents ignores an IKE message then this information would have to be removed, so there would need to be a timeout or inter-process communication in the implementation. For the MN it's a lot simpler, source address selection for the IKE implementation would always return the V6HoA. Message format for solution 2: ------------------------------ IPv4 header (src=V4ADDR, dst=HA_V4ADDR) UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT) ESP header IPv6 header (src=V6HOA, dst=HAADDR) Mobility header BU [IPv4 HAO] IPv4 CoA option In this option we run IKE over port 4500, but add "DSMIPV6_UDP_ENCAPSULATION" notification when negotiating ESP SAs. Those ESP SAs would use src/dst port DSMIPv6-PORT. But we would still have to rely on IKE to either implicitly or explicitly update its ports and addresses whenever the mobile node moves. Option 3: --------- Basically we didn't work out message formats for this option. I think we all agreed that it's a long shot and, while interesting, it essentially involves designing a new method for MIPv6 security, which is not the best or fastest way to handle this problem. Conclusions: IMO each one of those solutions has it's own flaws. There is no clean and perfect solution above, but there are no clean solutions with NATs unfortunately. I'm personally inclined to go with alternative 1 but let's hear some opinions on this. Time is critical because there is a lot of pressure to move this draft to the IESG. Please send comments. Thanks, Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 17 10:38:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiA2F-0003d9-2N; Wed, 17 Oct 2007 10:38:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiA2C-0003VQ-EV for mip6@ietf.org; Wed, 17 Oct 2007 10:38:08 -0400 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiA21-00071l-2Q for mip6@ietf.org; Wed, 17 Oct 2007 10:38:04 -0400 Received: from oaamta06sl.mx.bigpond.com ([124.190.106.219]) by omta02sl.mx.bigpond.com with ESMTP id <20071017143718.JBR20745.omta02sl.mx.bigpond.com@oaamta06sl.mx.bigpond.com> for ; Wed, 17 Oct 2007 14:37:18 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta06sl.mx.bigpond.com with ESMTP id <20071017143713.ISVO8739.oaamta06sl.mx.bigpond.com@PC20005>; Wed, 17 Oct 2007 14:37:13 +0000 From: "Hesham Soliman" To: , , Date: Thu, 18 Oct 2007 00:37:03 +1000 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgLEmbOttYXMIEITAOVofU56smYXAFuBg/g X-Spam-Score: 0.0 (/) X-Scan-Signature: a852d3320f01cddd04b35de85a7fe713 Cc: Subject: [Mip6] RE: DSMIP accommodation of split of v4 and v6 home link ? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0271483049==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0271483049== Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01C8111F.01442280" This is a multi-part message in MIME format. ------=_NextPart_000_005E_01C8111F.01442280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Karen, Christian, Thanks for the write up. It's never boring with 3GPP's design choices but unfortunately almost always sad.... Basically what you're describing is the result of making bad design choices like allocating home addresses outside the home network and effectively splitting the home network, while using every protocol under the sun at the same time....sigh Of course there are two ways of handling this: 1) This design breaks the fundamental requirement of DSMIPv6, which is that the home link is IPv6-enabled and therefore we don't need to address it or 2) allowing this somehow, one way is obviously what you suggest. I'd like to hear some more opionions on this. Hesham _____ From: Karen.Nielsen@tietoenator.com [mailto:Karen.Nielsen@tietoenator.com] Sent: Wednesday, October 10, 2007 5:52 PM To: mip6@ietf.org; Hesham@elevatemobile.com; Christian.Kaas-Petersen@tietoenator.com Subject: DSMIP accommodation of split of v4 and v6 home link ? Hi Hesham, All With the aim to clarify better. In the 3GPP LTE/SAE network, under final specification, mobility of the user equipment (UE) is realized using different IETF mechanisms: MIP, DSMIP, ProxyMIP, and IPv4-ProxyMIP, all centered on a home agent (HA) functionality and local mobility anchor (LMA) functionality in the packet data network gateway (PDN GW), and mobile access gateway functionality in the serving gateway (Serving GW), and mobile node functionality in the UE. The UE can be attached to the 3GPP in the following ways. * UE can have so-called 3GPP access, and this is found in two variants: * either the Serving GW hosts the mobile access gateway functionality and the PDN GW hosts the corresponding local mobility anchor functionality, * or the Serving GW realizes ordinary GTP tunnels which are terminated in the PDN GW and the PDN GW hosts corresponding home agent functionality. The UE does not know which variant is used, as it only sees a PDP context. This network is denoted the AA network. * UE can have non-3GPP access with network-based mobility. In this instance the mobile access gateway functionality is hosted in either the access gateway of the non-3GPP access network or in the evolved packet data gateway (ePDG), while the corresponding local mobility anchor functionality is hosted in the PDN GW. This network is denoted the BB network. * UE can have non-3GPP access with host-based mobility, in which case the mobile node uses DSMIP while the PDN GW hosts the corresponding home agent functionality. This network is denoted the CC network. >From a IP mobility perspective there is not much difference in between AA and BB. The notably difference in between the networks are * the possible usage of GTP in AA * potential difference in IPv6 and IPv4 access support In both networks, then from a IP mobility perspective, all user layer IP access addresses provided to the UE are home addresses and the address allocation is administratively controlled by the PDN GW which will ensure that the access addresses given out are the same on the two networks. As addresses are carried over in between the AA and all BB networks, the UE IPv6 home link spreads over potentially multiple BB networks and one AA network. Likewise for the IPv4 Home link. The CC network is always, IP mobility wise, a foreign network. The peculiar situation that we would like to support is the situation, presumably primarily a transition period, where the AA network or the BB network (or both) does not support IPv6 access addresses. But where still: * the UE uses an IPv6 HoA for DSMIPv6 signaling (obviously, this is a MUST) * the UE may roam in between AA and BB using an IPv4 HoA * the UE may use DSMIPv6 to roam in and out of CC * the UE may use DSMIPv6 to roam in between the AA network and BB networks with different IP access (plus/minus IPv6) capabilities. If neither of the networks (AA and BB) supports IPv6 access, then the UE will never be at home IPv6 wise. Conceptually the AA and the BB networks run network based mobility on IPv4 access but when IPv6 access cannot be provided, then the idea is to use DSMIPv6 in parallel to manage IPv6 mobility. This represents a logical split of the IPv4 and the IPv6 home link. Lack of deployment of IPv6 is one motivation for offering only an IPv4 PDP context in the 3GPP access (AA network). Another motivation is to limit the use of radio resources. Thus, even if the network in general is IPv6 capable, full capability may only be offered via non-3GPP access (BB or CC) with sufficient bandwidth. Based on this overall scenario description, and looking into DSMIP and its interaction with PMIPv6 and IPv4-PMIPv6, the functionality which we are after and which we cannot find explicitly described anywhere, is to allow DSMIPv6 to operate more independently on the v6HoA and v4HoA cache entries. Specifically so that a UE may use DSMIPv6 to signal * deregistration of an v4HoA registration * registration(update) of v6HoA DSMIPv6 registration to care-of-address equal v4Hoa in one and the same DSMIPv6 BU. To go more into the details with some examples: Example scenario 1: An UE boots up in the CC network, then moves to the BB network. We want to have IPv6 connectivity to the UE, because the PDN GW is connected to the IPv6 Internet as well as in order merely to use DSMIPv6 signaling, but we assume the BB and CC networks have IPv4 access connectivity only. This scenario also covers the case where the network mobility in network AA is controlled using PMIP. First, the UE boots up in the CC network, an IPv4-only foreign network. During this booting, the UE is given an IPv4 care-of address (v4CoA), later it is provided with IPv4 and IPv6 home addresses (v6HoA, v4HoA) via a combination of an IKEv2 exchange to HA (v6HoA allocation) and a request for v4HoA sent in a DSMIPv6 BU to HA, registrating the (v6HoA, v4CoA) relationship. The binding cache of the home agent will have the following two entries home address of node visited address of node ----------------------------------------------- v4HoA v4CoA v6HoA v4CoA Second, the UE moves to the BB network, an IPv4-only network with proxy mobility. Moving there, the mobile node is provided its IPv4 home address (v4HoA as above) as care-of-address, and the mobile access gateway function sends a proxy binding update which rewrites the first line of the binding cache giving the mobile access gateway's IPv4 address (v4PCoA) as the visited address. (The MAG address could also in theory be an IPv6 address (v6PCoa), but this distinction is not important here). Now the cache looks as follows: home address of node visited address of node ----------------------------------------------- v4HoA v4PCoA marked as PMIPv6/IPv4-PMIPv6 controlled v6HoA "old" v4CoA Or would PMIPv6 also manipulate the v6HoA entry, and if so, what would it do - ? Anyway, the UE knows nothing about PMIPv6/IPv4-PMIPv6 and would like to send a BU de-registrating the v4HoA binding and refreshing the v6HoA binding to use the v4HoA as IPv4 care-of-address. With the following desired result. home address of node visited address of node ----------------------------------------------- v4HoA v4PCoA marked as PMIPv6/IPv4-PMIPv6 controlled v6HoA v4HoA (DSMIPv6 controlled) The issues is how this should be done. Proposed options are described further below. Please note that correctly manipulating the v6HoA binding cache entry is required already alone to allow the HA to return the BACK. This will result in two tunnels for IPv6 traffic from HA to UE, the outer tunnel from HA to MAG (v4PCoa) and the inner IPv6 in IPv4 tunnel to v4HoA and as both tunnels originates in the HA this will require two consecutive look ups in the binding cache for Ivy traffic. But well, that's how thing goes. Example scenario 2: An UE boots up in the CC network, then moves to the AA network where host mobility is not done using PMIP (instead it is done using GTP). As above we want to have IPv6 connectivity to the UE, because the PDN GW is connected to the IPv6 Internet as well as in order merely to use DSMIPv6 signaling, but we assume the AA and the CC network have IPv4 access connectivity only. The address allocation and binding procedures in the CC is as in Example 1. With resulting Binding cache entries. home address of node visited address of node ----------------------------------------------- v4HoA v4CoA v6HoA v4CoA Second, the UE moves to the AA network, an IPv4-only network. Moving there, the mobile node is provided its IPv4 home address (v4HoA as above) as care-of-address. But without the involvement of PMIPv6 and the cache entries of the HA remains unaltered until the UE sends a DSMIPv6 BU. Again what the UE would like is to send a BU deleting the v4HoA binding and refreshing the v6HoA binding to use the v4HoA as IPv4 care-of-address. With the following desired result. home address of node visited address of node ----------------------------------------------- v6HoA v4HoA Again the issues is how this should be done. Proposed options are described further below. Also please note that again, correctly manipulating the v6HoA binding cache entry is required already alone to allow the HA to return the BACK. Proposed solution in DSMIPv6: The UE could send a binding update with some non-zero lifetime, reporting v6HoA to be found at v4HoA (in IPv4 care-of-address option), and additionally including v4HoA (in home address option) The home agent should conclude that the equality of the two IPv4 addresses means removal of the v4HoA cache entry. This does not imply changing any DSMIPv6 protocol messages, but it still deserves some text to say how the HA should handle the situation when the v4HoA is the same as the CoA. Another approach is to be explicit and set a bit or a lifetime attached to the IPv4 address in the IPv4 Home Address Option. Being explicit also indicates, that should a packet have the home address and the visited address equal, that packet is malformed. It is of course worth thinking about whether this scenario is relevant for the IETF to consider, but for 3GPP networks it will allow gradually introduction of IPv6 without modifying the protocols. Christian/Karen ------=_NextPart_000_005E_01C8111F.01442280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DSMIP accommodation of split of v4 and v6 home link = ?
Karen, Christian,
 
Thanks for the write up. It's never boring with = 3GPP's=20 design choices but unfortunately almost always = sad....
Basically what you're describing is the result = of making=20 bad design choices like allocating home addresses outside the home = network and=20 effectively splitting the home network, while using every protocol under = the sun=20 at the same time....sigh
Of course there are two ways of handling this: = 1) This=20 design breaks the fundamental requirement of DSMIPv6, which is that the = home=20 link is IPv6-enabled and therefore we don't need to address it or = 2)=20 allowing this somehow, one way is obviously what you suggest.=20 I'd like to hear some more opionions on this. =
 
Hesham

From: = Karen.Nielsen@tietoenator.com=20 [mailto:Karen.Nielsen@tietoenator.com]
Sent: Wednesday, = October 10,=20 2007 5:52 PM
To: mip6@ietf.org; Hesham@elevatemobile.com;=20 Christian.Kaas-Petersen@tietoenator.com
Subject: DSMIP = accommodation=20 of split of v4 and v6 home link ?

Hi Hesham, All

With the aim to clarify = better.=20

In the 3GPP LTE/SAE = network, under=20 final specification,
 mobility of the user equipment (UE) is realized using=20
different IETF = mechanisms: MIP,=20 DSMIP, ProxyMIP, and
IPv4-ProxyMIP, all centered on a home agent (HA) = functionality=20
and local mobility = anchor (LMA)=20 functionality in the packet data
network gateway (PDN GW), and mobile access gateway = functionality=20
in the serving = gateway (Serving=20 GW), and mobile node functionality
in the UE.  The UE can be attached to the 3GPP in the = following=20 ways.

 * UE can have = so-called 3GPP=20 access, and this is found in two
   variants:
    * either the Serving GW hosts the mobile = access=20 gateway
      functionality and the PDN GW = hosts the=20 corresponding
      local mobility anchor = functionality,=20
    = * or the=20 Serving GW realizes ordinary GTP tunnels which are
      = terminated in the=20 PDN GW and the PDN GW hosts corresponding
      home = agent=20 functionality.
   The=20 UE does not know which variant is used, as it only sees a =
   PDP context.  This = network is=20 denoted the AA network.

 * UE can have = non-3GPP access=20 with network-based mobility.  In
   this instance the mobile access gateway = functionality is=20
   hosted = in either=20 the access gateway of the non-3GPP access network
   or in the evolved = packet data=20 gateway (ePDG), while the corresponding local
   mobility anchor = functionality is=20 hosted in the PDN GW. 
   This network is denoted the BB network. =

 * UE can have = non-3GPP access=20 with host-based mobility, in which
   case the mobile node uses DSMIP while the PDN GW = hosts the=20
   = corresponding home=20 agent functionality.  This network is
   denoted the CC network. =

From a IP mobility = perspective there is=20 not much difference in between AA and BB.
The notably difference in between = the networks=20 are
* the possible = usage of GTP=20 in AA
* potential = difference in=20 IPv6 and IPv4 access support

In both networks, then from = a IP=20 mobility perspective, all user layer IP access addresses provided to=20
the UE are home = addresses and=20 the address allocation is administratively controlled by the =
PDN GW which will ensure that the = access=20 addresses given out are the same on the two networks.

As addresses are carried = over in=20 between the AA and all BB networks, the UE
IPv6 home link spreads over = potentially multiple=20 BB networks and one AA network.
Likewise for the IPv4 Home link.

The CC network is always, = IP mobility=20 wise, a foreign network.

The peculiar situation that = we would=20 like to support is the situation,
presumably primarily a transition period, where the AA = network=20
or the BB network = (or both)=20 does not support IPv6 access addresses.

But where still: =
* the UE uses an IPv6 HoA for = DSMIPv6 signaling=20 (obviously, this is a MUST)
*=20 the UE may roam in between AA and BB using an IPv4 HoA =
* the UE may use DSMIPv6 to roam in = and out of=20 CC
* the UE may use = DSMIPv6 to=20 roam in between the AA network and BB networks with different =
IP access (plus/minus IPv6) = capabilities.=20

If neither of the networks = (AA and BB)=20 supports IPv6 access, then
the=20 UE will never be at home IPv6 wise.

Conceptually the AA and the = BB networks=20 run network based mobility on IPv4 access
but when IPv6 access cannot be = provided, then=20
the idea is to use = DSMIPv6 in=20 parallel to manage IPv6 mobility.

This represents a logical = split of the=20 IPv4 and the IPv6 home link.

Lack of deployment of IPv6 = is one=20 motivation for offering only
an=20 IPv4 PDP context in the 3GPP access (AA network).  Another = motivation is=20
to limit the use of = radio=20 resources.  Thus, even if the network
in general is IPv6 capable, full = capability may=20 only be offered
via = non-3GPP=20 access (BB or CC) with sufficient bandwidth.

Based on this overall = scenario=20 description, and looking into DSMIP and its interaction with =
PMIPv6 and IPv4-PMIPv6, the = functionality which=20 we are after and
which we=20 cannot find explicitly described anywhere, is to allow DSMIPv6 to = operate more=20
independently on = the v6HoA and=20 v4HoA cache entries. Specifically so
that a UE may use DSMIPv6 to signal
* deregistration of an v4HoA = registration=20
* = registration(update) of v6HoA=20 DSMIPv6 registration to care-of-address equal v4Hoa
in one and the same DSMIPv6 BU. =

To go more into the details = with some=20 examples:

Example scenario 1: =

An UE boots up in the CC = network, then=20 moves to the BB network.
We=20 want to have IPv6 connectivity to the UE, because the PDN GW is = connected to=20 the
IPv6 Internet = as well as in=20 order merely to use DSMIPv6 signaling,
but we assume the BB and CC networks have IPv4 access = connectivity=20 only.

This scenario also covers = the case=20 where the network mobility in
network AA is controlled using PMIP.

First, the UE boots up in = the CC=20 network, an IPv4-only foreign network.
During this booting, the UE is given an IPv4 care-of address = (v4CoA),=20
later it is = provided with IPv4=20 and IPv6 home addresses (v6HoA, v4HoA) via
a combination of an IKEv2 exchange = to HA (v6HoA=20 allocation) and a request for v4HoA
sent in a DSMIPv6 BU to HA, registrating the (v6HoA, v4CoA)=20 relationship.
The = binding cache=20 of the home agent will have the following two entries

    home = address of=20 node    visited address of node
   =20 -----------------------------------------------
        =20 = v4HoA           &n= bsp;       =20 v4CoA
        =20 = v6HoA           &n= bsp;       =20 v4CoA

Second, the UE moves to the = BB network,=20 an IPv4-only network
with proxy=20 mobility.  Moving there, the mobile node is
provided its IPv4 home address = (v4HoA as above)=20 as care-of-address, and the
mobile access gateway function sends a proxy binding update=20
which rewrites the = first line=20 of the binding cache giving the
mobile access gateway's IPv4 address (v4PCoA) as the visited=20
address.  (The = MAG address=20 could also in theory be an IPv6 address (v6PCoa),
but this distinction is not = important here).=20
Now the cache looks = as follows:=20

home address of = node   =20 visited address of node
    = -----------------------------------------------=20
        =20 = v4HoA           &n= bsp;       =20 v4PCoA    marked as PMIPv6/IPv4-PMIPv6 controlled=20
        =20 = v6HoA           &n= bsp;       =20 "old" v4CoA

Or would PMIPv6 also = manipulate the=20 v6HoA entry, and if so, what would it do - ?

Anyway, the UE knows = nothing about=20 PMIPv6/IPv4-PMIPv6 and would
like to send a BU de-registrating the v4HoA binding and = refreshing the=20 v6HoA binding
to = use the v4HoA=20 as IPv4 care-of-address.
With=20 the following desired result.

    home = address of=20 node    visited address of node
   =20 -----------------------------------------------
        =20 = v4HoA           &n= bsp;       =20 v4PCoA marked as PMIPv6/IPv4-PMIPv6 controlled
        =20 = v6HoA           &n= bsp;       =20 v4HoA  (DSMIPv6 controlled)

The issues is how this = should be done.=20 Proposed options are described further below.
Please note that correctly = manipulating the=20 v6HoA binding cache entry is required
already alone to allow the HA to return the BACK.

This will result in two = tunnels for=20 IPv6 traffic from HA to UE, the outer tunnel
from HA to MAG (v4PCoa) and the = inner IPv6 in=20 IPv4 tunnel to v4HoA and as both tunnels originates in the HA =
this will require two consecutive = look ups in=20 the binding cache for Ivy traffic. But well, that's how thing goes.=20

Example scenario 2: =

An UE boots up in the CC = network, then=20 moves to the AA network where host mobility is
not done using PMIP (instead it is = done using=20 GTP). As above we want to have IPv6
connectivity to the UE, because the PDN GW is connected to = the=20
IPv6 Internet as = well as in=20 order merely to use DSMIPv6 signaling,
but we assume the AA and the CC network have IPv4 access=20
connectivity only. =

The address allocation and = binding=20 procedures in the CC is as in Example 1.
With resulting Binding cache = entries.=20

home address of = node   =20 visited address of node
    = -----------------------------------------------=20
        =20 = v4HoA           &n= bsp;       =20 v4CoA
        =20 = v6HoA           &n= bsp;       =20 v4CoA

Second, the UE moves to the = AA network,=20 an IPv4-only network.
Moving=20 there, the mobile node is
provided its IPv4 home address (v4HoA as above) as = care-of-address.=20
But without the = involvement of=20 PMIPv6 and the cache entries of the HA
remains unaltered until the UE sends a DSMIPv6 BU. Again what = the UE=20 would like
is to = send a BU=20 deleting the v4HoA binding and refreshing the v6HoA binding =
to use the v4HoA as IPv4 = care-of-address.=20
With the following = desired=20 result.


    home = address of=20 node    visited address of node
   =20 -----------------------------------------------
        =20 = v6HoA           &n= bsp;       =20 v4HoA 

Again the issues is how = this should be=20 done. Proposed options are described further below.

Also please note that = again, correctly=20 manipulating the v6HoA binding cache entry is required =
already alone to allow the HA to = return the=20 BACK.


Proposed solution in = DSMIPv6:=20

The UE could send a binding = update with=20 some non-zero lifetime, reporting v6HoA
to be found at v4HoA (in IPv4 = care-of-address=20 option), and additionally including v4HoA (in home address option)=20
The home agent = should conclude=20 that the equality of the two IPv4 addresses means
removal of the v4HoA cache entry.=20
This does not imply = changing=20 any DSMIPv6 protocol messages, but it still deserves some text to say = how the=20 HA
should handle = the situation=20 when the v4HoA is the same as the CoA.

Another approach is to be = explicit and=20 set a
bit or a = lifetime=20 attached to the IPv4 address in the IPv4 Home Address Option. =
Being explicit also indicates, that = should a=20 packet have
the = home address=20 and the visited address equal, that
packet is malformed.

It is of course worth = thinking about=20 whether this scenario
is=20 relevant for the IETF to consider, but for 3GPP networks =
it will allow gradually introduction = of IPv6=20 without modifying the protocols.

Christian/Karen

------=_NextPart_000_005E_01C8111F.01442280-- --===============0271483049== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0271483049==-- From mip6-bounces@ietf.org Wed Oct 17 11:15:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiAbB-0006F4-41; Wed, 17 Oct 2007 11:14:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiAb9-0006Aa-9i for mip6@ietf.org; Wed, 17 Oct 2007 11:14:15 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiAb2-00087l-Hc for mip6@ietf.org; Wed, 17 Oct 2007 11:14:15 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9HFDoZl023329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Oct 2007 08:13:50 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9HFDkdn010300; Wed, 17 Oct 2007 08:13:49 -0700 (PDT) Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Oct 2007 08:13:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] RE: DSMIP accommodation of split of v4 and v6 home link ? Date: Wed, 17 Oct 2007 08:13:46 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF4B950E6@NAEX16.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: DSMIP accommodation of split of v4 and v6 home link ? Thread-Index: AcgLEmbOttYXMIEITAOVofU56smYXAFuBg/gAAFhiTA= References: From: "Tsirtsis, George" To: "Hesham Soliman" , , , X-OriginalArrivalTime: 17 Oct 2007 15:13:48.0750 (UTC) FILETIME=[518D0EE0:01C810D0] X-Spam-Score: -4.0 (----) X-Scan-Signature: 3c5809f82a2ef36c74d8c0ab21f70455 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0073564835==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0073564835== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C810D0.51227284" This is a multi-part message in MIME format. ------_=_NextPart_001_01C810D0.51227284 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Karen, =20 I have been involved with the 3GPP Rel8 design (ex-SAE, currently called EPS) for some time now and I have to say your e-mail confuses the hell out of me. I will not go into all the statements I consider inaccurate in your e-mail (too long!), but I will just point out the following: =20 There is nothing in EPS architecture that requires or implies that the IPv4 and IPv6 home links need to be split. I do not know what gave you that idea but it is just not true. Whether PMIPv6 or DSMIPv6 is used, the corresponding LMA or HA, is supposed to be the owner of IPv4 and IPv6 HoAs for a given MN (UE in 3GPP terms). =20 It is also not true that the MN (or UE) is never at its home link. 3GPP accesses are typically expected to be configured as home links, in which case PMIP/GTP connects the MN directly to the PDNGW (playing the role of an LMA/HA). The address allocated to the MN via such accesses is then meant to either be moved along with PMIPv6 or be treated as a DSMIPv6 HoA when the MN moves to other (non-3GPP) accesses. =20 So, as a summary, I personally have a lot of issues with the EPS architecture but what you describe is not own of them. =20 BR George P.S.: BTW, I had to send this a second time after trimming the e-mail because the mailing list bounces e-mail over 40K. I suggest Karen next time publishes a draft :-) =20 ________________________________ From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 Sent: Wednesday, October 17, 2007 3:37 PM To: Karen.Nielsen@tietoenator.com; mip6@ietf.org; Christian.Kaas-Petersen@tietoenator.com Subject: [Mip6] RE: DSMIP accommodation of split of v4 and v6 home link ? =20 Karen, Christian,=20 =20 Thanks for the write up. It's never boring with 3GPP's design choices but unfortunately almost always sad.... Basically what you're describing is the result of making bad design choices like allocating home addresses outside the home network and effectively splitting the home network, while using every protocol under the sun at the same time....sigh Of course there are two ways of handling this: 1) This design breaks the fundamental requirement of DSMIPv6, which is that the home link is IPv6-enabled and therefore we don't need to address it or 2) allowing this somehow, one way is obviously what you suggest. I'd like to hear some more opionions on this.=20 =20 Hesham =20 =09 ________________________________ From: Karen.Nielsen@tietoenator.com [mailto:Karen.Nielsen@tietoenator.com]=20 Sent: Wednesday, October 10, 2007 5:52 PM To: mip6@ietf.org; Hesham@elevatemobile.com; Christian.Kaas-Petersen@tietoenator.com Subject: DSMIP accommodation of split of v4 and v6 home link ? Hi Hesham, All=20 With the aim to clarify better.=20 In the 3GPP LTE/SAE network, under final specification,=20 mobility of the user equipment (UE) is realized using=20 different IETF mechanisms: MIP, DSMIP, ProxyMIP, and=20 IPv4-ProxyMIP, all centered on a home agent (HA) functionality=20 and local mobility anchor (LMA) functionality in the packet data network gateway (PDN GW), and mobile access gateway functionality=20 in the serving gateway (Serving GW), and mobile node functionality=20 in the UE. The UE can be attached to the 3GPP in the following ways.=20 * UE can have so-called 3GPP access, and this is found in two=20 variants:=20 * either the Serving GW hosts the mobile access gateway=20 functionality and the PDN GW hosts the corresponding=20 local mobility anchor functionality,=20 * or the Serving GW realizes ordinary GTP tunnels which are=20 terminated in the PDN GW and the PDN GW hosts corresponding=20 home agent functionality.=20 The UE does not know which variant is used, as it only sees a PDP context. This network is denoted the AA network.=20 * UE can have non-3GPP access with network-based mobility. In=20 this instance the mobile access gateway functionality is=20 hosted in either the access gateway of the non-3GPP access network=20 or in the evolved packet data gateway (ePDG), while the corresponding local=20 mobility anchor functionality is hosted in the PDN GW. =20 This network is denoted the BB network.=20 * UE can have non-3GPP access with host-based mobility, in which=20 case the mobile node uses DSMIP while the PDN GW hosts the=20 corresponding home agent functionality. This network is=20 denoted the CC network.=20 From a IP mobility perspective there is not much difference in between AA and BB.=20 The notably difference in between the networks are=20 * the possible usage of GTP in AA=20 * potential difference in IPv6 and IPv4 access support=20 In both networks, then from a IP mobility perspective, all user layer IP access addresses provided to=20 the UE are home addresses and the address allocation is administratively controlled by the=20 PDN GW which will ensure that the access addresses given out are the same on the two networks.=20 As addresses are carried over in between the AA and all BB networks, the UE=20 IPv6 home link spreads over potentially multiple BB networks and one AA network.=20 Likewise for the IPv4 Home link.=20 The CC network is always, IP mobility wise, a foreign network.=20 The peculiar situation that we would like to support is the situation,=20 presumably primarily a transition period, where the AA network=20 or the BB network (or both) does not support IPv6 access addresses.=20 But where still:=20 * the UE uses an IPv6 HoA for DSMIPv6 signaling (obviously, this is a MUST)=20 * the UE may roam in between AA and BB using an IPv4 HoA=20 * the UE may use DSMIPv6 to roam in and out of CC=20 * the UE may use DSMIPv6 to roam in between the AA network and BB networks with different=20 IP access (plus/minus IPv6) capabilities.=20 If neither of the networks (AA and BB) supports IPv6 access, then=20 the UE will never be at home IPv6 wise.=20 Conceptually the AA and the BB networks run network based mobility on IPv4 access=20 but when IPv6 access cannot be provided, then=20 the idea is to use DSMIPv6 in parallel to manage IPv6 mobility.=20 This represents a logical split of the IPv4 and the IPv6 home link.=20 Lack of deployment of IPv6 is one motivation for offering only=20 an IPv4 PDP context in the 3GPP access (AA network). Another motivation is=20 to limit the use of radio resources. Thus, even if the network=20 in general is IPv6 capable, full capability may only be offered=20 via non-3GPP access (BB or CC) with sufficient bandwidth.=20 Based on this overall scenario description, and looking into DSMIP and its interaction with=20 PMIPv6 and IPv4-PMIPv6, the functionality which we are after and which we cannot find explicitly described anywhere, is to allow DSMIPv6 to operate more=20 independently on the v6HoA and v4HoA cache entries. Specifically so=20 that a UE may use DSMIPv6 to signal=20 * deregistration of an v4HoA registration=20 * registration(update) of v6HoA DSMIPv6 registration to care-of-address equal v4Hoa=20 in one and the same DSMIPv6 BU.=20 To go more into the details with some examples:=20 ------_=_NextPart_001_01C810D0.51227284 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DSMIP accommodation of split of v4 and v6 home link ?

Karen,

 

I have been involved with the 3GPP = Rel8 design (ex-SAE, currently called EPS) for some time now and I have to = say your e-mail confuses the hell out of me. I will not go into all the = statements I consider inaccurate in your e-mail (too long!), but I will just point = out the following:

 

There is nothing in EPS = architecture that requires or implies that the IPv4 and IPv6 home links need to be split. = I do not know what gave you that idea but it is just not true. Whether PMIPv6 = or DSMIPv6 is used, the corresponding LMA or HA, is supposed to be the = owner of IPv4 and IPv6 HoAs for a given MN (UE in 3GPP terms).

 

It is also not true that the MN (or = UE) is never at its home link. 3GPP accesses are typically expected to be = configured as home links, in which case PMIP/GTP connects the MN directly to the = PDNGW (playing the role of an LMA/HA). The address allocated to the MN via = such accesses is then meant to either be moved along with PMIPv6 or be = treated as a DSMIPv6 HoA when the MN moves to other (non-3GPP) = accesses.

 

So, as a summary, I personally have = a lot of issues with the EPS architecture but what you describe is not own of = them.

 

BR

George

P.S.: BTW, I had to send this a = second time after trimming the e-mail because the mailing list bounces e-mail = over 40K. I suggest Karen next time publishes a draft :-)

 

From: = Hesham Soliman [mailto:Hesham@elevatemobile.com]
Sent: Wednesday, October = 17, 2007 3:37 PM
To: = Karen.Nielsen@tietoenator.com; mip6@ietf.org; Christian.Kaas-Petersen@tietoenator.com
Subject: [Mip6] RE: DSMIP accommodation of split of v4 and v6 home link ?

 

Karen, Christian, =

 

Thanks for the write up. It's never = boring with 3GPP's design choices but unfortunately almost always = sad....

Basically what you're describing is = the result of making bad design choices like allocating home addresses = outside the home network and effectively splitting the home network, while using = every protocol under the sun at the same time....sigh

Of course there are two ways of = handling this: 1) This design breaks the fundamental requirement of DSMIPv6, = which is that the home link is IPv6-enabled and therefore we don't need to = address it or 2) allowing this somehow, one way is obviously what you suggest. I'd like to hear some more opionions on this. =

 

Hesham

 

From: Karen.Nielsen@tietoenator.com [mailto:Karen.Nielsen@tietoenator.com] =
Sent: Wednesday, October = 10, 2007 5:52 PM
To: mip6@ietf.org; Hesham@elevatemobile.com; Christian.Kaas-Petersen@tietoenator.com
Subject: DSMIP = accommodation of split of v4 and v6 home link ?

Hi Hesham, All

With the aim to clarify better.

In the 3GPP LTE/SAE network, under final specification,
 mobility of the = user equipment (UE) is realized using
different IETF = mechanisms: MIP, DSMIP, ProxyMIP, and
IPv4-ProxyMIP, all = centered on a home agent (HA) functionality
and local mobility = anchor (LMA) functionality in the packet data
network gateway (PDN = GW), and mobile access gateway functionality
in the serving gateway = (Serving GW), and mobile node functionality
in the UE.  The UE = can be attached to the 3GPP in the following ways.

 * UE can have so-called 3GPP access, and this is found in two =
   variants: =
    * = either the Serving GW hosts the mobile access gateway
      functionality and the PDN GW hosts the corresponding
      local mobility anchor functionality,
    * or = the Serving GW realizes ordinary GTP tunnels which are
      terminated in the PDN GW and the PDN GW hosts corresponding =
      home agent functionality.
   The UE does = not know which variant is used, as it only sees a
   PDP = context.  This network is denoted the AA network.

 * UE can have non-3GPP access with network-based mobility.  In =
   this = instance the mobile access gateway functionality is
   hosted in = either the access gateway of the non-3GPP access network
   or in the = evolved packet data gateway (ePDG), while the corresponding local =
   mobility = anchor functionality is hosted in the PDN GW. 
   This = network is denoted the BB network.

 * UE can have non-3GPP access with host-based mobility, in which =
   case the = mobile node uses DSMIP while the PDN GW hosts the
   = corresponding home agent functionality.  This network is
   denoted the = CC network.

From a IP mobility perspective there is not much difference in between AA and BB. =
The notably difference = in between the networks are
* the possible usage of = GTP in AA
* potential difference = in IPv6 and IPv4 access support

In both networks, then from a IP mobility perspective, all user layer IP access addresses provided to
the UE are home = addresses and the address allocation is administratively controlled by the =
PDN GW which will ensure = that the access addresses given out are the same on the two networks. =

As addresses are carried over in between the AA and all BB networks, the UE =
IPv6 home link spreads = over potentially multiple BB networks and one AA network.
Likewise for the IPv4 = Home link.

The CC network is always, IP mobility wise, a foreign network. =

The peculiar situation that we would like to support is the situation, =
presumably primarily a = transition period, where the AA network
or the BB network (or = both) does not support IPv6 access addresses.

But where still:
* the UE uses an IPv6 = HoA for DSMIPv6 signaling (obviously, this is a MUST)
* the UE may roam in = between AA and BB using an IPv4 HoA
* the UE may use DSMIPv6 = to roam in and out of CC
* the UE may use DSMIPv6 = to roam in between the AA network and BB networks with different
IP access (plus/minus = IPv6) capabilities.

If neither of the networks (AA and BB) supports IPv6 access, then =
the UE will never be at = home IPv6 wise.

Conceptually the AA and the BB networks run network based mobility on IPv4 access =
but when IPv6 access = cannot be provided, then
the idea is to use = DSMIPv6 in parallel to manage IPv6 mobility.

This represents a logical split of the IPv4 and the IPv6 home link. =

Lack of deployment of IPv6 is one motivation for offering only =
an IPv4 PDP context in = the 3GPP access (AA network).  Another motivation is
to limit the use of = radio resources.  Thus, even if the network
in general is IPv6 = capable, full capability may only be offered
via non-3GPP access (BB = or CC) with sufficient bandwidth.

Based on this overall scenario description, and looking into DSMIP and its = interaction with
PMIPv6 and IPv4-PMIPv6, = the functionality which we are after and
which we cannot find = explicitly described anywhere, is to allow DSMIPv6 to operate more =
independently on the = v6HoA and v4HoA cache entries. Specifically so
that a UE may use = DSMIPv6 to signal
* deregistration of an = v4HoA registration
* registration(update) = of v6HoA DSMIPv6 registration to care-of-address equal v4Hoa
in one and the same = DSMIPv6 BU.

To go more into the details with some examples:

------_=_NextPart_001_01C810D0.51227284-- --===============0073564835== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0073564835==-- From mip6-bounces@ietf.org Wed Oct 17 14:03:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiDCu-0005a5-El; Wed, 17 Oct 2007 14:01:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiDCs-0005YH-1L; Wed, 17 Oct 2007 14:01:22 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiDCq-0005Dh-NB; Wed, 17 Oct 2007 14:01:22 -0400 Received: from localhost ([127.0.0.1]:47096 helo=chardonnay.local ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IiDCT-0001Su-18; Wed, 17 Oct 2007 20:00:57 +0200 Message-ID: <47164DE5.2060005@levkowetz.com> Date: Wed, 17 Oct 2007 20:01:09 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] DSMIPv6 and IKE References: In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Hesham@elevatemobile.com, mip6@ietf.org, nemo@ietf.org, Pasi.Eronen@nokia.com, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -1.4 (-) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: nemo@ietf.org, mip6@ietf.org, Pasi.Eronen@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham, all, On 2007-10-17 15:59 Hesham Soliman said the following: > Folks, > > We had a discussion in a smaller group about this problem, which was > initially raised in one of Christain Kaas-Petersen's emails... ... > There are basically three ideas that were discussed in a small group: > > 1. Allow DSMIPv6 to look like a virtual link for IKE. Hence, IKE will simply > run over IPv6 and will not be aware of IPv4 at all. ... ... > IMO each one of those solutions has it's own flaws. There is no clean and > perfect solution above, but there are no clean solutions with NATs > unfortunately. I'm personally inclined to go with alternative 1 but let's > hear some opinions on this. Time is critical because there is a lot of > pressure to move this draft to the IESG. Please send comments. I concur. Alternative 1 would be my preference, too. Henrik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 17 14:45:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiDsT-00015V-TP; Wed, 17 Oct 2007 14:44:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiDsR-0000xa-KL; Wed, 17 Oct 2007 14:44:19 -0400 Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiDsG-0007Bx-I2; Wed, 17 Oct 2007 14:44:15 -0400 Received: from smtp1.fc.hp.com (smtp1.fc.hp.com [15.15.136.127]) by atlrel9.hp.com (Postfix) with ESMTP id 205B73523E; Wed, 17 Oct 2007 14:42:54 -0400 (EDT) Received: from [16.116.96.52] (wrx.zko.hp.com [16.116.96.52]) by smtp1.fc.hp.com (Postfix) with ESMTP id 7CC491CE0F0; Wed, 17 Oct 2007 18:42:53 +0000 (UTC) Message-ID: <471657AC.3060105@hp.com> Date: Wed, 17 Oct 2007 14:42:52 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: nicolas.dichtel@6wind.com Subject: Re: [Mip6] DHAAD and source address selection References: <4714CAE7.9080900@6wind.com> In-Reply-To: <4714CAE7.9080900@6wind.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: mip6@ietf.org, users@tahi.org, ipv6@ietf.org, ipv6ready-info@ipv6ready.org, mipv6_support@v6pc.jp X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, Nicolas Dichtel wrote: > I've a question about source address selection in HAAD Reply message. ... > RUT is a Home Agent and the Home Link is Link0. This is important. > MN1X sends a HAAD Request message to its home agent (RUT). The > destination address of this message is an anycast address. This anycast address is on Link0, the Home Link, so you should reply with an address from that link - the one you're using as the Home Agent address. The global address on Link1 is not a Home Agent address. > When RUT > sends the HAAD Reply message, which source address must be > used ? RUT(Link1) or RUT(Link0) ? Other parts of the RFC do state this more clearly, for example Section 10.6.3 on sending Advertisements: o The Source Address in the packet's IPv6 header MUST be set to the home agent's IP address to which the mobile node addressed its current home registration or its default global home agent address if no binding exists. Basically, it should use an address in the same prefix with which it's offering home agent services for - the one that would be included in the DHAAD reply if it included its own. > If the HAAD is sent with RUT(Link1), is it an error ? or is it > compliant with the specification ? Well, a lot of us helped define the correct behavior for the TAHI tests years ago during Connectathon testing, and our implementations behave this way. If you choose to do it differently there's no guarantee you'll be inter-operable with all the MNs out there, and you won't be able to get the IPv6 Ready MIPv6 Logo. This is at least something that should be addressed in the issues list that Alex is keeping track of. -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 18 20:34:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iifno-0005PL-G9; Thu, 18 Oct 2007 20:33:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iifnm-0005Lp-IY; Thu, 18 Oct 2007 20:33:22 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iifng-0007xU-CA; Thu, 18 Oct 2007 20:33:22 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 17:33:05 -0700 Message-ID: <4717FB41.8040807@azairenet.com> Date: Thu, 18 Oct 2007 17:33:05 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] DSMIPv6 and IKE References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2007 00:33:05.0100 (UTC) FILETIME=[9D1B78C0:01C811E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: nemo@ietf.org, mip6@ietf.org, Pasi.Eronen@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham and others, Thanks for coming up with multiple solutions to this problem. I have a few comments below. Hesham Soliman wrote: > Message format for solution 1: > ------------------------------ > > IPv4 header (src=V4ADDR, dst=HA_V4ADDR) > UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT) > IPv6 header (src=V6HOA, dst=HAADDR) > ESP header > Mobility header > BU [IPv4 HAO] > IPv4 CoA option > > And IKE messages would look like: > > IPv4 header (src=V4ADDR, dst=HA_V4ADDR) > UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT) > IPv6 header (src=V6HOA, dst=HAADDR) > UDP header (src=500, dst=500) > IKE message... > > With this solution, the HA would essentially store the route information for > the IKE messages (the port and address received in the outer header) and use > them as dst address and port in the respose message. This solution would work, but I am not too comfortable with the temporary tunnel being setup for IKEv2 messages. We don't have such a thing for a MIPv6 home agent today. All tunnel state is created only after the successful exchange of a BU/BAck. This information must > not be stored permanently in the HA, only to respond to the messages. > Obviously, if the IKE daemon in the HA silents ignores an IKE message then > this information would have to be removed, so there would need to be a > timeout or inter-process communication in the implementation. For the MN > it's a lot simpler, source address selection for the IKE implementation > would always return the V6HoA. > > Message format for solution 2: > ------------------------------ > > IPv4 header (src=V4ADDR, dst=HA_V4ADDR) > UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT) > ESP header > IPv6 header (src=V6HOA, dst=HAADDR) > Mobility header > BU [IPv4 HAO] > IPv4 CoA option > > In this option we run IKE over port 4500, but add > "DSMIPV6_UDP_ENCAPSULATION" > notification when negotiating ESP SAs. Those ESP SAs would use src/dst > port DSMIPv6-PORT. I would like to know more about the "cons" of this solution. In this solution the BU/BAck is always sent over port 4500 using UDP ESP encapsultion, but actual DS-MIPv6 tunnel uses "DSMIPv6-PORT". This should work fine. > But we would still have to rely on IKE to either implicitly or explicitly > update its ports and addresses whenever the mobile node moves. But today we *do not* assume that the exchange of a BU/BAck always updates the IKE SA. What if we assume the 'K' flag is always cleared when the mobile node is attached to an IPv4 access network. Of course this would always result in an IKEv2 exchange, in addition to the BU/BAck exchange every time the CoA changes. This is not so bad, since this defaults to lack of support for the 'K' flag. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 18 20:53:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iig5o-0003N0-Cy; Thu, 18 Oct 2007 20:52:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iig5m-0003Is-L9 for mip6@ietf.org; Thu, 18 Oct 2007 20:51:58 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iig5N-0008Rl-C2 for mip6@ietf.org; Thu, 18 Oct 2007 20:51:58 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 17:51:32 -0700 Message-ID: <4717FF94.6070800@azairenet.com> Date: Thu, 18 Oct 2007 17:51:32 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nicolas.dichtel@6wind.com Subject: Re: [Mip6] DHAAD and source address selection References: <4714CAE7.9080900@6wind.com> <471527ED.8090301@azairenet.com> <4715D603.6030103@6wind.com> In-Reply-To: <4715D603.6030103@6wind.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2007 00:51:32.0204 (UTC) FILETIME=[30FE22C0:01C811EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Sorry for the delay. I guess Brian already responded. Nothing more to add. Vijay Nicolas Dichtel wrote: > Hi, > > thank you for the answer. Have you more details/pointers to explain > your opinion ? > If the HAAD is sent with RUT(Link1), is it an error ? or is it > compliant with the specification ? > > Regards, > Nicolas > > > Vijay Devarapalli wrote: >> It should be the unicast source address of the RUT on Link0. >> >> But moving forward, when we revise RFC 3775, I think the anycast >> address should also be allowed to be used as the source address >> on the DHAAD reply message. There used to be a restriction earlier >> that an anycast address shouldn't be used as the source address, >> but was removed recently. I forget which spec. >> >> Vijay >> >> Nicolas Dichtel wrote: >>> Hi, >>> >>> I've a question about source address selection in HAAD Reply message. >>> >>> Here is the topology: >>> >>> MN1X >>> | >>> --------+-------+--------------- Link1X >>> | >>> R1 >>> | >>> --------+-------+----------------------- Link1 >>> | >>> RUT >>> | >>> - - - - + - - - - - - - - - - - - - - - Link0 >>> >>> >>> RUT is a Home Agent and the Home Link is Link0. Let's call RUT(Link1) >>> the unicast address sets of the interface connected to Link1 and >>> RUT(Link0) the unicast address sets to the interface connected to Link0. >>> >>> MN1X sends a HAAD Request message to its home agent (RUT). The >>> destination address of this message is an anycast address. When RUT >>> sends the HAAD Reply message, which source address must be >>> used ? RUT(Link1) or RUT(Link0) ? >>> >>> RFC3775 Section 10.5 just says: >>> "A home agent receiving a >>> Home Agent Address Discovery Request message that serves this subnet >>> SHOULD return an ICMP Home Agent Address Discovery Reply message to >>> the mobile node with the Source Address of the Reply packet set to >>> one of the global unicast addresses of the home agent." >>> >>> Following RFC3484, I think that rules #5 (Prefer outgoing interface) in >>> Section 4 is reached. But, there is some cases, like for ICMP ECHO Reply >>> (RFC 4443 Section 4.2), where source address must be the destination >>> address of the request message. In our case, the destination address is >>> an anycast address (assigned to the interface attached to Link0) and, >>> following the RFC2526 Section 1, the packet is delivered to RUT(Link0): >>> "The anycast address may be assigned to one or more network interfaces >>> (typically on different nodes), with the network delivering each >>> packet addressed to this address to the "nearest" interface based on >>> the notion of "distance" determined by the routing protocols in use." >>> >>> So, it's not clear which source address must/can be used. For example, >>> the TAHI tests suite expects the use of RUT(Link0). >>> >>> Regards, >>> Nicolas >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mext-bounces@ietf.org Fri Oct 19 01:40:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IikXK-0007XY-J4; Fri, 19 Oct 2007 01:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IikXI-0007RI-C3 for mext@ietf.org; Fri, 19 Oct 2007 01:36:40 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IikX5-0007cG-IS for mext@ietf.org; Fri, 19 Oct 2007 01:36:33 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 07:35:59 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C81211.EDB278C4" Date: Fri, 19 Oct 2007 07:35:58 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222D795@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-korhonen-mip6-service-04.txt Thread-Index: AcgRhw5RAzk6KPClRJe102w+RMSO7gAip/hw From: To: X-OriginalArrivalTime: 19 Oct 2007 05:35:59.0559 (UTC) FILETIME=[EDEDD570:01C81211] X-Spam-Score: -4.0 (----) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [MEXT] FW: I-D Action:draft-korhonen-mip6-service-04.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C81211.EDB278C4 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable FYI.. The draft has now been updated based on Jari's comments. Cheers, Jouni > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Thursday, October 18, 2007 3:30 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-korhonen-mip6-service-04.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : Service Selection for Mobile IPv6 > Author(s) : J. Korhonen, et al. > Filename : draft-korhonen-mip6-service-04.txt > Pages : 7 > Date : 2007-10-18 >=20 > In some Mobile IPv6 deployments identifying the mobile node=20 > or the mobility service subscriber is not enough to=20 > distinguish between multiple services possibly provisioned to=20 > the said mobile node and its mobility service subscription. =20 > A capability to specify different services in addition to the=20 > mobile node identity can be leveraged to provide flexibility=20 > for mobility service providers on provisioning multiple=20 > services to one mobility service subscription. This document=20 > describes a Service Selection Mobility Option for both=20 > conventional Mobile IPv6 and Proxy Mobile IPv6 that is=20 > intended to assist home agents to make a specific service=20 > selection for the mobility service subscription during the=20 > binding registration procedure. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-korhonen-mip6-service-04.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. ------_=_NextPart_001_01C81211.EDB278C4 Content-Type: text/plain; charset="us-ascii"; name="draft-korhonen-mip6-service-04.txt" Content-Transfer-Encoding: base64 Content-Description: draft-korhonen-mip6-service-04.txt Content-Disposition: attachment; filename="draft-korhonen-mip6-service-04.txt" RklMRSBRVUFSQU5USU5FRA0KLS0tLS0tLS0tLS0tLS0tLQ0KDQpNaWNyb3NvZnQgQW50aWdlbiBm b3IgRXhjaGFuZ2UgcmVtb3ZlZCBhIGZpbGUgc2luY2UgaXQgd2FzIGZvdW5kIHRvIG1hdGNoIGEg ZmlsdGVyLg0KRmlsZSBuYW1lOiAiZHJhZnRfa29yaG9uZW5fbWlwNl9zZXJ2aWNlXzA0LlVSTCIN CkZpbHRlciBuYW1lOiAiRklMRSBGSUxURVI9IHVubmFtZWQ6ICoudXJsIg0K ------_=_NextPart_001_01C81211.EDB278C4 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext ------_=_NextPart_001_01C81211.EDB278C4-- From mip6-bounces@ietf.org Fri Oct 19 05:53:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IioW5-000300-HK; Fri, 19 Oct 2007 05:51:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IioW4-0002wv-0e for mip6@ietf.org; Fri, 19 Oct 2007 05:51:40 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IioVw-0007qj-8H for mip6@ietf.org; Fri, 19 Oct 2007 05:51:39 -0400 X-AuditID: c10cb581-00000ac000000a38-76-47187e0a2d25 Received: from stingray.eu.tieto.com ([192.176.143.13]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 11:51:06 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 11:51:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] RE: DSMIP accommodation of split of v4 and v6 home link ? Date: Fri, 19 Oct 2007 11:51:09 +0200 Message-ID: In-Reply-To: <2309978910A6A6478C2C7585692B0AF4B950E6@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: DSMIP accommodation of split of v4 and v6 home link ? Thread-Index: AcgLEmbOttYXMIEITAOVofU56smYXAFuBg/gAAFhiTAAWS7+8A== References: <2309978910A6A6478C2C7585692B0AF4B950E6@NAEX16.na.qualcomm.com> From: To: , , , X-OriginalArrivalTime: 19 Oct 2007 09:51:10.0769 (UTC) FILETIME=[941F1210:01C81235] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: 4f585e1bcd209294c6b9386034cecfc6 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1551970640==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1551970640== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81235.93DEF5E5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81235.93DEF5E5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi George, =20 Thanks a lot for your response. =20 I will say, very briefly, what is our point. I do not what to pollute the mailing list with too=20 much misguided 3GPP non-sense=20 if that is what this is (from my side, that is !). =20 I agree with everything you say about address allocations=20 and how addresses moves along with the MN when it moves to other non-3GPP accesses (controlled by (IPv4-)PMIPv6 or DSMIPv6 respectively)=20 =20 The term "split of v4 and v6 home link" used by me, should be understood NOT TO SAY that the v4 and v6 home link is administratively split in between different operators, APN's or anything like that. INSTEAD the intention is to split away the tight coupling in between the v4 and the v6 home link which is present today in DSMIPv6 THEREBY ACCOMMODATING pre-LTE/SAE (or ESP) architectures where the HOME or VISITED 3GPP operator does not support=20 IPv6 PDP contexts. =20 In this situation, then alone to support v4 handovers, the MN needs a v6 HoA for DSMIPv6 signaling.=20 In addition, then it would not hurt, if the MN could also use this v6 address for v6 connectivity via a reverse DSMIPv6 tunnel to its HA. =20 What we describe is this situation and what we propose is a way to handle this situation using DSMIPv6. =20 I know that there are unclear point in the currents 3GPP specs, some (it seems) due to the write-up being a mixture of what could be achieved with 4285bis-like "DSMIPv6" operation and some which can be achieved with IKEv2, IPSec and DSMIPv6. In this context then the details we give is in the DSMIPv6 and IKEv2 solution realm, but I would like to stress that the issue=20 as well as the solution is, on a high-level, not dependent on whether we are speaking IKEv2 or 4285bis-like based authentication. =20 If DSMIPv6 closes now, then I suppose that we will have to write this up in a draft - :-) =20 BR, Karen =20 ________________________________ From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com]=20 Sent: Wednesday, October 17, 2007 5:14 PM To: Hesham Soliman; Nielsen Karen E; mip6@ietf.org; Kaas-Petersen Christian Subject: RE: [Mip6] RE: DSMIP accommodation of split of v4 and v6 home link ? =09 =09 Karen, =20 I have been involved with the 3GPP Rel8 design (ex-SAE, currently called EPS) for some time now and I have to say your e-mail confuses the hell out of me. I will not go into all the statements I consider inaccurate in your e-mail (too long!), but I will just point out the following: =20 There is nothing in EPS architecture that requires or implies that the IPv4 and IPv6 home links need to be split. I do not know what gave you that idea but it is just not true. Whether PMIPv6 or DSMIPv6 is used, the corresponding LMA or HA, is supposed to be the owner of IPv4 and IPv6 HoAs for a given MN (UE in 3GPP terms). =20 It is also not true that the MN (or UE) is never at its home link. 3GPP accesses are typically expected to be configured as home links, in which case PMIP/GTP connects the MN directly to the PDNGW (playing the role of an LMA/HA). The address allocated to the MN via such accesses is then meant to either be moved along with PMIPv6 or be treated as a DSMIPv6 HoA when the MN moves to other (non-3GPP) accesses. =20 So, as a summary, I personally have a lot of issues with the EPS architecture but what you describe is not own of them. =20 BR George P.S.: BTW, I had to send this a second time after trimming the e-mail because the mailing list bounces e-mail over 40K. I suggest Karen next time publishes a draft :-) =20 =09 ________________________________ ------_=_NextPart_001_01C81235.93DEF5E5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DSMIP accommodation of split of v4 and v6 home link = ?
Hi George,
 
Thanks a lot for your = response.
 
I will say, very briefly, what is our=20 point.
I do not what to pollute the mailing list = with too=20
much misguided 3GPP non-sense =
if that is what this is (from my = side, that=20 is !).
 
I agree with everything you say about address = allocations
and how addresses moves along with the=20 MN
when it moves to other non-3GPP accesses = (controlled by=20 (IPv4-)PMIPv6 or DSMIPv6 respectively)
 
The term "split of v4 and v6 home link" used = by me,=20 should be understood
NOT TO SAY that the v4 and v6 home link is=20 administratively split in between different operators, APN's or anything = like=20 that.
INSTEAD the intention is to split away the = tight=20 coupling in between the v4 and the v6 home link which is present today = in=20 DSMIPv6
THEREBY ACCOMMODATING pre-LTE/SAE (or ESP)=20 architectures where  the HOME or VISITED 3GPP operator does = not=20 support
IPv6 PDP contexts.
 
In this situation, then alone to support v4 = handovers,=20 the MN needs a v6 HoA for DSMIPv6 signaling.
In addition, then it would not hurt,=20 if the MN could also use this v6 address for = v6=20 connectivity via a reverse DSMIPv6 tunnel to its HA.
 
What we describe is this situation and what = we propose=20 is a way to handle this situation using DSMIPv6.
 
I know that there are unclear point in the = currents=20 3GPP specs, some (it seems) due to the write-up being a mixture of=20 what
could be achieved with 4285bis-like "DSMIPv6" = operation=20 and some which can be achieved with IKEv2, IPSec and=20 DSMIPv6.
In this context then the details we give is in the DSMIPv6 and IKEv2 solution realm, = but I would=20 like to stress that the issue
as well as the solution is, on a high-level, not dependent on whether we are = speaking IKEv2 or=20 4285bis-like based authentication.
 
If DSMIPv6 = closes now,=20 then I suppose that we will have to write this up in a draft -=20 :-)
 
BR, Karen
 

From: Tsirtsis, George=20 [mailto:tsirtsis@qualcomm.com]
Sent: Wednesday, October 17, = 2007=20 5:14 PM
To: Hesham Soliman; Nielsen Karen E; mip6@ietf.org;=20 Kaas-Petersen Christian
Subject: RE: [Mip6] RE: DSMIP = accommodation=20 of split of v4 and v6 home link ?

Karen,

 

I have been = involved=20 with the 3GPP Rel8 design (ex-SAE, currently called EPS) for some time = now and=20 I have to say your e-mail confuses the hell out of me. I will not go = into all=20 the statements I consider inaccurate in your e-mail (too long!), but I = will=20 just point out the following:

 

There is = nothing in=20 EPS architecture that requires or implies that the IPv4 and IPv6 home = links=20 need to be split. I do not know what gave you that idea but it is just = not=20 true. Whether PMIPv6 or DSMIPv6 is used, the corresponding LMA or HA, = is=20 supposed to be the owner of IPv4 and IPv6 HoAs for a given MN (UE in = 3GPP=20 terms).

 

It is also = not true=20 that the MN (or UE) is never at its home link. 3GPP accesses are = typically=20 expected to be configured as home links, in which case PMIP/GTP = connects the=20 MN directly to the PDNGW (playing the role of an LMA/HA). The address=20 allocated to the MN via such accesses is then meant to either be moved = along=20 with PMIPv6 or be treated as a DSMIPv6 HoA when the MN moves to other=20 (non-3GPP) accesses.

 

So, as a = summary, I=20 personally have a lot of issues with the EPS architecture but what you = describe is not own of them.

 

BR

George

P.S.: BTW, = I had to=20 send this a second time after trimming the e-mail because the mailing = list=20 bounces e-mail over 40K. I suggest Karen next time publishes a draft=20 :-)

 

------_=_NextPart_001_01C81235.93DEF5E5-- --===============1551970640== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1551970640==-- From mip6-bounces@ietf.org Fri Oct 19 06:26:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iip38-0003j5-Ek; Fri, 19 Oct 2007 06:25:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iip36-0003A4-Hc; Fri, 19 Oct 2007 06:25:48 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iip2s-0006Hq-8H; Fri, 19 Oct 2007 06:25:34 -0400 Received: from oaamta03sl.mx.bigpond.com ([124.190.106.219]) by omta05sl.mx.bigpond.com with ESMTP id <20071019102528.JUQ16667.omta05sl.mx.bigpond.com@oaamta03sl.mx.bigpond.com>; Fri, 19 Oct 2007 10:25:28 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta03sl.mx.bigpond.com with ESMTP id <20071019102528.YAVK23886.oaamta03sl.mx.bigpond.com@PC20005>; Fri, 19 Oct 2007 10:25:28 +0000 From: "Hesham Soliman" To: , Subject: RE: [Mip6] DSMIPv6 and IKE Date: Fri, 19 Oct 2007 20:25:18 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgR56BYSVhv7v+ERrmvTneqpYKa3QAQLYRgAARdbMA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I'll reply to both comments below. > > This solution would work, but I am not too comfortable with the > > temporary tunnel being setup for IKEv2 messages. We don't have > > such a thing for a MIPv6 home agent today. All tunnel state is > > created only after the successful exchange of a BU/BAck. > > I'm not also quite sure what exactly would be the tunnel > state created. For example, a message seen by the IKE daemon > would be simply: > > IPv6 header (src=V6HOA, dst=HAADDR) > UDP header (src=500, dst=500) > IKE message (IKE_SA_INIT request) > > and the reply sent would be > > IPv6 header (src=HAADDR, dst=V6HOA) > UDP header (src=500, dst=500) > IKE message (IKE_SA_INIT response) > > How would this actually get routed to the tunnel? To the kernel, > this looks just like an ordinary UDP packet going to V6HOA, and > would get sent out as usual (if we haven't done BU for the new > V4ADDR yet, it won't get sent there). => Basically the DSMIP6 code would have to capture any packet sent by the IKE daemon (known port)to the IPv6 home address that has already sent the original message. I think that would work. As you (Pasi) said, we would not create a route in the routing table, it would have to be treated as temporary state in the DSMIPv6 implementation. > In theory, we could have a modified DSMIPv6-only IKE daemon > that would understand the tunnel headers, and construct appropriate > replies, but then we're not talking about standard IPsec anymore. => I think we can do it without touching the IKE daemon. > > One solution that might work is putting the state information for > reply in the packet (as seen by IKE) itself: e.g. the source address > (as seen by IKE) would be "magic prefix:V4_ADDR:V4_PORT". But this > would be IPv6 NAT (although just inside a host -- so maybe not that > different to what e.g. HIP does by exposing just HITs to > applications)... => That's another way of doing it but we've been advised by the AD to not use mapped addresses at all and this is basically a mapped address. > > > > In this option we run IKE over port 4500, but add > > > "DSMIPV6_UDP_ENCAPSULATION" > > > notification when negotiating ESP SAs. Those ESP SAs would > > > use src/dst port DSMIPv6-PORT. > > > > I would like to know more about the "cons" of this solution. > > One obvious "con" is that it requires extensions to IPsec/IKE > (or in other words, IPsec/IKE implementation with DSMIPv6-specific > changes). => Agreed. > > > In this solution the BU/BAck is always sent over port 4500 > > using UDP ESP encapsultion, but actual DS-MIPv6 tunnel uses > > "DSMIPv6-PORT". This should work fine. > > Well... if the BU/BAck is sent over port 4500, we need some other > "BU-like" message that is sent over DSMIPv6-PORT. => Exactly. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 19 06:26:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iip3u-0005Ro-0S; Fri, 19 Oct 2007 06:26:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iip3s-0005Og-G8 for mip6@ietf.org; Fri, 19 Oct 2007 06:26:36 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iip3r-0006Jv-Od for mip6@ietf.org; Fri, 19 Oct 2007 06:26:36 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-128.messagelabs.com!1192789593!2980255!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 21648 invoked from network); 19 Oct 2007 10:26:33 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-3.tower-128.messagelabs.com with SMTP; 19 Oct 2007 10:26:33 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l9JAQSUq019524; Fri, 19 Oct 2007 03:26:33 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l9JAQRv5012346; Fri, 19 Oct 2007 05:26:28 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l9JAQONW012327; Fri, 19 Oct 2007 05:26:25 -0500 (CDT) Message-ID: <47188650.10106@gmail.com> Date: Fri, 19 Oct 2007 12:26:24 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karen.Nielsen@tietoenator.com Subject: Re: [Mip6] RE: DSMIP accommodation of split of v4 and v6 home link ? References: <2309978910A6A6478C2C7585692B0AF4B950E6@NAEX16.na.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000782-1, 17/10/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org GEorge, Karen, I support the initiative to have DS-MIPv6 support split IPv4-IPv6 home networks. I think it is reasonable to assume that an operator runs an IPv6-exclusive home network whose mobiles attach to a IPv4-exclusive Access Network. Alex Karen.Nielsen@tietoenator.com wrote: > Hi George, > > Thanks a lot for your response. > > I will say, very briefly, what is our point. > I do not what to pollute the mailing list with too > much misguided 3GPP non-sense > if that is what this is (from my side, that is !). > > I agree with everything you say about address allocations > and how addresses moves along with the MN > when it moves to other non-3GPP accesses (controlled by (IPv4-)PMIPv6 or > DSMIPv6 respectively) > > The term "split of v4 and v6 home link" used by me, should be understood > NOT TO SAY that the v4 and v6 home link is administratively split in > between different operators, APN's or anything like that. > INSTEAD the intention is to split away the tight coupling in between the > v4 and the v6 home link which is present today in DSMIPv6 > THEREBY ACCOMMODATING pre-LTE/SAE (or ESP) architectures where the HOME > or VISITED 3GPP operator does not support > IPv6 PDP contexts. > > In this situation, then alone to support v4 handovers, the MN needs a v6 > HoA for DSMIPv6 signaling. > In addition, then it would not hurt, if the MN could also use this v6 > address for v6 connectivity via a reverse DSMIPv6 tunnel to its HA. > > What we describe is this situation and what we propose is a way to > handle this situation using DSMIPv6. > > I know that there are unclear point in the currents 3GPP specs, some (it > seems) due to the write-up being a mixture of what > could be achieved with 4285bis-like "DSMIPv6" operation and some which > can be achieved with IKEv2, IPSec and DSMIPv6. > In this context then the details we give is in the DSMIPv6 and IKEv2 > solution realm, but I would like to stress that the issue > as well as the solution is, on a high-level, not dependent on whether we > are speaking IKEv2 or 4285bis-like based authentication. > > If DSMIPv6 closes now, then I suppose that we will have to write this up > in a draft - :-) > > BR, Karen > > > ------------------------------------------------------------------------ > *From:* Tsirtsis, George [mailto:tsirtsis@qualcomm.com] > *Sent:* Wednesday, October 17, 2007 5:14 PM > *To:* Hesham Soliman; Nielsen Karen E; mip6@ietf.org; Kaas-Petersen > Christian > *Subject:* RE: [Mip6] RE: DSMIP accommodation of split of v4 and v6 > home link ? > > Karen, > > > > I have been involved with the 3GPP Rel8 design (ex-SAE, currently > called EPS) for some time now and I have to say your e-mail confuses > the hell out of me. I will not go into all the statements I consider > inaccurate in your e-mail (too long!), but I will just point out the > following: > > > > There is nothing in EPS architecture that requires or implies that > the IPv4 and IPv6 home links need to be split. I do not know what > gave you that idea but it is just not true. Whether PMIPv6 or > DSMIPv6 is used, the corresponding LMA or HA, is supposed to be the > owner of IPv4 and IPv6 HoAs for a given MN (UE in 3GPP terms). > > > > It is also not true that the MN (or UE) is never at its home link. > 3GPP accesses are typically expected to be configured as home links, > in which case PMIP/GTP connects the MN directly to the PDNGW > (playing the role of an LMA/HA). The address allocated to the MN via > such accesses is then meant to either be moved along with PMIPv6 or > be treated as a DSMIPv6 HoA when the MN moves to other (non-3GPP) > accesses. > > > > So, as a summary, I personally have a lot of issues with the EPS > architecture but what you describe is not own of them. > > > > BR > > George > > P.S.: BTW, I had to send this a second time after trimming the > e-mail because the mailing list bounces e-mail over 40K. I suggest > Karen next time publishes a draft :-) > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 19 06:29:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iip6X-0000Iz-Kb; Fri, 19 Oct 2007 06:29:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iip6V-000057-El for mip6@ietf.org; Fri, 19 Oct 2007 06:29:19 -0400 Received: from omta03sl.mx.bigpond.com ([144.140.92.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iip6L-0006Oy-Hu for mip6@ietf.org; Fri, 19 Oct 2007 06:29:10 -0400 Received: from oaamta03sl.mx.bigpond.com ([124.190.106.219]) by omta03sl.mx.bigpond.com with ESMTP id <20071019102907.DFND5350.omta03sl.mx.bigpond.com@oaamta03sl.mx.bigpond.com> for ; Fri, 19 Oct 2007 10:29:07 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta03sl.mx.bigpond.com with ESMTP id <20071019102907.YBLD23886.oaamta03sl.mx.bigpond.com@PC20005>; Fri, 19 Oct 2007 10:29:07 +0000 From: "Hesham Soliman" To: "'Alexandru Petrescu'" , Subject: RE: [Mip6] RE: DSMIP accommodation of split of v4 and v6 home link ? Date: Fri, 19 Oct 2007 20:28:57 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <47188650.10106@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgSOok9AUOdvLroS/2cGu8JrLOxgwAADxEA X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > GEorge, Karen, I support the initiative to have DS-MIPv6 > support split > IPv4-IPv6 home networks. > > I think it is reasonable to assume that an operator runs an > IPv6-exclusive home network whose mobiles attach to a IPv4-exclusive > Access Network. => This is NOT what Karen is talking about. She's talking about an IPv4-only home network that offers IPv6 service.... Hesham > > Alex > > Karen.Nielsen@tietoenator.com wrote: > > Hi George, > > > > Thanks a lot for your response. > > > > I will say, very briefly, what is our point. > > I do not what to pollute the mailing list with too > > much misguided 3GPP non-sense > > if that is what this is (from my side, that is !). > > > > I agree with everything you say about address allocations > > and how addresses moves along with the MN > > when it moves to other non-3GPP accesses (controlled by > (IPv4-)PMIPv6 or > > DSMIPv6 respectively) > > > > The term "split of v4 and v6 home link" used by me, should > be understood > > NOT TO SAY that the v4 and v6 home link is > administratively split in > > between different operators, APN's or anything like that. > > INSTEAD the intention is to split away the tight coupling > in between the > > v4 and the v6 home link which is present today in DSMIPv6 > > THEREBY ACCOMMODATING pre-LTE/SAE (or ESP) architectures > where the HOME > > or VISITED 3GPP operator does not support > > IPv6 PDP contexts. > > > > In this situation, then alone to support v4 handovers, the > MN needs a v6 > > HoA for DSMIPv6 signaling. > > In addition, then it would not hurt, if the MN could also > use this v6 > > address for v6 connectivity via a reverse DSMIPv6 tunnel to its HA. > > > > What we describe is this situation and what we propose is a way to > > handle this situation using DSMIPv6. > > > > I know that there are unclear point in the currents 3GPP > specs, some (it > > seems) due to the write-up being a mixture of what > > could be achieved with 4285bis-like "DSMIPv6" operation > and some which > > can be achieved with IKEv2, IPSec and DSMIPv6. > > In this context then the details we give is in the DSMIPv6 > and IKEv2 > > solution realm, but I would like to stress that the issue > > as well as the solution is, on a high-level, not dependent > on whether we > > are speaking IKEv2 or 4285bis-like based authentication. > > > > If DSMIPv6 closes now, then I suppose that we will have to > write this up > > in a draft - :-) > > > > BR, Karen > > > > > > > ------------------------------------------------------------- > ----------- > > *From:* Tsirtsis, George [mailto:tsirtsis@qualcomm.com] > > *Sent:* Wednesday, October 17, 2007 5:14 PM > > *To:* Hesham Soliman; Nielsen Karen E; mip6@ietf.org; > Kaas-Petersen > > Christian > > *Subject:* RE: [Mip6] RE: DSMIP accommodation of split > of v4 and v6 > > home link ? > > > > Karen, > > > > > > > > I have been involved with the 3GPP Rel8 design > (ex-SAE, currently > > called EPS) for some time now and I have to say your > e-mail confuses > > the hell out of me. I will not go into all the > statements I consider > > inaccurate in your e-mail (too long!), but I will just > point out the > > following: > > > > > > > > There is nothing in EPS architecture that requires or > implies that > > the IPv4 and IPv6 home links need to be split. I do > not know what > > gave you that idea but it is just not true. Whether PMIPv6 or > > DSMIPv6 is used, the corresponding LMA or HA, is > supposed to be the > > owner of IPv4 and IPv6 HoAs for a given MN (UE in 3GPP terms). > > > > > > > > It is also not true that the MN (or UE) is never at > its home link. > > 3GPP accesses are typically expected to be configured > as home links, > > in which case PMIP/GTP connects the MN directly to the PDNGW > > (playing the role of an LMA/HA). The address allocated > to the MN via > > such accesses is then meant to either be moved along > with PMIPv6 or > > be treated as a DSMIPv6 HoA when the MN moves to other > (non-3GPP) > > accesses. > > > > > > > > So, as a summary, I personally have a lot of issues > with the EPS > > architecture but what you describe is not own of them. > > > > > > > > BR > > > > George > > > > P.S.: BTW, I had to send this a second time after trimming the > > e-mail because the mailing list bounces e-mail over > 40K. I suggest > > Karen next time publishes a draft :-) > > > > > > > > > ------------------------------------------------------------- > ----------- > > > > > > > ------------------------------------------------------------- > ----------- > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > _____________________________________________________________ > _________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > _____________________________________________________________ > _________ > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 19 06:33:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IipAF-0004wL-7Y; Fri, 19 Oct 2007 06:33:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IipAE-0004gD-5e for mip6@ietf.org; Fri, 19 Oct 2007 06:33:10 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iip9y-0006Wo-Eg for mip6@ietf.org; Fri, 19 Oct 2007 06:32:55 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1192789973!26795315!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 18054 invoked from network); 19 Oct 2007 10:32:53 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-15.tower-119.messagelabs.com with SMTP; 19 Oct 2007 10:32:53 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l9JAWrMc020526; Fri, 19 Oct 2007 03:32:53 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l9JAWpRZ020127; Fri, 19 Oct 2007 05:32:52 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l9JAWm4q020086; Fri, 19 Oct 2007 05:32:49 -0500 (CDT) Message-ID: <471887D0.9060303@gmail.com> Date: Fri, 19 Oct 2007 12:32:48 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] RE: DSMIP accommodation of split of v4 and v6 home link ? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000782-1, 17/10/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, 'Alexandru Petrescu' , Karen.Nielsen@tietoenator.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hesham Soliman wrote: > > GEorge, Karen, I support the initiative to have DS-MIPv6 > > support split > > IPv4-IPv6 home networks. > > > > I think it is reasonable to assume that an operator runs an > > IPv6-exclusive home network whose mobiles attach to a IPv4-exclusive > > Access Network. > > => This is NOT what Karen is talking about. She's talking about an IPv4-only > home network that offers IPv6 service.... I don't get it... but I prefer to give it up :-) Alex > > Hesham > > > > > Alex > > > > Karen.Nielsen@tietoenator.com wrote: > > > Hi George, > > > > > > Thanks a lot for your response. > > > > > > I will say, very briefly, what is our point. > > > I do not what to pollute the mailing list with too > > > much misguided 3GPP non-sense > > > if that is what this is (from my side, that is !). > > > > > > I agree with everything you say about address allocations > > > and how addresses moves along with the MN > > > when it moves to other non-3GPP accesses (controlled by > > (IPv4-)PMIPv6 or > > > DSMIPv6 respectively) > > > > > > The term "split of v4 and v6 home link" used by me, should > > be understood > > > NOT TO SAY that the v4 and v6 home link is > > administratively split in > > > between different operators, APN's or anything like that. > > > INSTEAD the intention is to split away the tight coupling > > in between the > > > v4 and the v6 home link which is present today in DSMIPv6 > > > THEREBY ACCOMMODATING pre-LTE/SAE (or ESP) architectures > > where the HOME > > > or VISITED 3GPP operator does not support > > > IPv6 PDP contexts. > > > > > > In this situation, then alone to support v4 handovers, the > > MN needs a v6 > > > HoA for DSMIPv6 signaling. > > > In addition, then it would not hurt, if the MN could also > > use this v6 > > > address for v6 connectivity via a reverse DSMIPv6 tunnel to its HA. > > > > > > What we describe is this situation and what we propose is a way to > > > handle this situation using DSMIPv6. > > > > > > I know that there are unclear point in the currents 3GPP > > specs, some (it > > > seems) due to the write-up being a mixture of what > > > could be achieved with 4285bis-like "DSMIPv6" operation > > and some which > > > can be achieved with IKEv2, IPSec and DSMIPv6. > > > In this context then the details we give is in the DSMIPv6 > > and IKEv2 > > > solution realm, but I would like to stress that the issue > > > as well as the solution is, on a high-level, not dependent > > on whether we > > > are speaking IKEv2 or 4285bis-like based authentication. > > > > > > If DSMIPv6 closes now, then I suppose that we will have to > > write this up > > > in a draft - :-) > > > > > > BR, Karen > > > > > > > > > > > ------------------------------------------------------------- > > ----------- > > > *From:* Tsirtsis, George [mailto:tsirtsis@qualcomm.com] > > > *Sent:* Wednesday, October 17, 2007 5:14 PM > > > *To:* Hesham Soliman; Nielsen Karen E; mip6@ietf.org; > > Kaas-Petersen > > > Christian > > > *Subject:* RE: [Mip6] RE: DSMIP accommodation of split > > of v4 and v6 > > > home link ? > > > > > > Karen, > > > > > > > > > > > > I have been involved with the 3GPP Rel8 design > > (ex-SAE, currently > > > called EPS) for some time now and I have to say your > > e-mail confuses > > > the hell out of me. I will not go into all the > > statements I consider > > > inaccurate in your e-mail (too long!), but I will just > > point out the > > > following: > > > > > > > > > > > > There is nothing in EPS architecture that requires or > > implies that > > > the IPv4 and IPv6 home links need to be split. I do > > not know what > > > gave you that idea but it is just not true. Whether PMIPv6 or > > > DSMIPv6 is used, the corresponding LMA or HA, is > > supposed to be the > > > owner of IPv4 and IPv6 HoAs for a given MN (UE in 3GPP terms). > > > > > > > > > > > > It is also not true that the MN (or UE) is never at > > its home link. > > > 3GPP accesses are typically expected to be configured > > as home links, > > > in which case PMIP/GTP connects the MN directly to the PDNGW > > > (playing the role of an LMA/HA). The address allocated > > to the MN via > > > such accesses is then meant to either be moved along > > with PMIPv6 or > > > be treated as a DSMIPv6 HoA when the MN moves to other > > (non-3GPP) > > > accesses. > > > > > > > > > > > > So, as a summary, I personally have a lot of issues > > with the EPS > > > architecture but what you describe is not own of them. > > > > > > > > > > > > BR > > > > > > George > > > > > > P.S.: BTW, I had to send this a second time after trimming the > > > e-mail because the mailing list bounces e-mail over > > 40K. I suggest > > > Karen next time publishes a draft :-) > > > > > > > > > > > > > > ------------------------------------------------------------- > > ----------- > > > > > > > > > > > ------------------------------------------------------------- > > ----------- > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _____________________________________________________________ > > _________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > _____________________________________________________________ > > _________ > > > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 19 07:02:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IipbQ-0000az-MY; Fri, 19 Oct 2007 07:01:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IipbO-0000WQ-LV; Fri, 19 Oct 2007 07:01:14 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IipbN-0007HQ-Q7; Fri, 19 Oct 2007 07:01:14 -0400 X-AuditID: c10cb581-000009340000122c-e0-47188e746acf Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 13:01:08 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 13:01:12 +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: [Mip6] DSMIPv6 and IKE Date: Fri, 19 Oct 2007 13:01:11 +0200 Message-ID: In-Reply-To: <4717FB41.8040807@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE Thread-Index: AcgR6Ki7DuOpFPVbTXqLGOYc9SVsDwAVfRZQ References: <4717FB41.8040807@azairenet.com> From: To: , X-OriginalArrivalTime: 19 Oct 2007 11:01:12.0272 (UTC) FILETIME=[5C698D00:01C8123F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: nemo@ietf.org, mip6@ietf.org, Pasi.Eronen@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The following is more or less what I originally thought would work, with a note on K bit and a note on ESP transport. I still think it will work. The MN is at some IPv6 capable foreign network, and it has already used IKE to negotiate both an ESP transport for BU/BA exchanges and some ESP tunnels for payload traffic. Now it moves to an IPv4-only foreign network. Depending on the K bit, there are two variants. First suppose the previous BU/BA exchange had cleared the K bit. A strict interpretation of this means either the IKE SA and all CHILD SAs are invalid and must be negotiated again, or MOBIKE must be used to move the IKE endpoint. Then the BU/BA exchange can be done. A perhaps less strict interpretation would say, that the IKE SA is a session between two node identities (reported in IDi and IDr payloads) and the ESP transport is between some IPv6 addresses in the nodes different from the interface addresses (namely the IPv6 home address (v6HoA) and the IPv6 home agent address (v6AgA)). Neither node identities nor IPv6 endpoint addresses have changed. So the ESP transport can still=20 be used to protect the IPv6 BU/BA, becoming IPv6 header (v6HoA, v6AgA) ESP transport mobility data which subsequently is prepended UDP (using DSMIPv6 ports) and IPv4 headers. Subsequently IKE can be negotiated or MOBIKE can be used to move the endpoints and any ESP tunnels for payload traffic. Next suppose the previous BU/BA exchange had set the K bit. In this case the less-strict-interpretation above can be used to do the BU/BA exchange, which makes one hole in the NAT box, followed by an IKE aliveness exchange, which makes another hole in the NAT box and is used to move the ESP tunnels for the payload traffic. Of course it would be nice if movement could be done in one exchange but reusing the IKE ports (ie UDP port 4500) gives a mixing of IKE and mobility and IPsec packets, which is kind of overloading the use of port 4500. Christian =20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > Sent: 19. oktober 2007 02:33 > To: Hesham Soliman > Cc: nemo@ietf.org; mip6@ietf.org; Pasi.Eronen@nokia.com > Subject: Re: [Mip6] DSMIPv6 and IKE >=20 > Hi Hesham and others, >=20 > Thanks for coming up with multiple solutions to this problem. > I have a few comments below. >=20 > Hesham Soliman wrote: >=20 > > Message format for solution 1: > > ------------------------------ > >=20 > > IPv4 header (src=3DV4ADDR, dst=3DHA_V4ADDR) UDP header=20 > (src=3DDSMIPv6-PORT,=20 > > dst=3DDSMIPv6-PORT) > > IPv6 header (src=3DV6HOA, dst=3DHAADDR) > > ESP header > > Mobility header > > BU [IPv4 HAO] > > IPv4 CoA option > > =20 > > And IKE messages would look like: > >=20 > > IPv4 header (src=3DV4ADDR, dst=3DHA_V4ADDR) UDP header=20 > (src=3DDSMIPv6-PORT,=20 > > dst=3DDSMIPv6-PORT) > > IPv6 header (src=3DV6HOA, dst=3DHAADDR) > > UDP header (src=3D500, dst=3D500) > > IKE message... > >=20 > > With this solution, the HA would essentially store the route=20 > > information for the IKE messages (the port and address=20 > received in the=20 > > outer header) and use them as dst address and port in the=20 > respose message. >=20 > This solution would work, but I am not too comfortable with=20 > the temporary tunnel being setup for IKEv2 messages. We don't=20 > have such a thing for a MIPv6 home agent today. All tunnel=20 > state is created only after the successful exchange of a BU/BAck. >=20 > This information must > > not be stored permanently in the HA, only to respond to the=20 > messages. > > Obviously, if the IKE daemon in the HA silents ignores an=20 > IKE message=20 > > then this information would have to be removed, so there=20 > would need to=20 > > be a timeout or inter-process communication in the=20 > implementation. For=20 > > the MN it's a lot simpler, source address selection for the IKE=20 > > implementation would always return the V6HoA. > >=20 > > Message format for solution 2: > > ------------------------------ > >=20 > > IPv4 header (src=3DV4ADDR, dst=3DHA_V4ADDR) UDP header=20 > (src=3DDSMIPv6-PORT,=20 > > dst=3DDSMIPv6-PORT) ESP header > > IPv6 header (src=3DV6HOA, dst=3DHAADDR) > > Mobility header > > BU [IPv4 HAO] > > IPv4 CoA option > >=20 > > In this option we run IKE over port 4500, but add=20 > > "DSMIPV6_UDP_ENCAPSULATION" > > notification when negotiating ESP SAs. Those ESP SAs would=20 > use src/dst=20 > > port DSMIPv6-PORT. >=20 > I would like to know more about the "cons" of this solution.=20 > In this solution the BU/BAck is always sent over port 4500=20 > using UDP ESP encapsultion, but actual DS-MIPv6 tunnel uses=20 > "DSMIPv6-PORT". This should work fine. >=20 > > But we would still have to rely on IKE to either implicitly or=20 > > explicitly update its ports and addresses whenever the=20 > mobile node moves. >=20 > But today we *do not* assume that the exchange of a BU/BAck=20 > always updates the IKE SA. What if we assume the 'K' flag is=20 > always cleared when the mobile node is attached to an IPv4=20 > access network. > Of course this would always result in an IKEv2 exchange, in=20 > addition to the BU/BAck exchange every time the CoA changes.=20 > This is not so bad, since this defaults to lack of support for the 'K' > flag. >=20 > Vijay >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 19 07:03:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IipdZ-0003PR-1V; Fri, 19 Oct 2007 07:03:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IipdX-0003NT-RY for mip6@ietf.org; Fri, 19 Oct 2007 07:03:27 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IipdW-0001rI-KR for mip6@ietf.org; Fri, 19 Oct 2007 07:03:27 -0400 X-AuditID: c10cb581-000009340000122c-2c-47188ef929f5 Received: from stingray.eu.tieto.com ([192.176.143.13]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 13:03:21 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 13:03:25 +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: [Mip6] RE: DSMIP accommodation of split of v4 and v6 home link ? Date: Fri, 19 Oct 2007 13:03:24 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: DSMIP accommodation of split of v4 and v6 home link ? Thread-Index: AcgSOok9AUOdvLroS/2cGu8JrLOxgwAADxEAAAA/ORA= References: <47188650.10106@gmail.com> From: To: , X-OriginalArrivalTime: 19 Oct 2007 11:03:25.0590 (UTC) FILETIME=[ABE04360:01C8123F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org >=20 >=20 > > GEorge, Karen, I support the initiative to have DS-MIPv6=20 > > support split=20 > > IPv4-IPv6 home networks. > >=20 > > I think it is reasonable to assume that an operator runs an=20 > > IPv6-exclusive home network whose mobiles attach to a=20 > IPv4-exclusive=20 > > Access Network. >=20 > =3D> This is NOT what Karen is talking about. She's talking=20 > about an IPv4-only > home network that offers IPv6 service.... >=20 Correct - and even more so: An Ipv4 only home network where handovers to v4 and/or v6 networks are controlled using DSMIPv6.=20 So the "Ipv6 service" is required alone for mobility support,=20 but can be used as well for IPv6 connectivity. The Ipv6 service (v6HoA) is provided NOT FROM the attach to the access network=20 BUT FROM the DSMIPv6 HA. With current DSMIPv6 this can be achieved, but then the MN will not be at home in the v4-only home network (because it is not at home v6 wise) and the consequence is that in order to have an v4 address that survives movements, the MN would have to acquire also an v4HoA from the HA=20 and all v4 communications would have to be ip-in-ip tunneled also over the v4-only home network. We would like to remove this extra tunnel. Why use DSMIPv6 at all for these scenarios - why not use some flavor of Mipv4 ? Because=20 DSMIPv6 it is the chosen future proof solution which will work also when the operator provides "direct ipv6 access" service. Karen > Hesham >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 19 07:25:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IipyE-0001VU-CE; Fri, 19 Oct 2007 07:24:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IipyD-0001BF-2n; Fri, 19 Oct 2007 07:24:49 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iipxw-0007vG-II; Fri, 19 Oct 2007 07:24:33 -0400 Received: from oaamta02sl.mx.bigpond.com ([124.190.106.219]) by omta04sl.mx.bigpond.com with ESMTP id <20071019112428.SKMP21837.omta04sl.mx.bigpond.com@oaamta02sl.mx.bigpond.com>; Fri, 19 Oct 2007 11:24:28 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta02sl.mx.bigpond.com with ESMTP id <20071019112428.YPJL10066.oaamta02sl.mx.bigpond.com@PC20005>; Fri, 19 Oct 2007 11:24:28 +0000 From: "Hesham Soliman" To: , Subject: RE: [Mip6] DSMIPv6 and IKE Date: Fri, 19 Oct 2007 21:24:15 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgR56BYSVhv7v+ERrmvTneqpYKa3QAQLYRgAARdbMAAAKdaoAABTTlg X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > => Basically the DSMIP6 code would have to capture any packet sent > > by the IKE daemon (known port)to the IPv6 home address that has > > already sent the original message. I think that would work. As you > > (Pasi) said, we would not create a route in the routing table, it > > would have to be treated as temporary state in the DSMIPv6 > > implementation. > > This requires some special kernel tweaks to capture all traffic > sent by the IKE daemon (and apply special processing to some part > of it). > > If this special requirement only applies to IKE traffic (but not > ESP), it might be almost doable...but it's not exactly nice, > as all the messages at this point are unauthenticated. => Right, no disagreement about that it's not nice :) I just don't think any of the solutions we came up with are nice. At least with this option we can do everything with one message and without modifying IKE. I guess the lack of authentication affects things for a very short time. That is, if state is stored for T then T = P where P is the time it takes the IKE daemon to process the message. It's not that bad really, just a little bit longer than any connection request that a server would receive. > > BTW, ESP actually has a similar problem vs. the virtual link > tunnel. When the BU arrives in the HA, it would look like this: > > IPv4 header (src=NATTED_V4ADDR, dst=HA_V4ADDR) > UDP header (src=NATTED_DSMIPv6-PORT, dst=DSMIPv6-PORT) > IPv6 header (src=V6HOA, dst=HAADDR) > ESP header > Mobility header > BU [IPv4 HAO] > IPv4 CoA option > > After doing the "virtual link" decapsulation the packet > would look like this: > > IPv6 header (src=V6HOA, dst=HAADDR) > ESP header > Mobility header > BU [IPv4 HAO] > IPv4 CoA option > > And after IPsec processing, the module actually parsing > the MH will see: > > IPv6 header (src=V6HOA, dst=HAADDR) > Mobility header > BU [IPv4 HAO] > IPv4 CoA option > > In other words: it won't see the information it really needs > (NATTED_V4ADDR and NATTED_DSMIPv6_PORT)! Again, the host > clearly has this information, but getting it might require > some serious architectural tweaking of IPsec and TCP/IP > stack in general.... => I don't think this needs architectural changes to IPsec implementations. The module that calls IPsec will already have this information. When the packet comes back from IPsec to the calling module it can append this information for the next function. This is totally transparent to IPsec and limited to the DSMIPv6 implementation. Thanks, Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 19 08:08:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiqcP-00033C-05; Fri, 19 Oct 2007 08:06:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiqcN-000303-Db; Fri, 19 Oct 2007 08:06:19 -0400 Received: from mail1.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiqcH-0004DA-LR; Fri, 19 Oct 2007 08:06:19 -0400 X-AuditID: c26e2f18-0000229400001c7c-c2-47189d8830c5 Received: from stingray.eu.tieto.com ([192.176.143.13]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 15:05:28 +0300 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 14:05:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] DSMIPv6 and IKE Date: Fri, 19 Oct 2007 14:05:47 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE Thread-Index: AcgQxeIU3weagNHDSpi4Htm5SEk99ABeeK7A References: From: To: , , X-OriginalArrivalTime: 19 Oct 2007 12:05:48.0763 (UTC) FILETIME=[62FB22B0:01C81248] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: Pasi.Eronen@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, I find that the problem description to be a little off from what I understood the problem to be and therefore I am also not totally in line with the proposed solutions. >=20 > Problem description: > -------------------- >=20 > DSMIPv6 obviously needs to provide a NAT traversal mechanism.=20 > The detection > of a NAT relies on the BU/BA message exchange. If a NAT were=20 > detected, UDP > encapsulation follows. Now, the problem is, for the BU to be=20 > sent, we need > to run IKE, which has it's own ports/traversal mechanisms.=20 > So if we run IKE and send the BU over the IKE tunnel, the HA=20 > will not know > what port number/address to send the MN's traffic to. Note that the MN > cannot include the port number=20 > and address because clearly it doesn't know what those values=20 > are since > they're allocated by the NAT.=20 >=20 > If we send the BU over port 4500 then we need to send another=20 > message (not > secured) using DSMIPv6 port to the HA with every handover. I=20 > think this is > unacceptable because we basically need to send two messages=20 > for handover and > one of them has zero security. So the idea of using two ports=20 > (4500 and > DSMIPv6 port) doesn't really work.=20 > And we don't have a way today of sending the BU separately=20 > over DSMIPv6 > port. I.e., what's described in the draft is not possible today.=20 A lot is said about sending the BU "over the IKE tunnel" and over the same ports=20 as IKE and IPSEC RFC 3948. Nothing is said about keeping the current design of sending the BU over a specific DSMIP port and then fixing the IKE and IPSEC port issues by a subsequent specific run of IKE to create the NAT port mappings for the 4500 port used by IKE and IPSec 3948.=20 By excluding this from the problem description, the solution is also excluded from the solution space. This way of looking at the problem do require multiple messages to complete the handover. Though still only one exchange for the BU to go through. The additional exchanges to ensure that all security SAs are up and running, that is: the IKE_SA which will ensure the continued aliveness of the ESP transport SA used to protect the BU as well as potential additional SAs for secure tunneling of payload=20 Is there a special reason why this solution is not looked at ? The solution does not fall into the category described above where it is said that one of the additional exchanges has zero security. > Solution space: > --------------- >=20 > There are basically three ideas that were discussed in a small group: >=20 > 1. Allow DSMIPv6 to look like a virtual link for IKE. Hence,=20 > IKE will simply > run over IPv6 and will not be aware of IPv4 at all.=20 >=20 > 2. Run IKE over port 4500, but add=20 > "DSMIPV6_UDP_ENCAPSULATION" notification > when negotiating ESP SAs >=20 > 3. Add a new message in MIP6 that creates a port mapping in=20 > the NAT. The BU > is still sent over 4500 and the new message is either=20 > insecure or (a long > shot) secured by a crypto token exchanged in the BU/BA.=20 Looking into the solutions proposed.=20 The first have the disadvantage that=20 we cannot benefit from IPSec and IKEs NAT traversal intelligence (e.g. RFC 3948), IPSEC SAs as IPSEC and IKE are now kept in the dark about the outer IP layers and NAT. Further it seems to make it even more complicated to handle IKE during movements, now IKE should be run on the CoA when in an Ipv6 foreign network (or Ipv6 homenetwork) but on the HoA when on an Ipv4 foreign network. Not so nice. Solution 2 seems to attempt to run IKE as normal but to have the RFC 3948 IPSEC SAs use a different port, namely the DSMIPv6 port. But then we distort the NAT traversality of IKE and IPSec which rely on the ports used in IKE to be the same as the port used in the 3948. (The latter has implications for when and how ports are updated in the IKE_SAs and the IPSec SAs when the NAT changes mappings). Solution 3 has the disadvantage that port 4500 is being overloaded. Today both IKE and 3948 ESP IPSec uses this port and there are rules for how one can detect whether a received packet is an IKE packet or an IPSec ESP packet, these rules are based on the fact that the SPI in the ESP header can never coincide with the beginning of the IKE header. With DSMIPv6, the next header will be an Ipv6 header and can it be guaranteed that the beginning of the Ipv6 header could not coincide with the SPI in the ESP header ? BR, Karen _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 19 14:16:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiwME-0006fA-Ec; Fri, 19 Oct 2007 14:14:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiwMC-00065w-VM for mip6@ietf.org; Fri, 19 Oct 2007 14:14:01 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiwLw-0006jX-PX for mip6@ietf.org; Fri, 19 Oct 2007 14:13:45 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 11:13:43 -0700 Message-ID: <4718F3D5.20606@azairenet.com> Date: Fri, 19 Oct 2007 11:13:41 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karen.Nielsen@tietoenator.com Subject: Re: [Mip6] RE: DSMIP accommodation of split of v4 and v6 home link ? References: <2309978910A6A6478C2C7585692B0AF4B950E6@NAEX16.na.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2007 18:13:43.0417 (UTC) FILETIME=[C8800690:01C8127B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Karen, Karen.Nielsen@tietoenator.com wrote: > The term "split of v4 and v6 home link" used by me, should be understood > NOT TO SAY that the v4 and v6 home link is administratively split in > between different operators, APN's or anything like that. > INSTEAD the intention is to split away the tight coupling in between the > v4 and the v6 home link which is present today in DSMIPv6 > THEREBY ACCOMMODATING pre-LTE/SAE (or ESP) architectures where the HOME > or VISITED 3GPP operator does not support > IPv6 PDP contexts. > > In this situation, then alone to support v4 handovers, the MN needs a v6 > HoA for DSMIPv6 signaling. > In addition, then it would not hurt, if the MN could also use this v6 > address for v6 connectivity via a reverse DSMIPv6 tunnel to its HA. The access network can be be IPv4-only. The mobile node does need an IPv6 Home Address all the time. If you are making a particular access link a home link, then the access network should understand IPv6. It can't be IPv4-only. Vijay > > What we describe is this situation and what we propose is a way to > handle this situation using DSMIPv6. > > I know that there are unclear point in the currents 3GPP specs, some (it > seems) due to the write-up being a mixture of what > could be achieved with 4285bis-like "DSMIPv6" operation and some which > can be achieved with IKEv2, IPSec and DSMIPv6. > In this context then the details we give is in the DSMIPv6 and IKEv2 > solution realm, but I would like to stress that the issue > as well as the solution is, on a high-level, n ot dependent on whether > we are speaking IKEv2 or 4285bis-like based authentication. > > If DSMIPv6 closes now, then I suppose that we will have to write this up > in a draft - :-) > > BR, Karen > > > *From:* Tsirtsis, George [mailto:tsirtsis@qualcomm.com] > *Sent:* Wednesday, October 17, 2007 5:14 PM > *To:* Hesham Soliman; Nielsen Karen E; mip6@ietf.org; Kaas-Petersen > Christian > *Subject:* RE: [Mip6] RE: DSMIP accommodation of split of v4 and v6 > home link ? > > Karen, > > > > I have been involved with the 3GPP Rel8 design (ex-SAE, currently > called EPS) for some time now and I have to say your e-mail confuses > the hell out of me. I will not go into all the statements I consider > inaccurate in your e-mail (too long!), but I will just point out the > following: > > > > There is nothing in EPS architecture that requires or implies that > the IPv4 and IPv6 home links need to be split. I do not know what > gave you that idea but it is just not true. Whether PMIPv6 or > DSMIPv6 is used, the corresponding LMA or HA, is supposed to be the > owner of IPv4 and IPv6 HoAs for a given MN (UE in 3GPP terms). > > > > It is also not true that the MN (or UE) is never at its home link. > 3GPP accesses are typically expected to be configured as home links, > in which case PMIP/GTP connects the MN directly to the PDNGW > (playing the role of an LMA/HA). The address allocated to the MN via > such accesses is then meant to either be moved along with PMIPv6 or > be treated as a DSMIPv6 HoA when the MN moves to other (non-3GPP) > accesses. > > > > So, as a summary, I personally have a lot of issues with the EPS > architecture but what you describe is not own of them. > > > > BR > > George > > P.S.: BTW, I had to send this a second time after trimming the > e-mail because the mailing list bounces e-mail over 40K. I suggest > Karen next time publishes a draft :-) > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 19 14:17:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiwPA-0002Hx-UR; Fri, 19 Oct 2007 14:17:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiwP8-0002Hc-Oz for mip6@ietf.org; Fri, 19 Oct 2007 14:17:02 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiwP8-0006qk-Cg for mip6@ietf.org; Fri, 19 Oct 2007 14:17:02 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 11:17:01 -0700 Message-ID: <4718F49C.7040708@azairenet.com> Date: Fri, 19 Oct 2007 11:17:00 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karen.Nielsen@tietoenator.com Subject: Re: [Mip6] RE: DSMIP accommodation of split of v4 and v6 home link ? References: <47188650.10106@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2007 18:17:01.0538 (UTC) FILETIME=[3E96E420:01C8127C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, alexandru.petrescu@gmail.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Karen.Nielsen@tietoenator.com wrote: > > An Ipv4 only home network where handovers to v4 and/or v6 networks > are controlled using DSMIPv6. You cannot deploy DS-MIPv6 in an IPv4-only home network. I don't believe the on-going work in 3GPP is trying to do this. Vijay > So the "Ipv6 service" is required alone for mobility support, > but can be used as well for IPv6 connectivity. > > The Ipv6 service (v6HoA) is provided NOT FROM the attach to the access > network > BUT FROM the DSMIPv6 HA. > > With current DSMIPv6 this can be achieved, but then the MN will > not be at home in the v4-only home network (because it is not at home v6 > wise) > and the consequence is that in order to have an v4 address that survives > movements, the MN > would have to acquire also an v4HoA from the HA > and all v4 communications would have to be ip-in-ip tunneled also over > the v4-only home network. > > We would like to remove this extra tunnel. > > Why use DSMIPv6 at all for these scenarios - why not use some flavor of > Mipv4 ? Because > DSMIPv6 it is the chosen future proof solution which > will work also when the operator provides "direct ipv6 access" service. > > Karen > > >> Hesham >> > > > > > > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 19 20:04:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij1nR-0007Yn-SC; Fri, 19 Oct 2007 20:02:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij1nR-0007Us-09; Fri, 19 Oct 2007 20:02:29 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ij1nG-0008Hq-Bn; Fri, 19 Oct 2007 20:02:24 -0400 Received: from oaamta01sl.mx.bigpond.com ([124.190.106.219]) by omta05sl.mx.bigpond.com with ESMTP id <20071020000141.JSMY16667.omta05sl.mx.bigpond.com@oaamta01sl.mx.bigpond.com>; Sat, 20 Oct 2007 00:01:41 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta01sl.mx.bigpond.com with ESMTP id <20071020000136.BEAP23516.oaamta01sl.mx.bigpond.com@PC20005>; Sat, 20 Oct 2007 00:01:36 +0000 From: "Hesham Soliman" To: , , Subject: RE: [Mip6] DSMIPv6 and IKE Date: Sat, 20 Oct 2007 10:01:27 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgQxeIU3weagNHDSpi4Htm5SEk99ABeeK7AABrNX5A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: Pasi.Eronen@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > DSMIPv6 obviously needs to provide a NAT traversal mechanism. > > The detection > > of a NAT relies on the BU/BA message exchange. If a NAT were > > detected, UDP > > encapsulation follows. Now, the problem is, for the BU to be > > sent, we need > > to run IKE, which has it's own ports/traversal mechanisms. > > So if we run IKE and send the BU over the IKE tunnel, the HA > > will not know > > what port number/address to send the MN's traffic to. Note > that the MN > > cannot include the port number > > and address because clearly it doesn't know what those values > > are since > > they're allocated by the NAT. > > > > If we send the BU over port 4500 then we need to send another > > message (not > > secured) using DSMIPv6 port to the HA with every handover. I > > think this is > > unacceptable because we basically need to send two messages > > for handover and > > one of them has zero security. So the idea of using two ports > > (4500 and > > DSMIPv6 port) doesn't really work. > > And we don't have a way today of sending the BU separately > > over DSMIPv6 > > port. I.e., what's described in the draft is not possible today. > > > A lot is said about sending the BU "over the IKE tunnel" and over the > same ports > as IKE and IPSEC RFC 3948. > > Nothing is said about keeping the current design of sending > the BU over > a specific DSMIP port and then fixing the IKE and IPSEC port issues > by a subsequent specific run of IKE to create the NAT port > mappings for > the 4500 port > used by IKE and IPSec 3948. => How can we send the BU over DSMIP port? Can you provide a solution for this? Hos is the SA established ? > > By excluding this from the problem > description, the solution is also excluded from the solution space. > > This way of looking at the problem do require multiple messages to > complete the handover. Though still only one exchange for > the BU to go > through. => The point is, there are alternatives that would solve the problem with two messages every handover, but why should we do that if we can avoid it? > The additional exchanges to ensure that all security SAs are up and > running, that is: > the IKE_SA which will ensure the continued aliveness of the ESP > transport SA used to protect the BU > as well as potential additional SAs for secure tunneling of payload > > Is there a special reason why this solution is not looked at ? => What is the solution? We have two classes of solutions in the three alternatives I sent. One class covers the "two message approach", the other (alternative 1) does it with one message. What other solution do you propose? Please send it to the list. I saw an email from Christian that I haven't read yet, may be that's what you mean. But it sounds like you're proposing another alternative for the "two message" approach. All things being the same, I'm personally not in favour of doing two messages every handover because we have two NAT traversal mechanisms running in parallel. Seems very inefficient. > > The solution does not fall into the category described above where > it is said that one of the additional exchanges has zero security. > > > Solution space: > > --------------- > > > > There are basically three ideas that were discussed in a > small group: > > > > 1. Allow DSMIPv6 to look like a virtual link for IKE. Hence, > > IKE will simply > > run over IPv6 and will not be aware of IPv4 at all. > > > > 2. Run IKE over port 4500, but add > > "DSMIPV6_UDP_ENCAPSULATION" notification > > when negotiating ESP SAs > > > > 3. Add a new message in MIP6 that creates a port mapping in > > the NAT. The BU > > is still sent over 4500 and the new message is either > > insecure or (a long > > shot) secured by a crypto token exchanged in the BU/BA. > > > Looking into the solutions proposed. > > The first have the disadvantage that > we cannot benefit from IPSec and IKEs NAT traversal > intelligence (e.g. > RFC 3948), > IPSEC SAs as IPSEC and IKE are now kept in the dark about > the outer IP > layers and NAT. => What is IKEs NAT traversal intelligence? We don't use 3948 but I don't understand what features we're missing. > Further it seems to make it even more complicated to handle > IKE during > movements, now IKE should > be run on the CoA when in an Ipv6 foreign network (or Ipv6 > homenetwork) > but on the HoA when on an Ipv4 foreign network. => No, you don't actually have to do that, but you can do what you suggest above. But at worste this is only an issue when changing admin domains. I still think it's much better to live with this corner case than having the norm be two messages per handover. I think we should optimise the more common case. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Oct 21 09:06:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjaPp-0007I6-QF; Sun, 21 Oct 2007 09:00:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjaPo-0007HU-4E; Sun, 21 Oct 2007 09:00:24 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjaPh-0005Bx-Le; Sun, 21 Oct 2007 09:00:24 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6872D198676; Sun, 21 Oct 2007 16:00:06 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id ECF761985F8; Sun, 21 Oct 2007 16:00:05 +0300 (EEST) Message-ID: <471B4D4A.1060700@piuha.net> Date: Sun, 21 Oct 2007 15:59:54 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Mobile IPv6 Mailing List , Dhcwg , draft-ietf-mip6-hiopt@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: Subject: [Mip6] AD review of draft-ietf-mip6-hiopt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I have made my AD review of this document. This document still needs a revision. Both due to comments given by Bernie Volz in DHC review (at the end of this e-mail), as well as for other reasons. I believe that the delivery of mobility information via DHCP is a valid approach. However, there are a number of details that still need work. The draft needs to talk about when such discovery is used. Its limitations must be described more accurately. And there are a number of issues in the description of the option formats. Substantial: > As part of configuring the initial TCP/IP parameters, a mobile node > can obtain home network information for the subnet it is directly > attached to, other subnets in the visited domain, or a subnet from > its home domain. This text makes it sound like a new home network is needed for everywhere the mobile node travels to. That is wrong. Suggested rewrite: As part of configuring the initial TCP/IP parameters, a mobile node can find itself a suitable home agent. Such a home agent might reside in the access network that the mobile node first connects to, or in a home network that the mobile node is associated with. > The mobile node MUST include > this option along with its Option Request option in its request. ... unless it already has configured home agent and other information for itself? It would be very expensive to do this on every movement, not to mention losing sessions if the home agent and home address are actually changed. That being said, the mobile node probably should do this occasionally to ensure that it is connected to the topologically best home agent. Yet you want to keep the old home agents still in use, to avoid losing your sessions... some text about this is probably needed either in this draft or somewhere else. > Home Network Identifier > > The identifier to specify the requested home network of > the mobile node. This field MUST be set in the form of user's > NAI [RFC4282]. The full NAI? This is problematic in many ways, including privacy, operation with mobile nodes that only know their domain but do not have a NAI, etc. Wouldn't it be more appropriate to simply provide the user's domain? > id-type > > The type of Home Network Identifier: > > 0 Visited domain (local ASP) > > 1 Target MSP > > 2 No preference This seems unnecessarily complicated. Is there some reason why you could simply include the target MSP domain information if it is known or an empty string otherwise and be allocated a local ASP in that case? > 3.2. MIP6 Relay Agent Option > > This option carries the RADIUS or Diameter attributes that are > received at the NAS from the AAAH. The DHCP relay agent sends this > option to the DHCP server in the Relay-Forward message. It does not carry RADIUS or Diameter attributes (and nor should it). Please align this text with the actual subattributes that you have. Also, it is inappropriate to assume that the information can only come from AAA. Presumably we'd like the mechanisms to be general enough that, for instance, manual configuration, link identifier, etc. could also be used to determine what mobility domains are appropriate for this client. Affects Section 4.2, too. > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_MIP6-HNINF | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | id-type | reserved | HNID_seq | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + > . sub-options . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > option-code > > OPTION_MIP6-HNINF (TBD). > > option-len > > Total length of the option-data in octets > > id-type > > The type of Home Network Identifier: > > 0 Visited domain (local ASP) > > 1 Home domain > > 2 No preference > > reserved > > An 8-bit field reserved for future use. The value MUST > be initialized to 0 by the sender and MUST be ignored by > the receiver. > > HNID_seq > > An 8-bit unsigned integer used for matching for Home Network > Identifier options when the mobile node has requested with > the multiple Home Network Identifier options with the same > id-type 1 but having different Home Network Identifiers. > > sub-options > > A series of sub-options carrying MIP6 bootstrap > information. Why is id-type field needed here? Just to be able to reply to the requested option? That does not seem so useful, IMHO. Or to be able to implement the Section 4.1 processing that is different depending on what type of network we are talking about? But wouldn't HNID_seq and the ordering of options be sufficient for this? > When the mobile node receives a Reply message from the DHCP server > and gets more than one home network information, it MUST have a > selection mechanism to determine which one to use for establishing a > Mobile IPv6 session. For example, if the mobile node acquires both > IPv6 address and FQDN of the home agent, it may try to use the > address information of the home agent first. I agree that a selection mechanism is needed. But is clear how I can evaluate an implementation's conformance to the MUST above. It might be better to simply enumerate in this draft what the order should be, and whether multiple in parallel contact attempts are required/allowed/discouraged. The subsequent text does do this, at least to an extent. Its not clear that the MUST above is needed if the text is complete. > However, how long the NAS should keep > the home information depends on the administrator's policy. When the > NAS does not keep the home information for the requesting mobile node > at the time of receiving the Information Request from the mobile > node, it may try to acquire the information by interacting with a AAA > server again through some other mechanisms which are not in the scope > of this document But such mechanisms do not exist in the general case. I would recommend simply requiring that the NAS needs to store the information. In any case, a NAS is required to know about the sessions it has. > 4.2. NAS/DHCP Relay Agent Behavior > > The NAS and the DHCP relay agent are assumed to be collocated in this > solution. This limitation needs to be stated upfront, in the Introduction. (And the limitation does not appear to be exactly what you say above. Presumably type 0 home agents can be requested without any relays.) Editorial: > OPTION_MIP6-HNID (TBD) Do you really have to mix underscore and dash in the same symbol? Bernie Volz's review: > 3.2.1. MIP6 Relay Agent Sub-option > > This sub-option carries the assigned home network information to the > DHCP server. > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sub-opt-code | sub-opt-len | reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . Home Network Information . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > sub-opt-code > > A 16-bit unsigned integer. The sub-option identifies the > type of the following Home Network Information field. > Possible values are: > > 1 Home subnet prefix > > 2 Complete IPv6 address of the home agent > > 3 FQDN of the home agent > > sub-opt-len > > An 8-bit unsigned integer. The length of the following > Home Network Information field + 1. > > > --> DHCPv6 uses 16-BIT option/suboption CODES AND 16-BIT LENGTHS, not > 8-bit lengths! And mixing 16/8 bits is the WORST thing that they could > ever do. My recommendation would be to use 16-bit codes and 16-bit > lengths. PERIOD. > > This same issue exists in 3.3.1, Home Network Information Sub-option. > > > Section 4 (and 4.3 in particular) mentions the ORO option but doesn't > make it clear that the OPTION_MIP6-HNINF option code *MUST* be included > in the ORO if the client ever wants this option returned by the server. > > In 4.1, is stated: > In this message > the mobile node (DHCP client) SHALL include the Option Code for the > Home Network Identifier option in the OPTION_ORO. > > But, why would the client include the OPTION_MIP6-HNID in the ORO, as > this is FROM CLIENT TO SERVER. I think they meant OPTION_MIP6-HNINF. > Section 3.1 states: > > 3.1. Home Network Identifier Option > > This option is used to indicate the target home network requested by > the mobile node to the DHCP server. The mobile node MUST include > this option along with its Option Request option in its request. > > > Personally, they need to go back to clean up this draft. It is NOT > acceptable and full of mistakes. > > I haven't studied it carefully, but as I've already found the above > issues, more work is needed to clean it up. > Oh, you can add another issue to this draft. Two of the email addresses > in the draft are bad: > > 5.1.0 - Unknown address error 550-'5.1.1 ... > User unknown' > 5.1.0 - Unknown address error 550-'5.1.1 No such user > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 22 05:46:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijtqc-0002eC-JU; Mon, 22 Oct 2007 05:45:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijtqa-0002bd-C1; Mon, 22 Oct 2007 05:45:20 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjtqO-00079W-84; Mon, 22 Oct 2007 05:45:15 -0400 X-AuditID: c10cb581-0000122400000124-4b-471c710d79a8 Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 11:44:45 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 11:44:46 +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: [Mip6] DSMIPv6 and IKE Date: Mon, 22 Oct 2007 11:44:45 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE Thread-Index: AcgQxeIU3weagNHDSpi4Htm5SEk99ABeeK7AABrNX5AAdSpmEA== References: From: To: , , X-OriginalArrivalTime: 22 Oct 2007 09:44:46.0131 (UTC) FILETIME=[2E193830:01C81490] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: Pasi.Eronen@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org =20 Hi Hesham, >=20 > =3D> How can we send the BU over DSMIP port? Can you provide a=20 > solution for > this?=20 > Hos is the SA established ?=20 >=20 Pls. see below. > >=20 > > By excluding this from the problem > > description, the solution is also excluded from the solution space. > >=20 > > This way of looking at the problem do require multiple messages to > > complete the handover. Though still only one exchange for=20 > > the BU to go > > through. >=20 > =3D> The point is, there are alternatives that would solve the=20 > problem with > two messages every handover, but why should we do that if we=20 > can avoid it?=20 >=20 Yes, 2 messages is a con, but it may still be less worse that the cons of the proposed 1 message alternatives. > > The additional exchanges to ensure that all security SAs are up and > > running, that is: > > the IKE_SA which will ensure the continued aliveness of the ESP > > transport SA used to protect the BU > > as well as potential additional SAs for secure tunneling=20 > of payload=20 > >=20 > > Is there a special reason why this solution is not looked at ? >=20 > =3D> What is the solution? We have two classes of solutions in the = three > alternatives I sent. One class covers the "two message=20 > approach", the other > (alternative 1) does it with one message. What other solution do you > propose? Please send it to the list. I saw an email from=20 > Christian that I > haven't read yet, may be that's what you mean. But it sounds=20 > like you're > proposing another alternative for the "two message" approach.=20 > All things > being the same, I'm personally not in favour of doing two=20 > messages every > handover because we have two NAT traversal mechanisms running=20 > in parallel. > Seems very inefficient. >=20 Yes, but it is only in the NAT traversal situation that we have 2 messages. When there is no NAT detected in the BU, the second message exchange (IKE run, pls. see below) need not be run. Yes, it is inefficient, but perhaps it is as efficient as it can be (?). > >=20 > >=20 > > Looking into the solutions proposed.=20 > >=20 > > The first have the disadvantage that=20 > > we cannot benefit from IPSec and IKEs NAT traversal=20 > > intelligence (e.g. > > RFC 3948), > > IPSEC SAs as IPSEC and IKE are now kept in the dark about=20 > > the outer IP > > layers and NAT. >=20 > =3D> What is IKEs NAT traversal intelligence? We don't use 3948=20 > but I don't > understand what features we're missing. How should we handle IPSec tunneling of payload from the MN to the HA: If IKE is kept unaware of the DSMIP tunnel, then it cannot negotiate Ipv6 in Ipv4 ESP tunnels and specifically it can not negotiate RFC 3948 tunnels for Ipv6 in Udp in Ipv4 tunnels for NAT traversal. Consequently IPSec tunneling of payload will have to be double=20 tunneled on the MN HA link, i.e.,: IPv4-UDP-IPv6-ESP-IPv6-Payload (for NAT traversal) or=20 IPv4-IPv6-ESP-IPv6-Payload for no NAT traversal. Whereas today when IKE uses the CoA, it can negotiate RFC 3948 tunnels for this purpose, which will result in: IPv4-UDP-ESP-IPv6-Payload=20 or standard tunnels IPv4-ESP-IPv6-Payload=20 for no NAT traversal. yes, IPSec tunneling is only a SHOULD, and a corner case, as RO is no point really on an Ipv4 only link. But is that the same as we will go with this (inefficient :-) way of doing it ? Perhaps there is another way, without the double tunneling, which is escaping me ? I would like to advocate the solution described by Christian. He has described the solution in=20 a couple of mails, please see the last mail. I will here only highlight the details. Solution 4. Run BU, BACK as described in DSMIP to a specific port. The IPSEC transport ESP negotiated=20 for IPv6 can be used to protect the BU, BACK. The DSMIP layer will remove (respectively add) the outer IP-UDP headers before (respectively after) the packet is being IPSec decrypted (respectively encrypted). IKE can negotiate the transport SAs regardless of whether the CoA is the Ipv6 HoA or an Ipv4 (private or public) or and Ipv6 CoA. As in standard Mipv6 the transport SA in place is expected to be OK although the IKE SA is no longer valid as the MN end-point (the CoA) has moved.=20 When the BU detects no NAT. The IKE SA and all IPSec tunnel SAs can be updated as in standard MIPv6 as no UDP ports are in play, only the new CoA must be inserted in the IKE SA and the IPSEC SA. When the BU/BACK exchange informs the MN that a NAT was present then it need to start en IKE exchange so the ports in the IKE SA and associated IPSEC tunnel SAs can be appropriately updated. Now we are done. Yes it requires multiple exchanges to fix the IKE and IPSEC ports, but only in the case where a NAT is detected. Further it is only the traffic which relies on IPSEc tunneling which is impacted by the delay caused by the=20 additional IKE exchange. Hope this explains. BR, Karen _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 22 05:52:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjtxB-0005Av-Sf; Mon, 22 Oct 2007 05:52:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjtxA-00059d-89; Mon, 22 Oct 2007 05:52:08 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ijtx9-0004C4-Fa; Mon, 22 Oct 2007 05:52:08 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9M9pjnt010249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Oct 2007 02:51:46 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9M9pjRe000375; Mon, 22 Oct 2007 02:51:45 -0700 (PDT) Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Oct 2007 02:51:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] DSMIPv6 and IKE Date: Mon, 22 Oct 2007 02:51:42 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF4B9543C@NAEX16.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE Thread-Index: AcgQxeIU3weagNHDSpi4Htm5SEk99ABeeK7AABrNX5AAeVJfYA== References: From: "Tsirtsis, George" To: "Hesham Soliman" , , , X-OriginalArrivalTime: 22 Oct 2007 09:51:45.0210 (UTC) FILETIME=[27E399A0:01C81491] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: Pasi.Eronen@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi all, I also think that requiring more messages on every handoff should not be done lightly here. The solution proposed by Hesham seems efficient and others have also indicates that although it requires special processing of a limited number of messages, it looks doable....so IMO this is the preferred option here. Thanks George -----Original Message----- From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 Sent: Saturday, October 20, 2007 1:01 AM To: Karen.Nielsen@tietoenator.com; mip6@ietf.org; nemo@ietf.org Cc: Pasi.Eronen@nokia.com Subject: RE: [Mip6] DSMIPv6 and IKE > > DSMIPv6 obviously needs to provide a NAT traversal mechanism.=20 > > The detection > > of a NAT relies on the BU/BA message exchange. If a NAT were=20 > > detected, UDP > > encapsulation follows. Now, the problem is, for the BU to be=20 > > sent, we need > > to run IKE, which has it's own ports/traversal mechanisms.=20 > > So if we run IKE and send the BU over the IKE tunnel, the HA=20 > > will not know > > what port number/address to send the MN's traffic to. Note=20 > that the MN > > cannot include the port number=20 > > and address because clearly it doesn't know what those values=20 > > are since > > they're allocated by the NAT.=20 > >=20 > > If we send the BU over port 4500 then we need to send another=20 > > message (not > > secured) using DSMIPv6 port to the HA with every handover. I=20 > > think this is > > unacceptable because we basically need to send two messages=20 > > for handover and > > one of them has zero security. So the idea of using two ports=20 > > (4500 and > > DSMIPv6 port) doesn't really work.=20 > > And we don't have a way today of sending the BU separately=20 > > over DSMIPv6 > > port. I.e., what's described in the draft is not possible today.=20 >=20 >=20 > A lot is said about sending the BU "over the IKE tunnel" and over the > same ports=20 > as IKE and IPSEC RFC 3948. >=20 > Nothing is said about keeping the current design of sending=20 > the BU over > a specific DSMIP port and then fixing the IKE and IPSEC port issues > by a subsequent specific run of IKE to create the NAT port=20 > mappings for > the 4500 port > used by IKE and IPSec 3948.=20 =3D> How can we send the BU over DSMIP port? Can you provide a solution for this?=20 Hos is the SA established ?=20 >=20 > By excluding this from the problem > description, the solution is also excluded from the solution space. >=20 > This way of looking at the problem do require multiple messages to > complete the handover. Though still only one exchange for=20 > the BU to go > through. =3D> The point is, there are alternatives that would solve the problem with two messages every handover, but why should we do that if we can avoid it?=20 > The additional exchanges to ensure that all security SAs are up and > running, that is: > the IKE_SA which will ensure the continued aliveness of the ESP > transport SA used to protect the BU > as well as potential additional SAs for secure tunneling of payload=20 >=20 > Is there a special reason why this solution is not looked at ? =3D> What is the solution? We have two classes of solutions in the three alternatives I sent. One class covers the "two message approach", the other (alternative 1) does it with one message. What other solution do you propose? Please send it to the list. I saw an email from Christian that I haven't read yet, may be that's what you mean. But it sounds like you're proposing another alternative for the "two message" approach. All things being the same, I'm personally not in favour of doing two messages every handover because we have two NAT traversal mechanisms running in parallel. Seems very inefficient. >=20 > The solution does not fall into the category described above where > it is said that one of the additional exchanges has zero security. >=20 > > Solution space: > > --------------- > >=20 > > There are basically three ideas that were discussed in a=20 > small group: > >=20 > > 1. Allow DSMIPv6 to look like a virtual link for IKE. Hence,=20 > > IKE will simply > > run over IPv6 and will not be aware of IPv4 at all.=20 > >=20 > > 2. Run IKE over port 4500, but add=20 > > "DSMIPV6_UDP_ENCAPSULATION" notification > > when negotiating ESP SAs > >=20 > > 3. Add a new message in MIP6 that creates a port mapping in=20 > > the NAT. The BU > > is still sent over 4500 and the new message is either=20 > > insecure or (a long > > shot) secured by a crypto token exchanged in the BU/BA.=20 >=20 >=20 > Looking into the solutions proposed.=20 >=20 > The first have the disadvantage that=20 > we cannot benefit from IPSec and IKEs NAT traversal=20 > intelligence (e.g. > RFC 3948), > IPSEC SAs as IPSEC and IKE are now kept in the dark about=20 > the outer IP > layers and NAT. =3D> What is IKEs NAT traversal intelligence? We don't use 3948 but I don't understand what features we're missing. > Further it seems to make it even more complicated to handle=20 > IKE during > movements, now IKE should > be run on the CoA when in an Ipv6 foreign network (or Ipv6=20 > homenetwork) > but on the HoA when on an Ipv4 foreign network. =3D> No, you don't actually have to do that, but you can do what you suggest above. But at worste this is only an issue when changing admin domains. I still think it's much better to live with this corner case than having the norm be two messages per handover. I think we should optimise the more common case.=20 Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mext-bounces@ietf.org Mon Oct 22 05:59:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iju1d-0000kY-A9; Mon, 22 Oct 2007 05:56:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iju1b-0000jP-J7 for mext@ietf.org; Mon, 22 Oct 2007 05:56:43 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iju1S-0007fT-56 for mext@ietf.org; Mon, 22 Oct 2007 05:56:43 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id EDBFF198683; Mon, 22 Oct 2007 12:56:27 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 943D2198670; Mon, 22 Oct 2007 12:56:27 +0300 (EEST) Message-ID: <471C3B28.7020107@piuha.net> Date: Mon, 22 Oct 2007 08:54:48 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Jouni Korhonen Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt References: <4700A05C.3070905@piuha.net> In-Reply-To: <4700A05C.3070905@piuha.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 1.4 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org The new version addresses the concerns I had. Thanks. The document will now be moved forward. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mip6-bounces@ietf.org Mon Oct 22 09:58:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijxmf-0006G3-M9; Mon, 22 Oct 2007 09:57:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjxlG-0004Gl-0w; Mon, 22 Oct 2007 09:56:06 -0400 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ijxky-0003Dd-Eo; Mon, 22 Oct 2007 09:55:55 -0400 Received: from oaamta01sl.mx.bigpond.com ([124.190.106.219]) by omta02sl.mx.bigpond.com with ESMTP id <20071022135532.EZUU20745.omta02sl.mx.bigpond.com@oaamta01sl.mx.bigpond.com>; Mon, 22 Oct 2007 13:55:32 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta01sl.mx.bigpond.com with ESMTP id <20071022135531.ZCDY23516.oaamta01sl.mx.bigpond.com@PC20005>; Mon, 22 Oct 2007 13:55:31 +0000 From: "Hesham Soliman" To: , , Subject: RE: [Mip6] DSMIPv6 and IKE Date: Mon, 22 Oct 2007 23:55:21 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgQxeIU3weagNHDSpi4Htm5SEk99ABeeK7AABrNX5AAdSpmEAAG8pfg X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: Pasi.Eronen@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > > > => The point is, there are alternatives that would solve the > > problem with > > two messages every handover, but why should we do that if we > > can avoid it? > > > > Yes, 2 messages is a con, but it may still be less worse > that the cons of the proposed 1 message alternatives. => It's difficult to say what "less worse" means unless you can quantify it. > > => What is the solution? We have two classes of solutions > in the three > > alternatives I sent. One class covers the "two message > > approach", the other > > (alternative 1) does it with one message. What other > solution do you > > propose? Please send it to the list. I saw an email from > > Christian that I > > haven't read yet, may be that's what you mean. But it sounds > > like you're > > proposing another alternative for the "two message" approach. > > All things > > being the same, I'm personally not in favour of doing two > > messages every > > handover because we have two NAT traversal mechanisms running > > in parallel. > > Seems very inefficient. > > > > Yes, but it is only in the NAT traversal situation that we have 2 > messages. => Which is most of the time! > > > Looking into the solutions proposed. > > > > > > The first have the disadvantage that > > > we cannot benefit from IPSec and IKEs NAT traversal > > > intelligence (e.g. > > > RFC 3948), > > > IPSEC SAs as IPSEC and IKE are now kept in the dark about > > > the outer IP > > > layers and NAT. > > > > => What is IKEs NAT traversal intelligence? We don't use 3948 > > but I don't > > understand what features we're missing. > > How should we handle IPSec tunneling of payload from the MN > to the HA: > > If IKE is kept unaware of the DSMIP tunnel, then it cannot negotiate > Ipv6 in Ipv4 ESP tunnels and specifically it can not > negotiate RFC 3948 > tunnels > for Ipv6 in Udp in Ipv4 tunnels for NAT traversal. => Forgetting about 3948 tunnels because it's not an accident that we don't use it, why can't IKE negotiate those tunnels? > > IPv4-UDP-IPv6-ESP-IPv6-Payload (for NAT traversal) > > or > > IPv4-IPv6-ESP-IPv6-Payload > > for no NAT traversal. => Correct, I thought you were saying that it can't be done (above). > > Whereas today when IKE uses the CoA, it can negotiate RFC > 3948 tunnels > for this purpose, > which will result in: > > IPv4-UDP-ESP-IPv6-Payload > > or standard tunnels > > IPv4-ESP-IPv6-Payload > > for no NAT traversal. > > yes, IPSec tunneling is only a SHOULD, and a corner case, as RO is no > point really on an Ipv4 only link. > But is that the same as we will go with this (inefficient :-) way of > doing it ? > > Perhaps there is another way, without the double tunneling, which is > escaping me ? => I don't know if there can be another way and I doubt that there is one. I agree that we should try to reduce the tunnels but this is the choice that we're faced with. an extra header for the VPN case Vs two RTTs for handover. I'd like to get rid of both problems but it's not possible because of NATs. > Solution 4. > > Run BU, BACK as described in DSMIP to a specific port. The IPSEC > transport ESP negotiated > for IPv6 can be used to protect the BU, BACK. The DSMIP layer will > remove (respectively add) > the outer IP-UDP headers before (respectively after) the > packet is being > IPSec decrypted (respectively encrypted). > > IKE can negotiate the transport SAs regardless of whether > the CoA is the > Ipv6 HoA or an Ipv4 (private or public) > or and Ipv6 CoA. > > As in standard Mipv6 the transport SA in place is expected to be OK > although the IKE SA is no longer > valid as the MN end-point (the CoA) has moved. > > When the BU detects no NAT. The IKE SA and all IPSec tunnel > SAs can be > updated as in standard MIPv6 as no UDP ports are in play, > only the new CoA must be inserted in the IKE SA and the IPSEC SA. > > When the BU/BACK exchange informs the MN that a NAT was > present then it > need to start en IKE exchange so the > ports in the IKE SA and associated IPSEC tunnel SAs can be > appropriately > updated. > > Now we are done. > > Yes it requires multiple exchanges to fix the IKE and IPSEC > ports, but > only in the case where a NAT is detected. => Yes of course, but that's the majority of the cases! > Further it is only the traffic which relies on IPSEc > tunneling which is > impacted by the delay caused by the > additional IKE exchange. > > Hope this explains. => Ok but I want to make it clear that this falls under the "two message" class of solutions. You seemed to indicate in your last email that there was a class of solutions missing. So we still have to consider the same tradeoff that we're talking about now. I'm assuming that when you say IKE sets up the SA, you mean that there is no modification needed for IKE, correct? I'm not an IKE expert so can you elaborate on the IKE messages that will be sent over port 4500 to setup an SA for DSMIPv6 ports? Hesham > > BR, Karen > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 22 10:46:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjyX4-0001UZ-Bv; Mon, 22 Oct 2007 10:45:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjyX3-0001PZ-37; Mon, 22 Oct 2007 10:45:29 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjyWw-0005os-S4; Mon, 22 Oct 2007 10:45:29 -0400 X-AuditID: c10cb581-00002318000021cc-ca-471cb7790aed Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 16:45:13 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 16:45:13 +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: [Mip6] DSMIPv6 and IKE Date: Mon, 22 Oct 2007 16:45:12 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE Thread-Index: AcgQxeIU3weagNHDSpi4Htm5SEk99ABeeK7AABrNX5AAdSpmEAAG8pfgAAeKn8A= References: From: To: , , , X-OriginalArrivalTime: 22 Oct 2007 14:45:13.0435 (UTC) FILETIME=[273582B0:01C814BA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Pasi.Eronen@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Here is another proposal, maybe not exactly another class of solutions, but reducing the problem to one packet exchange. In the two-message approach, two entries are made in the NAT box: one for an IKE exchange,=20 another for the BU/BA exchange. The NAT entry for IKE is used not just for IKE packets but by all ESP tunnel packets. So this entry is kept=20 alive in the NAT box by a lot of traffic. That may not be the case=20 for the BU/BA exchange, which will happen only occasionally when the=20 lifetime is to be renewed. Why not introduce a new payload in IKE in which the BU or the BA packet is carried? =20 =20 This looks a little like MOBIKE, but MOBIKE is always doing two=20 exchanges because the responder has to verify the initiator=20 has sent a correct IP address. This verification can be done by=20 examining the BU packet as transported by IKE. The new IKE payload for the BU and BA will work similar to the way EAP messages are carried back and forth by IKE.=20 Christian > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: 22. oktober 2007 15:55 > To: Nielsen Karen E; mip6@ietf.org; nemo@ietf.org > Cc: Pasi.Eronen@nokia.com > Subject: RE: [Mip6] DSMIPv6 and IKE >=20 >=20 > =3D> Ok but I want to make it clear that this falls under the=20 > "two message" > class of solutions. You seemed to indicate in your last email=20 > that there was > a class of solutions missing. So we still have to consider=20 > the same tradeoff > that we're talking about now. I'm assuming that when you say=20 > IKE sets up the > SA, you mean that there is no modification needed for IKE,=20 > correct? I'm not > an IKE expert so can you elaborate on the IKE messages that=20 > will be sent > over port 4500 to setup an SA for DSMIPv6 ports?=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 22 16:54:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik4Gb-0004Q9-VX; Mon, 22 Oct 2007 16:52:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik4GZ-0004Mh-Vr; Mon, 22 Oct 2007 16:52:52 -0400 Received: from mail1.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik4GY-0001Jc-Up; Mon, 22 Oct 2007 16:52:51 -0400 X-AuditID: c26e2f18-00001ea8000021a8-2e-471d0d8c22cd Received: from camaro.eu.tieto.com ([192.176.143.42]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 23:52:28 +0300 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 22:52:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] DSMIPv6 and IKE Date: Mon, 22 Oct 2007 22:51:29 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE Thread-Index: AcgQxeIU3weagNHDSpi4Htm5SEk99ABeeK7AABrNX5AAdSpmEAAG8pfgABFwDSA= References: From: To: X-OriginalArrivalTime: 22 Oct 2007 20:52:48.0168 (UTC) FILETIME=[80DAB280:01C814ED] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham,=20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Monday, October 22, 2007 3:55 PM > To: Nielsen Karen E; mip6@ietf.org; nemo@ietf.org > Cc: Pasi.Eronen@nokia.com > Subject: RE: [Mip6] DSMIPv6 and IKE >=20 >=20 > > >=20 > > > =3D> The point is, there are alternatives that would solve the=20 > > > problem with > > > two messages every handover, but why should we do that if we=20 > > > can avoid it?=20 > > >=20 > >=20 > > Yes, 2 messages is a con, but it may still be less worse > > that the cons of the proposed 1 message alternatives. >=20 > =3D> It's difficult to say what "less worse" means unless you=20 > can quantify it. In my opinion, I was doing that below. But I apologize for=20 giving soft words instead of technical arguments. >=20 >=20 > > > =3D> What is the solution? We have two classes of solutions=20 > > in the three > > > alternatives I sent. One class covers the "two message=20 > > > approach", the other > > > (alternative 1) does it with one message. What other=20 > > solution do you > > > propose? Please send it to the list. I saw an email from=20 > > > Christian that I > > > haven't read yet, may be that's what you mean. But it sounds=20 > > > like you're > > > proposing another alternative for the "two message" approach.=20 > > > All things > > > being the same, I'm personally not in favour of doing two=20 > > > messages every > > > handover because we have two NAT traversal mechanisms running=20 > > > in parallel. > > > Seems very inefficient. > > >=20 > >=20 > > Yes, but it is only in the NAT traversal situation that we have 2 > > messages. >=20 > =3D> Which is most of the time!=20 >=20 OK, I accept that. > > > > Looking into the solutions proposed.=20 > > > >=20 > > > > The first have the disadvantage that=20 > > > > we cannot benefit from IPSec and IKEs NAT traversal=20 > > > > intelligence (e.g. > > > > RFC 3948), > > > > IPSEC SAs as IPSEC and IKE are now kept in the dark about=20 > > > > the outer IP > > > > layers and NAT. > > >=20 > > > =3D> What is IKEs NAT traversal intelligence? We don't use 3948=20 > > > but I don't > > > understand what features we're missing. > >=20 > > How should we handle IPSec tunneling of payload from the MN=20 > > to the HA: > >=20 > > If IKE is kept unaware of the DSMIP tunnel, then it cannot=20 > negotiate > > Ipv6 in Ipv4 ESP tunnels and specifically it can not=20 > > negotiate RFC 3948 > > tunnels > > for Ipv6 in Udp in Ipv4 tunnels for NAT traversal. >=20 > =3D> Forgetting about 3948 tunnels because it's not an accident=20 > that we don't > use it, why can't IKE negotiate those tunnels?=20 >=20 Why don't you want 3948 tunnels ? > >=20 > > IPv4-UDP-IPv6-ESP-IPv6-Payload (for NAT traversal) > >=20 > > or=20 > >=20 > > IPv4-IPv6-ESP-IPv6-Payload > >=20 > > for no NAT traversal. >=20 > =3D> Correct, I thought you were saying that it can't be done (above). I was saying that IKEv2 in this situation cannot negotiate Ipv6 in Ipv4 ESP tunnels, which is true. >=20 > >=20 > > Whereas today when IKE uses the CoA, it can negotiate RFC=20 > > 3948 tunnels > > for this purpose, > > which will result in: > >=20 > > IPv4-UDP-ESP-IPv6-Payload=20 > >=20 > > or standard tunnels > >=20 > > IPv4-ESP-IPv6-Payload=20 > >=20 > > for no NAT traversal. > >=20 > > yes, IPSec tunneling is only a SHOULD, and a corner case,=20 > as RO is no > > point really on an Ipv4 only link. > > But is that the same as we will go with this (inefficient=20 > :-) way of > > doing it ? > >=20 > > Perhaps there is another way, without the double=20 > tunneling, which is > > escaping me ? >=20 > =3D> I don't know if there can be another way and I doubt that=20 > there is one. I > agree that we should try to reduce the tunnels but this is=20 > the choice that > we're faced with. an extra header for the VPN case Vs two=20 > RTTs for handover. > I'd like to get rid of both problems but it's not possible=20 > because of NATs. >=20 > > Solution 4. > >=20 > > Run BU, BACK as described in DSMIP to a specific port. The IPSEC > > transport ESP negotiated=20 > > for IPv6 can be used to protect the BU, BACK. The DSMIP layer will > > remove (respectively add) > > the outer IP-UDP headers before (respectively after) the=20 > > packet is being > > IPSec decrypted (respectively encrypted). > >=20 > > IKE can negotiate the transport SAs regardless of whether=20 > > the CoA is the > > Ipv6 HoA or an Ipv4 (private or public) > > or and Ipv6 CoA. > >=20 > > As in standard Mipv6 the transport SA in place is expected to be OK > > although the IKE SA is no longer > > valid as the MN end-point (the CoA) has moved.=20 > >=20 > > When the BU detects no NAT. The IKE SA and all IPSec tunnel=20 > > SAs can be > > updated as in standard MIPv6 as no UDP ports are in play, > > only the new CoA must be inserted in the IKE SA and the IPSEC SA. > >=20 > > When the BU/BACK exchange informs the MN that a NAT was=20 > > present then it > > need to start en IKE exchange so the > > ports in the IKE SA and associated IPSEC tunnel SAs can be=20 > > appropriately > > updated. > >=20 > > Now we are done. > >=20 > > Yes it requires multiple exchanges to fix the IKE and IPSEC=20 > > ports, but > > only in the case where a NAT is detected. >=20 > =3D> Yes of course, but that's the majority of the cases!=20 Ok, I accept. >=20 > > Further it is only the traffic which relies on IPSEc=20 > > tunneling which is > > impacted by the delay caused by the=20 > > additional IKE exchange. > >=20 > > Hope this explains. >=20 > =3D> Ok but I want to make it clear that this falls under the=20 > "two message" > class of solutions. You seemed to indicate in your last email=20 > that there was > a class of solutions missing.=20 I am sorry if I mislead you. I was only trying to say that this 2 message exchange=20 solution wasn't one in which one of the messages had zero security, so I felt that it was missing from the general descriptions about 2 message exchange solutions given in your mail. I wanted to make sure that this solution was discarded for the right reasons. So we still have to consider=20 > the same tradeoff > that we're talking about now. I think that it is worthwhile to notice that the handover for all traffic which is not IPSec tunnel encapsulated on the MN=3DHA path is achieved in 1 RTT. I'm assuming that when you say=20 > IKE sets up the > SA, you mean that there is no modification needed for IKE,=20 > correct? I am not sure what you mean here.=20 But standard IKEv2 can negotiate=20 * the Ipv6 transport ESP SA from the MN to the HA required for Ipv6 level protection of the BU * standard IPSec tunnel (Ipv6 in Ipv4 or Ipv4 in Ipv4), the local end-point in the outer Ipv4 header of the tunnel SA being the HA's Ipv4 address, when there is no NAT * and, when there's a NAT in between the MN and the HA, ESP UDP encapsulated tunnel IPSec Sas (RFC 3948), the local end-point in the outer Ipv4 header of the tunnel SA being the HA's Ipv4 address and with an UDP header inserted. I'm not > an IKE expert so can you elaborate on the IKE messages that=20 > will be sent > over port 4500 to setup an SA for DSMIPv6 ports?=20 I am not entirely sure what you mean. If you mean whether IKE can negotiate an IPSEC ESP SA that takes an Ipv6 (or an Ipv4 packet) packet, encrypts it and append and Ipv4 header, UDP header to DSMIP port and ESP=20 header (in reverse order), then I don't think that standard IKE can do that over port 4500. If that it what you mean, then I may suddenly understand why we fail to understand one another. If you want the IPSec tunneled packets to look as if they were destined for the DSMIP port, then forget about everything I have=20 said. I don't understand why you would like to have that, if that is what you want indeed - ? - but that's a different discussion. Thanks ! Karen _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 22 18:15:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik5XN-0007s8-B2; Mon, 22 Oct 2007 18:14:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik5XL-0007nf-WA; Mon, 22 Oct 2007 18:14:16 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik5XI-0007yX-0M; Mon, 22 Oct 2007 18:14:12 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 15:14:11 -0700 Message-ID: <471D20B2.90001@azairenet.com> Date: Mon, 22 Oct 2007 15:14:10 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip6] DSMIPv6 and IKE References: <2309978910A6A6478C2C7585692B0AF4B9543C@NAEX16.na.qualcomm.com> In-Reply-To: <2309978910A6A6478C2C7585692B0AF4B9543C@NAEX16.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2007 22:14:11.0163 (UTC) FILETIME=[DF589AB0:01C814F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: nemo@ietf.org, mip6@ietf.org, Karen.Nielsen@tietoenator.com, Pasi.Eronen@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Tsirtsis, George wrote: > Hi all, > > I also think that requiring more messages on every handoff should not be > done lightly here. This statement is not entirely correct. The IKEv2 exchange following a handover is not in the critical path. It can done much later after the handover. For example it could be done 60 seconds after the handover. The exchange of BU/BAck would update the binding right away. This would be equivalent to not supporting the 'K' bit in RFC 3775. In RFC 3775, if either the mobile node or the home agent is not capable of updating the IKEv2 SA based on the BU/BAck, there is always an IKEv2 exchange following the handover. > The solution proposed by Hesham seems efficient and > others have also indicates that although it requires special processing > of a limited number of messages, it looks doable....so IMO this is the > preferred option here. Depends. Using some temporary tunnel state and making IKEv2 run over that tunnel is not that straight forward. Vijay > > Thanks > George > > > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Saturday, October 20, 2007 1:01 AM > To: Karen.Nielsen@tietoenator.com; mip6@ietf.org; nemo@ietf.org > Cc: Pasi.Eronen@nokia.com > Subject: RE: [Mip6] DSMIPv6 and IKE > > > > DSMIPv6 obviously needs to provide a NAT traversal mechanism. > > > The detection > > > of a NAT relies on the BU/BA message exchange. If a NAT were > > > detected, UDP > > > encapsulation follows. Now, the problem is, for the BU to be > > > sent, we need > > > to run IKE, which has it's own ports/traversal mechanisms. > > > So if we run IKE and send the BU over the IKE tunnel, the HA > > > will not know > > > what port number/address to send the MN's traffic to. Note > > that the MN > > > cannot include the port number > > > and address because clearly it doesn't know what those values > > > are since > > > they're allocated by the NAT. > > > > > > If we send the BU over port 4500 then we need to send another > > > message (not > > > secured) using DSMIPv6 port to the HA with every handover. I > > > think this is > > > unacceptable because we basically need to send two messages > > > for handover and > > > one of them has zero security. So the idea of using two ports > > > (4500 and > > > DSMIPv6 port) doesn't really work. > > > And we don't have a way today of sending the BU separately > > > over DSMIPv6 > > > port. I.e., what's described in the draft is not possible today. > > > > > > A lot is said about sending the BU "over the IKE tunnel" and over the > > same ports > > as IKE and IPSEC RFC 3948. > > > > Nothing is said about keeping the current design of sending > > the BU over > > a specific DSMIP port and then fixing the IKE and IPSEC port issues > > by a subsequent specific run of IKE to create the NAT port > > mappings for > > the 4500 port > > used by IKE and IPSec 3948. > > => How can we send the BU over DSMIP port? Can you provide a solution > for > this? > Hos is the SA established ? > > > > > By excluding this from the problem > > description, the solution is also excluded from the solution space. > > > > This way of looking at the problem do require multiple messages to > > complete the handover. Though still only one exchange for > > the BU to go > > through. > > => The point is, there are alternatives that would solve the problem > with > two messages every handover, but why should we do that if we can avoid > it? > > > The additional exchanges to ensure that all security SAs are up and > > running, that is: > > the IKE_SA which will ensure the continued aliveness of the ESP > > transport SA used to protect the BU > > as well as potential additional SAs for secure tunneling of payload > > > > Is there a special reason why this solution is not looked at ? > > => What is the solution? We have two classes of solutions in the three > alternatives I sent. One class covers the "two message approach", the > other > (alternative 1) does it with one message. What other solution do you > propose? Please send it to the list. I saw an email from Christian that > I > haven't read yet, may be that's what you mean. But it sounds like you're > proposing another alternative for the "two message" approach. All things > being the same, I'm personally not in favour of doing two messages every > handover because we have two NAT traversal mechanisms running in > parallel. > Seems very inefficient. > > > > > The solution does not fall into the category described above where > > it is said that one of the additional exchanges has zero security. > > > > > Solution space: > > > --------------- > > > > > > There are basically three ideas that were discussed in a > > small group: > > > > > > 1. Allow DSMIPv6 to look like a virtual link for IKE. Hence, > > > IKE will simply > > > run over IPv6 and will not be aware of IPv4 at all. > > > > > > 2. Run IKE over port 4500, but add > > > "DSMIPV6_UDP_ENCAPSULATION" notification > > > when negotiating ESP SAs > > > > > > 3. Add a new message in MIP6 that creates a port mapping in > > > the NAT. The BU > > > is still sent over 4500 and the new message is either > > > insecure or (a long > > > shot) secured by a crypto token exchanged in the BU/BA. > > > > > > Looking into the solutions proposed. > > > > The first have the disadvantage that > > we cannot benefit from IPSec and IKEs NAT traversal > > intelligence (e.g. > > RFC 3948), > > IPSEC SAs as IPSEC and IKE are now kept in the dark about > > the outer IP > > layers and NAT. > > => What is IKEs NAT traversal intelligence? We don't use 3948 but I > don't > understand what features we're missing. > > > Further it seems to make it even more complicated to handle > > IKE during > > movements, now IKE should > > be run on the CoA when in an Ipv6 foreign network (or Ipv6 > > homenetwork) > > but on the HoA when on an Ipv4 foreign network. > > => No, you don't actually have to do that, but you can do what you > suggest > above. But at worste this is only an issue when changing admin domains. > I > still think it's much better to live with this corner case than having > the > norm be two messages per handover. I think we should optimise the more > common case. > > Hesham > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 22 23:26:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkAOK-0008Gf-5O; Mon, 22 Oct 2007 23:25:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkAOI-00082Y-CM; Mon, 22 Oct 2007 23:25:14 -0400 Received: from mx06.syd.iprimus.net.au ([210.50.76.235]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkANw-0002ML-Hf; Mon, 22 Oct 2007 23:24:53 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALcFHUfTG2yO/2dsb2JhbAA X-IronPort-AV: E=Sophos;i="4.21,315,1188741600"; d="scan'208";a="73462588" Received: from 142.001.vod.mel.iprimus.net.au (HELO PC20005) ([211.27.108.142]) by smtp06.syd.iprimus.net.au with ESMTP; 23 Oct 2007 13:24:45 +1000 From: "Hesham Soliman" To: Subject: RE: [Mip6] DSMIPv6 and IKE Date: Tue, 23 Oct 2007 13:24:32 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: Thread-Index: AcgQxeIU3weagNHDSpi4Htm5SEk99ABeeK7AABrNX5AAdSpmEAAG8pfgABFwDSAAEF7c8A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > => Forgetting about 3948 tunnels because it's not an accident > > that we don't > > use it, why can't IKE negotiate those tunnels? > > > > Why don't you want 3948 tunnels ? => Because I want to avoid running two traversal mechanisms simultaneously and ending up with two messages. > > => Ok but I want to make it clear that this falls under the > > "two message" > > class of solutions. You seemed to indicate in your last email > > that there was > > a class of solutions missing. > > I am sorry if I mislead you. I was only trying to say that this 2 > message exchange > solution wasn't one in which one of the messages had zero > security, so I > felt that it was missing > from the general descriptions about 2 message exchange > solutions given > in your mail. => OK, agreed. > So we still have to consider > > the same tradeoff > > that we're talking about now. > > I think that it is worthwhile to notice that the handover for all > traffic which is not > IPSec tunnel encapsulated on the MN=HA path is achieved in 1 RTT. => So you're saying that all IPsec tunnel encapsulated traffic is going over port 4500, right? IMO, from a performance point of view it's not good enough to tell a customer part of your traffic will take 1 RTT for handovers and the secure part will take 2 RTT. > I am not sure what you mean here. > But standard IKEv2 can negotiate > * the Ipv6 transport ESP SA from the MN to the HA required for Ipv6 > level protection of the BU > * standard IPSec tunnel (Ipv6 in Ipv4 or Ipv4 in Ipv4), the local > end-point in the outer Ipv4 header of the tunnel SA being > the HA's Ipv4 > address, when there is no NAT > * and, when there's a NAT in between the MN and the HA, ESP UDP > encapsulated tunnel IPSec Sas (RFC 3948), the local > end-point in the outer Ipv4 header of the tunnel SA being > the HA's Ipv4 > address and with an UDP header inserted. => Yes I understand that, but I'm talking about this: MN has address 10.0.0.1 A. MN's NATTED address for IKE: 61.0.0.1 outer port 30000 B. MN's NATTED address for DSMIP 61.0.0.100 outer port 40000 Given that IKE doesn't know anything about B, can it still negotiate an SA for DSMIP to send a BU? This is what I'm trying to understand. As much detail on the IKE messages as possible please. > > I am not entirely sure what you mean. If you mean whether IKE can > negotiate > an IPSEC ESP SA that takes an Ipv6 (or an Ipv4 packet) > packet, encrypts > it and append and Ipv4 header, UDP header to DSMIP port and ESP > header (in reverse order), then I don't think that standard > IKE can do > that over port 4500. > > If that it what you mean, then I may suddenly understand why > we fail to > understand one another. > If you want the IPSec tunneled packets to look as if they > were destined > for the DSMIP port, then forget about everything I have > said. => I'm not sure if we're on the same page here. You're saying that you can send a BU secured with ESP, using DSMIP ports, correct? I.e. using the same numbers above: src = 10.0.0.1 dst = HAv4 UDP src port = 15000 dst port = DSMIPv6port src6 = HoA dst6 = HA6 ESP BU Is this correct? My question above is how did you setup this SA? Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 23 07:44:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkI9n-0004RO-Fz; Tue, 23 Oct 2007 07:42:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkI9l-0004OF-9B for mip6@ietf.org; Tue, 23 Oct 2007 07:42:45 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkI9e-0003UV-Sh for mip6@ietf.org; Tue, 23 Oct 2007 07:42:45 -0400 X-AuditID: c10cb581-000011ac000006f0-d2-471dde1e3294 Received: from camaro.eu.tieto.com ([192.176.143.42]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 13:42:22 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 13:42: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] DSMIPv6 and IKE Date: Tue, 23 Oct 2007 13:42:17 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE Thread-Index: AcgQxeIU3weagNHDSpi4Htm5SEk99ABeeK7AABrNX5AAdSpmEAAG8pfgABFwDSAAEF7c8AAIStdg References: From: To: X-OriginalArrivalTime: 23 Oct 2007 11:42:17.0765 (UTC) FILETIME=[C39CED50:01C81569] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi,=20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Tuesday, October 23, 2007 5:25 AM > To: Nielsen Karen E > Cc: mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] DSMIPv6 and IKE >=20 >=20 > > > =3D> Forgetting about 3948 tunnels because it's not an accident=20 > > > that we don't > > > use it, why can't IKE negotiate those tunnels?=20 > > >=20 > >=20 > > Why don't you want 3948 tunnels ? >=20 > =3D> Because I want to avoid running two traversal mechanisms=20 > simultaneously > and ending up with two messages.=20 >=20 Ok, that's the reason, I understand. But let me say this: We are running a number of protocols, Mobility, IPSec and IKE and they each have their build-in way of traversing NAT=20 - well the first we are defining now. I think the wise thing is to build with=20 the NAT traversal mechanism of each of the protocols and not make too many special shortcuts.=20 Yes, it may take several exchanges, but it is robust. >=20 > > > =3D> Ok but I want to make it clear that this falls under the=20 > > > "two message" > > > class of solutions. You seemed to indicate in your last email=20 > > > that there was > > > a class of solutions missing.=20 > >=20 > > I am sorry if I mislead you. I was only trying to say that this 2 > > message exchange=20 > > solution wasn't one in which one of the messages had zero=20 > > security, so I > > felt that it was missing > > from the general descriptions about 2 message exchange=20 > > solutions given > > in your mail. >=20 > =3D> OK, agreed. >=20 > > So we still have to consider=20 > > > the same tradeoff > > > that we're talking about now. > >=20 > > I think that it is worthwhile to notice that the handover for all > > traffic which is not > > IPSec tunnel encapsulated on the MN=3DHA path is achieved in 1 RTT. >=20 > =3D> So you're saying that all IPsec tunnel encapsulated=20 > traffic is going over > port 4500, right?=20 Right. > IMO, from a performance point of view it's not good enough to tell a > customer part of your traffic will take 1 RTT for handovers=20 > and the secure > part will take 2 RTT. >=20 Well, yes, but they also know that there is almost always a price to pay for security.=20 > > I am not sure what you mean here.=20 > > But standard IKEv2 can negotiate=20 > > * the Ipv6 transport ESP SA from the MN to the HA required for Ipv6 > > level protection of the BU > > * standard IPSec tunnel (Ipv6 in Ipv4 or Ipv4 in Ipv4), the local > > end-point in the outer Ipv4 header of the tunnel SA being=20 > > the HA's Ipv4 > > address, when there is no NAT > > * and, when there's a NAT in between the MN and the HA, ESP UDP > > encapsulated tunnel IPSec Sas (RFC 3948), the local > > end-point in the outer Ipv4 header of the tunnel SA being=20 > > the HA's Ipv4 > > address and with an UDP header inserted. >=20 > =3D> Yes I understand that, but I'm talking about this: > MN has address 10.0.0.1 > A. MN's NATTED address for IKE: 61.0.0.1 outer port 30000 > B. MN's NATTED address for DSMIP 61.0.0.100 outer port 40000 >=20 > Given that IKE doesn't know anything about B, can it still=20 > negotiate an SA > for DSMIP to send a BU? This is what I'm trying to understand. As much > detail on the IKE messages as possible please.=20 >=20 The IPSec SA that is used to protect the BU should be ESP transport on IPv6 level. Therefore IKE and IPSEc does not need to know anything about the outer UDP and IPv4 encapsulation of DSMIP. As IKE and IPSec does not need to know anything about the destination option and the routing header in standard MIP. IKE can negotiate ESP transport SAs given the right IPv6 selectors=20 (MN v6HoA and HA v6 address, protocol =3D MH of BU type)=20 in the IKE payload. Details: New IKE_SA and IPSec SA establishment situation: IKE messages, as they arrive at IKE/HA, appears as if the arrive from=20 the address set A destined for HA v4 address and port 4500. But transport SA negotiations is not dependent on the=20 endpoint addresses of the IKE connection. [Tunnel SAs however are !!] First there is the IKE_SA_INIT exchange (one message going back and forth) which establishes the IKE_SA credentials. The IKE_SA is established between address set A and HAv4 adresss and port 4500. Secondly there is the IKE_AUTH exchange (one message going back and forth). This exchange authenticates the first exchange as well as it negotiates=20 a child IPSEC SA, which in this case will be an ESP Ipv6 anchored transport IPSec SA. The IPSec SA is established based on the traffic selectors and the SA material (crypto algorithms and such) proposed by the initiator and included in the IKE message contents, the traffic selector will in this situation say MN v6HoA, HA v6 address and MH type BU. The IPSEC SA may also be established as a child to an existing IKE_SA, in this situation we only have one message exchange carrying the same selector set, SA material and more as above. In both cases, again to stress, the transport SA is by no means related to the characteristics of the underlying connection from address set A to HAv4 addresss and port 4500. > >=20 > > I am not entirely sure what you mean. If you mean whether IKE can > > negotiate > > an IPSEC ESP SA that takes an Ipv6 (or an Ipv4 packet)=20 > > packet, encrypts > > it and append and Ipv4 header, UDP header to DSMIP port and ESP=20 > > header (in reverse order), then I don't think that standard=20 > > IKE can do > > that over port 4500. > >=20 > > If that it what you mean, then I may suddenly understand why=20 > > we fail to > > understand one another. > > If you want the IPSec tunneled packets to look as if they=20 > > were destined > > for the DSMIP port, then forget about everything I have=20 > > said. >=20 > =3D> I'm not sure if we're on the same page here. You're saying=20 > that you can > send a BU secured with ESP, using DSMIP ports, correct? I.e.=20 > using the same > numbers above: > src =3D 10.0.0.1 > dst =3D HAv4 > UDP src port =3D 15000 dst port =3D DSMIPv6port > src6 =3D HoA > dst6 =3D HA6 > ESP > BU >=20 > Is this correct? My question above is how did you setup this SA? The SA is set-up as described above,=20 if it has not been set-up before the MN moved. Most likely it is set-up prior to the move. And in this situation, as it is not bound to anything=20 but the IPv6 addresses of the MN and the HA, it will survive the move until=20 the associated IKE_SA dies or the IPSec_SA needs to be re-keyed. The associated IKE_SA needs to be refreshed and updated=20 regularly as does all IPSec SA's under it. But it takes some time before IKE calls a peer out and=20 tears down the IKE_SA and the IPSEc SA's, so the SA should work after the movement. Yes there are corner cases, but let's not go there. All this is no different from standard Mobile Ipv6. Based on the BU, the HA may update the address of the MN end-point in the IKE_SA and the tunnel IPSec SAs. Further the HA (DSMIP code) will know whether=20 this is sufficient depending on whether there is NAT or not. If there is no NAT now, we are done. But the above step may* include changing the IKE_SA from an IKE_SA with NAT to an IKE_SA with no NAT as well as it may* include changing all RFC 3948 IPSEC tunnels associated with the IKE_SA to standard IPSEc tunnel SAs with no NAT. * for the situation where there was a NAT before the move. All this may also include changing the IP address version, if we are moving from Ipv4 to Ipv6 or the other way around. Now assume that there is a NAT now. The HA (DSMIP code) must make sure that the nature of the IKE_SA and the associated IPSec tunnel SAs is put in accordance with the fact that there's a NAT. If there was no NAT before this means changing the nature of the IKE_SA to an IKE_SA with NAT and changing all tunnel IPSEC SAs to RFC 3948 ones. The DSMIP does not need to keep track of whether there was a NAT before, only it must ensure that everything now is in accordance with the fact that there is a NAT. Now we are set to update the MN address and=20 port end-point information in the IKE_SA and in the RFC 3948 tunnel SAs.=20 This can be done in two ways: 1. IKE dead peer detection: If the MN sends an appropriately authenticated IKE dead peer detection packet when it has received the BACK, this will automatically make the IKE at the HA update the IKE_SA and all associated IPSec 3948 Sas with the correct port and addressed of the MN as mapped by the NAT. This to the IKE entity at the HA corresponds to the situation whether the NAT has changed its mappings and the above reaction is a SHOULD in RFC 4306 (Section 2.23). 2. If there is payload to be sent towards the HA via an IPSEc 3948 tunnel SA, the receipt of this packet at the HA should result in the same updating being done by the HA. Now as a MN may not always have a IPSec tunnel SA to the HA, we cannot rely on 2. as a general mechanism. Further it should be stressed that this does not mean that the RTT delay for IPSec tunneled packets is only 1 RTT, because in the reverse direction from HA to MN, the ports and addresses are first being updated after the receipt of the tunneled packet at the HA, thus 1,5 RTT (not 2 RTT, but not 1 RTT either). Instead of doing all this complex (but standard compliant) fiddling, one could also use MOBIKE to move the endpoint of the IKE_SA and the associated tunnel SAs, but it may not be so nice to have to require MOBIKE (?) A third alternative is no rerun IKE entirely and re-negotiate all SAs after the BU/BACK exchange. Again the delay caused only impacts secure traffic. Karen >=20 > Hesham >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 23 23:34:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkWya-0001K9-BH; Tue, 23 Oct 2007 23:32:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkWyY-0001I0-4f for mip6@ietf.org; Tue, 23 Oct 2007 23:32:10 -0400 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkWyN-0002mh-H1 for mip6@ietf.org; Tue, 23 Oct 2007 23:32:06 -0400 Received: from oaamta02ps.mx.bigpond.com ([124.190.106.219]) by omta01ps.mx.bigpond.com with ESMTP id <20071024033115.ZHRU13408.omta01ps.mx.bigpond.com@oaamta02ps.mx.bigpond.com> for ; Wed, 24 Oct 2007 03:31:15 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta02ps.mx.bigpond.com with ESMTP id <20071024033115.UQAY6780.oaamta02ps.mx.bigpond.com@PC20005>; Wed, 24 Oct 2007 03:31:15 +0000 From: "Hesham Soliman" To: Subject: RE: [Mip6] DSMIPv6 and IKE Date: Wed, 24 Oct 2007 13:31:04 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: Thread-Index: AcgQxeIU3weagNHDSpi4Htm5SEk99ABeeK7AABrNX5AAdSpmEAAG8pfgABFwDSAAEF7c8AAIStdgAAnJvBA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > => Because I want to avoid running two traversal mechanisms > > simultaneously > > and ending up with two messages. > > > > Ok, that's the reason, I understand. But let me say this: > > We are running a number of protocols, Mobility, IPSec and IKE > and they each have their build-in way of traversing NAT > - well the first we are defining now. > I think the wise thing is to build with > the NAT traversal mechanism of each of the protocols > and not make too many special shortcuts. > Yes, it may take several exchanges, but it is robust. => Robustness is not an absolute. You're talking about robustness of the implementation, but an operator wants robustness of other things like handover in a mobile system. Telling them that half the traffic will need more RTTs doesn't sound like an attractive feature for them. They don't care how you implement it as long as it's stable. > > IMO, from a performance point of view it's not good enough > to tell a > > customer part of your traffic will take 1 RTT for handovers > > and the secure > > part will take 2 RTT. > > > > Well, yes, but they also know that there is almost > always a price to pay for security. => I'll have to agree to disagree with this logic. If I were running a mobile network I wouldn't accept *this* price. > The IPSec SA that is used to protect the BU should be ESP > transport on > IPv6 level. > Therefore IKE and IPSEc does not need to know anything about > the outer > UDP and IPv4 encapsulation of DSMIP. > As IKE and IPSec does not need to know anything about the destination > option and > the routing header in standard MIP. > > IKE can negotiate ESP transport SAs given the right IPv6 selectors > (MN v6HoA and HA v6 address, protocol = MH of BU type) > in the IKE payload. > > Details: > > New IKE_SA and IPSec SA establishment situation: > > IKE messages, as they arrive at IKE/HA, appears as if the > arrive from > the address set A destined for HA v4 address and port 4500. > But transport SA negotiations is not dependent on the > endpoint addresses of the IKE connection. [Tunnel SAs however are !!] > > First there is the IKE_SA_INIT exchange (one message going back and > forth) > which establishes the IKE_SA credentials. The IKE_SA is established > between > address set A and HAv4 adresss and port 4500. > > Secondly there is the IKE_AUTH exchange (one message going back and > forth). > This exchange authenticates the first exchange as well as it > negotiates > a child IPSEC SA, which in this case will be an ESP Ipv6 anchored > transport IPSec SA. > The IPSec SA is established based on the traffic selectors and the SA > material (crypto algorithms and such) > proposed by the initiator and included in the IKE message > contents, the > traffic selector will in this situation say > MN v6HoA, HA v6 address and MH type BU. > > The IPSEC SA may also be established as a child to an > existing IKE_SA, > in this situation > we only have one message exchange carrying the same selector set, SA > material and more as above. > > In both cases, again to stress, the transport SA is by no > means related > to the > characteristics of the underlying connection from address > set A to HAv4 > addresss and port 4500. => Ok, got it thanks. So we'll end up with the same packet for the BU in both cases but the only difference is what we already discussed, i.e. two NAT traversals Vs one, which will affect secure traffic only. Thanks for the details below as well. I'll send a summary email to the list to finish this issue. Hesham > > Is this correct? My question above is how did you setup this SA? > > The SA is set-up as described above, > if it has not been set-up before the MN moved. > Most likely it is set-up prior to the move. > And in this situation, as it is not bound to anything > but the IPv6 addresses of the MN and the HA, > it will survive the move until > the associated IKE_SA dies or the IPSec_SA needs to be re-keyed. > > The associated IKE_SA needs to be refreshed and updated > regularly as does all IPSec SA's under it. But > it takes some time before IKE calls a peer out and > tears down the IKE_SA and the IPSEc SA's, so the > SA should work after the movement. > Yes there are corner cases, but let's not go there. > All this is no different from standard Mobile Ipv6. > > Based on the BU, the HA may update the address > of the MN end-point in the IKE_SA and the tunnel IPSec SAs. > Further the HA (DSMIP code) will know whether > this is sufficient depending on whether there is NAT or not. > > If there is no NAT now, we are done. But the above step may* include > changing the > IKE_SA from an IKE_SA with NAT to an IKE_SA with no NAT as well as it > may* include > changing all RFC 3948 IPSEC tunnels associated with the IKE_SA to > standard IPSEc tunnel SAs > with no NAT. > > * for the situation where there was a NAT before the move. > > All this may also include changing the IP address version, if we are > moving from Ipv4 > to Ipv6 or the other way around. > > Now assume that there is a NAT now. > > The HA (DSMIP code) must make sure that the nature > of the IKE_SA and the associated IPSec tunnel SAs is put in > accordance > with the fact that there's a NAT. If there was no NAT before > this means > changing > the nature of the IKE_SA to an IKE_SA with NAT and changing > all tunnel > IPSEC SAs to RFC 3948 ones. > > The DSMIP does not need to keep track of whether there was a > NAT before, > only it must ensure that > everything now is in accordance with the fact that there is a NAT. > > Now we are set to update the MN address and > port end-point information in the IKE_SA and in > the RFC 3948 tunnel SAs. > > This can be done in two ways: > > 1. IKE dead peer detection: > > If the MN sends an appropriately authenticated IKE dead peer > detection > packet when it has received the BACK, > this will automatically make the IKE at the HA update the > IKE_SA and all > associated IPSec 3948 Sas with the correct > port and addressed of the MN as mapped by the NAT. > > This to the IKE entity at the HA corresponds to the situation whether > the NAT has changed its mappings > and the above reaction is a SHOULD in RFC 4306 (Section 2.23). > > 2. If there is payload to be sent towards the HA via an IPSEc 3948 > tunnel SA, the receipt of > this packet at the HA should result in the same updating > being done by > the HA. > > Now as a MN may not always have a IPSec tunnel SA to the HA, > we cannot > rely on 2. as a general mechanism. > Further it should be stressed that this does not mean that > the RTT delay > for IPSec tunneled packets is only 1 RTT, > because in the reverse direction from HA to MN, the ports > and addresses > are first being updated after the receipt > of the tunneled packet at the HA, thus 1,5 RTT (not 2 RTT, > but not 1 RTT > either). > > Instead of doing all this complex (but standard compliant) > fiddling, one > could also use MOBIKE to move the endpoint > of the IKE_SA and the associated tunnel SAs, but it may not > be so nice > to have to require MOBIKE (?) > > A third alternative is no rerun IKE entirely and re-negotiate all SAs > after the BU/BACK exchange. Again > the delay caused only impacts secure traffic. > > Karen > > > > > Hesham > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 25 10:03:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il3Hm-0006OK-1Z; Thu, 25 Oct 2007 10:02:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il3Hk-0006K5-Qx; Thu, 25 Oct 2007 10:02:08 -0400 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il3HY-0004V2-N6; Thu, 25 Oct 2007 10:02:02 -0400 Received: from oaamta07ps.mx.bigpond.com ([124.190.106.219]) by omta01ps.mx.bigpond.com with ESMTP id <20071025140118.MAWQ13408.omta01ps.mx.bigpond.com@oaamta07ps.mx.bigpond.com>; Thu, 25 Oct 2007 14:01:18 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta07ps.mx.bigpond.com with ESMTP id <20071025140118.PRQB17155.oaamta07ps.mx.bigpond.com@PC20005>; Thu, 25 Oct 2007 14:01:18 +0000 From: "Hesham Soliman" To: , Date: Fri, 26 Oct 2007 00:01:06 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgXD2Nk409BdK32Rr+w24XNw+KidQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Subject: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Folks, This discussion has been going on for a while and I'm sure it wasn't for easy to follow. This email contains a summary of the discussion so far and a call for comment/concensus. Please respond promptly because there is some pressure from 3GPP to get this draft out very soon. The issue is how to run IKE in combination with DSMIPv6 in a private IPv4-only network. If you want more detail about why this is a problem please look at the thread "DSMIPv6 and IKE". There are three types of solutions that we discussed. A quick summary of each below: 1. The Virtual link approach. In this case IKE runs over v6 only and is completely unaware of the IPv4 network. As a result IKE's NAT traversal is never invoked. Only DSMIPv6's NAT traversal is used. In this approach, the DSMIPv6 implementation in the HA is required to cache the outer IPv4 address and source port of the IPv4 message that contains IKE, then append them to the response from its own IKE daemon. This is basically done to hide the IPv4 network from IKE and effectively disable its NAT traversal, which solves our problem. Three people agreed with this approach but two people (I'm including Christian) are against it. So there doesn't seem to be concensus on this. I believe the concern here was that the HA's caching of the outer address and port was complex for the implementation. 2. Karen suggested a way of running IKE without any changes (again see the thread for details). In this approach DSMIPv6 BUs are secured with ESP as usual. Normal traffic is sent over the DSMIPv6 port. However, secure traffic is sent over the IKE port (4500). The result of this approach is that it takes two messages to complete a handover, one from DSMIPv6 (BU) and an update from IKE (for the secure traffic). The concern that I had here in the discussion with Karen was the number of messages and the delays associated for that. Of course IKE doesn't do movement detection ...etc. So my concern is the discriminatory experience of the handover for different parts of the traffic. 3. The third class of solutions involves either modifying MIPv6 (adding new messages) or IKE or both. I'm only including this for completeness, no one really wants this. Please send your comments on the above. Basically the options are 1 or 2. In theory we could do both but I think it's best to pick one method for this to avoid interoperability issues and additional complexity. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 26 01:43:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlHxb-0007HM-91; Fri, 26 Oct 2007 01:42:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlHxZ-0007HA-TT; Fri, 26 Oct 2007 01:42:17 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlHxZ-0003xy-Aa; Fri, 26 Oct 2007 01:42:17 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 22:42:16 -0700 Message-ID: <47217E35.7010705@azairenet.com> Date: Thu, 25 Oct 2007 22:42:13 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2007 05:42:16.0387 (UTC) FILETIME=[F76D7930:01C81792] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham, IMO, we should go with solution 2) below. I prefer that we let IKEv2 use its own NAT traversal mechanism. Regarding two round trips during a handover, note that the IKEv2 exchange to re-establish the IKEv2 SA and the IPsec SAs is not in the critical path of handover. The BU/BAck messages can be exchanged with the existing IPsec SAs. The IKEv2 exchange can be happen a few seconds (or minutes) after the handover. So there is *no* impact on the handover. This would be the same as the lack of support for the "K" flag in RFC 3775. In RFC 3775, if either the mobile node or the home agent are not capable of updating the IKE SA based on the exchange of BU/BAck, there is always an IKE exchange after the handover (or whenever the CoA changes). Please let me know if I am missing something related to the impact of the IKEv2 exchange on the handover. I am not comfortable with the temporary tunnel created in solution 1). Vijay Hesham Soliman wrote: > Folks, > > This discussion has been going on for a while and I'm sure it wasn't for > easy to follow. > This email contains a summary of the discussion so far and a call for > comment/concensus. Please respond promptly because there is some pressure > from 3GPP to get this draft out very soon. > > The issue is how to run IKE in combination with DSMIPv6 in a private > IPv4-only network. If you want more detail about why this is a problem > please look at the thread "DSMIPv6 and IKE". > > There are three types of solutions that we discussed. A quick summary of > each below: > > 1. The Virtual link approach. In this case IKE runs over v6 only and is > completely unaware of the IPv4 network. As a result IKE's NAT traversal is > never invoked. Only DSMIPv6's NAT traversal is used. In this approach, the > DSMIPv6 implementation in the HA is required to cache the outer IPv4 address > and source port of the IPv4 message that contains IKE, then append them to > the response from its own IKE daemon. This is basically done to hide the > IPv4 network from IKE and effectively disable its NAT traversal, which > solves our problem. > Three people agreed with this approach but two people (I'm including > Christian) are against it. So there doesn't seem to be concensus on this. I > believe the concern here was that the HA's caching of the outer address and > port was complex for the implementation. > > 2. Karen suggested a way of running IKE without any changes (again see the > thread for details). In this approach DSMIPv6 BUs are secured with ESP as > usual. Normal traffic is sent over the DSMIPv6 port. However, secure traffic > is sent over the IKE port (4500). The result of this approach is that it > takes two messages to complete a handover, one from DSMIPv6 (BU) and an > update from IKE (for the secure traffic). The concern that I had here in the > discussion with Karen was the number of messages and the delays associated > for that. Of course IKE doesn't do movement detection ...etc. So my concern > is the discriminatory experience of the handover for different parts of the > traffic. > > 3. The third class of solutions involves either modifying MIPv6 (adding new > messages) or IKE or both. I'm only including this for completeness, no one > really wants this. > > Please send your comments on the above. Basically the options are 1 or 2. In > theory we could do both but I think it's best to pick one method for this to > avoid interoperability issues and additional complexity. > > Hesham > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 26 02:21:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlIXz-0006OG-UP; Fri, 26 Oct 2007 02:19:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlIXy-0005Io-SZ; Fri, 26 Oct 2007 02:19:55 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlIXi-0005CU-51; Fri, 26 Oct 2007 02:19:38 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.190.106.219]) by omta05sl.mx.bigpond.com with ESMTP id <20071026061934.LOBO14987.omta05sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Fri, 26 Oct 2007 06:19:34 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta07sl.mx.bigpond.com with ESMTP id <20071026061932.YABK5930.oaamta07sl.mx.bigpond.com@PC20005>; Fri, 26 Oct 2007 06:19:32 +0000 From: "Hesham Soliman" To: "'Vijay Devarapalli'" Subject: RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Date: Fri, 26 Oct 2007 16:19:23 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47217E35.7010705@azairenet.com> Thread-index: AcgXkvj8EUmQIo/vRg2DCVsK6a6TmwABPztA X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > IMO, we should go with solution 2) below. I prefer that we let > IKEv2 use its own NAT traversal mechanism. Regarding two round > trips during a handover, note that the IKEv2 exchange to > re-establish the IKEv2 SA and the IPsec SAs is not in the > critical path of handover. => It is in the critical path for the secure packets. That's what the discussion was about. The BU/BAck messages can be exchanged > with the existing IPsec SAs. The IKEv2 exchange can be happen a > few seconds (or minutes) after the handover. So there is *no* > impact on the handover. => No, see above. This is only good for insecure traffic. At least this is not solution 2 below. Hesham > > This would be the same as the lack of support for the "K" flag > in RFC 3775. In RFC 3775, if either the mobile node or the home > agent are not capable of updating the IKE SA based on the > exchange of BU/BAck, there is always an IKE exchange after the > handover (or whenever the CoA changes). > > Please let me know if I am missing something related to the > impact of the IKEv2 exchange on the handover. > > I am not comfortable with the temporary tunnel created in > solution 1). > > Vijay > > Hesham Soliman wrote: > > Folks, > > > > This discussion has been going on for a while and I'm sure > it wasn't for > > easy to follow. > > This email contains a summary of the discussion so far and > a call for > > comment/concensus. Please respond promptly because there > is some pressure > > from 3GPP to get this draft out very soon. > > > > The issue is how to run IKE in combination with DSMIPv6 in > a private > > IPv4-only network. If you want more detail about why this > is a problem > > please look at the thread "DSMIPv6 and IKE". > > > > There are three types of solutions that we discussed. A > quick summary of > > each below: > > > > 1. The Virtual link approach. In this case IKE runs over > v6 only and is > > completely unaware of the IPv4 network. As a result IKE's > NAT traversal is > > never invoked. Only DSMIPv6's NAT traversal is used. In > this approach, the > > DSMIPv6 implementation in the HA is required to cache the > outer IPv4 address > > and source port of the IPv4 message that contains IKE, > then append them to > > the response from its own IKE daemon. This is basically > done to hide the > > IPv4 network from IKE and effectively disable its NAT > traversal, which > > solves our problem. > > Three people agreed with this approach but two people (I'm > including > > Christian) are against it. So there doesn't seem to be > concensus on this. I > > believe the concern here was that the HA's caching of the > outer address and > > port was complex for the implementation. > > > > 2. Karen suggested a way of running IKE without any > changes (again see the > > thread for details). In this approach DSMIPv6 BUs are > secured with ESP as > > usual. Normal traffic is sent over the DSMIPv6 port. > However, secure traffic > > is sent over the IKE port (4500). The result of this > approach is that it > > takes two messages to complete a handover, one from > DSMIPv6 (BU) and an > > update from IKE (for the secure traffic). The concern that > I had here in the > > discussion with Karen was the number of messages and the > delays associated > > for that. Of course IKE doesn't do movement detection > ...etc. So my concern > > is the discriminatory experience of the handover for > different parts of the > > traffic. > > > > 3. The third class of solutions involves either modifying > MIPv6 (adding new > > messages) or IKE or both. I'm only including this for > completeness, no one > > really wants this. > > > > Please send your comments on the above. Basically the > options are 1 or 2. In > > theory we could do both but I think it's best to pick one > method for this to > > avoid interoperability issues and additional complexity. > > > > Hesham > > > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 26 02:40:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlIqp-00055K-GF; Fri, 26 Oct 2007 02:39:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlIqo-00055A-LV; Fri, 26 Oct 2007 02:39:22 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlIqi-0007HX-Ci; Fri, 26 Oct 2007 02:39:22 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9Q6cwad020001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 Oct 2007 23:38:59 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9Q6cv2v028024; Thu, 25 Oct 2007 23:38:58 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Oct 2007 23:38:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Date: Thu, 25 Oct 2007 23:38:57 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Thread-Index: AcgXD2Nk409BdK32Rr+w24XNw+KidQAii1/g References: From: "Narayanan, Vidya" To: "Hesham Soliman" , , X-OriginalArrivalTime: 26 Oct 2007 06:38:57.0228 (UTC) FILETIME=[E27CA0C0:01C8179A] X-Spam-Score: -4.0 (----) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham, A few comments inline. =20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Thursday, October 25, 2007 7:01 AM > To: mip6@ietf.org; nemo@ietf.org > Subject: [Mip6] DSMIPv6 and IKE - Summary and call for concensus >=20 > Folks, >=20 > This discussion has been going on for a while and I'm sure it=20 > wasn't for easy to follow.=20 > This email contains a summary of the discussion so far and a=20 > call for comment/concensus. Please respond promptly because=20 > there is some pressure from 3GPP to get this draft out very soon.=20 >=20 > The issue is how to run IKE in combination with DSMIPv6 in a=20 > private IPv4-only network. If you want more detail about why=20 > this is a problem please look at the thread "DSMIPv6 and IKE".=20 >=20 > There are three types of solutions that we discussed. A quick=20 > summary of each below: >=20 > 1. The Virtual link approach. In this case IKE runs over v6=20 > only and is completely unaware of the IPv4 network. As a=20 > result IKE's NAT traversal is never invoked. Only DSMIPv6's=20 > NAT traversal is used. In this approach, the > DSMIPv6 implementation in the HA is required to cache the=20 > outer IPv4 address and source port of the IPv4 message that=20 > contains IKE, then append them to the response from its own=20 > IKE daemon. This is basically done to hide the > IPv4 network from IKE and effectively disable its NAT=20 > traversal, which solves our problem.=20 > Three people agreed with this approach but two people (I'm including > Christian) are against it. So there doesn't seem to be=20 > concensus on this. I believe the concern here was that the=20 > HA's caching of the outer address and port was complex for=20 > the implementation. >=20 I'm not as concerned about the complexity aspect, but, I'm more concerned about the changes to the IPsec architecture this brings. I think this solution requires an SPD bypass rule to be setup for the DSMIP6 port that will first allow MIP6 to process the packets before IPsec has a chance to apply the SPD rule for BU. It is strange in that the IPsec protection is somehow sought for packets from the trusted boundary (i.e., MIP6 to IPsec in the same box) rather than the untrusted boundary (the packet coming in from the untrusted portion is the one to the DSMIP6 port and that is bypassed). One could argue that this isn't a big deal, but, given IPsec's design of inspecting all packets coming from the untrusted boundary first, it does make me uncomfortable to skew that.=20 > 2. Karen suggested a way of running IKE without any changes=20 > (again see the thread for details). In this approach DSMIPv6=20 > BUs are secured with ESP as usual. Normal traffic is sent=20 > over the DSMIPv6 port. However, secure traffic is sent over=20 > the IKE port (4500). The result of this approach is that it=20 > takes two messages to complete a handover, one from DSMIPv6=20 > (BU) and an update from IKE (for the secure traffic). The=20 > concern that I had here in the discussion with Karen was the=20 > number of messages and the delays associated for that. Of=20 > course IKE doesn't do movement detection ...etc. So my=20 > concern is the discriminatory experience of the handover for=20 > different parts of the traffic.=20 >=20 Sorry to say that I have not yet caught up on this solution fully and so, am unable to comment on it yet. From your recent email, it sounds like we have two roundtrips in the critical path, if the data is to be secured with IPsec as well. Can these roundtrips be in parallel or are they sequential? If they need to be sequential, I think that is a big enough negative impact on handoff times. If they can be parallel and can be processed out of order at the HA, I'd be less concerned with it.=20 > 3. The third class of solutions involves either modifying=20 > MIPv6 (adding new > messages) or IKE or both. I'm only including this for=20 > completeness, no one really wants this.=20 >=20 I'm not sure I understand this part. We are adding new functionality to MIP6 to support DSMIP6. And, we are adding NAT-T to MIP6 specifically for that. Given that, why is it a big deal to support a new message in MIP6 for this sake? This also makes the udpates need two messages, but, in this case, it definitely can be parallel and processed out of order and hence, there is no impact on handoff times. =20 Vidya > Please send your comments on the above. Basically the options=20 > are 1 or 2. In theory we could do both but I think it's best=20 > to pick one method for this to avoid interoperability issues=20 > and additional complexity.=20 >=20 > Hesham >=20 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 26 03:04:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJE6-0004xb-JR; Fri, 26 Oct 2007 03:03:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJE5-0004ws-5T; Fri, 26 Oct 2007 03:03:25 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlJDy-00083T-Uh; Fri, 26 Oct 2007 03:03:25 -0400 X-AuditID: c10cb581-00001af80000165c-79-472191205ff6 Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 09:02:56 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 09:03: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: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Date: Fri, 26 Oct 2007 09:03:00 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Thread-Index: AcgXkvj8EUmQIo/vRg2DCVsK6a6TmwABPztAAAFi6NA= References: <47217E35.7010705@azairenet.com> From: To: , X-OriginalArrivalTime: 26 Oct 2007 07:03:00.0287 (UTC) FILETIME=[3E9DF4F0:01C8179E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, > > IMO, we should go with solution 2) below. I prefer that we let > > IKEv2 use its own NAT traversal mechanism. Regarding two round > > trips during a handover, note that the IKEv2 exchange to > > re-establish the IKEv2 SA and the IPsec SAs is not in the > > critical path of handover.=20 >=20 > =3D> It is in the critical path for the secure packets. That's what = the > discussion was about. >=20 > The BU/BAck messages can be exchanged > > with the existing IPsec SAs. The IKEv2 exchange can be happen a > > few seconds (or minutes) after the handover. So there is *no* > > impact on the handover. >=20 > =3D> No, see above. This is only good for insecure traffic. At=20 > least this is > not solution 2 below. >=20 Actually secure traffic from the MN towards the HA is not impacted by the delay, but it is true that secure traffic in the HA to MN direction is impacted. It will not function until the HA IPSEC SA has been upated with the correct ports and addresses and this will not happen until one of the following two things has happened: * the MN has send secure traffic towarsd the HA * the MN has initiated an IKE_SA update exchange=20 Karen > Hesham >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 26 03:06:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJGx-0008PE-DD; Fri, 26 Oct 2007 03:06:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJGw-0007rk-2a; Fri, 26 Oct 2007 03:06:22 -0400 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlJGY-0006an-Re; Fri, 26 Oct 2007 03:05:59 -0400 Received: from oaamta06sl.mx.bigpond.com ([124.190.106.219]) by omta02sl.mx.bigpond.com with ESMTP id <20071026070554.SBFF22254.omta02sl.mx.bigpond.com@oaamta06sl.mx.bigpond.com>; Fri, 26 Oct 2007 07:05:54 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta06sl.mx.bigpond.com with ESMTP id <20071026070554.ZEYY15362.oaamta06sl.mx.bigpond.com@PC20005>; Fri, 26 Oct 2007 07:05:54 +0000 From: "Hesham Soliman" To: "'Narayanan, Vidya'" , , Subject: RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Date: Fri, 26 Oct 2007 17:05:44 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-index: AcgXD2Nk409BdK32Rr+w24XNw+KidQAii1/gAAEXFRA= X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > 1. The Virtual link approach. In this case IKE runs over v6 > > only and is completely unaware of the IPv4 network. As a > > result IKE's NAT traversal is never invoked. Only DSMIPv6's > > NAT traversal is used. In this approach, the > > DSMIPv6 implementation in the HA is required to cache the > > outer IPv4 address and source port of the IPv4 message that > > contains IKE, then append them to the response from its own > > IKE daemon. This is basically done to hide the > > IPv4 network from IKE and effectively disable its NAT > > traversal, which solves our problem. > > Three people agreed with this approach but two people (I'm > including > > Christian) are against it. So there doesn't seem to be > > concensus on this. I believe the concern here was that the > > HA's caching of the outer address and port was complex for > > the implementation. > > > > I'm not as concerned about the complexity aspect, but, I'm more > concerned about the changes to the IPsec architecture this brings. I > think this solution requires an SPD bypass rule to be setup for the > DSMIP6 port that will first allow MIP6 to process the packets before > IPsec has a chance to apply the SPD rule for BU. It is > strange in that > the IPsec protection is somehow sought for packets from the trusted > boundary (i.e., MIP6 to IPsec in the same box) rather than > the untrusted > boundary (the packet coming in from the untrusted portion is > the one to > the DSMIP6 port and that is bypassed). One could argue that > this isn't > a big deal, but, given IPsec's design of inspecting all > packets coming > from the untrusted boundary first, it does make me > uncomfortable to skew > that. => I really don't get two things about your comment: A. The packet format is the same for both alternatives so I'm not sure if this is a general comment or specific to this alternative. It shouldn't be the latter. B. How are we bypassing anything in IPsec? I mean, there is no more bypassing here than the processing of the routing header in MIP6. Simply removing the outer IPv4 header, which can never be protected by IPsec, is not bypassing it. I don't get that. > > > 2. Karen suggested a way of running IKE without any changes > > (again see the thread for details). In this approach DSMIPv6 > > BUs are secured with ESP as usual. Normal traffic is sent > > over the DSMIPv6 port. However, secure traffic is sent over > > the IKE port (4500). The result of this approach is that it > > takes two messages to complete a handover, one from DSMIPv6 > > (BU) and an update from IKE (for the secure traffic). The > > concern that I had here in the discussion with Karen was the > > number of messages and the delays associated for that. Of > > course IKE doesn't do movement detection ...etc. So my > > concern is the discriminatory experience of the handover for > > different parts of the traffic. > > > > Sorry to say that I have not yet caught up on this solution fully and > so, am unable to comment on it yet. From your recent email, > it sounds > like we have two roundtrips in the critical path, if the > data is to be > secured with IPsec as well. Can these roundtrips be in > parallel or are > they sequential? If they need to be sequential, I think > that is a big > enough negative impact on handoff times. If they can be parallel and => They can definitely be in parallel, but I don't think IKE knows enough about movement to do this in any timely manner. So, it makes the handover of the secure traffic non-deterministic. Sorry if I gave that impression (that they have to be sent sequentially). > > 3. The third class of solutions involves either modifying > > MIPv6 (adding new > > messages) or IKE or both. I'm only including this for > > completeness, no one really wants this. > > > > I'm not sure I understand this part. We are adding new > functionality to > MIP6 to support DSMIP6. And, we are adding NAT-T to MIP6 > specifically > for that. Given that, why is it a big deal to support a new > message in > MIP6 for this sake? This also makes the udpates need two > messages, but, > in this case, it definitely can be parallel and processed > out of order > and hence, there is no impact on handoff times. => Well, we already have the two message solution, so why invent another two message case that need to be secured ...etc? Hesham > > Vidya > > > Please send your comments on the above. Basically the options > > are 1 or 2. In theory we could do both but I think it's best > > to pick one method for this to avoid interoperability issues > > and additional complexity. > > > > Hesham > > > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 26 03:07:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJHw-0001rY-Py; Fri, 26 Oct 2007 03:07:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJHu-0001a7-SJ; Fri, 26 Oct 2007 03:07:22 -0400 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlJHp-0006c4-SY; Fri, 26 Oct 2007 03:07:18 -0400 Received: from oaamta01sl.mx.bigpond.com ([124.190.106.219]) by omta02sl.mx.bigpond.com with ESMTP id <20071026070715.SCCY22254.omta02sl.mx.bigpond.com@oaamta01sl.mx.bigpond.com>; Fri, 26 Oct 2007 07:07:15 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta01sl.mx.bigpond.com with ESMTP id <20071026070715.YGBS23516.oaamta01sl.mx.bigpond.com@PC20005>; Fri, 26 Oct 2007 07:07:15 +0000 From: "Hesham Soliman" To: , Subject: RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Date: Fri, 26 Oct 2007 17:07:04 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-index: AcgXkvj8EUmQIo/vRg2DCVsK6a6TmwABPztAAAFi6NAAAEt3IA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > => No, see above. This is only good for insecure traffic. At > > least this is > > not solution 2 below. > > > > Actually secure traffic from the MN towards the HA is not impacted by > the delay, => Yes of course, but we normally measure the handover delay ignoring the direction of traffic. Hesham > but it is true that secure traffic in the HA to MN direction is > impacted. It will > not function until the HA IPSEC SA has been upated with the correct > ports and addresses and this will not happen until one of > the following > two things has happened: > > * the MN has send secure traffic towarsd the HA > * the MN has initiated an IKE_SA update exchange > > Karen > > > Hesham > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 26 03:52:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJyu-0000dw-Q3; Fri, 26 Oct 2007 03:51:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJyt-0000aD-Bk; Fri, 26 Oct 2007 03:51:47 -0400 Received: from mail1.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlJyl-0001F9-1a; Fri, 26 Oct 2007 03:51:47 -0400 X-AuditID: c26e2f18-00001748000012a0-83-47219c5c335c Received: from camaro.eu.tieto.com ([192.176.143.43]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 10:50:52 +0300 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 09:51:11 +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: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Date: Fri, 26 Oct 2007 09:51:10 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Thread-Index: AcgXD2Nk409BdK32Rr+w24XNw+KidQAjuLsA References: From: To: , , X-OriginalArrivalTime: 26 Oct 2007 07:51:11.0693 (UTC) FILETIME=[FA077FD0:01C817A4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, With respect to the latter then I believe that we should choose one solution=20 and one solution only for interoperability reasons. I am in favor of solution 2.=20 Solution 1. breaks with the paradigm of standard MIPv6 that IKE is run on the CoA level and I think that we should keep this basic paradigm. This allow us to build the DSMIP NAT traversal mechanism with the standard NAT traversal mechanism of the protocols we are using (IPSEC and IKE) and giving NATs and the complexity of things, I think that it is very wise to build as much as possible with standard building blocks. (This also allows for future interworking with MOBIKE if ever desired) I would like to spend a few words giving some additional details of=20 the characteristics of the solutions which perhaps is not clear form the summary. Solution 1: Secure Tunneling of payload: Secure Traffic will is in this situation be send with two IP tunneling headers, the DSMIP one (which IKE and IPSec is oblivious to) and the IPSec tunnel header, that is: IPv4 header=20 UDP header=20 IPv6 header (src=3DV6HOA, dst=3DHAADDR) ESP IPv6 (src=3Dv6Hoa, dst=3DCNADDR) Payload Data the IPSEc protocol being a standard 4301 ESP tunnel. Solution 2: Secure Tunneling of payload: Secure Traffic will=20 is in this situation be=20 send with RFC 3948 IPSec tunneling, that is IPv4 header=20 UDP header=20 ESP IPv6 (src=3Dv6Hoa, dst=3DCNADDR) Payload Data Update of IKE_SA and IPSec Sas: The IPSEc transport ESP used to protect the BU/BACK exchange=20 is the same as in solution 1 and seen in isolation it survives movements.=20 But in order for it to be refreshed (and simply for it not to be torn down at some point) the IKE_SA must be updated after the movement. The IPSec RFC 3948 has the same dependency towards the IKE_SA but in addition the IPSec RFC 3948 only=20 functions when a NAT mapping has been created for UDP 4500 communication in between HA and MN, and the IPSec SA (HA side) has been updated with this information. The basic principle of solution 2 is to perform the updating on the IKE_SA and the IPSec RFC 3948 SA AFTER the BU/BACK exchange. This is a modular and robust approach, BUT it introduces delay. The IKE_SA is first updated and the IPSec tunnel will first be fully operational in both directions, when either of the followings has happened: *A secure packet from the MN has arrived and has been processed at the HA *An authenticated IKE packet from the MN carrying NAT configuration options in=20 IKE payload has arrived and has been processed at the HA. BR, Karen > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Thursday, October 25, 2007 4:01 PM > To: mip6@ietf.org; nemo@ietf.org > Subject: [Mip6] DSMIPv6 and IKE - Summary and call for concensus >=20 > Folks, >=20 > This discussion has been going on for a while and I'm sure it=20 > wasn't for > easy to follow.=20 > This email contains a summary of the discussion so far and a call for > comment/concensus. Please respond promptly because there is=20 > some pressure > from 3GPP to get this draft out very soon.=20 >=20 > The issue is how to run IKE in combination with DSMIPv6 in a private > IPv4-only network. If you want more detail about why this is a problem > please look at the thread "DSMIPv6 and IKE".=20 >=20 > There are three types of solutions that we discussed. A quick=20 > summary of > each below: >=20 > 1. The Virtual link approach. In this case IKE runs over v6=20 > only and is > completely unaware of the IPv4 network. As a result IKE's NAT=20 > traversal is > never invoked. Only DSMIPv6's NAT traversal is used. In this=20 > approach, the > DSMIPv6 implementation in the HA is required to cache the=20 > outer IPv4 address > and source port of the IPv4 message that contains IKE, then=20 > append them to > the response from its own IKE daemon. This is basically done=20 > to hide the > IPv4 network from IKE and effectively disable its NAT traversal, which > solves our problem.=20 > Three people agreed with this approach but two people (I'm including > Christian) are against it. So there doesn't seem to be=20 > concensus on this. I > believe the concern here was that the HA's caching of the=20 > outer address and > port was complex for the implementation. >=20 > 2. Karen suggested a way of running IKE without any changes=20 > (again see the > thread for details). In this approach DSMIPv6 BUs are secured=20 > with ESP as > usual. Normal traffic is sent over the DSMIPv6 port. However,=20 > secure traffic > is sent over the IKE port (4500). The result of this approach=20 > is that it > takes two messages to complete a handover, one from DSMIPv6=20 > (BU) and an > update from IKE (for the secure traffic). The concern that I=20 > had here in the > discussion with Karen was the number of messages and the=20 > delays associated > for that. Of course IKE doesn't do movement detection ...etc.=20 > So my concern > is the discriminatory experience of the handover for=20 > different parts of the > traffic.=20 >=20 > 3. The third class of solutions involves either modifying=20 > MIPv6 (adding new > messages) or IKE or both. I'm only including this for=20 > completeness, no one > really wants this.=20 >=20 > Please send your comments on the above. Basically the options=20 > are 1 or 2. In > theory we could do both but I think it's best to pick one=20 > method for this to > avoid interoperability issues and additional complexity.=20 >=20 > Hesham >=20 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 26 04:38:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlKgx-0005T8-Dc; Fri, 26 Oct 2007 04:37:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlKgt-00059k-9F; Fri, 26 Oct 2007 04:37:15 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlKgo-0001F0-LU; Fri, 26 Oct 2007 04:37:11 -0400 Received: from ep_ms5_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JQI007L8FXMAR@mailout2.samsung.com>; Fri, 26 Oct 2007 17:36:58 +0900 (KST) Received: from ep_spt01 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JQI00CE4FXMUY@ms5.samsung.com>; Fri, 26 Oct 2007 17:36:58 +0900 (KST) Content-return: prohibited Date: Fri, 26 Oct 2007 08:36:58 +0000 (GMT) From: Heejin Jang To: Jari Arkko Message-id: <2579070.104701193387818401.JavaMail.weblogic@epml05> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20071026083407252@heejin.jang X-MTR: 20071026083407252@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: ML X-EPHeader: ML X-Spam-Score: -1.2 (-) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: Mobile IPv6 Mailing List , "draft-ietf-mip6-hiopt@tools.ietf.org" , Dhcwg Subject: [Mip6] Re: AD review of draft-ietf-mip6-hiopt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: heejin.jang@samsung.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0142370714==" Errors-To: mip6-bounces@ietf.org --===============0142370714== Content-return: prohibited Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 SGksIEphcmkuDQpJIGFwcHJlY2lhdGUgeW91ciBraW5kIHJldmlldy4gDQpUaGUgaGlvcHQgZHJh ZnQgIGlzIGN1cnJlbnRseSB1bmRlciByZXZpc2lvbiBiYXNlZCBvbiB5b3VyIGNvbW1lbnRzIGFu ZCBESEMgZm9sa3MsDQphbmQgd2UncmUgcGxhbm5pbmcgdG8gc3VibWl0IHRoZSByZXZpc2VkIG9u ZSAgbmV4dCB3ZWVrLiANCiANCi0gQmVzdCByZWdhcmRzLCANCkhlZWppbi4NCiANCiANCi0tLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tDQpTZW5kZXIgOiBKYXJpIEFya2tvPGphcmkuYXJr a29AcGl1aGEubmV0Pg0KRGF0ZSAgIDogMjAwNy0xMC0yMSAyMTo1OQ0KVGl0bGUgIDogQUQgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtbWlwNi1oaW9wdA0KDQpJIGhhdmUgbWFkZSBteSBBRCByZXZpZXcg b2YgdGhpcyBkb2N1bWVudC4NCg0KVGhpcyBkb2N1bWVudCBzdGlsbCBuZWVkcyBhIHJldmlzaW9u LiBCb3RoIGR1ZSB0byBjb21tZW50cyBnaXZlbiBieQ0KQmVybmllIFZvbHogaW4gREhDIHJldmll dyAoYXQgdGhlIGVuZCBvZiB0aGlzIGUtbWFpbCksIGFzIHdlbGwgYXMgZm9yDQpvdGhlciByZWFz b25zLg0KDQpJIGJlbGlldmUgdGhhdCB0aGUgZGVsaXZlcnkgb2YgbW9iaWxpdHkgaW5mb3JtYXRp b24gdmlhIERIQ1AgaXMgYSB2YWxpZA0KYXBwcm9hY2guIEhvd2V2ZXIsIHRoZXJlIGFyZSBhIG51 bWJlciBvZiBkZXRhaWxzIHRoYXQgc3RpbGwgbmVlZCB3b3JrLg0KVGhlIGRyYWZ0IG5lZWRzIHRv IHRhbGsgYWJvdXQgd2hlbiBzdWNoIGRpc2NvdmVyeSBpcyB1c2VkLiBJdHMNCmxpbWl0YXRpb25z IG11c3QgYmUgZGVzY3JpYmVkIG1vcmUgYWNjdXJhdGVseS4gQW5kIHRoZXJlIGFyZSBhIG51bWJl ciBvZg0KaXNzdWVzIGluIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgb3B0aW9uIGZvcm1hdHMuDQoN ClN1YnN0YW50aWFsOg0KDQo+ICAgIEFzIHBhcnQgb2YgY29uZmlndXJpbmcgdGhlIGluaXRpYWwg VENQL0lQIHBhcmFtZXRlcnMsIGEgbW9iaWxlIG5vZGUNCj4gICAgY2FuIG9idGFpbiBob21lIG5l dHdvcmsgaW5mb3JtYXRpb24gZm9yIHRoZSBzdWJuZXQgaXQgaXMgZGlyZWN0bHkNCj4gICAgYXR0 YWNoZWQgdG8sIG90aGVyIHN1Ym5ldHMgaW4gdGhlIHZpc2l0ZWQgZG9tYWluLCBvciBhIHN1Ym5l dCBmcm9tDQo+ICAgIGl0cyBob21lIGRvbWFpbi4NCg0KVGhpcyB0ZXh0IG1ha2VzIGl0IHNvdW5k IGxpa2UgYSBuZXcgaG9tZSBuZXR3b3JrIGlzIG5lZWRlZCBmb3INCmV2ZXJ5d2hlcmUgdGhlIG1v YmlsZSBub2RlIHRyYXZlbHMgdG8uIFRoYXQgaXMgd3JvbmcuIFN1Z2dlc3RlZCByZXdyaXRlOg0K DQpBcyBwYXJ0IG9mIGNvbmZpZ3VyaW5nIHRoZSBpbml0aWFsIFRDUC9JUCBwYXJhbWV0ZXJzLCBh IG1vYmlsZSBub2RlIGNhbg0KZmluZCBpdHNlbGYgYSBzdWl0YWJsZSBob21lIGFnZW50LiBTdWNo IGEgaG9tZSBhZ2VudCBtaWdodCByZXNpZGUgaW4gdGhlDQphY2Nlc3MgbmV0d29yayB0aGF0IHRo ZSBtb2JpbGUgbm9kZSBmaXJzdCBjb25uZWN0cyB0bywgb3IgaW4gYSBob21lDQpuZXR3b3JrIHRo YXQgdGhlIG1vYmlsZSBub2RlIGlzIGFzc29jaWF0ZWQgd2l0aC4NCg0KPiAgICBUaGUgbW9iaWxl IG5vZGUgTVVTVCBpbmNsdWRlDQo+ICAgIHRoaXMgb3B0aW9uIGFsb25nIHdpdGggaXRzIE9wdGlv biBSZXF1ZXN0IG9wdGlvbiBpbiBpdHMgcmVxdWVzdC4NCi4uLiB1bmxlc3MgaXQgYWxyZWFkeSBo YXMgY29uZmlndXJlZCBob21lIGFnZW50IGFuZCBvdGhlciBpbmZvcm1hdGlvbg0KZm9yIGl0c2Vs Zj8gSXQgd291bGQgYmUgdmVyeSBleHBlbnNpdmUgdG8gZG8gdGhpcyBvbiBldmVyeSBtb3ZlbWVu dCwgbm90DQp0byBtZW50aW9uIGxvc2luZyBzZXNzaW9ucyBpZiB0aGUgaG9tZSBhZ2VudCBhbmQg aG9tZSBhZGRyZXNzIGFyZQ0KYWN0dWFsbHkgY2hhbmdlZC4NCg0KVGhhdCBiZWluZyBzYWlkLCB0 aGUgbW9iaWxlIG5vZGUgcHJvYmFibHkgc2hvdWxkIGRvIHRoaXMgb2NjYXNpb25hbGx5IHRvDQpl bnN1cmUgdGhhdCBpdCBpcyBjb25uZWN0ZWQgdG8gdGhlIHRvcG9sb2dpY2FsbHkgYmVzdCBob21l IGFnZW50LiBZZXQNCnlvdSB3YW50IHRvIGtlZXAgdGhlIG9sZCBob21lIGFnZW50cyBzdGlsbCBp biB1c2UsIHRvIGF2b2lkIGxvc2luZyB5b3VyDQpzZXNzaW9ucy4uLiBzb21lIHRleHQgYWJvdXQg dGhpcyBpcyBwcm9iYWJseSBuZWVkZWQgZWl0aGVyIGluIHRoaXMgZHJhZnQNCm9yIHNvbWV3aGVy ZSBlbHNlLg0KDQo+ICAgICAgICAgSG9tZSBOZXR3b3JrIElkZW50aWZpZXINCj4NCj4gICAgICAg ICAgICBUaGUgaWRlbnRpZmllciB0byBzcGVjaWZ5IHRoZSByZXF1ZXN0ZWQgaG9tZSBuZXR3b3Jr IG9mDQo+ICAgICAgICAgICAgdGhlIG1vYmlsZSBub2RlLiBUaGlzIGZpZWxkIE1VU1QgYmUgc2V0 IGluIHRoZSBmb3JtIG9mIHVzZXImIzM5O3MNCj4gICAgICAgICAgICBOQUkgW1JGQzQyODJdLg0K DQpUaGUgZnVsbCBOQUk/IFRoaXMgaXMgcHJvYmxlbWF0aWMgaW4gbWFueSB3YXlzLCBpbmNsdWRp bmcgcHJpdmFjeSwNCm9wZXJhdGlvbiB3aXRoIG1vYmlsZSBub2RlcyB0aGF0IG9ubHkga25vdyB0 aGVpciBkb21haW4gYnV0IGRvIG5vdCBoYXZlDQphIE5BSSwgZXRjLg0KDQpXb3VsZG4mIzM5O3Qg aXQgYmUgbW9yZSBhcHByb3ByaWF0ZSB0byBzaW1wbHkgcHJvdmlkZSB0aGUgdXNlciYjMzk7cyBk b21haW4/DQoNCj4gICAgICAgICBpZC10eXBlDQo+DQo+ICAgICAgICAgICAgVGhlIHR5cGUgb2Yg SG9tZSBOZXR3b3JrIElkZW50aWZpZXI6DQo+DQo+ICAgICAgICAgICAgICAgIDAgICAgVmlzaXRl ZCBkb21haW4gKGxvY2FsIEFTUCkNCj4NCj4gICAgICAgICAgICAgICAgMSAgICBUYXJnZXQgTVNQ DQo+DQo+ICAgICAgICAgICAgICAgIDIgICAgTm8gcHJlZmVyZW5jZQ0KDQpUaGlzIHNlZW1zIHVu bmVjZXNzYXJpbHkgY29tcGxpY2F0ZWQuIElzIHRoZXJlIHNvbWUgcmVhc29uIHdoeSB5b3UgY291 bGQNCnNpbXBseSBpbmNsdWRlIHRoZSB0YXJnZXQgTVNQIGRvbWFpbiBpbmZvcm1hdGlvbiBpZiBp dCBpcyBrbm93biBvciBhbg0KZW1wdHkgc3RyaW5nIG90aGVyd2lzZSBhbmQgYmUgYWxsb2NhdGVk IGEgbG9jYWwgQVNQIGluIHRoYXQgY2FzZT8NCg0KPiAzLjIuICBNSVA2IFJlbGF5IEFnZW50IE9w dGlvbg0KPg0KPiAgICBUaGlzIG9wdGlvbiBjYXJyaWVzIHRoZSBSQURJVVMgb3IgRGlhbWV0ZXIg YXR0cmlidXRlcyB0aGF0IGFyZQ0KPiAgICByZWNlaXZlZCBhdCB0aGUgTkFTIGZyb20gdGhlIEFB QUguICBUaGUgREhDUCByZWxheSBhZ2VudCBzZW5kcyB0aGlzDQo+ICAgIG9wdGlvbiB0byB0aGUg REhDUCBzZXJ2ZXIgaW4gdGhlIFJlbGF5LUZvcndhcmQgbWVzc2FnZS4NCkl0IGRvZXMgbm90IGNh cnJ5IFJBRElVUyBvciBEaWFtZXRlciBhdHRyaWJ1dGVzIChhbmQgbm9yIHNob3VsZCBpdCkuDQpQ bGVhc2UgYWxpZ24gdGhpcyB0ZXh0IHdpdGggdGhlIGFjdHVhbCBzdWJhdHRyaWJ1dGVzIHRoYXQg eW91IGhhdmUuDQoNCkFsc28sIGl0IGlzIGluYXBwcm9wcmlhdGUgdG8gYXNzdW1lIHRoYXQgdGhl IGluZm9ybWF0aW9uIGNhbiBvbmx5IGNvbWUNCmZyb20gQUFBLiBQcmVzdW1hYmx5IHdlJiMzOTtk IGxpa2UgdGhlIG1lY2hhbmlzbXMgdG8gYmUgZ2VuZXJhbCBlbm91Z2ggdGhhdCwNCmZvciBpbnN0 YW5jZSwgbWFudWFsIGNvbmZpZ3VyYXRpb24sIGxpbmsgaWRlbnRpZmllciwgZXRjLiBjb3VsZCBh bHNvIGJlDQp1c2VkIHRvIGRldGVybWluZSB3aGF0IG1vYmlsaXR5IGRvbWFpbnMgYXJlIGFwcHJv cHJpYXRlIGZvciB0aGlzIGNsaWVudC4NCg0KQWZmZWN0cyBTZWN0aW9uIDQuMiwgdG9vLg0KDQo+ ICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDENCj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgfCAgICAgICBPUFRJT05fTUlQNi1ITklO RiAgICAgICB8ICAgICAgICAgICBvcHRpb24tbGVuICAgICAgICAgIHwNCj4gICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN Cj4gICAgfCAgICAgaWQtdHlwZSAgIHwgICAgcmVzZXJ2ZWQgICB8ICAgIEhOSURfc2VxICAgfCAg ICAgICAgICAgICAgIHwNCj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKyAgICAgICAgICAgICAgICsNCj4gICAgLiAgICAgICAgICAgICAgICAgICAg ICAgICAgc3ViLW9wdGlvbnMgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCj4gICAgLiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC4NCj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCj4NCj4gICAgICAgICAgb3B0aW9uLWNvZGUNCj4NCj4gICAgICAg ICAgICAgT1BUSU9OX01JUDYtSE5JTkYgKFRCRCkuDQo+DQo+ICAgICAgICAgIG9wdGlvbi1sZW4N Cj4NCj4gICAgICAgICAgICAgVG90YWwgbGVuZ3RoIG9mIHRoZSBvcHRpb24tZGF0YSBpbiBvY3Rl dHMNCj4NCj4gICAgICAgICAgaWQtdHlwZQ0KPg0KPiAgICAgICAgICAgICBUaGUgdHlwZSBvZiBI b21lIE5ldHdvcmsgSWRlbnRpZmllcjoNCj4NCj4gICAgICAgICAgICAgICAgIDAgICAgVmlzaXRl ZCBkb21haW4gKGxvY2FsIEFTUCkNCj4NCj4gICAgICAgICAgICAgICAgIDEgICAgSG9tZSBkb21h aW4NCj4NCj4gICAgICAgICAgICAgICAgIDIgICAgTm8gcHJlZmVyZW5jZQ0KPg0KPiAgICAgICAg ICByZXNlcnZlZA0KPg0KPiAgICAgICAgICAgICBBbiA4LWJpdCBmaWVsZCByZXNlcnZlZCBmb3Ig ZnV0dXJlIHVzZS4gIFRoZSB2YWx1ZSBNVVNUDQo+ICAgICAgICAgICAgIGJlIGluaXRpYWxpemVk IHRvIDAgYnkgdGhlIHNlbmRlciBhbmQgTVVTVCBiZSBpZ25vcmVkIGJ5DQo+ICAgICAgICAgICAg IHRoZSByZWNlaXZlci4NCj4NCj4gICAgICAgICAgSE5JRF9zZXENCj4NCj4gICAgICAgICAgICAg QW4gOC1iaXQgdW5zaWduZWQgaW50ZWdlciB1c2VkIGZvciBtYXRjaGluZyBmb3IgSG9tZSBOZXR3 b3JrDQo+ICAgICAgICAgICAgIElkZW50aWZpZXIgb3B0aW9ucyB3aGVuIHRoZSBtb2JpbGUgbm9k ZSBoYXMgcmVxdWVzdGVkIHdpdGgNCj4gICAgICAgICAgICAgdGhlIG11bHRpcGxlIEhvbWUgTmV0 d29yayBJZGVudGlmaWVyIG9wdGlvbnMgd2l0aCB0aGUgc2FtZQ0KPiAgICAgICAgICAgICBpZC10 eXBlIDEgYnV0IGhhdmluZyBkaWZmZXJlbnQgSG9tZSBOZXR3b3JrIElkZW50aWZpZXJzLg0KPg0K PiAgICAgICAgICBzdWItb3B0aW9ucw0KPg0KPiAgICAgICAgICAgICBBIHNlcmllcyBvZiBzdWIt b3B0aW9ucyBjYXJyeWluZyBNSVA2IGJvb3RzdHJhcA0KPiAgICAgICAgICAgICBpbmZvcm1hdGlv bi4NCg0KV2h5IGlzIGlkLXR5cGUgZmllbGQgbmVlZGVkIGhlcmU/IEp1c3QgdG8gYmUgYWJsZSB0 byByZXBseSB0byB0aGUNCnJlcXVlc3RlZCBvcHRpb24/IFRoYXQgZG9lcyBub3Qgc2VlbSBzbyB1 c2VmdWwsIElNSE8uIE9yIHRvIGJlIGFibGUgdG8NCmltcGxlbWVudCB0aGUgU2VjdGlvbiA0LjEg cHJvY2Vzc2luZyB0aGF0IGlzIGRpZmZlcmVudCBkZXBlbmRpbmcgb24gd2hhdA0KdHlwZSBvZiBu ZXR3b3JrIHdlIGFyZSB0YWxraW5nIGFib3V0PyBCdXQgd291bGRuJiMzOTt0IEhOSURfc2VxIGFu ZCB0aGUNCm9yZGVyaW5nIG9mIG9wdGlvbnMgYmUgc3VmZmljaWVudCBmb3IgdGhpcz8NCg0KPiAg ICBXaGVuIHRoZSBtb2JpbGUgbm9kZSByZWNlaXZlcyBhIFJlcGx5IG1lc3NhZ2UgZnJvbSB0aGUg REhDUCBzZXJ2ZXINCj4gICAgYW5kIGdldHMgbW9yZSB0aGFuIG9uZSBob21lIG5ldHdvcmsgaW5m b3JtYXRpb24sIGl0IE1VU1QgaGF2ZSBhDQo+ICAgIHNlbGVjdGlvbiBtZWNoYW5pc20gdG8gZGV0 ZXJtaW5lIHdoaWNoIG9uZSB0byB1c2UgZm9yIGVzdGFibGlzaGluZyBhDQo+ICAgIE1vYmlsZSBJ UHY2IHNlc3Npb24uICBGb3IgZXhhbXBsZSwgaWYgdGhlIG1vYmlsZSBub2RlIGFjcXVpcmVzIGJv dGgNCj4gICAgSVB2NiBhZGRyZXNzIGFuZCBGUUROIG9mIHRoZSBob21lIGFnZW50LCBpdCBtYXkg dHJ5IHRvIHVzZSB0aGUNCj4gICAgYWRkcmVzcyBpbmZvcm1hdGlvbiBvZiB0aGUgaG9tZSBhZ2Vu dCBmaXJzdC4NCg0KSSBhZ3JlZSB0aGF0IGEgc2VsZWN0aW9uIG1lY2hhbmlzbSBpcyBuZWVkZWQu IEJ1dCBpcyBjbGVhciBob3cgSSBjYW4NCmV2YWx1YXRlIGFuIGltcGxlbWVudGF0aW9uJiMzOTtz IGNvbmZvcm1hbmNlIHRvIHRoZSBNVVNUIGFib3ZlLiBJdCBtaWdodCBiZQ0KYmV0dGVyIHRvIHNp bXBseSBlbnVtZXJhdGUgaW4gdGhpcyBkcmFmdCB3aGF0IHRoZSBvcmRlciBzaG91bGQgYmUsIGFu ZA0Kd2hldGhlciBtdWx0aXBsZSBpbiBwYXJhbGxlbCBjb250YWN0IGF0dGVtcHRzIGFyZQ0KcmVx dWlyZWQvYWxsb3dlZC9kaXNjb3VyYWdlZC4gVGhlIHN1YnNlcXVlbnQgdGV4dCBkb2VzIGRvIHRo aXMsIGF0IGxlYXN0DQp0byBhbiBleHRlbnQuIEl0cyBub3QgY2xlYXIgdGhhdCB0aGUgTVVTVCBh Ym92ZSBpcyBuZWVkZWQgaWYgdGhlIHRleHQgaXMNCmNvbXBsZXRlLg0KDQo+ICAgIEhvd2V2ZXIs IGhvdyBsb25nIHRoZSBOQVMgc2hvdWxkIGtlZXANCj4gICAgdGhlIGhvbWUgaW5mb3JtYXRpb24g ZGVwZW5kcyBvbiB0aGUgYWRtaW5pc3RyYXRvciYjMzk7cyBwb2xpY3kuICBXaGVuIHRoZQ0KPiAg ICBOQVMgZG9lcyBub3Qga2VlcCB0aGUgaG9tZSBpbmZvcm1hdGlvbiBmb3IgdGhlIHJlcXVlc3Rp bmcgbW9iaWxlIG5vZGUNCj4gICAgYXQgdGhlIHRpbWUgb2YgcmVjZWl2aW5nIHRoZSBJbmZvcm1h dGlvbiBSZXF1ZXN0IGZyb20gdGhlIG1vYmlsZQ0KPiAgICBub2RlLCBpdCBtYXkgdHJ5IHRvIGFj cXVpcmUgdGhlIGluZm9ybWF0aW9uIGJ5IGludGVyYWN0aW5nIHdpdGggYSBBQUENCj4gICAgc2Vy dmVyIGFnYWluIHRocm91Z2ggc29tZSBvdGhlciBtZWNoYW5pc21zIHdoaWNoIGFyZSBub3QgaW4g dGhlIHNjb3BlDQo+ICAgIG9mIHRoaXMgZG9jdW1lbnQNCg0KQnV0IHN1Y2ggbWVjaGFuaXNtcyBk byBub3QgZXhpc3QgaW4gdGhlIGdlbmVyYWwgY2FzZS4gSSB3b3VsZCByZWNvbW1lbmQNCnNpbXBs eSByZXF1aXJpbmcgdGhhdCB0aGUgTkFTIG5lZWRzIHRvIHN0b3JlIHRoZSBpbmZvcm1hdGlvbi4g SW4gYW55DQpjYXNlLCBhIE5BUyBpcyByZXF1aXJlZCB0byBrbm93IGFib3V0IHRoZSBzZXNzaW9u cyBpdCBoYXMuDQoNCj4gNC4yLiAgTkFTL0RIQ1AgUmVsYXkgQWdlbnQgQmVoYXZpb3INCj4NCj4g ICAgVGhlIE5BUyBhbmQgdGhlIERIQ1AgcmVsYXkgYWdlbnQgYXJlIGFzc3VtZWQgdG8gYmUgY29s bG9jYXRlZCBpbiB0aGlzDQo+ICAgIHNvbHV0aW9uLg0KDQpUaGlzIGxpbWl0YXRpb24gbmVlZHMg dG8gYmUgc3RhdGVkIHVwZnJvbnQsIGluIHRoZSBJbnRyb2R1Y3Rpb24uDQoNCihBbmQgdGhlIGxp bWl0YXRpb24gZG9lcyBub3QgYXBwZWFyIHRvIGJlIGV4YWN0bHkgd2hhdCB5b3Ugc2F5IGFib3Zl Lg0KUHJlc3VtYWJseSB0eXBlIDAgaG9tZSBhZ2VudHMgY2FuIGJlIHJlcXVlc3RlZCB3aXRob3V0 IGFueSByZWxheXMuKQ0KDQpFZGl0b3JpYWw6DQoNCj4gICAgICAgICAgICBPUFRJT05fTUlQNi1I TklEIChUQkQpDQpEbyB5b3UgcmVhbGx5IGhhdmUgdG8gbWl4IHVuZGVyc2NvcmUgYW5kIGRhc2gg aW4gdGhlIHNhbWUgc3ltYm9sPw0KDQpCZXJuaWUgVm9seiYjMzk7cyByZXZpZXc6DQoNCj4gMy4y LjEuICBNSVA2IFJlbGF5IEFnZW50IFN1Yi1vcHRpb24NCj4NCj4gICAgVGhpcyBzdWItb3B0aW9u IGNhcnJpZXMgdGhlIGFzc2lnbmVkIGhvbWUgbmV0d29yayBpbmZvcm1hdGlvbiB0byB0aGUNCj4g ICAgREhDUCBzZXJ2ZXIuDQo+DQo+DQo+ICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCj4gICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAg fCAgICAgICAgICBzdWItb3B0LWNvZGUgICAgICAgICB8ICBzdWItb3B0LWxlbiAgfCAgICByZXNl cnZlZCAgIHwNCj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCj4gICAgLiAgICAgICAgICAg ICAgICAgICBIb21lIE5ldHdvcmsgSW5mb3JtYXRpb24gICAgICAgICAgICAgICAgICAgIC4NCj4g ICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC4NCj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4NCj4gICAgICAgICAgc3ViLW9wdC1jb2RlDQo+ DQo+ICAgICAgICAgICAgIEEgMTYtYml0IHVuc2lnbmVkIGludGVnZXIuIFRoZSBzdWItb3B0aW9u IGlkZW50aWZpZXMgdGhlDQo+ICAgICAgICAgICAgIHR5cGUgb2YgdGhlIGZvbGxvd2luZyBIb21l IE5ldHdvcmsgSW5mb3JtYXRpb24gZmllbGQuDQo+ICAgICAgICAgICAgIFBvc3NpYmxlIHZhbHVl cyBhcmU6DQo+DQo+ICAgICAgICAgICAgICAgICAxICAgIEhvbWUgc3VibmV0IHByZWZpeA0KPg0K PiAgICAgICAgICAgICAgICAgMiAgICBDb21wbGV0ZSBJUHY2IGFkZHJlc3Mgb2YgdGhlIGhvbWUg YWdlbnQNCj4NCj4gICAgICAgICAgICAgICAgIDMgICAgRlFETiBvZiB0aGUgaG9tZSBhZ2VudA0K Pg0KPiAgICAgICAgICBzdWItb3B0LWxlbg0KPg0KPiAgICAgICAgICAgICBBbiA4LWJpdCB1bnNp Z25lZCBpbnRlZ2VyLiBUaGUgbGVuZ3RoIG9mIHRoZSBmb2xsb3dpbmcNCj4gICAgICAgICAgICAg SG9tZSBOZXR3b3JrIEluZm9ybWF0aW9uIGZpZWxkICsgMS4NCj4NCj4NCj4gLS0+IERIQ1B2NiB1 c2VzIDE2LUJJVCBvcHRpb24vc3Vib3B0aW9uIENPREVTIEFORCAxNi1CSVQgTEVOR1RIUywgbm90 DQo+IDgtYml0IGxlbmd0aHMhIEFuZCBtaXhpbmcgMTYvOCBiaXRzIGlzIHRoZSBXT1JTVCB0aGlu ZyB0aGF0IHRoZXkgY291bGQNCj4gZXZlciBkby4gTXkgcmVjb21tZW5kYXRpb24gd291bGQgYmUg dG8gdXNlIDE2LWJpdCBjb2RlcyBhbmQgMTYtYml0DQo+IGxlbmd0aHMuIFBFUklPRC4NCj4NCj4g VGhpcyBzYW1lIGlzc3VlIGV4aXN0cyBpbiAzLjMuMSwgSG9tZSBOZXR3b3JrIEluZm9ybWF0aW9u IFN1Yi1vcHRpb24uDQo+DQo+DQo+IFNlY3Rpb24gNCAoYW5kIDQuMyBpbiBwYXJ0aWN1bGFyKSBt ZW50aW9ucyB0aGUgT1JPIG9wdGlvbiBidXQgZG9lc24mIzM5O3QNCj4gbWFrZSBpdCBjbGVhciB0 aGF0IHRoZSBPUFRJT05fTUlQNi1ITklORiBvcHRpb24gY29kZSAqTVVTVCogYmUgaW5jbHVkZWQN Cj4gaW4gdGhlIE9STyBpZiB0aGUgY2xpZW50IGV2ZXIgd2FudHMgdGhpcyBvcHRpb24gcmV0dXJu ZWQgYnkgdGhlIHNlcnZlci4NCj4NCj4gSW4gNC4xLCBpcyBzdGF0ZWQ6DQo+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSW4gdGhpcyBtZXNzYWdlDQo+ICAg IHRoZSBtb2JpbGUgbm9kZSAoREhDUCBjbGllbnQpIFNIQUxMIGluY2x1ZGUgdGhlIE9wdGlvbiBD b2RlIGZvciB0aGUNCj4gICAgSG9tZSBOZXR3b3JrIElkZW50aWZpZXIgb3B0aW9uIGluIHRoZSBP UFRJT05fT1JPLg0KPg0KPiBCdXQsIHdoeSB3b3VsZCB0aGUgY2xpZW50IGluY2x1ZGUgdGhlIE9Q VElPTl9NSVA2LUhOSUQgaW4gdGhlIE9STywgYXMNCj4gdGhpcyBpcyBGUk9NIENMSUVOVCBUTyBT RVJWRVIuIEkgdGhpbmsgdGhleSBtZWFudCBPUFRJT05fTUlQNi1ITklORi4NCj4gU2VjdGlvbiAz LjEgc3RhdGVzOg0KPg0KPiAzLjEuICBIb21lIE5ldHdvcmsgSWRlbnRpZmllciBPcHRpb24NCj4N Cj4gICAgVGhpcyBvcHRpb24gaXMgdXNlZCB0byBpbmRpY2F0ZSB0aGUgdGFyZ2V0IGhvbWUgbmV0 d29yayByZXF1ZXN0ZWQgYnkNCj4gICAgdGhlIG1vYmlsZSBub2RlIHRvIHRoZSBESENQIHNlcnZl ci4gIFRoZSBtb2JpbGUgbm9kZSBNVVNUIGluY2x1ZGUNCj4gICAgdGhpcyBvcHRpb24gYWxvbmcg d2l0aCBpdHMgT3B0aW9uIFJlcXVlc3Qgb3B0aW9uIGluIGl0cyByZXF1ZXN0Lg0KPg0KPg0KPiBQ ZXJzb25hbGx5LCB0aGV5IG5lZWQgdG8gZ28gYmFjayB0byBjbGVhbiB1cCB0aGlzIGRyYWZ0LiBJ dCBpcyBOT1QNCj4gYWNjZXB0YWJsZSBhbmQgZnVsbCBvZiBtaXN0YWtlcy4NCj4NCj4gSSBoYXZl biYjMzk7dCBzdHVkaWVkIGl0IGNhcmVmdWxseSwgYnV0IGFzIEkmIzM5O3ZlIGFscmVhZHkgZm91 bmQgdGhlIGFib3ZlDQo+IGlzc3VlcywgbW9yZSB3b3JrIGlzIG5lZWRlZCB0byBjbGVhbiBpdCB1 cC4NCg0KPiBPaCwgeW91IGNhbiBhZGQgYW5vdGhlciBpc3N1ZSB0byB0aGlzIGRyYWZ0LiBUd28g b2YgdGhlIGVtYWlsIGFkZHJlc3Nlcw0KPiBpbiB0aGUgZHJhZnQgYXJlIGJhZDoNCj4NCj4gNS4x LjAgLSBVbmtub3duIGFkZHJlc3MgZXJyb3IgNTUwLSYjMzk7NS4xLjEgPGF0aGVuZUBzYWl0LnNh bXN1bmcuY28ua3I+Li4uDQo+IFVzZXIgdW5rbm93biYjMzk7DQo+IDUuMS4wIC0gVW5rbm93biBh ZGRyZXNzIGVycm9yIDU1MC0mIzM5OzUuMS4xIE5vIHN1Y2ggdXNlcg0KPiA8YWxwZXIwMS55ZWdp bkBwYXJ0bmVyLnNhbXN1bmcuY29tPg0KDQoNCg0K --===============0142370714== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0142370714==-- From mip6-bounces@ietf.org Fri Oct 26 05:17:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlLJ6-00018z-RB; Fri, 26 Oct 2007 05:16:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlLJ6-000123-4L; Fri, 26 Oct 2007 05:16:44 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlLJ5-00030l-Ne; Fri, 26 Oct 2007 05:16:44 -0400 X-AuditID: c10cb581-00002044000020cc-dd-4721b0754df0 Received: from stingray.eu.tieto.com ([192.176.143.13]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 11:16:37 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 11:16:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Date: Fri, 26 Oct 2007 11:16:41 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Thread-Index: AcgXD2Nk409BdK32Rr+w24XNw+KidQAii1/gAAEXFRAABHSkQA== References: From: To: , , , X-OriginalArrivalTime: 26 Oct 2007 09:16:42.0267 (UTC) FILETIME=[EC16F6B0:01C817B0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, =20 Can these roundtrips be in=20 > > parallel or are > > they sequential? If they need to be sequential, I think=20 > > that is a big > > enough negative impact on handoff times. If they can be=20 > parallel and >=20 > =3D> They can definitely be in parallel, but I don't think IKE=20 > knows enough > about movement to do this in any timely manner. So, it makes=20 > the handover of > the secure traffic non-deterministic. Sorry if I gave that=20 > impression (that > they have to be sent sequentially).=20 >=20 With the IKEv2 RFC in hand, and only the RFC - NOT individual implementations, then with minimal interpretation of section 2.23 of RFC 4306, the update cannot be done in parallel, the HA MUST process the BU and make some changes in the IKE_SA and the IPSEC tunnel SAS before a single IKE exchange can update the IKE_SAs and the RFC 3948 IPSec SAs appropriately. If we are speaking of a full new IKE_SA establishment and a new IPsec tunnel SA creation (means 2 extra RTTs) then this can be done in parallel. With MOBIKE, the update can be done in parallel and would only detail one exchange. BR, Karen _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 26 06:52:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlMld-0000Wi-1i; Fri, 26 Oct 2007 06:50:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlMla-0000VB-4f; Fri, 26 Oct 2007 06:50:15 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlMlP-0007uw-Px; Fri, 26 Oct 2007 06:50:10 -0400 Received: from oaamta08sl.mx.bigpond.com ([124.190.106.219]) by omta04sl.mx.bigpond.com with ESMTP id <20071026104920.DBXY1805.omta04sl.mx.bigpond.com@oaamta08sl.mx.bigpond.com>; Fri, 26 Oct 2007 10:49:20 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta08sl.mx.bigpond.com with ESMTP id <20071026104916.XOF10966.oaamta08sl.mx.bigpond.com@PC20005>; Fri, 26 Oct 2007 10:49:16 +0000 From: "Hesham Soliman" To: , , , Subject: RE: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Date: Fri, 26 Oct 2007 20:49:06 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-index: AcgXD2Nk409BdK32Rr+w24XNw+KidQAii1/gAAEXFRAABHSkQAADfJpg X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Thanks Karen for the clarification. So, we have two cases here: 1. Standard IKEv2 = Sequential updates 2. Mobike = parallel updates. Hesham > -----Original Message----- > From: Karen.Nielsen@tietoenator.com > [mailto:Karen.Nielsen@tietoenator.com] > Sent: Friday, October 26, 2007 7:17 PM > To: Hesham@elevatemobile.com; vidyan@qualcomm.com; > mip6@ietf.org; nemo@ietf.org > Subject: RE: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and > call for concensus > > Hi, > > Can these roundtrips be in > > > parallel or are > > > they sequential? If they need to be sequential, I think > > > that is a big > > > enough negative impact on handoff times. If they can be > > parallel and > > > > => They can definitely be in parallel, but I don't think IKE > > knows enough > > about movement to do this in any timely manner. So, it makes > > the handover of > > the secure traffic non-deterministic. Sorry if I gave that > > impression (that > > they have to be sent sequentially). > > > > With the IKEv2 RFC in hand, and only the RFC - NOT individual > implementations, > then with minimal interpretation of section 2.23 of RFC > 4306, the update > cannot be done in parallel, the HA MUST process the BU and make some > changes in the IKE_SA and the IPSEC tunnel SAS before a single IKE > exchange can update the IKE_SAs and the RFC 3948 IPSec SAs > appropriately. > > If we are speaking of a full new IKE_SA establishment and a new IPsec > tunnel SA > creation (means 2 extra RTTs) then this can be done in parallel. > > With MOBIKE, the update can be done in parallel and would only detail > one > exchange. > > BR, Karen > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 26 15:13:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlUZo-0007Qj-2m; Fri, 26 Oct 2007 15:10:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlUZk-0007AR-Hi; Fri, 26 Oct 2007 15:10:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlUZk-0004RU-5t; Fri, 26 Oct 2007 15:10:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 19EDB2AC81; Fri, 26 Oct 2007 19:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IlUZF-0001Dx-S5; Fri, 26 Oct 2007 15:10:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 26 Oct 2007 15:10:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: mip6@ietf.org Subject: [Mip6] I-D Action:draft-ietf-mip6-ha-switch-04.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-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 Mobility for IPv6 Working Group of the IETF. Title : Mobility Header Home Agent Switch Message Author(s) : B. Haley, et al. Filename : draft-ietf-mip6-ha-switch-04.txt Pages : 12 Date : 2007-10-26 This document specifies a new Mobility Header message type that can be used between a home agent and mobile node to signal a mobile node that it should acquire a new home agent. Haley, et al Expires - April 2008 [page 1] Home Agent Switch Message October 2007 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-ha-switch-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-ha-switch-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-ha-switch-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-26150220.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-ha-switch-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-ha-switch-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-26150220.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Mon Oct 29 20:35:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imf39-0006Wi-RP; Mon, 29 Oct 2007 20:33:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imf2t-0003rb-Bd; Mon, 29 Oct 2007 20:33:27 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imf2i-0003G7-4b; Mon, 29 Oct 2007 20:33:16 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 17:33:11 -0700 Message-ID: <47267BC6.2090302@azairenet.com> Date: Mon, 29 Oct 2007 17:33:10 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman , Karen.Nielsen@tietoenator.com, Christian.Kaas-Petersen@tietoenator.com Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2007 00:33:11.0281 (UTC) FILETIME=[7355DE10:01C81A8C] X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Thanks Hesham. I think I mixed up solution 2 described below in your email with solution 2 described in an email you sent on the 17th of October. http://www1.ietf.org/mail-archive/web/mip6/current/msg06856.html I do want to avoid two round trips during every handover. I also want to avoid running MOBIKE at the same time as MIPv6. Does not make sense. Having said, I would like to figure out whats wrong with running IKEv2 on port 4500, but sending the BU on DS-MIPv6 port with a transport mode SA. Lets say IKEv2 runs on UDP port 4500 always and negotiates a transport mode SA for protecting the BU. When the BU packet goes through the SPD entries, the transport mode SA is picked. After IPsec processing the packet will be as follows IPv6 hdr (src=V6HOA, dst=HAADDR) ESP Hdr BU IPv4 CoA option With DS-MIPv6 encapsulation the packet becomes IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) IPv6 hdr (src=V6HOA, dst=HAADDR) ESP Hdr BU IPv4 CoA option Now lets assume the mobile node moves and attaches to another IPv4 access network. The transport mode IPsec SA is still valid. IKEv2 does not know that the mobile node moved, its IPv4 address changed or if there is a new NAT in the path. So the mobile node can send a BU right away as follows. IPv4 hdr (src=new_V4ADDR, dst=HA_V4ADDR) UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) IPv6 hdr (src=V6HOA, dst=HAADDR) ESP Hdr BU IPv4 CoA option (new IPv4 CoA) When the HA receives the BU, the packet will appear like the following IPv4 hdr (src=NATTED_new_V4ADDR, dst=HA_V4ADDR) UDP hdr (srcport=NATTED_DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) IPv6 hdr (src=V6HOA, dst=HAADDR) ESP Hdr BU IPv4 CoA option (new IPv4 CoA) The HA would process the BU and respond to the NATTED_DS-MIPv6-PORT. Meanwhile the MIPv6 stack on the mobile node will trigger the IKEv2 daemon on the mobile node to re-run IKEv2. This is because the original IKEv2 SA iFrom mip6-bounces@ietf.org Mon Oct 29 20:35:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imf39-0006Wi-RP; Mon, 29 Oct 2007 20:33:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imf2t-0003rb-Bd; Mon, 29 Oct 2007 20:33:27 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imf2i-0003G7-4b; Mon, 29 Oct 2007 20:33:16 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 17:33:11 -0700 Message-ID: <47267BC6.2090302@azairenet.com> Date: Mon, 29 Oct 2007 17:33:10 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman , Karen.Nielsen@tietoenator.com, Christian.Kaas-Petersen@tietoenator.com Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2007 00:33:11.0281 (UTC) FILETIME=[7355DE10:01C81A8C] X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Thanks Hesham. I think I mixed up solution 2 described below in your email with solution 2 described in an email you sent on the 17th of October. http://www1.ietf.org/mail-archive/web/mip6/current/msg06856.html I do want to avoid two round trips during every handover. I also want to avoid running MOBIKE at the same time as MIPv6. Does not make sense. Having said, I would like to figure out whats wrong with running IKEv2 on port 4500, but sending the BU on DS-MIPv6 port with a transport mode SA. Lets say IKEv2 runs on UDP port 4500 always and negotiates a transport mode SA for protecting the BU. When the BU packet goes through the SPD entries, the transport mode SA is picked. After IPsec processing the packet will be as follows IPv6 hdr (src=V6HOA, dst=HAADDR) ESP Hdr BU IPv4 CoA option With DS-MIPv6 encapsulation the packet becomes IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) IPv6 hdr (src=V6HOA, dst=HAADDR) ESP Hdr BU IPv4 CoA option Now lets assume the mobile node moves and attaches to another IPv4 access network. The transport mode IPsec SA is still valid. IKEv2 does not know that the mobile node moved, its IPv4 address changed or if there is a new NAT in the path. So the mobile node can send a BU right away as follows. IPv4 hdr (src=new_V4ADDR, dst=HA_V4ADDR) UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) IPv6 hdr (src=V6HOA, dst=HAADDR) ESP Hdr BU IPv4 CoA option (new IPv4 CoA) When the HA receives the BU, the packet will appear like the following IPv4 hdr (src=NATTED_new_V4ADDR, dst=HA_V4ADDR) UDP hdr (srcport=NATTED_DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) IPv6 hdr (src=V6HOA, dst=HAADDR) ESP Hdr BU IPv4 CoA option (new IPv4 CoA) The HA would process the BU and respond to the NATTED_DS-MIPv6-PORT. Meanwhile the MIPv6 stack on the mobile node will trigger the IKEv2 daemon on the mobile node to re-run IKEv2. This is because the original IKEv2 SA is not valid anymore. When the IKEv2 SAs are re-negotiated, new IPsec SAs are also setup. This would allow the IKEv2 exchange to happen out of the critical path. There is no update to the IKEv2 SA based on the BU/BAck exchange. There are no tunnel mode SAs created for any MIPv6 signaling messages. What am I missing now? Vijay Hesham Soliman wrote: > > IMO, we should go with solution 2) below. I prefer that we let > > IKEv2 use its own NAT traversal mechanism. Regarding two round > > trips during a handover, note that the IKEv2 exchange to > > re-establish the IKEv2 SA and the IPsec SAs is not in the > > critical path of handover. > > => It is in the critical path for the secure packets. That's what the > discussion was about. > > The BU/BAck messages can be exchanged > > with the existing IPsec SAs. The IKEv2 exchange can be happen a > > few seconds (or minutes) after the handover. So there is *no* > > impact on the handover. > > => No, see above. This is only good for insecure traffic. At least this is > not solution 2 below. > > Hesham > > > > > This would be the same as the lack of support for the "K" flag > > in RFC 3775. In RFC 3775, if either the mobile node or the home > > agent are not capable of updating the IKE SA based on the > > exchange of BU/BAck, there is always an IKE exchange after the > > handover (or whenever the CoA changes). > > > > Please let me know if I am missing something related to the > > impact of the IKEv2 exchange on the handover. > > > > I am not comfortable with the temporary tunnel created in > > solution 1). > > > > Vijay > > > > Hesham Soliman wrote: > > > Folks, > > > > > > This discussion has been going on for a while and I'm sure > > it wasn't for > > > easy to follow. > > > This email contains a summary of the discussion so far and > > a call for > > > comment/concensus. Please respond promptly because there > > is some pressure > > > from 3GPP to get this draft out very soon. > > > > > > The issue is how to run IKE in combination with DSMIPv6 in > > a private > > > IPv4-only network. If you want more detail about why this > > is a problem > > > please look at the thread "DSMIPv6 and IKE". > > > > > > There are three types of solutions that we discussed. A > > quick summary of > > > each below: > > > > > > 1. The Virtual link approach. In this case IKE runs over > > v6 only and is > > > completely unaware of the IPv4 network. As a result IKE's > > NAT traversal is > > > never invoked. Only DSMIPv6's NAT traversal is used. In > > this approach, the > > > DSMIPv6 implementation in the HA is required to cache the > > outer IPv4 address > > > and source port of the IPv4 message that contains IKE, > > then append them to > > > the response from its own IKE daemon. This is basically > > done to hide the > > > IPv4 network from IKE and effectively disable its NAT > > traversal, which > > > solves our problem. > > > Three people agreed with this approach but two people (I'm > > including > > > Christian) are against it. So there doesn't seem to be > > concensus on this. I > > > believe the concern here was that the HA's caching of the > > outer address and > > > port was complex for the implementation. > > > > > > 2. Karen suggested a way of running IKE without any > > changes (again see the > > > thread for details). In this approach DSMIPv6 BUs are > > secured with ESP as > > > usual. Normal traffic is sent over the DSMIPv6 port. > > However, secure traffic > > > is sent over the IKE port (4500). The result of this > > approach is that it > > > takes two messages to complete a handover, one from > > DSMIPv6 (BU) and an > > > update from IKE (for the secure traffic). The concern that > > I had here in the > > > discussion with Karen was the number of messages and the > > delays associated > > > for that. Of course IKE doesn't do movement detection > > ...etc. So my concern > > > is the discriminatory experience of the handover for > > different parts of the >s not valid anymore. When the IKEv2 SAs are re-negotiated, new IPsec SAs are also setup. This would allow the IKEv2 exchange to happen out of the critical path. There is no update to the IKEv2 SA based on the BU/BAck exchange. There are no tunnel mode SAs created for any MIPv6 signaling messages. What am I missing now? Vijay Hesham Soliman wrote: > > IMO, we should go with solution 2) below. I prefer that we let > > IKEv2 use its own NAT traversal mechanism. Regarding two round > > trips during a handover, note that the IKEv2 exchange to > > re-establish the IKEv2 SA and the IPsec SAs is not in the > > critical path of handover. > > => It is in the critical path for the secure packets. That's what the > discussion was about. > > The BU/BAck messages can be exchanged > > with the existing IPsec SAs. The IKEv2 exchange can be happen a > > few seconds (or minutes) after the handover. So there is *no* > > impact on the handover. > > => No, see above. This is only good for insecure traffic. At least this is > not solution 2 below. > > Hesham > > > > > This would be the same as the lack of support for the "K" flag > > in RFC 3775. In RFC 3775, if either the mobile node or the home > > agent are not capable of updating the IKE SA based on the > > exchange of BU/BAck, there is always an IKE exchange after the > > handover (or whenever the CoA changes). > > > > Please let me know if I am missing something related to the > > impact of the IKEv2 exchange on the handover. > > > > I am not comfortable with the temporary tunnel created in > > solution 1). > > > > Vijay > > > > Hesham Soliman wrote: > > > Folks, > > > > > > This discussion has been going on for a while and I'm sure > > it wasn't for > > > easy to follow. > > > This email contains a summary of the discussion so far and > > a call for > > > comment/concensus. Please respond promptly because there > > is some pressure > > > from 3GPP to get this draft out very soon. > > > > > > The issue is how to run IKE in combination with DSMIPv6 in > > a private > > > IPv4-only network. If you want more detail about why this > > is a problem > > > please look at the thread "DSMIPv6 and IKE". > > > > > > There are three types of solutions that we discussed. A > > quick summary of > > > each below: > > > > > > 1. The Virtual link approach. In this case IKE runs over > > v6 only and is > > > completely unaware of the IPv4 network. As a result IKE's > > NAT traversal is > > > never invoked. Only DSMIPv6's NAT traversal is used. In > > this approach, the > > > DSMIPv6 implementation in the HA is required to cache the > > outer IPv4 address > > > and source port of the IPv4 message that contains IKE, > > then append them to > > > the response from its own IKE daemon. This is basically > > done to hide the > > > IPv4 network from IKE and effectively disable its NAT > > traversal, which > > > solves our problem. > > > Three people agreed with this approach but two people (I'm > > including > > > Christian) are against it. So there doesn't seem to be > > concensus on this. I > > > believe the concern here was that the HA's caching of the > > outer address and > > > port was complex for the implementation. > > > > > > 2. Karen suggested a way of running IKE without any > > changes (again see the > > > thread for details). In this approach DSMIPv6 BUs are > > secured with ESP as > > > usual. Normal traffic is sent over the DSMIPv6 port. > > However, secure traffic > > > is sent over the IKE port (4500). The result of this > > approach is that it > > > takes two messages to complete a handover, one from > > DSMIPv6 (BU) and an > > > update from IKE (for the secure traffic). The concern that > > I had here in the > > > discussion with Karen was the number of messages and the > > delays associated > > > for that. Of course IKE doesn't do movement detection > > ...etc. So my concern > > > is the discriminatory experience of the handover for > > different parts of the > > > traffic. > > > > > > 3. The third class of solutions involves either modifying > > MIPv6 (adding new > > > messages) or IKE or both. I'm only including this for > > completeness, no one > > > really wants this. > > > > > > Please send your comments on the above. Basically the > > options are 1 or 2. In > > > theory we could do both but I think it's best to pick one > > method for this to > > > avoid interoperability issues and additional complexity. > > > > > > Hesham > > > > > > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 29 20:35:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imf3d-00020N-Kk; Mon, 29 Oct 2007 20:34:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imf3b-0001tu-Bv; Mon, 29 Oct 2007 20:34:11 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imf3a-0003KB-Vb; Mon, 29 Oct 2007 20:34:11 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 17:34:09 -0700 Message-ID: <47267C01.90809@azairenet.com> Date: Mon, 29 Oct 2007 17:34:09 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karen.Nielsen@tietoenator.com Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus References: <47217E35.7010705@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2007 00:34:09.0812 (UTC) FILETIME=[9638FD40:01C81A8C] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Karen.Nielsen@tietoenator.com wrote: > Hi, > >> > IMO, we should go with solution 2) below. I prefer that we let >> > IKEv2 use its own NAT traversal mechanism. Regarding two round >> > trips during a handover, note that the IKEv2 exchange to >> > re-establish the IKEv2 SA and the IPsec SAs is not in the >> > critical path of handover. >> >> => It is in the critical path for the secure packets. That's what the >> discussion was about. >> >> The BU/BAck messages can be exchanged >> > with the existing IPsec SAs. The IKEv2 exchange can be happen a >> > few seconds (or minutes) after the handover. So there is *no* >> > impact on the handover. >> >> => No, see above. This is only good for insecure traffic. At >> least this is >> not solution 2 below. >> > > Actually secure traffic from the MN towards the HA is not impacted by > the delay, > but it is true that secure traffic in the HA to MN direction is > impacted. It will > not function until the HA IPSEC SA has been upated with the correct > ports and addresses But why? I thought this was a transport mode SA keyed on the IPv6 home address of the mobile node. Vijay and this will not happen unt > > traffic. > > > > > > 3. The third class of solutions involves either modifying > > MIPv6 (adding new > > > messages) or IKE or both. I'm only including this for > > completeness, no one > > > really wants this. > > > > > > Please send your comments on the above. Basically the > > options are 1 or 2. In > > > theory we could do both but I think it's best to pick one > > method for this to > > > avoid interoperability issues and additional complexity. > > > > > > Hesham > > > > > > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 29 20:35:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imf3d-00020N-Kk; Mon, 29 Oct 2007 20:34:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imf3b-0001tu-Bv; Mon, 29 Oct 2007 20:34:11 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imf3a-0003KB-Vb; Mon, 29 Oct 2007 20:34:11 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 17:34:09 -0700 Message-ID: <47267C01.90809@azairenet.com> Date: Mon, 29 Oct 2007 17:34:09 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karen.Nielsen@tietoenator.com Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus References: <47217E35.7010705@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2007 00:34:09.0812 (UTC) FILETIME=[9638FD40:01C81A8C] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Karen.Nielsen@tietoenator.com wrote: > Hi, > >> > IMO, we should go with solution 2) below. I prefer that we let >> > IKEv2 use its own NAT traversal mechanism. Regarding two round >> > trips during a handover, note that the IKEv2 exchange to >> > re-establish the IKEv2 SA and the IPsec SAs is not in the >> > critical path of handover. >> >> => It is in the critical path for the secure packets. That's what the >> discussion was about. >> >> The BU/BAck messages can be exchanged >> > with the existing IPsec SAs. The IKEv2 exchange can be happen a >> > few seconds (or minutes) after the handover. So there is *no* >> > impact on the handover. >> >> => No, see above. This is only good for insecure traffic. At >> least this is >> not solution 2 below. >> > > Actually secure traffic from the MN towards the HA is not impacted by > the delay, > but it is true that secure traffic in the HA to MN direction is > impacted. It will > not function until the HA IPSEC SA has been upated with the correct > ports and addresses But why? I thought this was a transport mode SA keyed on the IPv6 home address of the mobile node. Vijay and this will not happen until one of the following > two things has happened: > > * the MN has send secure traffic towarsd the HA > * the MN has initiated an IKE_SA update exchange > > Karen > >> Hesham >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 il one of the following > two things has happened: > > * the MN has send secure traffic towarsd the HA > * the MN has initiated an IKE_SA update exchange > > Karen > >> Hesham >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 29 20:38:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imf7b-0004vJ-Mb; Mon, 29 Oct 2007 20:38:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imf7a-0004vB-7j; Mon, 29 Oct 2007 20:38:18 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imf7Z-0003ZE-R9; Mon, 29 Oct 2007 20:38:18 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 17:38:01 -0700 Message-ID: <47267CE9.30306@azairenet.com> Date: Mon, 29 Oct 2007 17:38:01 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karen.Nielsen@tietoenator.com Subject: Re: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2007 00:38:01.0187 (UTC) FILETIME=[20220330:01C81A8D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Karen, I am not sure if you are talking about a transport mode SA or tunnel mode SA to protect the BU. You have used both in your emails. Vijay Karen.Nielsen@tietoenator.com wrote: > Hi, > > Can these roundtrips be in > > > parallel or are > > > they sequential? If they need to be sequential, I think > > > that is a big > > > enough negative impact on handoff times. If they can be > > parallel and > > > > => They can definitely be in parallel, but I don't think IKE > > knows enough > > about movement to do this in any timely manner. So, it makes > > the handover of > > the secure traffic non-deterministic. Sorry if I gave that > > impression (that > > they have to be sent sequentially). > > > > With the IKEv2 RFC in hand, and only the RFC - NOT individual > implementations, > then with minimal interpretation of section 2.23 of RFC 4306, the update > cannot be done in parallel, the HA MUST process the BU and make some > changes in the IKE_SA and the IPSEC tunnel SAS before a single IKE > exchange can update the IKE_SAs and the RFC 3948 IPSec SAs > appropriately. > > If we are speaking of a full new IKE_SA establishment and a new IPsec > tunnel SA > creation (means 2 extra RTTs) then this can be done in parallel. > > With MOBIKE, the update can be done in parallel and would only detail > one > exchange. > > BR, Karen > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 30 03:29:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImlWQ-0005am-LJ; Tue, 30 Oct 2007 03:28:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImlWO-0005aW-Js; Tue, 30 Oct 2007 03:28:20 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImlWO-0007tb-06; Tue, 30 Oct 2007 03:28:20 -0400 X-AuditID: c10cb581-0000256c00001ed8-d7-4726dcf3317c Received: from stingray.eu.tieto.com ([192.176.143.13]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 08:27:47 +0100 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 08:27:47 +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: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Date: Tue, 30 Oct 2007 08:27:46 +0100 Message-ID: In-Reply-To: <47267CE9.30306@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Thread-Index: AcgajYYywFpmOUMiRbSBJ6Mhy+A6bgAOL5Mg References: <47267CE9.30306@azairenet.com> From: To: X-OriginalArrivalTime: 30 Oct 2007 07:27:47.0165 (UTC) FILETIME=[5E8488D0:01C81AC6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay, I am talking transport ESP to protect BU/BACK. Tunnel mode ESP to protect payload. Karen=20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > Sent: Tuesday, October 30, 2007 1:38 AM > To: Nielsen Karen E > Cc: nemo@ietf.org; mip6@ietf.org > Subject: Re: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and=20 > call for concensus >=20 > Karen, >=20 > I am not sure if you are talking about a transport mode SA or tunnel > mode SA to protect the BU. You have used both in your emails. >=20 > Vijay >=20 > Karen.Nielsen@tietoenator.com wrote: > > Hi, > >=20 > > Can these roundtrips be in > > > > parallel or are > > > > they sequential? If they need to be sequential, I think > > > > that is a big > > > > enough negative impact on handoff times. If they can be > > > parallel and > > > > > > =3D> They can definitely be in parallel, but I don't think IKE > > > knows enough > > > about movement to do this in any timely manner. So, it makes > > > the handover of > > > the secure traffic non-deterministic. Sorry if I gave that > > > impression (that > > > they have to be sent sequentially). > > > > >=20 > > With the IKEv2 RFC in hand, and only the RFC - NOT individual > > implementations, > > then with minimal interpretation of section 2.23 of RFC=20 > 4306, the update > > cannot be done in parallel, the HA MUST process the BU and make some > > changes in the IKE_SA and the IPSEC tunnel SAS before a single IKE > > exchange can update the IKE_SAs and the RFC 3948 IPSec SAs > > appropriately. > >=20 > > If we are speaking of a full new IKE_SA establishment and a=20 > new IPsec > > tunnel SA > > creation (means 2 extra RTTs) then this can be done in parallel. > >=20 > > With MOBIKE, the update can be done in parallel and would=20 > only detail > > one > > exchange. > >=20 > > BR, Karen > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 30 03:43:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imlj0-0007Sy-JP; Tue, 30 Oct 2007 03:41:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imliz-0007Sk-Mh; Tue, 30 Oct 2007 03:41:21 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imliz-0008GW-9x; Tue, 30 Oct 2007 03:41:21 -0400 X-AuditID: c10cb581-000002a000001ed8-7e-4726e0202e3d Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 08:41:20 +0100 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 08:41:19 +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: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Date: Tue, 30 Oct 2007 08:41:19 +0100 Message-ID: In-Reply-To: <47267C01.90809@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Thread-Index: AcgajYbLsCYvqe8ITzSfXYilKl3gkgAOgBeQ References: <47217E35.7010705@azairenet.com> <47267C01.90809@azairenet.com> From: To: X-OriginalArrivalTime: 30 Oct 2007 07:41:19.0806 (UTC) FILETIME=[42E3B5E0:01C81AC8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay,=20 > >> > >=20 > > Actually secure traffic from the MN towards the HA is not=20 > impacted by > > the delay, > > but it is true that secure traffic in the HA to MN direction is > > impacted. It will > > not function until the HA IPSEC SA has been upated with the correct > > ports and addresses=20 >=20 > But why? I thought this was a transport mode SA keyed on the IPv6 home > address of the mobile node. >=20 Yes, the transport mode SA's are, but the tunnel mode SAs for payload protection are not in the scenario I am considering. The delay I am speaking about is related uniquely to the transport mode SAs (as well as of course to rekeying and such of the transport mode SAs, whenever that is needed.) I, myself, is not very concerned with delay associated with tunnel mode IPSec protection from HA to MN. Especially given that Route Optimization is not relevant for DSMIP. Read, the only case, I am aware off, where tunnel mode protection is required by the MIP standard (MUST). Yes there are multicast and other things, but is it really crucial if we have a delay there (?). Karen > Vijay >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 30 03:57:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imlxe-0003NY-OT; Tue, 30 Oct 2007 03:56:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imlxd-0003MZ-KC; Tue, 30 Oct 2007 03:56:29 -0400 Received: from mail1.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imlxd-0000Tf-2i; Tue, 30 Oct 2007 03:56:29 -0400 X-AuditID: c26e2f18-0000227c000016e0-48-4726e398572c Received: from camaro.eu.tieto.com ([192.176.143.43]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 09:56:08 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 08:56:26 +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: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Date: Tue, 30 Oct 2007 08:56:22 +0100 Message-ID: In-Reply-To: <47267BC6.2090302@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Thread-Index: AcgajHv/RCFXZNDlRiiS1EJ/c/oezgAPbcKQ References: <47267BC6.2090302@azairenet.com> From: To: , , X-OriginalArrivalTime: 30 Oct 2007 07:56:26.0945 (UTC) FILETIME=[5F962310:01C81ACA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org =20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > Sent: Tuesday, October 30, 2007 1:33 AM > To: Hesham Soliman; Nielsen Karen E; Kaas-Petersen Christian > Cc: mip6@ietf.org; nemo@ietf.org > Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus >=20 > Thanks Hesham. >=20 > I think I mixed up solution 2 described below in your email with > solution 2 described in an email you sent on the 17th of October. > http://www1.ietf.org/mail-archive/web/mip6/current/msg06856.html >=20 > I do want to avoid two round trips during every handover. I also want > to avoid running MOBIKE at the same time as MIPv6. Does not=20 > make sense. >=20 > Having said, I would like to figure out whats wrong with running IKEv2 > on port 4500, but sending the BU on DS-MIPv6 port with a=20 > transport mode > SA. >=20 > Lets say IKEv2 runs on UDP port 4500 always and negotiates a transport > mode SA for protecting the BU. >=20 > When the BU packet goes through the SPD entries, the transport mode SA > is picked. After IPsec processing the packet will be as follows >=20 > IPv6 hdr (src=3DV6HOA, dst=3DHAADDR) > ESP Hdr > BU > IPv4 CoA option >=20 > With DS-MIPv6 encapsulation the packet becomes >=20 > IPv4 hdr (src=3DV4ADDR, dst=3DHA_V4ADDR) > UDP hdr (srcport=3DDS-MIPv6-PORT, dstport=3DDS-MIPv6-PORT) > IPv6 hdr (src=3DV6HOA, dst=3DHAADDR) > ESP Hdr > BU > IPv4 CoA option >=20 > Now lets assume the mobile node moves and attaches to another IPv4 > access network. The transport mode IPsec SA is still valid. IKEv2 > does not know that the mobile node moved, its IPv4 address changed > or if there is a new NAT in the path. So the mobile node can send > a BU right away as follows. >=20 > IPv4 hdr (src=3Dnew_V4ADDR, dst=3DHA_V4ADDR) > UDP hdr (srcport=3DDS-MIPv6-PORT, dstport=3DDS-MIPv6-PORT) > IPv6 hdr (src=3DV6HOA, dst=3DHAADDR) > ESP Hdr > BU > IPv4 CoA option (new IPv4 CoA) >=20 > When the HA receives the BU, the packet will appear like the following >=20 > IPv4 hdr (src=3DNATTED_new_V4ADDR, dst=3DHA_V4ADDR) > UDP hdr (srcport=3DNATTED_DS-MIPv6-PORT, dstport=3DDS-MIPv6-PORT) > IPv6 hdr (src=3DV6HOA, dst=3DHAADDR) > ESP Hdr > BU > IPv4 CoA option (new IPv4 CoA) >=20 > The HA would process the BU and respond to the NATTED_DS-MIPv6-PORT. >=20 > Meanwhile the MIPv6 stack on the mobile node will trigger the IKEv2 > daemon on the mobile node to re-run IKEv2. This is because=20 > the original > IKEv2 SA is not valid anymore. When the IKEv2 SAs are=20 > re-negotiated, new > IPsec SAs are also setup. >=20 > This would allow the IKEv2 exchange to happen out of the=20 > critical path. > There is no update to the IKEv2 SA based on the BU/BAck=20 > exchange. There > are no tunnel mode SAs created for any MIPv6 signaling messages. What > am I missing now? >=20 Delay associated with tunnel SAs for payload protection. Karen > Vijay >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mext-bounces@ietf.org Tue Oct 30 06:04:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imnsq-0003Eu-MM; Tue, 30 Oct 2007 05:59:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imnso-0003Ek-PZ for mext@ietf.org; Tue, 30 Oct 2007 05:59:38 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imnso-0004sW-8o for mext@ietf.org; Tue, 30 Oct 2007 05:59:38 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 10:59:36 +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: [MEXT] AD review of draft-korhonen-mip6-service-03.txt Date: Tue, 30 Oct 2007 10:59:35 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9261@SEHAN021MB.tcad.telia.se> In-Reply-To: <471C3B28.7020107@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] AD review of draft-korhonen-mip6-service-03.txt Thread-Index: AcgUkdGD2EnIIVvDQumEffqsWfuUYAGSKLlg References: <4700A05C.3070905@piuha.net> <471C3B28.7020107@piuha.net> From: To: X-OriginalArrivalTime: 30 Oct 2007 09:59:36.0504 (UTC) FILETIME=[941B5B80:01C81ADB] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: draft-korhonen-mip6-service@tools.ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org There was comment I received offline pointing out that description of the service selection option identifier in -04 does not mention DNS anymore. In -03 it read "The Identifier MAY be resolveable by DNS." I think it could be put back. The new text could be: " o Type: 8-bit identifier set to TBD (to be defined by IANA) of the type of the skipable mobility option. Depending on the system deployment the Identifier MAY be resolveable by DNS." Any thoughts?=20 Cheers, Jouni > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Monday, October 22, 2007 8:55 AM > To: Korhonen, Jouni /TeliaSonera Finland Oyj > Cc: draft-korhonen-mip6-service@tools.ietf.org; mext@ietf.org > Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt >=20 >=20 > The new version addresses the concerns I had. Thanks. The=20 > document will now be moved forward. >=20 > Jari >=20 >=20 >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mip6-bounces@ietf.org Tue Oct 30 06:20:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImoC3-0006GH-CN; Tue, 30 Oct 2007 06:19:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImoC2-0006Fd-6f for mip6@ietf.org; Tue, 30 Oct 2007 06:19:30 -0400 Received: from mout.perfora.net ([74.208.4.196]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImoC1-0005TN-QZ for mip6@ietf.org; Tue, 30 Oct 2007 06:19:30 -0400 Received: from IBM52A5038A94F ([88.233.212.1]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1ImoBp2YuT-00060c; Tue, 30 Oct 2007 06:19:28 -0400 From: "Alper Yegin" To: "'Heejin Jang'" , , Date: Tue, 30 Oct 2007 12:19:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acgax1P96F3xV7K6R7OKBMHgjp8nwwAFN6IQ In-Reply-To: <66e98e80710300034ma2be56aj8b6cbb0559f989e5@mail.gmail.com> Message-Id: <0MKp8S-1ImoBp2YuT-00060c@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1+TzJMl4tjQJ4wLwcmZHCoFN7Q396LdlcASiy4 KGsy8w7w5uYjtR6lV1OmO+E+jy6LeWTKv129ij3Ay4AKXzkP1L Wbsdr/2ybEb3wliJqQfVQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'Gopal Dommety' Subject: [Mip6] RE: reply for AD's comments X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, > > > As part of configuring the initial TCP/IP parameters, a mobile node > > > can obtain home network information for the subnet it is directly > > > attached to, other subnets in the visited domain, or a subnet from > > > its home domain. > > > > This text makes it sound like a new home network is needed for > > everywhere the mobile node travels to. That is wrong. Suggested > > rewrite: > > > > As part of configuring the initial TCP/IP parameters, a mobile node > > can find itself a suitable home agent. Such a home agent might reside > > in the access network that the mobile node first connects to, or in a > > home network that the mobile node is associated with. Can we strike the "first"? The HA assignment is not limited to the very first time MN does not know its HA. MN may choose to use the HA in its immediately connected network even if it had another HA a while ago from some other network. MN may choose to start MIP session on demand, hence re-anchoring it dynamically. In such case, an all-time session continuity cannot be expected, though chunks of session continuity may be all that MN needs. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mext-bounces@ietf.org Tue Oct 30 10:32:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ims4w-0002xV-NY; Tue, 30 Oct 2007 10:28:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ims4v-0002xC-0R for mext@ietf.org; Tue, 30 Oct 2007 10:28:25 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ims4u-0005Gi-Fn for mext@ietf.org; Tue, 30 Oct 2007 10:28:24 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5C390198677; Tue, 30 Oct 2007 16:28:23 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D1652198670; Tue, 30 Oct 2007 16:28:22 +0200 (EET) Message-ID: <47273F85.9000505@piuha.net> Date: Tue, 30 Oct 2007 16:28:21 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt References: <4700A05C.3070905@piuha.net> <471C3B28.7020107@piuha.net> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9261@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9261@SEHAN021MB.tcad.telia.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org I'm wary of specifying something might be found in DNS or might not. Also, do we have any evidence that we actually need the identifiers to be resolved by DNS? In any case, no one would turn on service for a particular domain without an agreement in place with that domain. So the box initiating a VPN tunnel simply has to have configuration for that domain, its not enough for the DNS query to succeed. Jari jouni.korhonen@teliasonera.com kirjoitti: > There was comment I received offline pointing out that description > of the service selection option identifier in -04 does not mention > DNS anymore. In -03 it read > "The Identifier MAY be resolveable by DNS." > I think it could be put back. The new text could be: > > " o Type: 8-bit identifier set to TBD (to be defined by IANA) of the > type of the skipable mobility option. Depending on the system > deployment the Identifier MAY be resolveable by DNS." > > Any thoughts? > > > > Cheers, > Jouni > > >> -----Original Message----- >> From: Jari Arkko [mailto:jari.arkko@piuha.net] >> Sent: Monday, October 22, 2007 8:55 AM >> To: Korhonen, Jouni /TeliaSonera Finland Oyj >> Cc: draft-korhonen-mip6-service@tools.ietf.org; mext@ietf.org >> Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt >> >> >> The new version addresses the concerns I had. Thanks. The >> document will now be moved forward. >> >> Jari >> >> >> >> > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mip6-bounces@ietf.org Tue Oct 30 11:15:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imso3-0000rD-Mm; Tue, 30 Oct 2007 11:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imso2-0000q2-9y; Tue, 30 Oct 2007 11:15:02 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imsnw-0007vX-3b; Tue, 30 Oct 2007 11:15:02 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 08:14:46 -0700 Message-ID: <47274A5D.8010505@azairenet.com> Date: Tue, 30 Oct 2007 08:14:37 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karen.Nielsen@tietoenator.com Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus References: <47267BC6.2090302@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2007 15:14:47.0067 (UTC) FILETIME=[9BAE46B0:01C81B07] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, nemo@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Karen.Nielsen@tietoenator.com wrote: > > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >> Sent: Tuesday, October 30, 2007 1:33 AM >> To: Hesham Soliman; Nielsen Karen E; Kaas-Petersen Christian >> Cc: mip6@ietf.org; nemo@ietf.org >> Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus >> >> Thanks Hesham. >> >> I think I mixed up solution 2 described below in your email with >> solution 2 described in an email you sent on the 17th of October. >> http://www1.ietf.org/mail-archive/web/mip6/current/msg06856.html >> >> I do want to avoid two round trips during every handover. I also want >> to avoid running MOBIKE at the same time as MIPv6. Does not >> make sense. >> >> Having said, I would like to figure out whats wrong with running IKEv2 >> on port 4500, but sending the BU on DS-MIPv6 port with a >> transport mode >> SA. >> >> Lets say IKEv2 runs on UDP port 4500 always and negotiates a transport >> mode SA for protecting the BU. >> >> When the BU packet goes through the SPD entries, the transport mode SA >> is picked. After IPsec processing the packet will be as follows >> >> IPv6 hdr (src=V6HOA, dst=HAADDR) >> ESP Hdr >> BU >> IPv4 CoA option >> >> With DS-MIPv6 encapsulation the packet becomes >> >> IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) >> UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) >> IPv6 hdr (src=V6HOA, dst=HAADDR) >> ESP Hdr >> BU >> IPv4 CoA option >> >> Now lets assume the mobile node moves and attaches to another IPv4 >> access network. The transport mode IPsec SA is still valid. IKEv2 >> does not know that the mobile node moved, its IPv4 address changed >> or if there is a new NAT in the path. So the mobile node can send >> a BU right away as follows. >> >> IPv4 hdr (src=new_V4ADDR, dst=HA_V4ADDR) >> UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) >> IPv6 hdr (src=V6HOA, dst=HAADDR) >> ESP Hdr >> BU >> IPv4 CoA option (new IPv4 CoA) >> >> When the HA receives the BU, the packet will appear like the following >> >> IPv4 hdr (src=NATTED_new_V4ADDR, dst=HA_V4ADDR) >> UDP hdr (srcport=NATTED_DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) >> IPv6 hdr (src=V6HOA, dst=HAADDR) >> ESP Hdr >> BU >> IPv4 CoA option (new IPv4 CoA) >> >> The HA would process the BU and respond to the NATTED_DS-MIPv6-PORT. >> >> Meanwhile the MIPv6 stack on the mobile node will trigger the IKEv2 >> daemon on the mobile node to re-run IKEv2. This is because >> the original >> IKEv2 SA is not valid anymore. When the IKEv2 SAs are >> re-negotiated, new >> IPsec SAs are also setup. >> >> This would allow the IKEv2 exchange to happen out of the >> critical path. >> There is no update to the IKEv2 SA based on the BU/BAck >> exchange. There >> are no tunnel mode SAs created for any MIPv6 signaling messages. What >> am I missing now? >> > > Delay associated with tunnel SAs for payload protection. Can we then first conclude that we don't have an issue for completing the BU/BAck exchange? IPsec ESP protection in tunnel mode for payload packets is optional after all. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 30 16:13:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImxRg-0001TF-0z; Tue, 30 Oct 2007 16:12:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImxRb-0001Rb-OE; Tue, 30 Oct 2007 16:12:11 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImxRb-0000lY-Dl; Tue, 30 Oct 2007 16:12:11 -0400 X-AuditID: c10cb581-0000140c00002520-69-47279018476e Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 21:12:08 +0100 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 21:12:09 +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: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Date: Tue, 30 Oct 2007 21:12:07 +0100 Message-ID: In-Reply-To: <47274A5D.8010505@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Thread-Index: AcgbB59Ys9QNSqAGSkmXcvMuuv+OKAAKU6aA References: <47267BC6.2090302@azairenet.com> <47274A5D.8010505@azairenet.com> From: To: X-OriginalArrivalTime: 30 Oct 2007 20:12:09.0189 (UTC) FILETIME=[266A0950:01C81B31] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, nemo@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay,=20 >=20 > Can we then first conclude that we don't have an issue for > completing the BU/BAck exchange? >=20 > IPsec ESP protection in tunnel mode for payload packets is > optional after all. >=20 Couldn't agree more ! Karen > Vijay >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 30 16:34:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imxli-000644-MW; Tue, 30 Oct 2007 16:32:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imxli-00063w-9a; Tue, 30 Oct 2007 16:32:58 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imxlh-0001Qr-Sa; Tue, 30 Oct 2007 16:32:58 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 13:32:56 -0700 Message-ID: <472794F8.6000208@azairenet.com> Date: Tue, 30 Oct 2007 13:32:56 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karen.Nielsen@tietoenator.com, Hesham@elevatemobile.com, Christian.Kaas-Petersen@tietoenator.com References: <47267BC6.2090302@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2007 20:32:56.0750 (UTC) FILETIME=[0E04BCE0:01C81B34] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: nemo@ietf.org, mip6@ietf.org, Pasi.Eronen@nokia.com Subject: [Mip6] Payload protection and NAT traversal X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org It appears to me that we don't really need to change anything for sending BU/BAck as long as we run IKEv2 on port 4500 and negotiate a transport mode SA keyed on the IPv6 home address for protecting the BU/BAck. Now coming to payload protection using ESP in tunnel mode, there is an issue. Payload packets are always sent as follows IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) UDP hdr (dstport=4500) ESP hdr IPv6 hdr (src=V6HOA, dst=CN_V6) Payload If IPv4 packets are being sent, the packet format would be as follows. IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) UDP hdr (dstport=4500) ESP hdr IPv4 hdr (src=V4HOA, dst=CN_V4) Payload So in this case, we are using IPsec NAT traversal. We need IKEv2 to run after every handover before packets can sent/received. Note that the BU/BAck exchange happens immediately without any impact. Note that if tunnel mode ESP protection is not being used for the payload traffic, the packet format would be as follows. IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) UDP hdr (dstport=DS-MIPv6-PORT) ESP hdr IPv6 hdr (src=V6HOA, dst=CN_V6) Payload One option would be to live with this. Payload protection is optional anyway. If you have a secure access link, then you don't really need to encrypt payload traffic. But if you still want to use ESP tunnel mode encryption for the payload, we need a solution. One solution is for the home agent to treat the handover as if the NAT box on the path rebooted (or lost state) and came up with a new NATted IPv4 address and source port for the payload packets sent by the mobile node. The home agent just accepts the packets and responds to the new NATTED port. The home agent can do this for a configurable amount of time while waiting for a fresh IKEv2 exchange to update the NAT traversal information. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 30 16:36:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imxoo-0000fr-IF; Tue, 30 Oct 2007 16:36:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imxon-0000eS-26; Tue, 30 Oct 2007 16:36:09 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imxom-0001XY-IY; Tue, 30 Oct 2007 16:36:08 -0400 X-AuditID: c10cb581-0000248000000558-73-472795b50dce Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 21:36:05 +0100 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 21:36:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Oct 2007 21:36:05 +0100 Message-ID: In-Reply-To: <472794F8.6000208@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Payload protection and NAT traversal Thread-Index: AcgbNBZxrKlaGsIxTDKu6tywammWyAAAEAnA References: <47267BC6.2090302@azairenet.com> <472794F8.6000208@azairenet.com> From: To: , , X-OriginalArrivalTime: 30 Oct 2007 20:36:06.0990 (UTC) FILETIME=[7F690EE0:01C81B34] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: nemo@ietf.org, mip6@ietf.org, Pasi.Eronen@nokia.com Subject: [Mip6] RE: Payload protection and NAT traversal X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay,=20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > Sent: Tuesday, October 30, 2007 9:33 PM > To: Nielsen Karen E; Hesham@elevatemobile.com; Kaas-Petersen Christian > Cc: mip6@ietf.org; nemo@ietf.org; Pasi.Eronen@nokia.com > Subject: Payload protection and NAT traversal >=20 > It appears to me that we don't really need to change anything for > sending BU/BAck as long as we run IKEv2 on port 4500 and negotiate > a transport mode SA keyed on the IPv6 home address for protecting > the BU/BAck. >=20 > Now coming to payload protection using ESP in tunnel mode, there > is an issue. Payload packets are always sent as follows >=20 > IPv4 hdr (src=3DV4ADDR, dst=3DHA_V4ADDR) > UDP hdr (dstport=3D4500) > ESP hdr > IPv6 hdr (src=3DV6HOA, dst=3DCN_V6) > Payload >=20 > If IPv4 packets are being sent, the packet format would be as > follows. >=20 > IPv4 hdr (src=3DV4ADDR, dst=3DHA_V4ADDR) > UDP hdr (dstport=3D4500) > ESP hdr > IPv4 hdr (src=3DV4HOA, dst=3DCN_V4) > Payload >=20 > So in this case, we are using IPsec NAT traversal. We need IKEv2 > to run after every handover before packets can sent/received. Note > that the BU/BAck exchange happens immediately without any impact. >=20 > Note that if tunnel mode ESP protection is not being used for the > payload traffic, the packet format would be as follows. >=20 > IPv4 hdr (src=3DV4ADDR, dst=3DHA_V4ADDR) > UDP hdr (dstport=3DDS-MIPv6-PORT) > ESP hdr > IPv6 hdr (src=3DV6HOA, dst=3DCN_V6) > Payload >=20 > One option would be to live with this. Payload protection is > optional anyway. If you have a secure access link, then you don't > really need to encrypt payload traffic. >=20 > But if you still want to use ESP tunnel mode encryption for the > payload, we need a solution. One solution is for the home agent to > treat the handover as if the NAT box on the path rebooted (or lost > state) and came up with a new NATted IPv4 address and source port > for the payload packets sent by the mobile node. The home agent > just accepts the packets and responds to the new NATTED port. The > home agent can do this for a configurable amount of time while > waiting for a fresh IKEv2 exchange to update the NAT traversal > information. >=20 Yes, I agree, this is exactly and indeed what I have said. Karen > Vijay >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 30 19:33:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0Z1-0008Vm-9l; Tue, 30 Oct 2007 19:32:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0Z0-0008Jl-0L; Tue, 30 Oct 2007 19:32:02 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In0Yo-0003zv-VB; Tue, 30 Oct 2007 19:31:57 -0400 Received: from oaamta02sl.mx.bigpond.com ([124.190.106.219]) by omta01sl.mx.bigpond.com with ESMTP id <20071030233118.ZGFW26650.omta01sl.mx.bigpond.com@oaamta02sl.mx.bigpond.com>; Tue, 30 Oct 2007 23:31:18 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta02sl.mx.bigpond.com with ESMTP id <20071030233117.SOZK10066.oaamta02sl.mx.bigpond.com@PC20005>; Tue, 30 Oct 2007 23:31:17 +0000 From: "Hesham Soliman" To: "'Vijay Devarapalli'" , , Subject: RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Date: Wed, 31 Oct 2007 10:30:43 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcgajHdXweg6hCAlQHqWKMbnBJLpbwAyKW7w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47267BC6.2090302@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org This is exactly what we've been discussing, except you took out the case of protection of payload packets. So the solution you list below cannot be compared with alt 1 or 2 because it only addresses part of the problem, i.e. no payload security. Hesham > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Tuesday, October 30, 2007 10:33 AM > To: Hesham Soliman; Karen.Nielsen@tietoenator.com; > Christian.Kaas-Petersen@tietoenator.com > Cc: mip6@ietf.org; nemo@ietf.org > Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus > > Thanks Hesham. > > I think I mixed up solution 2 described below in your email with > solution 2 described in an email you sent on the 17th of October. > http://www1.ietf.org/mail-archive/web/mip6/current/msg06856.html > > I do want to avoid two round trips during every handover. I also want > to avoid running MOBIKE at the same time as MIPv6. Does not > make sense. > > Having said, I would like to figure out whats wrong with > running IKEv2 > on port 4500, but sending the BU on DS-MIPv6 port with a > transport mode > SA. > > Lets say IKEv2 runs on UDP port 4500 always and negotiates a > transport > mode SA for protecting the BU. > > When the BU packet goes through the SPD entries, the > transport mode SA > is picked. After IPsec processing the packet will be as follows > > IPv6 hdr (src=V6HOA, dst=HAADDR) > ESP Hdr > BU > IPv4 CoA option > > With DS-MIPv6 encapsulation the packet becomes > > IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) > UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > IPv6 hdr (src=V6HOA, dst=HAADDR) > ESP Hdr > BU > IPv4 CoA option > > Now lets assume the mobile node moves and attaches to another IPv4 > access network. The transport mode IPsec SA is still valid. IKEv2 > does not know that the mobile node moved, its IPv4 address changed > or if there is a new NAT in the path. So the mobile node can send > a BU right away as follows. > > IPv4 hdr (src=new_V4ADDR, dst=HA_V4ADDR) > UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > IPv6 hdr (src=V6HOA, dst=HAADDR) > ESP Hdr > BU > IPv4 CoA option (new IPv4 CoA) > > When the HA receives the BU, the packet will appear like the > following > > IPv4 hdr (src=NATTED_new_V4ADDR, dst=HA_V4ADDR) > UDP hdr (srcport=NATTED_DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > IPv6 hdr (src=V6HOA, dst=HAADDR) > ESP Hdr > BU > IPv4 CoA option (new IPv4 CoA) > > The HA would process the BU and respond to the NATTED_DS-MIPv6-PORT. > > Meanwhile the MIPv6 stack on the mobile node will trigger the IKEv2 > daemon on the mobile node to re-run IKEv2. This is because > the original > IKEv2 SA is not valid anymore. When the IKEv2 SAs are > re-negotiated, new > IPsec SAs are also setup. > > This would allow the IKEv2 exchange to happen out of the > critical path. > There is no update to the IKEv2 SA based on the BU/BAck > exchange. There > are no tunnel mode SAs created for any MIPv6 signaling messages. What > am I missing now? > > Vijay > > Hesham Soliman wrote: > > > IMO, we should go with solution 2) below. I prefer that we let > > > IKEv2 use its own NAT traversal mechanism. Regarding two round > > > trips during a handover, note that the IKEv2 exchange to > > > re-establish the IKEv2 SA and the IPsec SAs is not in the > > > critical path of handover. > > > > => It is in the critical path for the secure packets. > That's what the > > discussion was about. > > > > The BU/BAck messages can be exchanged > > > with the existing IPsec SAs. The IKEv2 exchange can be happen a > > > few seconds (or minutes) after the handover. So there is *no* > > > impact on the handover. > > > > => No, see above. This is only good for insecure traffic. > At least this is > > not solution 2 below. > > > > Hesham > > > > > > > > This would be the same as the lack of support for the "K" flag > > > in RFC 3775. In RFC 3775, if either the mobile node or the home > > > agent are not capable of updating the IKE SA based on the > > > exchange of BU/BAck, there is always an IKE exchange after the > > > handover (or whenever the CoA changes). > > > > > > Please let me know if I am missing something related to the > > > impact of the IKEv2 exchange on the handover. > > > > > > I am not comfortable with the temporary tunnel created in > > > solution 1). > > > > > > Vijay > > > > > > Hesham Soliman wrote: > > > > Folks, > > > > > > > > This discussion has been going on for a while and I'm sure > > > it wasn't for > > > > easy to follow. > > > > This email contains a summary of the discussion so far and > > > a call for > > > > comment/concensus. Please respond promptly because there > > > is some pressure > > > > from 3GPP to get this draft out very soon. > > > > > > > > The issue is how to run IKE in combination with DSMIPv6 in > > > a private > > > > IPv4-only network. If you want more detail about why this > > > is a problem > > > > please look at the thread "DSMIPv6 and IKE". > > > > > > > > There are three types of solutions that we discussed. A > > > quick summary of > > > > each below: > > > > > > > > 1. The Virtual link approach. In this case IKE runs over > > > v6 only and is > > > > completely unaware of the IPv4 network. As a result IKE's > > > NAT traversal is > > > > never invoked. Only DSMIPv6's NAT traversal is used. In > > > this approach, the > > > > DSMIPv6 implementation in the HA is required to cache the > > > outer IPv4 address > > > > and source port of the IPv4 message that contains IKE, > > > then append them to > > > > the response from its own IKE daemon. This is basically > > > done to hide the > > > > IPv4 network from IKE and effectively disable its NAT > > > traversal, which > > > > solves our problem. > > > > Three people agreed with this approach but two people (I'm > > > including > > > > Christian) are against it. So there doesn't seem to be > > > concensus on this. I > > > > believe the concern here was that the HA's caching of the > > > outer address and > > > > port was complex for the implementation. > > > > > > > > 2. Karen suggested a way of running IKE without any > > > changes (again see the > > > > thread for details). In this approach DSMIPv6 BUs are > > > secured with ESP as > > > > usual. Normal traffic is sent over the DSMIPv6 port. > > > However, secure traffic > > > > is sent over the IKE port (4500). The result of this > > > approach is that it > > > > takes two messages to complete a handover, one from > > > DSMIPv6 (BU) and an > > > > update from IKE (for the secure traffic). The concern that > > > I had here in the > > > > discussion with Karen was the number of messages and the > > > delays associated > > > > for that. Of course IKE doesn't do movement detection > > > ...etc. So my concern > > > > is the discriminatory experience of the handover for > > > different parts of the > > > > traffic. > > > > > > > > 3. The third class of solutions involves either modifying > > > MIPv6 (adding new > > > > messages) or IKE or both. I'm only including this for > > > completeness, no one > > > > really wants this. > > > > > > > > Please send your comments on the above. Basically the > > > options are 1 or 2. In > > > > theory we could do both but I think it's best to pick one > > > method for this to > > > > avoid interoperability issues and additional complexity. > > > > > > > > Hesham > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 30 19:39:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0fk-0005v2-9Z; Tue, 30 Oct 2007 19:39:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0fj-0005sb-3Y; Tue, 30 Oct 2007 19:38:59 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In0fY-0004HO-HU; Tue, 30 Oct 2007 19:38:55 -0400 Received: from oaamta05sl.mx.bigpond.com ([124.190.106.219]) by omta05sl.mx.bigpond.com with ESMTP id <20071030233814.UIYJ14987.omta05sl.mx.bigpond.com@oaamta05sl.mx.bigpond.com>; Tue, 30 Oct 2007 23:38:14 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta05sl.mx.bigpond.com with ESMTP id <20071030233814.SZWF18730.oaamta05sl.mx.bigpond.com@PC20005>; Tue, 30 Oct 2007 23:38:14 +0000 From: "Hesham Soliman" To: "'Vijay Devarapalli'" , , Date: Wed, 31 Oct 2007 10:38:02 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcgbNA/08l1Q0mhmTfCXR/cDOHEAgQAIcHmg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <472794F8.6000208@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: nemo@ietf.org, mip6@ietf.org, Pasi.Eronen@nokia.com Subject: [Mip6] RE: Payload protection and NAT traversal X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > It appears to me that we don't really need to change anything for > sending BU/BAck as long as we run IKEv2 on port 4500 and negotiate > a transport mode SA keyed on the IPv6 home address for protecting > the BU/BAck. > > Now coming to payload protection using ESP in tunnel mode, there > is an issue. Payload packets are always sent as follows > > IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) > UDP hdr (dstport=4500) > ESP hdr > IPv6 hdr (src=V6HOA, dst=CN_V6) > Payload > > If IPv4 packets are being sent, the packet format would be as > follows. > > IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) > UDP hdr (dstport=4500) > ESP hdr > IPv4 hdr (src=V4HOA, dst=CN_V4) > Payload > > So in this case, we are using IPsec NAT traversal. We need IKEv2 > to run after every handover before packets can sent/received. Note > that the BU/BAck exchange happens immediately without any impact. > > Note that if tunnel mode ESP protection is not being used for the > payload traffic, the packet format would be as follows. > > IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) > UDP hdr (dstport=DS-MIPv6-PORT) > ESP hdr > IPv6 hdr (src=V6HOA, dst=CN_V6) > Payload > > One option would be to live with this. Payload protection is > optional anyway. If you have a secure access link, then you don't > really need to encrypt payload traffic. > > But if you still want to use ESP tunnel mode encryption for the > payload, we need a solution. One solution is for the home agent to > treat the handover as if the NAT box on the path rebooted (or lost > state) and came up with a new NATted IPv4 address and source port > for the payload packets sent by the mobile node. The home agent > just accepts the packets and responds to the new NATTED port. The > home agent can do this for a configurable amount of time while > waiting for a fresh IKEv2 exchange to update the NAT traversal > information. => These are all options, true. So you're saying the HA stores both sets of information for a short time? Because the change could also be a DoS, so until a timeout takes place the HA wouldn't know whether it was a genuine change or an attack. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 30 19:50:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0q6-000120-S0; Tue, 30 Oct 2007 19:49:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0q5-00011p-ME; Tue, 30 Oct 2007 19:49:41 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In0pz-0004nn-CE; Tue, 30 Oct 2007 19:49:41 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 16:49:29 -0700 Message-ID: <4727C308.6040004@azairenet.com> Date: Tue, 30 Oct 2007 16:49:28 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2007 23:49:29.0719 (UTC) FILETIME=[832D0070:01C81B4F] X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, Karen.Nielsen@tietoenator.com, nemo@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hesham Soliman wrote: > This is exactly what we've been discussing, except you took out the case of > protection of payload packets. hmm... are you sure? You said a couple of times that sending a BU would take two round trips for solution 2. > So the solution you list below cannot be > compared with alt 1 or 2 Neither solution 1 nor 2 will work for payload security when you use ESP in tunnel mode for the payload packets. > because it only addresses part of the problem, i.e. > no payload security. Note that providing payload security was never a requirement. Vijay > > Hesham > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > Sent: Tuesday, October 30, 2007 10:33 AM > > To: Hesham Soliman; Karen.Nielsen@tietoenator.com; > > Christian.Kaas-Petersen@tietoenator.com > > Cc: mip6@ietf.org; nemo@ietf.org > > Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus > > > > Thanks Hesham. > > > > I think I mixed up solution 2 described below in your email with > > solution 2 described in an email you sent on the 17th of October. > > http://www1.ietf.org/mail-archive/web/mip6/current/msg06856.html > > > > I do want to avoid two round trips during every handover. I also want > > to avoid running MOBIKE at the same time as MIPv6. Does not > > make sense. > > > > Having said, I would like to figure out whats wrong with > > running IKEv2 > > on port 4500, but sending the BU on DS-MIPv6 port with a > > transport mode > > SA. > > > > Lets say IKEv2 runs on UDP port 4500 always and negotiates a > > transport > > mode SA for protecting the BU. > > > > When the BU packet goes through the SPD entries, the > > transport mode SA > > is picked. After IPsec processing the packet will be as follows > > > > IPv6 hdr (src=V6HOA, dst=HAADDR) > > ESP Hdr > > BU > > IPv4 CoA option > > > > With DS-MIPv6 encapsulation the packet becomes > > > > IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) > > UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > > IPv6 hdr (src=V6HOA, dst=HAADDR) > > ESP Hdr > > BU > > IPv4 CoA option > > > > Now lets assume the mobile node moves and attaches to another IPv4 > > access network. The transport mode IPsec SA is still valid. IKEv2 > > does not know that the mobile node moved, its IPv4 address changed > > or if there is a new NAT in the path. So the mobile node can send > > a BU right away as follows. > > > > IPv4 hdr (src=new_V4ADDR, dst=HA_V4ADDR) > > UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > > IPv6 hdr (src=V6HOA, dst=HAADDR) > > ESP Hdr > > BU > > IPv4 CoA option (new IPv4 CoA) > > > > When the HA receives the BU, the packet will appear like the > > following > > > > IPv4 hdr (src=NATTED_new_V4ADDR, dst=HA_V4ADDR) > > UDP hdr (srcport=NATTED_DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > > IPv6 hdr (src=V6HOA, dst=HAADDR) > > ESP Hdr > > BU > > IPv4 CoA option (new IPv4 CoA) > > > > The HA would process the BU and respond to the NATTED_DS-MIPv6-PORT. > > > > Meanwhile the MIPv6 stack on the mobile node will trigger the IKEv2 > > daemon on the mobile node to re-run IKEv2. This is because > > the original > > IKEv2 SA is not valid anymore. When the IKEv2 SAs are > > re-negotiated, new > > IPsec SAs are also setup. > > > > This would allow the IKEv2 exchange to happen out of the > > critical path. > > There is no update to the IKEv2 SA based on the BU/BAck > > exchange. There > > are no tunnel mode SAs created for any MIPv6 signaling messages. What > > am I missing now? > > > > Vijay > > > > Hesham Soliman wrote: > > > > IMO, we should go with solution 2) below. I prefer that we let > > > > IKEv2 use its own NAT traversal mechanism. Regarding two round > > > > trips during a handover, note that the IKEv2 exchange to > > > > re-establish the IKEv2 SA and the IPsec SAs is not in the > > > > critical path of handover. > > > > > > => It is in the critical path for the secure packets. > > That's what the > > > discussion was about. > > > > > > The BU/BAck messages can be exchanged > > > > with the existing IPsec SAs. The IKEv2 exchange can be happen a > > > > few seconds (or minutes) after the handover. So there is *no* > > > > impact on the handover. > > > > > > => No, see above. This is only good for insecure traffic. > > At least this is > > > not solution 2 below. > > > > > > Hesham > > > > > > > > > > > This would be the same as the lack of support for the "K" flag > > > > in RFC 3775. In RFC 3775, if either the mobile node or the home > > > > agent are not capable of updating the IKE SA based on the > > > > exchange of BU/BAck, there is always an IKE exchange after the > > > > handover (or whenever the CoA changes). > > > > > > > > Please let me know if I am missing something related to the > > > > impact of the IKEv2 exchange on the handover. > > > > > > > > I am not comfortable with the temporary tunnel created in > > > > solution 1). > > > > > > > > Vijay > > > > > > > > Hesham Soliman wrote: > > > > > Folks, > > > > > > > > > > This discussion has been going on for a while and I'm sure > > > > it wasn't for > > > > > easy to follow. > > > > > This email contains a summary of the discussion so far and > > > > a call for > > > > > comment/concensus. Please respond promptly because there > > > > is some pressure > > > > > from 3GPP to get this draft out very soon. > > > > > > > > > > The issue is how to run IKE in combination with DSMIPv6 in > > > > a private > > > > > IPv4-only network. If you want more detail about why this > > > > is a problem > > > > > please look at the thread "DSMIPv6 and IKE". > > > > > > > > > > There are three types of solutions that we discussed. A > > > > quick summary of > > > > > each below: > > > > > > > > > > 1. The Virtual link approach. In this case IKE runs over > > > > v6 only and is > > > > > completely unaware of the IPv4 network. As a result IKE's > > > > NAT traversal is > > > > > never invoked. Only DSMIPv6's NAT traversal is used. In > > > > this approach, the > > > > > DSMIPv6 implementation in the HA is required to cache the > > > > outer IPv4 address > > > > > and source port of the IPv4 message that contains IKE, > > > > then append them to > > > > > the response from its own IKE daemon. This is basically > > > > done to hide the > > > > > IPv4 network from IKE and effectively disable its NAT > > > > traversal, which > > > > > solves our problem. > > > > > Three people agreed with this approach but two people (I'm > > > > including > > > > > Christian) are against it. So there doesn't seem to be > > > > concensus on this. I > > > > > believe the concern here was that the HA's caching of the > > > > outer address and > > > > > port was complex for the implementation. > > > > > > > > > > 2. Karen suggested a way of running IKE without any > > > > changes (again see the > > > > > thread for details). In this approach DSMIPv6 BUs are > > > > secured with ESP as > > > > > usual. Normal traffic is sent over the DSMIPv6 port. > > > > However, secure traffic > > > > > is sent over the IKE port (4500). The result of this > > > > approach is that it > > > > > takes two messages to complete a handover, one from > > > > DSMIPv6 (BU) and an > > > > > update from IKE (for the secure traffic). The concern that > > > > I had here in the > > > > > discussion with Karen was the number of messages and the > > > > delays associated > > > > > for that. Of course IKE doesn't do movement detection > > > > ...etc. So my concern > > > > > is the discriminatory experience of the handover for > > > > different parts of the > > > > > traffic. > > > > > > > > > > 3. The third class of solutions involves either modifying > > > > MIPv6 (adding new > > > > > messages) or IKE or both. I'm only including this for > > > > completeness, no one > > > > > really wants this. > > > > > > > > > > Please send your comments on the above. Basically the > > > > options are 1 or 2. In > > > > > theory we could do both but I think it's best to pick one > > > > method for this to > > > > > avoid interoperability issues and additional complexity. > > > > > > > > > > Hesham > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Mip6 mailing list > > > > > Mip6@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 30 19:54:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0ue-0000EB-A4; Tue, 30 Oct 2007 19:54:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0uc-0008Ds-DO; Tue, 30 Oct 2007 19:54:22 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In0uI-00007V-Iv; Tue, 30 Oct 2007 19:54:04 -0400 Received: from oaamta05sl.mx.bigpond.com ([124.190.106.219]) by omta05sl.mx.bigpond.com with ESMTP id <20071030235359.VACY14987.omta05sl.mx.bigpond.com@oaamta05sl.mx.bigpond.com>; Tue, 30 Oct 2007 23:53:59 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta05sl.mx.bigpond.com with ESMTP id <20071030235358.THKL18730.oaamta05sl.mx.bigpond.com@PC20005>; Tue, 30 Oct 2007 23:53:58 +0000 From: "Hesham Soliman" To: "'Vijay Devarapalli'" Subject: RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Date: Wed, 31 Oct 2007 10:53:47 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcgbT4eDdrodxwaHTL2zUGtNbkQ8mgACIHgQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4727C308.6040004@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, Karen.Nielsen@tietoenator.com, nemo@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > Hesham Soliman wrote: > > This is exactly what we've been discussing, except you > took out the case of > > protection of payload packets. > > hmm... are you sure? You said a couple of times that sending a BU > would take two round trips for solution 2. => No, I said the handover would take 2 RTTs. > > > So the solution you list below cannot be > > compared with alt 1 or 2 > > Neither solution 1 nor 2 will work for payload security when you > use ESP in tunnel mode for the payload packets. => Sure they will, Karen already sent the packet formats. Solution 2 uses port 4500 for tunnel mode, hence the entire discussion about 2 RTT handovers. > > > because it only addresses part of the problem, i.e. > > no payload security. > > Note that providing payload security was never a requirement. => You mean for DSMIPv6? I think we have to be realistic. I don't think it makes sense to use MIP6 and Mobike at the same time just so we can encrypt payload traffic. I think you agreed with that in your last email. So, if you don't want that then you need to figure out how to secure payload traffic. Otherwise, the solution we have will only look good on paper. Hesham > > Vijay > > > > > Hesham > > > > > -----Original Message----- > > > From: Vijay Devarapalli > [mailto:vijay.devarapalli@azairenet.com] > > > Sent: Tuesday, October 30, 2007 10:33 AM > > > To: Hesham Soliman; Karen.Nielsen@tietoenator.com; > > > Christian.Kaas-Petersen@tietoenator.com > > > Cc: mip6@ietf.org; nemo@ietf.org > > > Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call > for concensus > > > > > > Thanks Hesham. > > > > > > I think I mixed up solution 2 described below in your email with > > > solution 2 described in an email you sent on the 17th > of October. > > > http://www1.ietf.org/mail-archive/web/mip6/current/msg06856.html > > > > > > I do want to avoid two round trips during every > handover. I also want > > > to avoid running MOBIKE at the same time as MIPv6. Does not > > > make sense. > > > > > > Having said, I would like to figure out whats wrong with > > > running IKEv2 > > > on port 4500, but sending the BU on DS-MIPv6 port with a > > > transport mode > > > SA. > > > > > > Lets say IKEv2 runs on UDP port 4500 always and negotiates a > > > transport > > > mode SA for protecting the BU. > > > > > > When the BU packet goes through the SPD entries, the > > > transport mode SA > > > is picked. After IPsec processing the packet will be as follows > > > > > > IPv6 hdr (src=V6HOA, dst=HAADDR) > > > ESP Hdr > > > BU > > > IPv4 CoA option > > > > > > With DS-MIPv6 encapsulation the packet becomes > > > > > > IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) > > > UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > > > IPv6 hdr (src=V6HOA, dst=HAADDR) > > > ESP Hdr > > > BU > > > IPv4 CoA option > > > > > > Now lets assume the mobile node moves and attaches to > another IPv4 > > > access network. The transport mode IPsec SA is still > valid. IKEv2 > > > does not know that the mobile node moved, its IPv4 > address changed > > > or if there is a new NAT in the path. So the mobile > node can send > > > a BU right away as follows. > > > > > > IPv4 hdr (src=new_V4ADDR, dst=HA_V4ADDR) > > > UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > > > IPv6 hdr (src=V6HOA, dst=HAADDR) > > > ESP Hdr > > > BU > > > IPv4 CoA option (new IPv4 CoA) > > > > > > When the HA receives the BU, the packet will appear like the > > > following > > > > > > IPv4 hdr (src=NATTED_new_V4ADDR, dst=HA_V4ADDR) > > > UDP hdr (srcport=NATTED_DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > > > IPv6 hdr (src=V6HOA, dst=HAADDR) > > > ESP Hdr > > > BU > > > IPv4 CoA option (new IPv4 CoA) > > > > > > The HA would process the BU and respond to the > NATTED_DS-MIPv6-PORT. > > > > > > Meanwhile the MIPv6 stack on the mobile node will > trigger the IKEv2 > > > daemon on the mobile node to re-run IKEv2. This is because > > > the original > > > IKEv2 SA is not valid anymore. When the IKEv2 SAs are > > > re-negotiated, new > > > IPsec SAs are also setup. > > > > > > This would allow the IKEv2 exchange to happen out of the > > > critical path. > > > There is no update to the IKEv2 SA based on the BU/BAck > > > exchange. There > > > are no tunnel mode SAs created for any MIPv6 signaling > messages. What > > > am I missing now? > > > > > > Vijay > > > > > > Hesham Soliman wrote: > > > > > IMO, we should go with solution 2) below. I prefer > that we let > > > > > IKEv2 use its own NAT traversal mechanism. > Regarding two round > > > > > trips during a handover, note that the IKEv2 exchange to > > > > > re-establish the IKEv2 SA and the IPsec SAs is not in the > > > > > critical path of handover. > > > > > > > > => It is in the critical path for the secure packets. > > > That's what the > > > > discussion was about. > > > > > > > > The BU/BAck messages can be exchanged > > > > > with the existing IPsec SAs. The IKEv2 exchange > can be happen a > > > > > few seconds (or minutes) after the handover. So > there is *no* > > > > > impact on the handover. > > > > > > > > => No, see above. This is only good for insecure traffic. > > > At least this is > > > > not solution 2 below. > > > > > > > > Hesham > > > > > > > > > > > > > > This would be the same as the lack of support for > the "K" flag > > > > > in RFC 3775. In RFC 3775, if either the mobile > node or the home > > > > > agent are not capable of updating the IKE SA based on the > > > > > exchange of BU/BAck, there is always an IKE > exchange after the > > > > > handover (or whenever the CoA changes). > > > > > > > > > > Please let me know if I am missing something related to the > > > > > impact of the IKEv2 exchange on the handover. > > > > > > > > > > I am not comfortable with the temporary tunnel created in > > > > > solution 1). > > > > > > > > > > Vijay > > > > > > > > > > Hesham Soliman wrote: > > > > > > Folks, > > > > > > > > > > > > This discussion has been going on for a while > and I'm sure > > > > > it wasn't for > > > > > > easy to follow. > > > > > > This email contains a summary of the discussion > so far and > > > > > a call for > > > > > > comment/concensus. Please respond promptly because there > > > > > is some pressure > > > > > > from 3GPP to get this draft out very soon. > > > > > > > > > > > > The issue is how to run IKE in combination with > DSMIPv6 in > > > > > a private > > > > > > IPv4-only network. If you want more detail about > why this > > > > > is a problem > > > > > > please look at the thread "DSMIPv6 and IKE". > > > > > > > > > > > > There are three types of solutions that we discussed. A > > > > > quick summary of > > > > > > each below: > > > > > > > > > > > > 1. The Virtual link approach. In this case IKE runs over > > > > > v6 only and is > > > > > > completely unaware of the IPv4 network. As a > result IKE's > > > > > NAT traversal is > > > > > > never invoked. Only DSMIPv6's NAT traversal is used. In > > > > > this approach, the > > > > > > DSMIPv6 implementation in the HA is required to > cache the > > > > > outer IPv4 address > > > > > > and source port of the IPv4 message that contains IKE, > > > > > then append them to > > > > > > the response from its own IKE daemon. This is basically > > > > > done to hide the > > > > > > IPv4 network from IKE and effectively disable its NAT > > > > > traversal, which > > > > > > solves our problem. > > > > > > Three people agreed with this approach but two > people (I'm > > > > > including > > > > > > Christian) are against it. So there doesn't seem to be > > > > > concensus on this. I > > > > > > believe the concern here was that the HA's > caching of the > > > > > outer address and > > > > > > port was complex for the implementation. > > > > > > > > > > > > 2. Karen suggested a way of running IKE without any > > > > > changes (again see the > > > > > > thread for details). In this approach DSMIPv6 BUs are > > > > > secured with ESP as > > > > > > usual. Normal traffic is sent over the DSMIPv6 port. > > > > > However, secure traffic > > > > > > is sent over the IKE port (4500). The result of this > > > > > approach is that it > > > > > > takes two messages to complete a handover, one from > > > > > DSMIPv6 (BU) and an > > > > > > update from IKE (for the secure traffic). The > concern that > > > > > I had here in the > > > > > > discussion with Karen was the number of messages and the > > > > > delays associated > > > > > > for that. Of course IKE doesn't do movement detection > > > > > ...etc. So my concern > > > > > > is the discriminatory experience of the handover for > > > > > different parts of the > > > > > > traffic. > > > > > > > > > > > > 3. The third class of solutions involves either > modifying > > > > > MIPv6 (adding new > > > > > > messages) or IKE or both. I'm only including this for > > > > > completeness, no one > > > > > > really wants this. > > > > > > > > > > > > Please send your comments on the above. Basically the > > > > > options are 1 or 2. In > > > > > > theory we could do both but I think it's best to > pick one > > > > > method for this to > > > > > > avoid interoperability issues and additional complexity. > > > > > > > > > > > > Hesham > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Mip6 mailing list > > > > > > Mip6@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 30 20:05:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In13r-0001BJ-QC; Tue, 30 Oct 2007 20:03:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In13q-00012G-Bx; Tue, 30 Oct 2007 20:03:54 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In13p-0000SR-VF; Tue, 30 Oct 2007 20:03:54 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 17:03:51 -0700 Message-ID: <4727C667.9020709@azairenet.com> Date: Tue, 30 Oct 2007 17:03:51 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 00:03:51.0886 (UTC) FILETIME=[85113EE0:01C81B51] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, Karen.Nielsen@tietoenator.com, nemo@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hesham Soliman wrote: > > Hesham Soliman wrote: > > > This is exactly what we've been discussing, except you > > took out the case of > > > protection of payload packets. > > > > hmm... are you sure? You said a couple of times that sending a BU > > would take two round trips for solution 2. > > => No, I said the handover would take 2 RTTs. Ok never mind then. BU/BAck exchange does not require two round trips. > > > So the solution you list below cannot be > > > compared with alt 1 or 2 > > > > Neither solution 1 nor 2 will work for payload security when you > > use ESP in tunnel mode for the payload packets. > > => Sure they will, Karen already sent the packet formats. Solution 2 uses > port 4500 for tunnel mode, hence the entire discussion about 2 RTT > handovers. I repeat, none of the solutions work as long as you use ESP UDP encapsulation (port 4500) for the payload traffic to the CN. > > > because it only addresses part of the problem, i.e. > > > no payload security. > > > > Note that providing payload security was never a requirement. > > => You mean for DSMIPv6? I think we have to be realistic. I don't think it > makes sense to use MIP6 and Mobike at the same time just so we can encrypt > payload traffic. I think you agreed with that in your last email. So, if you > don't want that then you need to figure out how to secure payload traffic. > Otherwise, the solution we have will only look good on paper. RFC 3775, 3776 and 4877 say ESP protection for payload traffic is optional. If you have a secure access link or if you application layer security obviously you don't need to encrypt all traffic reverse tunneled through the home agent. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 30 20:05:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In14Q-0001cy-K6; Tue, 30 Oct 2007 20:04:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In14O-0001cG-CU; Tue, 30 Oct 2007 20:04:28 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In14L-0005P9-6S; Tue, 30 Oct 2007 20:04:28 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 17:04:23 -0700 Message-ID: <4727C686.10503@azairenet.com> Date: Tue, 30 Oct 2007 17:04:22 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 00:04:23.0245 (UTC) FILETIME=[97C23FD0:01C81B51] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, Karen.Nielsen@tietoenator.com, Pasi.Eronen@nokia.com, nemo@ietf.org Subject: [Mip6] Re: Payload protection and NAT traversal X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hesham Soliman wrote: > > It appears to me that we don't really need to change anything for > > sending BU/BAck as long as we run IKEv2 on port 4500 and negotiate > > a transport mode SA keyed on the IPv6 home address for protecting > > the BU/BAck. > > > > Now coming to payload protection using ESP in tunnel mode, there > > is an issue. Payload packets are always sent as follows > > > > IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) > > UDP hdr (dstport=4500) > > ESP hdr > > IPv6 hdr (src=V6HOA, dst=CN_V6) > > Payload > > > > If IPv4 packets are being sent, the packet format would be as > > follows. > > > > IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) > > UDP hdr (dstport=4500) > > ESP hdr > > IPv4 hdr (src=V4HOA, dst=CN_V4) > > Payload > > > > So in this case, we are using IPsec NAT traversal. We need IKEv2 > > to run after every handover before packets can sent/received. Note > > that the BU/BAck exchange happens immediately without any impact. > > > > Note that if tunnel mode ESP protection is not being used for the > > payload traffic, the packet format would be as follows. > > > > IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) > > UDP hdr (dstport=DS-MIPv6-PORT) > > ESP hdr > > IPv6 hdr (src=V6HOA, dst=CN_V6) > > Payload > > > > One option would be to live with this. Payload protection is > > optional anyway. If you have a secure access link, then you don't > > really need to encrypt payload traffic. > > > > But if you still want to use ESP tunnel mode encryption for the > > payload, we need a solution. One solution is for the home agent to > > treat the handover as if the NAT box on the path rebooted (or lost > > state) and came up with a new NATted IPv4 address and source port > > for the payload packets sent by the mobile node. The home agent > > just accepts the packets and responds to the new NATTED port. The > > home agent can do this for a configurable amount of time while > > waiting for a fresh IKEv2 exchange to update the NAT traversal > > information. > > => These are all options, true. So you're saying the HA stores both sets of > information for a short time? Because the change could also be a DoS, so > until a timeout takes place the HA wouldn't know whether it was a genuine > change or an attack. You are supposed to deal with intermediate NATs losing state and allocating new NATed source address and source port anyway. Nothing new. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 30 20:14:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1Ca-0005Aj-HS; Tue, 30 Oct 2007 20:12:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1CY-0005AU-Qs; Tue, 30 Oct 2007 20:12:54 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In1CS-0005mj-9h; Tue, 30 Oct 2007 20:12:54 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9V0Bf6H003136; Wed, 31 Oct 2007 02:12:17 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 02:12:13 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 19:12:10 -0500 Received: from 10.241.59.168 ([10.241.59.168]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 31 Oct 2007 00:12:10 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 30 Oct 2007 19:12:51 -0500 Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus From: Basavaraj Patil To: ext Hesham Soliman , Vijay Devarapalli , , Message-ID: Thread-Topic: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Thread-Index: AcgajHdXweg6hCAlQHqWKMbnBJLpbwAyKW7wAACVqhA= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 00:12:10.0811 (UTC) FILETIME=[AE7328B0:01C81B52] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org But Hesham... Do we need to solve the payload security issue? I thought the MIP6 signaling security was what was being tackled. 0Raj On 10/30/07 7:30 PM, "ext Hesham Soliman" wrote: > This is exactly what we've been discussing, except you took out the case of > protection of payload packets. So the solution you list below cannot be > compared with alt 1 or 2 because it only addresses part of the problem, i.e. > no payload security. > > Hesham > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >> Sent: Tuesday, October 30, 2007 10:33 AM >> To: Hesham Soliman; Karen.Nielsen@tietoenator.com; >> Christian.Kaas-Petersen@tietoenator.com >> Cc: mip6@ietf.org; nemo@ietf.org >> Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus >> >> Thanks Hesham. >> >> I think I mixed up solution 2 described below in your email with >> solution 2 described in an email you sent on the 17th of October. >> http://www1.ietf.org/mail-archive/web/mip6/current/msg06856.html >> >> I do want to avoid two round trips during every handover. I also want >> to avoid running MOBIKE at the same time as MIPv6. Does not >> make sense. >> >> Having said, I would like to figure out whats wrong with >> running IKEv2 >> on port 4500, but sending the BU on DS-MIPv6 port with a >> transport mode >> SA. >> >> Lets say IKEv2 runs on UDP port 4500 always and negotiates a >> transport >> mode SA for protecting the BU. >> >> When the BU packet goes through the SPD entries, the >> transport mode SA >> is picked. After IPsec processing the packet will be as follows >> >> IPv6 hdr (src=V6HOA, dst=HAADDR) >> ESP Hdr >> BU >> IPv4 CoA option >> >> With DS-MIPv6 encapsulation the packet becomes >> >> IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) >> UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) >> IPv6 hdr (src=V6HOA, dst=HAADDR) >> ESP Hdr >> BU >> IPv4 CoA option >> >> Now lets assume the mobile node moves and attaches to another IPv4 >> access network. The transport mode IPsec SA is still valid. IKEv2 >> does not know that the mobile node moved, its IPv4 address changed >> or if there is a new NAT in the path. So the mobile node can send >> a BU right away as follows. >> >> IPv4 hdr (src=new_V4ADDR, dst=HA_V4ADDR) >> UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) >> IPv6 hdr (src=V6HOA, dst=HAADDR) >> ESP Hdr >> BU >> IPv4 CoA option (new IPv4 CoA) >> >> When the HA receives the BU, the packet will appear like the >> following >> >> IPv4 hdr (src=NATTED_new_V4ADDR, dst=HA_V4ADDR) >> UDP hdr (srcport=NATTED_DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) >> IPv6 hdr (src=V6HOA, dst=HAADDR) >> ESP Hdr >> BU >> IPv4 CoA option (new IPv4 CoA) >> >> The HA would process the BU and respond to the NATTED_DS-MIPv6-PORT. >> >> Meanwhile the MIPv6 stack on the mobile node will trigger the IKEv2 >> daemon on the mobile node to re-run IKEv2. This is because >> the original >> IKEv2 SA is not valid anymore. When the IKEv2 SAs are >> re-negotiated, new >> IPsec SAs are also setup. >> >> This would allow the IKEv2 exchange to happen out of the >> critical path. >> There is no update to the IKEv2 SA based on the BU/BAck >> exchange. There >> are no tunnel mode SAs created for any MIPv6 signaling messages. What >> am I missing now? >> >> Vijay >> >> Hesham Soliman wrote: >>>> IMO, we should go with solution 2) below. I prefer that we let >>>> IKEv2 use its own NAT traversal mechanism. Regarding two round >>>> trips during a handover, note that the IKEv2 exchange to >>>> re-establish the IKEv2 SA and the IPsec SAs is not in the >>>> critical path of handover. >>> >>> => It is in the critical path for the secure packets. >> That's what the >>> discussion was about. >>> >>> The BU/BAck messages can be exchanged >>>> with the existing IPsec SAs. The IKEv2 exchange can be happen a >>>> few seconds (or minutes) after the handover. So there is *no* >>>> impact on the handover. >>> >>> => No, see above. This is only good for insecure traffic. >> At least this is >>> not solution 2 below. >>> >>> Hesham >>> >>>> >>>> This would be the same as the lack of support for the "K" flag >>>> in RFC 3775. In RFC 3775, if either the mobile node or the home >>>> agent are not capable of updating the IKE SA based on the >>>> exchange of BU/BAck, there is always an IKE exchange after the >>>> handover (or whenever the CoA changes). >>>> >>>> Please let me know if I am missing something related to the >>>> impact of the IKEv2 exchange on the handover. >>>> >>>> I am not comfortable with the temporary tunnel created in >>>> solution 1). >>>> >>>> Vijay >>>> >>>> Hesham Soliman wrote: >>>>> Folks, >>>>> >>>>> This discussion has been going on for a while and I'm sure >>>> it wasn't for >>>>> easy to follow. >>>>> This email contains a summary of the discussion so far and >>>> a call for >>>>> comment/concensus. Please respond promptly because there >>>> is some pressure >>>>> from 3GPP to get this draft out very soon. >>>>> >>>>> The issue is how to run IKE in combination with DSMIPv6 in >>>> a private >>>>> IPv4-only network. If you want more detail about why this >>>> is a problem >>>>> please look at the thread "DSMIPv6 and IKE". >>>>> >>>>> There are three types of solutions that we discussed. A >>>> quick summary of >>>>> each below: >>>>> >>>>> 1. The Virtual link approach. In this case IKE runs over >>>> v6 only and is >>>>> completely unaware of the IPv4 network. As a result IKE's >>>> NAT traversal is >>>>> never invoked. Only DSMIPv6's NAT traversal is used. In >>>> this approach, the >>>>> DSMIPv6 implementation in the HA is required to cache the >>>> outer IPv4 address >>>>> and source port of the IPv4 message that contains IKE, >>>> then append them to >>>>> the response from its own IKE daemon. This is basically >>>> done to hide the >>>>> IPv4 network from IKE and effectively disable its NAT >>>> traversal, which >>>>> solves our problem. >>>>> Three people agreed with this approach but two people (I'm >>>> including >>>>> Christian) are against it. So there doesn't seem to be >>>> concensus on this. I >>>>> believe the concern here was that the HA's caching of the >>>> outer address and >>>>> port was complex for the implementation. >>>>> >>>>> 2. Karen suggested a way of running IKE without any >>>> changes (again see the >>>>> thread for details). In this approach DSMIPv6 BUs are >>>> secured with ESP as >>>>> usual. Normal traffic is sent over the DSMIPv6 port. >>>> However, secure traffic >>>>> is sent over the IKE port (4500). The result of this >>>> approach is that it >>>>> takes two messages to complete a handover, one from >>>> DSMIPv6 (BU) and an >>>>> update from IKE (for the secure traffic). The concern that >>>> I had here in the >>>>> discussion with Karen was the number of messages and the >>>> delays associated >>>>> for that. Of course IKE doesn't do movement detection >>>> ...etc. So my concern >>>>> is the discriminatory experience of the handover for >>>> different parts of the >>>>> traffic. >>>>> >>>>> 3. The third class of solutions involves either modifying >>>> MIPv6 (adding new >>>>> messages) or IKE or both. I'm only including this for >>>> completeness, no one >>>>> really wants this. >>>>> >>>>> Please send your comments on the above. Basically the >>>> options are 1 or 2. In >>>>> theory we could do both but I think it's best to pick one >>>> method for this to >>>>> avoid interoperability issues and additional complexity. >>>>> >>>>> Hesham >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mip6 mailing list >>>>> Mip6@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>>> >>>> >>>> >>> >>> >> >> > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 30 20:46:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1iD-00055p-Ra; Tue, 30 Oct 2007 20:45:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1iC-0004Xg-FA; Tue, 30 Oct 2007 20:45:36 -0400 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In1hv-0002Ft-3c; Tue, 30 Oct 2007 20:45:19 -0400 Received: from oaamta01sl.mx.bigpond.com ([124.190.106.219]) by omta02sl.mx.bigpond.com with ESMTP id <20071031004514.CNJE22254.omta02sl.mx.bigpond.com@oaamta01sl.mx.bigpond.com>; Wed, 31 Oct 2007 00:45:14 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta01sl.mx.bigpond.com with ESMTP id <20071031004509.TLTV23516.oaamta01sl.mx.bigpond.com@PC20005>; Wed, 31 Oct 2007 00:45:09 +0000 From: "Hesham Soliman" To: "'Vijay Devarapalli'" Subject: RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Date: Wed, 31 Oct 2007 11:44:58 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcgbUYlOD1Z9uRTyTkmlZrhAUQj+IwADdVpA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4727C667.9020709@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, Karen.Nielsen@tietoenator.com, nemo@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > => Sure they will, Karen already sent the packet formats. > Solution 2 uses > > port 4500 for tunnel mode, hence the entire discussion about 2 RTT > > handovers. > > I repeat, none of the solutions work as long as you use ESP UDP > encapsulation (port 4500) for the payload traffic to the CN. => CN? No one is talking about sending anything to the CN. > > => You mean for DSMIPv6? I think we have to be realistic. > I don't think it > > makes sense to use MIP6 and Mobike at the same time just > so we can encrypt > > payload traffic. I think you agreed with that in your last > email. So, if you > > don't want that then you need to figure out how to secure > payload traffic. > > Otherwise, the solution we have will only look good on paper. > > RFC 3775, 3776 and 4877 say ESP protection for payload traffic is > optional. If you have a secure access link or if you application > layer security obviously you don't need to encrypt all traffic > reverse tunneled through the home agent. => Interesting opinion, so you don't think there is a need for VPNs in cellular systems. Anyway, I know they're not required in MIPv6 but I'm talking about practical deployment. We disagree on that. Hesham > > Vijay > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 30 20:48:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1kY-0007aT-VH; Tue, 30 Oct 2007 20:48:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1kX-000710-8b; Tue, 30 Oct 2007 20:48:01 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In1kD-0002LL-Rh; Tue, 30 Oct 2007 20:47:43 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.190.106.219]) by omta01sl.mx.bigpond.com with ESMTP id <20071031004734.BTBE26650.omta01sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Wed, 31 Oct 2007 00:47:34 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta07sl.mx.bigpond.com with ESMTP id <20071031004733.UDFD5930.oaamta07sl.mx.bigpond.com@PC20005>; Wed, 31 Oct 2007 00:47:33 +0000 From: "Hesham Soliman" To: "'Basavaraj Patil'" , "'Vijay Devarapalli'" , , Subject: RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Date: Wed, 31 Oct 2007 11:47:22 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcgajHdXweg6hCAlQHqWKMbnBJLpbwAyKW7wAACVqhAAAg3P0A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > But Hesham... Do we need to solve the payload security issue? > I thought the MIP6 signaling security was what was being tackled. => We're simply solving the full case. The discussion was always dealing with both cases. We always knew that we can do the BU/BA with transport mode, but we were not sure how to address the entire use case with a mix of secure and insecure traffic. That was always the problem. Hesham > > 0Raj > > > On 10/30/07 7:30 PM, "ext Hesham Soliman" > wrote: > > > This is exactly what we've been discussing, except you > took out the case of > > protection of payload packets. So the solution you list > below cannot be > > compared with alt 1 or 2 because it only addresses part of > the problem, i.e. > > no payload security. > > > > Hesham > > > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > >> Sent: Tuesday, October 30, 2007 10:33 AM > >> To: Hesham Soliman; Karen.Nielsen@tietoenator.com; > >> Christian.Kaas-Petersen@tietoenator.com > >> Cc: mip6@ietf.org; nemo@ietf.org > >> Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call > for concensus > >> > >> Thanks Hesham. > >> > >> I think I mixed up solution 2 described below in your email with > >> solution 2 described in an email you sent on the 17th of October. > >> http://www1.ietf.org/mail-archive/web/mip6/current/msg06856.html > >> > >> I do want to avoid two round trips during every handover. > I also want > >> to avoid running MOBIKE at the same time as MIPv6. Does not > >> make sense. > >> > >> Having said, I would like to figure out whats wrong with > >> running IKEv2 > >> on port 4500, but sending the BU on DS-MIPv6 port with a > >> transport mode > >> SA. > >> > >> Lets say IKEv2 runs on UDP port 4500 always and negotiates a > >> transport > >> mode SA for protecting the BU. > >> > >> When the BU packet goes through the SPD entries, the > >> transport mode SA > >> is picked. After IPsec processing the packet will be as follows > >> > >> IPv6 hdr (src=V6HOA, dst=HAADDR) > >> ESP Hdr > >> BU > >> IPv4 CoA option > >> > >> With DS-MIPv6 encapsulation the packet becomes > >> > >> IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) > >> UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > >> IPv6 hdr (src=V6HOA, dst=HAADDR) > >> ESP Hdr > >> BU > >> IPv4 CoA option > >> > >> Now lets assume the mobile node moves and attaches to another IPv4 > >> access network. The transport mode IPsec SA is still valid. IKEv2 > >> does not know that the mobile node moved, its IPv4 address changed > >> or if there is a new NAT in the path. So the mobile node can send > >> a BU right away as follows. > >> > >> IPv4 hdr (src=new_V4ADDR, dst=HA_V4ADDR) > >> UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > >> IPv6 hdr (src=V6HOA, dst=HAADDR) > >> ESP Hdr > >> BU > >> IPv4 CoA option (new IPv4 CoA) > >> > >> When the HA receives the BU, the packet will appear like the > >> following > >> > >> IPv4 hdr (src=NATTED_new_V4ADDR, dst=HA_V4ADDR) > >> UDP hdr (srcport=NATTED_DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > >> IPv6 hdr (src=V6HOA, dst=HAADDR) > >> ESP Hdr > >> BU > >> IPv4 CoA option (new IPv4 CoA) > >> > >> The HA would process the BU and respond to the > NATTED_DS-MIPv6-PORT. > >> > >> Meanwhile the MIPv6 stack on the mobile node will trigger > the IKEv2 > >> daemon on the mobile node to re-run IKEv2. This is because > >> the original > >> IKEv2 SA is not valid anymore. When the IKEv2 SAs are > >> re-negotiated, new > >> IPsec SAs are also setup. > >> > >> This would allow the IKEv2 exchange to happen out of the > >> critical path. > >> There is no update to the IKEv2 SA based on the BU/BAck > >> exchange. There > >> are no tunnel mode SAs created for any MIPv6 signaling > messages. What > >> am I missing now? > >> > >> Vijay > >> > >> Hesham Soliman wrote: > >>>> IMO, we should go with solution 2) below. I prefer that we let > >>>> IKEv2 use its own NAT traversal mechanism. Regarding two round > >>>> trips during a handover, note that the IKEv2 exchange to > >>>> re-establish the IKEv2 SA and the IPsec SAs is not in the > >>>> critical path of handover. > >>> > >>> => It is in the critical path for the secure packets. > >> That's what the > >>> discussion was about. > >>> > >>> The BU/BAck messages can be exchanged > >>>> with the existing IPsec SAs. The IKEv2 exchange can be happen a > >>>> few seconds (or minutes) after the handover. So there is *no* > >>>> impact on the handover. > >>> > >>> => No, see above. This is only good for insecure traffic. > >> At least this is > >>> not solution 2 below. > >>> > >>> Hesham > >>> > >>>> > >>>> This would be the same as the lack of support for the "K" flag > >>>> in RFC 3775. In RFC 3775, if either the mobile node or the home > >>>> agent are not capable of updating the IKE SA based on the > >>>> exchange of BU/BAck, there is always an IKE exchange after the > >>>> handover (or whenever the CoA changes). > >>>> > >>>> Please let me know if I am missing something related to the > >>>> impact of the IKEv2 exchange on the handover. > >>>> > >>>> I am not comfortable with the temporary tunnel created in > >>>> solution 1). > >>>> > >>>> Vijay > >>>> > >>>> Hesham Soliman wrote: > >>>>> Folks, > >>>>> > >>>>> This discussion has been going on for a while and I'm sure > >>>> it wasn't for > >>>>> easy to follow. > >>>>> This email contains a summary of the discussion so far and > >>>> a call for > >>>>> comment/concensus. Please respond promptly because there > >>>> is some pressure > >>>>> from 3GPP to get this draft out very soon. > >>>>> > >>>>> The issue is how to run IKE in combination with DSMIPv6 in > >>>> a private > >>>>> IPv4-only network. If you want more detail about why this > >>>> is a problem > >>>>> please look at the thread "DSMIPv6 and IKE". > >>>>> > >>>>> There are three types of solutions that we discussed. A > >>>> quick summary of > >>>>> each below: > >>>>> > >>>>> 1. The Virtual link approach. In this case IKE runs over > >>>> v6 only and is > >>>>> completely unaware of the IPv4 network. As a result IKE's > >>>> NAT traversal is > >>>>> never invoked. Only DSMIPv6's NAT traversal is used. In > >>>> this approach, the > >>>>> DSMIPv6 implementation in the HA is required to cache the > >>>> outer IPv4 address > >>>>> and source port of the IPv4 message that contains IKE, > >>>> then append them to > >>>>> the response from its own IKE daemon. This is basically > >>>> done to hide the > >>>>> IPv4 network from IKE and effectively disable its NAT > >>>> traversal, which > >>>>> solves our problem. > >>>>> Three people agreed with this approach but two people (I'm > >>>> including > >>>>> Christian) are against it. So there doesn't seem to be > >>>> concensus on this. I > >>>>> believe the concern here was that the HA's caching of the > >>>> outer address and > >>>>> port was complex for the implementation. > >>>>> > >>>>> 2. Karen suggested a way of running IKE without any > >>>> changes (again see the > >>>>> thread for details). In this approach DSMIPv6 BUs are > >>>> secured with ESP as > >>>>> usual. Normal traffic is sent over the DSMIPv6 port. > >>>> However, secure traffic > >>>>> is sent over the IKE port (4500). The result of this > >>>> approach is that it > >>>>> takes two messages to complete a handover, one from > >>>> DSMIPv6 (BU) and an > >>>>> update from IKE (for the secure traffic). The concern that > >>>> I had here in the > >>>>> discussion with Karen was the number of messages and the > >>>> delays associated > >>>>> for that. Of course IKE doesn't do movement detection > >>>> ...etc. So my concern > >>>>> is the discriminatory experience of the handover for > >>>> different parts of the > >>>>> traffic. > >>>>> > >>>>> 3. The third class of solutions involves either modifying > >>>> MIPv6 (adding new > >>>>> messages) or IKE or both. I'm only including this for > >>>> completeness, no one > >>>>> really wants this. > >>>>> > >>>>> Please send your comments on the above. Basically the > >>>> options are 1 or 2. In > >>>>> theory we could do both but I think it's best to pick one > >>>> method for this to > >>>>> avoid interoperability issues and additional complexity. > >>>>> > >>>>> Hesham > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Mip6 mailing list > >>>>> Mip6@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/mip6 > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 30 20:49:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1m6-0002LH-3z; Tue, 30 Oct 2007 20:49:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1m4-0002AZ-NE; Tue, 30 Oct 2007 20:49:36 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In1ls-0007ai-V4; Tue, 30 Oct 2007 20:49:26 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.190.106.219]) by omta05sl.mx.bigpond.com with ESMTP id <20071031004905.XHCB14987.omta05sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Wed, 31 Oct 2007 00:49:05 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta07sl.mx.bigpond.com with ESMTP id <20071031004905.UDYC5930.oaamta07sl.mx.bigpond.com@PC20005>; Wed, 31 Oct 2007 00:49:05 +0000 From: "Hesham Soliman" To: "'Vijay Devarapalli'" Date: Wed, 31 Oct 2007 11:48:54 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcgbUZlmcTmXA92gS3qlWGgCdyOtbwADm+fg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4727C686.10503@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, Karen.Nielsen@tietoenator.com, Pasi.Eronen@nokia.com, nemo@ietf.org Subject: [Mip6] RE: Payload protection and NAT traversal X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > => These are all options, true. So you're saying the HA > stores both sets of > > information for a short time? Because the change could > also be a DoS, so > > until a timeout takes place the HA wouldn't know whether > it was a genuine > > change or an attack. > > You are supposed to deal with intermediate NATs losing state and > allocating new NATed source address and source port anyway. Nothing > new. => You didn't answer my question above. What you say amounts to a requirement, my question was: So you're saying the HA > stores both sets of > > information for a short time? Because the change could > also be a DoS, so > > until a timeout takes place the HA wouldn't know whether > it was a genuine > > change or an attack. Hesham > > Vijay > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 30 20:56:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1ri-0002av-VO; Tue, 30 Oct 2007 20:55:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1rh-0002VS-8s; Tue, 30 Oct 2007 20:55:25 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In1rg-0002gG-Kk; Tue, 30 Oct 2007 20:55:25 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9V0tELg030596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Oct 2007 17:55:14 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9V0tDXX018532; Tue, 30 Oct 2007 17:55:14 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 17:55:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Date: Tue, 30 Oct 2007 17:55:14 -0700 Message-ID: In-Reply-To: <4727C667.9020709@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Thread-Index: AcgbUcXU/rBj7IJiSpiSE9n9O2i56gABKDCg References: <4727C667.9020709@azairenet.com> From: "Narayanan, Vidya" To: "Vijay Devarapalli" , "Hesham Soliman" X-OriginalArrivalTime: 31 Oct 2007 00:55:13.0904 (UTC) FILETIME=[B217DF00:01C81B58] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, Karen.Nielsen@tietoenator.com, nemo@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham, Vijay, all, Sorry my responses on this thread have been so sporadic and less than useful. Hesham had a couple of questions on my last email, so, I will just attempt to clarify those below. The two things I wanted to point out with this approach are:=20 * If IKEv2 was run on port 4500, this solution requires an update to RFC3948 which mandates that all ESP packets be sent to UDP port 4500. AFAIK, this requirement was put consciously so that all incoming packets from the untrusted interface can be put through IPsec processing in the same manner. And, RFC3948 defines how to differentiate IKEv2 from ESP packets coming in on port 4500. =20 * If we didn't run IKEv2 on port 4500 and instead hid the NAT-T from IKEv2 (which is what Hesham's first option was proposing), I think we'll need a bypass entry to allow the BU coming in on the DSMIP6 port to be given to MIP6. An implementation may allow that directly, but, that's not feasible if the implementation really followed RFC4301. So, at least in principle, we need to talk about having an SPD bypass entry for the DSMIP6 port, processing of the packet by DSMIP6 to remove the NAT-T headers and subsequently ESP processing with the right SPD entry. Implementations need to handle this correctly. =20 Thanks, Vidya > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > Sent: Tuesday, October 30, 2007 5:04 PM > To: Hesham Soliman > Cc: Christian.Kaas-Petersen@tietoenator.com; mip6@ietf.org;=20 > Karen.Nielsen@tietoenator.com; nemo@ietf.org > Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus >=20 > Hesham Soliman wrote: > > > Hesham Soliman wrote: > > > > This is exactly what we've been discussing, except you > took=20 > > out the case of > > protection of payload packets. > > > > > > hmm... are you sure? You said a couple of times that=20 > sending a BU =20 > > > would take two round trips for solution 2. > >=20 > > =3D> No, I said the handover would take 2 RTTs.=20 >=20 > Ok never mind then. BU/BAck exchange does not require two round trips. >=20 > > > > So the solution you list below cannot be > > compared=20 > with alt 1=20 > > or 2 > > Neither solution 1 nor 2 will work for payload security=20 > > when you > use ESP in tunnel mode for the payload packets. > >=20 > > =3D> Sure they will, Karen already sent the packet formats.=20 > Solution 2=20 > > uses port 4500 for tunnel mode, hence the entire discussion about 2=20 > > RTT handovers. >=20 > I repeat, none of the solutions work as long as you use ESP=20 > UDP encapsulation (port 4500) for the payload traffic to the CN. >=20 > > > > because it only addresses part of the problem, i.e. > > > > no payload security.=20 > > > > > > Note that providing payload security was never a requirement. > >=20 > > =3D> You mean for DSMIPv6? I think we have to be realistic. I don't=20 > > think it makes sense to use MIP6 and Mobike at the same=20 > time just so=20 > > we can encrypt payload traffic. I think you agreed with=20 > that in your=20 > > last email. So, if you don't want that then you need to=20 > figure out how to secure payload traffic. > > Otherwise, the solution we have will only look good on paper.=20 >=20 > RFC 3775, 3776 and 4877 say ESP protection for payload=20 > traffic is optional. If you have a secure access link or if=20 > you application layer security obviously you don't need to=20 > encrypt all traffic reverse tunneled through the home agent. >=20 > Vijay >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 30 22:20:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In3B7-0000QT-K0; Tue, 30 Oct 2007 22:19:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In3B5-0000LO-QF; Tue, 30 Oct 2007 22:19:31 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In3Aq-0005q3-4u; Tue, 30 Oct 2007 22:19:16 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 19:19:14 -0700 Message-ID: <4727E621.9030602@azairenet.com> Date: Tue, 30 Oct 2007 19:19:13 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 02:19:14.0381 (UTC) FILETIME=[6E739FD0:01C81B64] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, Karen.Nielsen@tietoenator.com, nemo@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hesham Soliman wrote: > > > => Sure they will, Karen already sent the packet formats. > > Solution 2 uses > > > port 4500 for tunnel mode, hence the entire discussion about 2 RTT > > > handovers. > > > > I repeat, none of the solutions work as long as you use ESP UDP > > encapsulation (port 4500) for the payload traffic to the CN. > > => CN? No one is talking about sending anything to the CN. Payload traffic to the CN reverse tunneled through the HA. You know what I meant. > > > > => You mean for DSMIPv6? I think we have to be realistic. > > I don't think it > > > makes sense to use MIP6 and Mobike at the same time just > > so we can encrypt > > > payload traffic. I think you agreed with that in your last > > email. So, if you > > > don't want that then you need to figure out how to secure > > payload traffic. > > > Otherwise, the solution we have will only look good on paper. > > > > RFC 3775, 3776 and 4877 say ESP protection for payload traffic is > > optional. If you have a secure access link or if you application > > layer security obviously you don't need to encrypt all traffic > > reverse tunneled through the home agent. > > => Interesting opinion, so you don't think there is a need for VPNs in > cellular systems. Anyway, I know they're not required in MIPv6 but I'm > talking about practical deployment. We disagree on that. Ok. I am interested in solving the problem, but it is optional according to the specifications we have. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 30 22:20:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In3BS-0000eB-BE; Tue, 30 Oct 2007 22:19:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In3BR-0000cQ-Kf; Tue, 30 Oct 2007 22:19:53 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In3BQ-00036w-EY; Tue, 30 Oct 2007 22:19:53 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 19:19:51 -0700 Message-ID: <4727E647.7070500@azairenet.com> Date: Tue, 30 Oct 2007 19:19:51 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 02:19:51.0912 (UTC) FILETIME=[84D26680:01C81B64] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, Karen.Nielsen@tietoenator.com, Pasi.Eronen@nokia.com, nemo@ietf.org Subject: [Mip6] Re: Payload protection and NAT traversal X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hesham Soliman wrote: > > > => These are all options, true. So you're saying the HA > > stores both sets of > > > information for a short time? Because the change could > > also be a DoS, so > > > until a timeout takes place the HA wouldn't know whether > > it was a genuine > > > change or an attack. > > > > You are supposed to deal with intermediate NATs losing state and > > allocating new NATed source address and source port anyway. Nothing > > new. > > => You didn't answer my question above. What you say amounts to a > requirement, my question was: I was responding to it. It is not a DoS attack. Vijay > So you're saying the HA > > stores both sets of > > > information for a short time? Because the change could > > also be a DoS, so > > > until a timeout takes place the HA wouldn't know whether > > it was a genuine > > > change or an attack. > > Hesham > > > > > Vijay > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 31 00:08:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In4ro-0002Du-3C; Wed, 31 Oct 2007 00:07:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In4rm-0002Di-VV; Wed, 31 Oct 2007 00:07:42 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In4rg-0006su-Ok; Wed, 31 Oct 2007 00:07:42 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 21:07:35 -0700 Message-ID: <4727FF7D.5070705@azairenet.com> Date: Tue, 30 Oct 2007 21:07:25 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus References: <4727C667.9020709@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 04:07:35.0965 (UTC) FILETIME=[91B29CD0:01C81B73] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, nemo@ietf.org, Karen.Nielsen@tietoenator.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Narayanan, Vidya wrote: > Hi Hesham, Vijay, all, > Sorry my responses on this thread have been so sporadic and less than > useful. Hesham had a couple of questions on my last email, so, I will > just attempt to clarify those below. The two things I wanted to point > out with this approach are: > > * If IKEv2 was run on port 4500, this solution requires an update to > RFC3948 which mandates that all ESP packets be sent to UDP port 4500. > AFAIK, this requirement was put consciously so that all incoming packets > from the untrusted interface can be put through IPsec processing in the > same manner. And, RFC3948 defines how to differentiate IKEv2 from ESP > packets coming in on port 4500. For DS-MIPv6 we are negotiating a transport mode ESP SA for the IPv6 traffic. In fact there is an IPv6 header before the ESP header. So IPsec is not performing UDP encapsulation. UDP encapsulation is being done by DS-MIPv6. I don't believe 3948 considered something like this. As far as RFC 3948 is concerned there is always an IPv4 header preceding the ESP header. Therefore there is a need for UDP encapsulation. Vijay > > * If we didn't run IKEv2 on port 4500 and instead hid the NAT-T from > IKEv2 (which is what Hesham's first option was proposing), I think we'll > need a bypass entry to allow the BU coming in on the DSMIP6 port to be > given to MIP6. An implementation may allow that directly, but, that's > not feasible if the implementation really followed RFC4301. So, at > least in principle, we need to talk about having an SPD bypass entry for > the DSMIP6 port, processing of the packet by DSMIP6 to remove the NAT-T > headers and subsequently ESP processing with the right SPD entry. > Implementations need to handle this correctly. > > Thanks, > Vidya > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >> Sent: Tuesday, October 30, 2007 5:04 PM >> To: Hesham Soliman >> Cc: Christian.Kaas-Petersen@tietoenator.com; mip6@ietf.org; >> Karen.Nielsen@tietoenator.com; nemo@ietf.org >> Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus >> >> Hesham Soliman wrote: >>> > Hesham Soliman wrote: >>> > > This is exactly what we've been discussing, except you > took >>> out the case of > > protection of payload packets. >>> > >>> > hmm... are you sure? You said a couple of times that >> sending a BU >>>> would take two round trips for solution 2. >>> => No, I said the handover would take 2 RTTs. >> Ok never mind then. BU/BAck exchange does not require two round trips. >> >>> > > So the solution you list below cannot be > > compared >> with alt 1 >>> or 2 > > Neither solution 1 nor 2 will work for payload security >>> when you > use ESP in tunnel mode for the payload packets. >>> >>> => Sure they will, Karen already sent the packet formats. >> Solution 2 >>> uses port 4500 for tunnel mode, hence the entire discussion about 2 >>> RTT handovers. >> I repeat, none of the solutions work as long as you use ESP >> UDP encapsulation (port 4500) for the payload traffic to the CN. >> >>> > > because it only addresses part of the problem, i.e. >>> > > no payload security. >>> > >>> > Note that providing payload security was never a requirement. >>> >>> => You mean for DSMIPv6? I think we have to be realistic. I don't >>> think it makes sense to use MIP6 and Mobike at the same >> time just so >>> we can encrypt payload traffic. I think you agreed with >> that in your >>> last email. So, if you don't want that then you need to >> figure out how to secure payload traffic. >>> Otherwise, the solution we have will only look good on paper. >> RFC 3775, 3776 and 4877 say ESP protection for payload >> traffic is optional. If you have a secure access link or if >> you application layer security obviously you don't need to >> encrypt all traffic reverse tunneled through the home agent. >> >> Vijay >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 31 00:34:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In5GA-0001fA-AA; Wed, 31 Oct 2007 00:32:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In5G9-0001ex-J7; Wed, 31 Oct 2007 00:32:53 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In5G3-0007io-76; Wed, 31 Oct 2007 00:32:53 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9V4WPGj002544; Wed, 31 Oct 2007 06:32:26 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 06:32:25 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 23:32:23 -0500 Received: from 10.241.59.244 ([10.241.59.244]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 31 Oct 2007 04:32:23 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 30 Oct 2007 23:33:01 -0500 From: Basavaraj Patil To: ext Hesham Soliman , , Message-ID: Thread-Topic: Please review and provide input to DSMIP6-IKEv2 discussion Thread-Index: AcgXD2Nk409BdK32Rr+w24XNw+KidQEZ7tPI In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 04:32:23.0674 (UTC) FILETIME=[0870FDA0:01C81B77] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Subject: [Mip6] Please review and provide input to DSMIP6-IKEv2 discussion X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, I would like to encourage more people on the MIP6 and NEMO lists to review the discussion related to DSMIP6 and IKEv2 and the issue that was raised earlier as well as the proposed solutions. Please provide your feedback to the ML. At the present time there are only a handful of people commenting and it is difficult to gauge consensus as a result. I have also requested a couple of IKE experts (Tero Kivinen and Pasi Eronen) to review and provide input. -Basavaraj On 10/25/07 9:01 AM, "ext Hesham Soliman" wrote: > Folks, > > This discussion has been going on for a while and I'm sure it wasn't for > easy to follow. > This email contains a summary of the discussion so far and a call for > comment/concensus. Please respond promptly because there is some pressure > from 3GPP to get this draft out very soon. > > The issue is how to run IKE in combination with DSMIPv6 in a private > IPv4-only network. If you want more detail about why this is a problem > please look at the thread "DSMIPv6 and IKE". > > There are three types of solutions that we discussed. A quick summary of > each below: > > 1. The Virtual link approach. In this case IKE runs over v6 only and is > completely unaware of the IPv4 network. As a result IKE's NAT traversal is > never invoked. Only DSMIPv6's NAT traversal is used. In this approach, the > DSMIPv6 implementation in the HA is required to cache the outer IPv4 address > and source port of the IPv4 message that contains IKE, then append them to > the response from its own IKE daemon. This is basically done to hide the > IPv4 network from IKE and effectively disable its NAT traversal, which > solves our problem. > Three people agreed with this approach but two people (I'm including > Christian) are against it. So there doesn't seem to be concensus on this. I > believe the concern here was that the HA's caching of the outer address and > port was complex for the implementation. > > 2. Karen suggested a way of running IKE without any changes (again see the > thread for details). In this approach DSMIPv6 BUs are secured with ESP as > usual. Normal traffic is sent over the DSMIPv6 port. However, secure traffic > is sent over the IKE port (4500). The result of this approach is that it > takes two messages to complete a handover, one from DSMIPv6 (BU) and an > update from IKE (for the secure traffic). The concern that I had here in the > discussion with Karen was the number of messages and the delays associated > for that. Of course IKE doesn't do movement detection ...etc. So my concern > is the discriminatory experience of the handover for different parts of the > traffic. > > 3. The third class of solutions involves either modifying MIPv6 (adding new > messages) or IKE or both. I'm only including this for completeness, no one > really wants this. > > Please send your comments on the above. Basically the options are 1 or 2. In > theory we could do both but I think it's best to pick one method for this to > avoid interoperability issues and additional complexity. > > Hesham > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 31 02:33:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In76Z-0006PV-I3; Wed, 31 Oct 2007 02:31:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In76X-0006K3-TZ for mip6@ietf.org; Wed, 31 Oct 2007 02:31:05 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In76U-0004Cc-2w for mip6@ietf.org; Wed, 31 Oct 2007 02:31:03 -0400 Received: from ep_ms5_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JQR00BPPJF7OX@mailout2.samsung.com> for mip6@ietf.org; Wed, 31 Oct 2007 15:30:43 +0900 (KST) Received: from ep_spt04 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JQR004PXJF7DS@ms5.samsung.com> for mip6@ietf.org; Wed, 31 Oct 2007 15:30:43 +0900 (KST) Content-return: prohibited Date: Wed, 31 Oct 2007 06:30:43 +0000 (GMT) From: Heejin Jang To: mip6@ietf.org Message-id: <9908908.171511193812243189.JavaMail.weblogic@epml05> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20071031062924528@heejin.jang X-MTR: 20071031062924528@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML X-Spam-Score: -1.2 (-) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Subject: [Mip6] Reply for AD's comments on draft-ietf-mip6-hiopt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: heejin.jang@samsung.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1319505052==" Errors-To: mip6-bounces@ietf.org --===============1319505052== Content-return: prohibited Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 SGkgSmFyaSBhbmQgZm9sa3MuDQoNClRoZSBkcmFmdCBoYXMgYmVlbiByZXZpc2VkIGJhc2VkIG9u IEFEJ3MgcmV2aWV3IHJlc3VsdHMgYW5kIGNvbW1lbnRzDQpmcm9tIERIQyBmb2xrcy4gRm9yIGRl dGFpbGVkIG1vZGlmaWNhdGlvbiBiYXNlZCBvbiBBRCdzIGZlZWRiYWNrLA0KcGxlYXNlIHNlZSB0 aGUgYmVsb3cuDQoNCkphcmksIGtpbmx5IHNlZSB0aGF0IHRoZSByZXZpc2lvbiB3YXMgZG9uZSBw cm9wZXJseSwgYW5kIGxldCB1cyBrbm93DQp5b3VyIG9waW5pb24uIA0KVGhhbmtzIGFnYWluLg0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gSSBoYXZlIG1hZGUgbXkgQUQgcmV2aWV3IG9mIHRoaXMgZG9jdW1lbnQuDQo+ DQo+IFRoaXMgZG9jdW1lbnQgc3RpbGwgbmVlZHMgYSByZXZpc2lvbi4gQm90aCBkdWUgdG8gY29t bWVudHMgZ2l2ZW4gYnkNCj4gQmVybmllIFZvbHogaW4gREhDIHJldmlldyAoYXQgdGhlIGVuZCBv ZiB0aGlzIGUtbWFpbCksIGFzIHdlbGwgYXMgZm9yDQo+IG90aGVyIHJlYXNvbnMuDQoNCi0gU2hv dyBxdW90ZWQgdGV4dCAtDQo+IEkgYmVsaWV2ZSB0aGF0IHRoZSBkZWxpdmVyeSBvZiBtb2JpbGl0 eSBpbmZvcm1hdGlvbiB2aWEgREhDUCBpcyBhDQo+IHZhbGlkIGFwcHJvYWNoLiBIb3dldmVyLCB0 aGVyZSBhcmUgYSBudW1iZXIgb2YgZGV0YWlscyB0aGF0IHN0aWxsIG5lZWQNCj4gd29yay4NCj4g VGhlIGRyYWZ0IG5lZWRzIHRvIHRhbGsgYWJvdXQgd2hlbiBzdWNoIGRpc2NvdmVyeSBpcyB1c2Vk LiBJdHMNCj4gbGltaXRhdGlvbnMgbXVzdCBiZSBkZXNjcmliZWQgbW9yZSBhY2N1cmF0ZWx5LiBB bmQgdGhlcmUgYXJlIGEgbnVtYmVyDQo+IG9mIGlzc3VlcyBpbiB0aGUgZGVzY3JpcHRpb24gb2Yg dGhlIG9wdGlvbiBmb3JtYXRzLg0KPg0KPiBTdWJzdGFudGlhbDoNCj4NCj4gPiAgICBBcyBwYXJ0 IG9mIGNvbmZpZ3VyaW5nIHRoZSBpbml0aWFsIFRDUC9JUCBwYXJhbWV0ZXJzLCBhIG1vYmlsZSBu b2RlDQo+ID4gICAgY2FuIG9idGFpbiBob21lIG5ldHdvcmsgaW5mb3JtYXRpb24gZm9yIHRoZSBz dWJuZXQgaXQgaXMgZGlyZWN0bHkNCj4gPiAgICBhdHRhY2hlZCB0bywgb3RoZXIgc3VibmV0cyBp biB0aGUgdmlzaXRlZCBkb21haW4sIG9yIGEgc3VibmV0IGZyb20NCj4gPiAgICBpdHMgaG9tZSBk b21haW4uDQo+DQo+IFRoaXMgdGV4dCBtYWtlcyBpdCBzb3VuZCBsaWtlIGEgbmV3IGhvbWUgbmV0 d29yayBpcyBuZWVkZWQgZm9yDQo+IGV2ZXJ5d2hlcmUgdGhlIG1vYmlsZSBub2RlIHRyYXZlbHMg dG8uIFRoYXQgaXMgd3JvbmcuIFN1Z2dlc3RlZA0KPiByZXdyaXRlOg0KPg0KPiBBcyBwYXJ0IG9m IGNvbmZpZ3VyaW5nIHRoZSBpbml0aWFsIFRDUC9JUCBwYXJhbWV0ZXJzLCBhIG1vYmlsZSBub2Rl DQo+IGNhbiBmaW5kIGl0c2VsZiBhIHN1aXRhYmxlIGhvbWUgYWdlbnQuIFN1Y2ggYSBob21lIGFn ZW50IG1pZ2h0IHJlc2lkZQ0KPiBpbiB0aGUgYWNjZXNzIG5ldHdvcmsgdGhhdCB0aGUgbW9iaWxl IG5vZGUgZmlyc3QgY29ubmVjdHMgdG8sIG9yIGluIGENCj4gaG9tZSBuZXR3b3JrIHRoYXQgdGhl IG1vYmlsZSBub2RlIGlzIGFzc29jaWF0ZWQgd2l0aC4NCg0KT2suIFdlJ2xsIHJlcGxhY2UgdGhl IGV4aXN0aW5nIHBhcmFncmFwaCB3aXRoIHRoZSBhYm92ZSBvbmUuDQoNCj4gPiAgICBUaGUgbW9i aWxlIG5vZGUgTVVTVCBpbmNsdWRlDQo+ID4gICAgdGhpcyBvcHRpb24gYWxvbmcgd2l0aCBpdHMg T3B0aW9uIFJlcXVlc3Qgb3B0aW9uIGluIGl0cyByZXF1ZXN0Lg0KPiAuLi4gdW5sZXNzIGl0IGFs cmVhZHkgaGFzIGNvbmZpZ3VyZWQgaG9tZSBhZ2VudCBhbmQgb3RoZXIgaW5mb3JtYXRpb24NCj4g Zm9yIGl0c2VsZj8gSXQgd291bGQgYmUgdmVyeSBleHBlbnNpdmUgdG8gZG8gdGhpcyBvbiBldmVy eSBtb3ZlbWVudCwNCj4gbm90IHRvIG1lbnRpb24gbG9zaW5nIHNlc3Npb25zIGlmIHRoZSBob21l IGFnZW50IGFuZCBob21lIGFkZHJlc3MgYXJlDQo+IGFjdHVhbGx5IGNoYW5nZWQuDQo+DQo+IFRo YXQgYmVpbmcgc2FpZCwgdGhlIG1vYmlsZSBub2RlIHByb2JhYmx5IHNob3VsZCBkbyB0aGlzIG9j Y2FzaW9uYWxseQ0KPiB0byBlbnN1cmUgdGhhdCBpdCBpcyBjb25uZWN0ZWQgdG8gdGhlIHRvcG9s b2dpY2FsbHkgYmVzdCBob21lIGFnZW50Lg0KPiBZZXQgeW91IHdhbnQgdG8ga2VlcCB0aGUgb2xk IGhvbWUgYWdlbnRzIHN0aWxsIGluIHVzZSwgdG8gYXZvaWQgbG9zaW5nDQo+IHlvdXIgc2Vzc2lv bnMuLi4gc29tZSB0ZXh0IGFib3V0IHRoaXMgaXMgcHJvYmFibHkgbmVlZGVkIGVpdGhlciBpbg0K PiB0aGlzIGRyYWZ0IG9yIHNvbWV3aGVyZSBlbHNlLg0KDQoNCk9rLiBUaGUgcHJvcG9zZWQgc2No ZW1lIGlzIGEga2luZCBvZiBib290c3RyYXBwaW5nIG1lY2hhbmlzbXMsIHNvIHRoZQ0KZGlzY292 ZXJ5IHByb2NlZHVyZSBkb2VzIG5vdCBuZWVkIHRvIGJlIHBlcmZvcm1lZCBhdCBldmVyeSBNTidz DQptb3ZlbWVudCwgYnV0IGlzIHBlcmZvcm1lZCB3aGVuIHRoZSBtb2JpbGUgbm9kZSBuZWVkcyBi b290c3RyYXBwaW5nIG9yDQpjaGFuZ2Ugb2YgY3VycmVudCBob21lIGFnZW50LiBGb3IgY2xhcml0 eSwgd2UnbGwgYWRkIHRoZSBmb2xsb3dpbmcNCg0KcGFyYWdyYXBoIGluIHNlY3Rpb24gNC4xIChN b2JpbGUgTm9kZSBCZWhhdmlvcikuDQoNCiIgVGhlIG1vYmlsZSBub2RlIGRvZXMgbm90IG5lZWQg dG8gcGVyZm9ybSB0aGUgaG9tZSBpbmZvcm1hdGlvbg0KZGlzY292ZXJ5IHByb2NlZHVyZSBhZnRl ciBpdHMgZXZlcnkgbW92ZW1lbnQuIEl0IG1heSB0cnkgdG8gcGVyZm9ybQ0KdGhlIGhvbWUgbmV0 d29yayBpbmZvcm1hdGlvbiBkaXNjb3Zlcnkgd2hlbiBpdCBsYWNrcyBob21lIG5ldHdvcmsNCmlu Zm9ybWF0aW9uIGZvciBNSVB2NiBvciBuZWVkcyB0byBjaGFuZ2UgdGhlIGhvbWUgYWdlbnQgZm9y IHNvbWUNCnJlYXNvbnMsIGZvciBpbnN0YW5jZSwgdG8gcmVjb3ZlciBmcm9tIHRoZSBzaW5nbGUg cG9pbnQgb2YgZmFpbHVyZSBvZg0KdGhlIGV4aXN0aW5nIGhvbWUgYWdlbnQgb3IgdG8gZmluZCB0 aGUgdG9wb2xvZ2ljYWxseSBiZXN0IGhvbWUgYWdlbnQiDQoNCj4gPiAgICAgICAgIEhvbWUgTmV0 d29yayBJZGVudGlmaWVyDQo+ID4NCj4gPiAgICAgICAgICAgIFRoZSBpZGVudGlmaWVyIHRvIHNw ZWNpZnkgdGhlIHJlcXVlc3RlZCBob21lIG5ldHdvcmsgb2YNCj4gPiAgICAgICAgICAgIHRoZSBt b2JpbGUgbm9kZS4gVGhpcyBmaWVsZCBNVVNUIGJlIHNldCBpbiB0aGUgZm9ybSBvZiB1c2VyJ3MN Cj4gPiAgICAgICAgICAgIE5BSSBbUkZDNDI4Ml0uDQo+DQo+IFRoZSBmdWxsIE5BST8gVGhpcyBp cyBwcm9ibGVtYXRpYyBpbiBtYW55IHdheXMsIGluY2x1ZGluZyBwcml2YWN5LA0KPiBvcGVyYXRp b24gd2l0aCBtb2JpbGUgbm9kZXMgdGhhdCBvbmx5IGtub3cgdGhlaXIgZG9tYWluIGJ1dCBkbyBu b3QNCj4gaGF2ZSBhIE5BSSwgZXRjLg0KPg0KPiBXb3VsZG4ndCBpdCBiZSBtb3JlIGFwcHJvcHJp YXRlIHRvIHNpbXBseSBwcm92aWRlIHRoZSB1c2VyJ3MgZG9tYWluPw0KDQoNCk9rLiBXZSBjb25z aWRlcnMgRlFETiBvZiBkb21haW4gcmVxdWVzdGVkIGJ5IHRoZSBtb2JpbGUgbm9kZSBpbnN0ZWFk DQoNCm9mIGZ1bGwgTkFJLCB3aGljaCBjYW4gcmVtb3ZlIHRoZSBwcm9ibGVtcyB5b3UgbWVudGlv bmVkLg0KDQo+ID4gICAgICAgICBpZC10eXBlDQo+ID4NCj4gPiAgICAgICAgICAgIFRoZSB0eXBl IG9mIEhvbWUgTmV0d29yayBJZGVudGlmaWVyOg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgMCAg ICBWaXNpdGVkIGRvbWFpbiAobG9jYWwgQVNQKQ0KPiA+DQo+ID4gICAgICAgICAgICAgICAgMSAg ICBUYXJnZXQgTVNQDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAyICAgIE5vIHByZWZlcmVuY2UN Cj4NCj4gVGhpcyBzZWVtcyB1bm5lY2Vzc2FyaWx5IGNvbXBsaWNhdGVkLiBJcyB0aGVyZSBzb21l IHJlYXNvbiB3aHkgeW91DQo+IGNvdWxkIHNpbXBseSBpbmNsdWRlIHRoZSB0YXJnZXQgTVNQIGRv bWFpbiBpbmZvcm1hdGlvbiBpZiBpdCBpcyBrbm93bg0KPiBvciBhbiBlbXB0eSBzdHJpbmcgb3Ro ZXJ3aXNlIGFuZCBiZSBhbGxvY2F0ZWQgYSBsb2NhbCBBU1AgaW4gdGhhdA0KPiBjYXNlPw0KDQoN ClRoZSBpZC10eXBlIGlzIG5lY2Vzc2FyeSB0byBjbGFyaWZ5IHRoZSBtb2JpbGUgbm9kZSdzIHBy ZWZlcmVuY2UgZm9yIHRoZQ0KcmVxdWVzdGVkIGhvbWUgbmV0d29yay4NCg0KSWYgdGhlIG1vYmls ZSBub2RlIHdhbnRzIHRvIHJldHJpZXZlIHRoZSBob21lIGluZm9ybWF0aW9uIGJvdGggZnJvbQ0K dGhlIHZpc2l0ZWQgbmV0d29yayBhbmQgdGhlIHNwZWNpZmllZCB0YXJnZXQgTVNQLCBpdCBpcyBi ZXR0ZXIgdG8NCmNsYXJpZnkgaXRzIGludGVudCBieSBzcGVjaWZ5aW5nIHRoZSBpZC10eXBlIDAg YW5kIDEgaW4gdHdvIG9wdGlvbnMNCnRoYW4gc2ltcGx5IGJ5IHNlbmRpbmcgdHdvIG9wdGlvbnMs IG9uZSBvcHRpb24gd2l0aCBubyBpZC10eXBlIGFuZCBvbmUNCg0Kb3B0aW9uIHdpdGggdGhlIHRh cmdldCBNU1AgKHRoaXMgbG9va3MgYW1iaWd1b3VzKS4NCkFkZGl0aW9uYWxseSwgSWYgREhDUCBj YW4ga25vdyB0aGUga2luZCBvZiBob21lIG5ldHdvcmsgcmVxdWVzdGVkIGJ5DQpNTiBleHBsaWNp dGx5LCBpdCBkb2VzIG5vdCBuZWVkIHRvIHRyYW5zZmVyIHVubmVjZXNzYXJ5IGluZm9ybWF0aW9u DQp3aGljaCBpcyBub3QgaW4gdGhlIG1vYmlsZSBub2RlJ3MgaW50ZXJlc3QuIFNvLCB3ZSB0aGlu ayBpdCdzIGJldHRlcg0KdG8ga2VlcCB0aGUgaWQtdHlwZSBpbiB0aGUgSE4gSWRlbnRpZmllciBv cHRpb24uDQoNCg0KPiA+IDMuMi4gIE1JUDYgUmVsYXkgQWdlbnQgT3B0aW9uDQo+ID4NCj4gPiAg ICBUaGlzIG9wdGlvbiBjYXJyaWVzIHRoZSBSQURJVVMgb3IgRGlhbWV0ZXIgYXR0cmlidXRlcyB0 aGF0IGFyZQ0KPiA+ICAgIHJlY2VpdmVkIGF0IHRoZSBOQVMgZnJvbSB0aGUgQUFBSC4gIFRoZSBE SENQIHJlbGF5IGFnZW50IHNlbmRzIHRoaXMNCj4gPiAgICBvcHRpb24gdG8gdGhlIERIQ1Agc2Vy dmVyIGluIHRoZSBSZWxheS1Gb3J3YXJkIG1lc3NhZ2UuDQo+IEl0IGRvZXMgbm90IGNhcnJ5IFJB RElVUyBvciBEaWFtZXRlciBhdHRyaWJ1dGVzIChhbmQgbm9yIHNob3VsZCBpdCkuDQo+IFBsZWFz ZSBhbGlnbiB0aGlzIHRleHQgd2l0aCB0aGUgYWN0dWFsIHN1YmF0dHJpYnV0ZXMgdGhhdCB5b3Ug aGF2ZS4NCg0KT2suIFRoZSB0ZXh0IHdpbGwgYmUgcmV3cml0ZWQgYXMgYmVsb3cuDQoNCiIgVGhp cyBvcHRpb24gY2FycmllcyB0aGUgaG9tZSBuZXR3b3JrIGluZm9ybWF0aW9uIHBhcmFtZXRlcnMg d2hpY2gNCndlcmUgdHJhbnNmZXJyZWQgdG8gdGhlIE5BUyBmcm9tIEFBQUggYnkgdXNpbmcgW0kt RC5pZXRmLW1pcDYtcmFkaXVzXS4NClRoZSBESENQIHJlbGF5IGFnZW50IHNlbmRzIHRoaXMgb3B0 aW9uIHRvIHRoZSBESENQIHNlcnZlciBpbiB0aGUNClJlbGF5LUZvcndhcmQgbWVzc2FnZS4iDQoN Cj4gQWxzbywgaXQgaXMgaW5hcHByb3ByaWF0ZSB0byBhc3N1bWUgdGhhdCB0aGUgaW5mb3JtYXRp b24gY2FuIG9ubHkgY29tZQ0KPiBmcm9tIEFBQS4gUHJlc3VtYWJseSB3ZSdkIGxpa2UgdGhlIG1l Y2hhbmlzbXMgdG8gYmUgZ2VuZXJhbCBlbm91Z2gNCj4gdGhhdCwgZm9yIGluc3RhbmNlLCBtYW51 YWwgY29uZmlndXJhdGlvbiwgbGluayBpZGVudGlmaWVyLCBldGMuIGNvdWxkDQo+IGFsc28gYmUg dXNlZCB0byBkZXRlcm1pbmUgd2hhdCBtb2JpbGl0eSBkb21haW5zIGFyZSBhcHByb3ByaWF0ZSBm b3INCj4gdGhpcyBjbGllbnQuDQoNClRoZSBmb2xsb3dpbmcgcGFyYWdyYXBoIGluIFNlY3Rpb24g NC4zIChESENQIHNlcnZlciBiZWhhdmlvcikgZGVzY3JpYmVzIHRoYXQNCnRoZXJlIGNhbiBiZSBt b3JlIHRoYW4gb25lIHdheXMgZm9yIERIQ1Agc2VydmVyIHRvIGxlYXJuIHRoZSBob21lDQoNCm5l dHdvcmsgaW5mb3JtYXRpb24sIGJ1dCB0aGUgbWVjaGFuaXNtIGlzIG5vdCBpbiB0aGUgc2NvcGUg b2YgdGhpcyBkb2N1bWVudC4NCg0KLSBTaG93IHF1b3RlZCB0ZXh0IC0NCg0KIlRoZSBESENQIHNl cnZlciBzaG91bGQgcHJvdmlkZSBhbGwgb2YgdGhlIG1hdGNoaW5nIGhvbWUgaW5mb3JtYXRpb24N CmluIEhvbWUgTmV0d29yayBJbmZvcm1hdGlvbiBvcHRpb24ocykgYmFzZWQgb24gaXRzIHBvbGlj eS4gIFRoZXJlIGNhbg0KYmUgc2V2ZXJhbCB3YXlzIHRoYXQgYSBESENQIHNlcnZlciBsZWFybnMg bWVjaGFuaXNtIHRvIGtub3cgb3INCnJldHJpZXZlIHRoZSByZXF1ZXN0ZWQgaG9tZSBuZXR3b3Jr IGluZm9ybWF0aW9uLiAgRm9yIGluc3RhbmNlLCBhcw0KZGVzY3JpYmVkIGluIFtJLUQuaWV0Zi1t aXA2LXJhZGl1c10sIHRoZSBOQVMgY2FuIGxlYXJuIHRoZQ0KaW5mb3JtYXRpb24gdmlhIFJBRElV UyBkdXJpbmcgbmV0d29yayBhY2Nlc3MgYXV0aGVudGljYXRpb24sIGFuZCBOQVMtDQpjb2xsb2Nh dGVkIERIQ1AgcmVsYXkgY2FuIHRyYW5zZmVyIGl0IHRvIHRoZSBESENQIHNlcnZlciBieSB0aGUN CnByb3Bvc2VkIERIQ1Agb3B0aW9uIGluIHRoaXMgZG9jdW1lbnQuICBIb3dldmVyLCB0aGUgbWVj aGFuaXNtIGJ5DQp3aGljaCB0aGUgREhDUCBzZXJ2ZXIgaXMgcHJvdmlzaW9uZWQgd2l0aCB0aGUg aG9tZSBuZXR3b3JrDQppbmZvcm1hdGlvbiBvciBvYnRhaW5zIGl0IGR5bmFtaWNhbGx5IGlzIG91 dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuIg0KDQpJdCB3aWxsIGJlIHNsaWdodGx5 IHJldmlzZWQgYXMgZm9sbG93cy4NCg0KIlRoZSBESENQIHNlcnZlciBzaG91bGQgcHJvdmlkZSBh bGwgb2YgdGhlIG1hdGNoaW5nIGhvbWUgaW5mb3JtYXRpb24NCmluIEhvbWUgTmV0d29yayBJbmZv cm1hdGlvbiBvcHRpb24ocykgYmFzZWQgb24gaXRzIHBvbGljeS4gIFRoZXJlIGNhbg0KYmUgc2V2 ZXJhbCB3YXlzIHRoYXQgYSBESENQIHNlcnZlciBsZWFybnMgbWVjaGFuaXNtIHRvIGtub3cgb3IN CnJldHJpZXZlIHRoZSByZXF1ZXN0ZWQgaG9tZSBuZXR3b3JrIGluZm9ybWF0aW9uLiAgRm9yIGlu c3RhbmNlLCBhcw0KZGVzY3JpYmVkIGluIFtJLUQuaWV0Zi1taXA2LXJhZGl1c10sIHRoZSBOQVMg Y2FuIGxlYXJuIHRoZQ0KaW5mb3JtYXRpb24gdmlhIFJBRElVUyBkdXJpbmcgbmV0d29yayBhY2Nl c3MgYXV0aGVudGljYXRpb24sIGFuZCBOQVMtDQpjb2xsb2NhdGVkIERIQ1AgcmVsYXkgY2FuIHRy YW5zZmVyIGl0IHRvIHRoZSBESENQIHNlcnZlciBieSB0aGUNCnByb3Bvc2VkIERIQ1Agb3B0aW9u IGluIHRoaXMgZG9jdW1lbnQuIE9yIHRoZSBob21lIGluZm9ybWF0aW9uIG1heSBoYXZlDQpiZWVu IGNvbmZpZ3VyZWQgc3RhdGljYWxseSBpbiB0aGUgREhDUCBzZXJ2ZXIgYnkgYWRtaW5pc3RyYXRv cnMuIEhvd2V2ZXIsDQp0aGUgbWVjaGFuaXNtIGJ5IHdoaWNoIHRoZSBESENQIHNlcnZlciBpcyBw cm92aXNpb25lZCB3aXRoIHRoZSBob21lIG5ldHdvcmsNCmluZm9ybWF0aW9uIG9yIG9idGFpbnMg aXQgZHluYW1pY2FsbHkgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4iDQoN Cj4gQWZmZWN0cyBTZWN0aW9uIDQuMiwgdG9vLg0KPg0KPiA+ICAgICAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCj4gPiAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KPiA+ICAgIHwgICAgICAgT1BUSU9OX01JUDYtSE5JTkYgICAgICAgfCAgICAgICAg ICAgb3B0aW9uLWxlbiAgICAgICAgICB8DQo+ID4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gPiAgICB8ICAgICBp ZC10eXBlICAgfCAgICByZXNlcnZlZCAgIHwgICAgSE5JRF9zZXEgICB8ICAgICAgICAgICAgICAg fA0KPiA+ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsgICAgICAgICAgICAgICArDQo+ID4gICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgc3Vi LW9wdGlvbnMgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCj4gPiAgICAuICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLg0KPiA+ ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQo+ID4NCj4gPiAgICAgICAgICBvcHRpb24tY29kZQ0KPiA+DQo+ID4gICAg ICAgICAgICAgT1BUSU9OX01JUDYtSE5JTkYgKFRCRCkuDQo+ID4NCj4gPiAgICAgICAgICBvcHRp b24tbGVuDQo+ID4NCj4gPiAgICAgICAgICAgICBUb3RhbCBsZW5ndGggb2YgdGhlIG9wdGlvbi1k YXRhIGluIG9jdGV0cw0KPiA+DQo+ID4gICAgICAgICAgaWQtdHlwZQ0KPiA+DQo+ID4gICAgICAg ICAgICAgVGhlIHR5cGUgb2YgSG9tZSBOZXR3b3JrIElkZW50aWZpZXI6DQo+ID4NCj4gPiAgICAg ICAgICAgICAgICAgMCAgICBWaXNpdGVkIGRvbWFpbiAobG9jYWwgQVNQKQ0KPiA+DQo+ID4gICAg ICAgICAgICAgICAgIDEgICAgSG9tZSBkb21haW4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAy ICAgIE5vIHByZWZlcmVuY2UNCj4gPg0KPiA+ICAgICAgICAgIHJlc2VydmVkDQo+ID4NCj4gPiAg ICAgICAgICAgICBBbiA4LWJpdCBmaWVsZCByZXNlcnZlZCBmb3IgZnV0dXJlIHVzZS4gIFRoZSB2 YWx1ZSBNVVNUDQo+ID4gICAgICAgICAgICAgYmUgaW5pdGlhbGl6ZWQgdG8gMCBieSB0aGUgc2Vu ZGVyIGFuZCBNVVNUIGJlIGlnbm9yZWQgYnkNCj4gPiAgICAgICAgICAgICB0aGUgcmVjZWl2ZXIu DQo+ID4NCj4gPiAgICAgICAgICBITklEX3NlcQ0KPiA+DQo+ID4gICAgICAgICAgICAgQW4gOC1i aXQgdW5zaWduZWQgaW50ZWdlciB1c2VkIGZvciBtYXRjaGluZyBmb3IgSG9tZSBOZXR3b3JrDQo+ ID4gICAgICAgICAgICAgSWRlbnRpZmllciBvcHRpb25zIHdoZW4gdGhlIG1vYmlsZSBub2RlIGhh cyByZXF1ZXN0ZWQgd2l0aA0KPiA+ICAgICAgICAgICAgIHRoZSBtdWx0aXBsZSBIb21lIE5ldHdv cmsgSWRlbnRpZmllciBvcHRpb25zIHdpdGggdGhlIHNhbWUNCj4gPiAgICAgICAgICAgICBpZC10 eXBlIDEgYnV0IGhhdmluZyBkaWZmZXJlbnQgSG9tZSBOZXR3b3JrIElkZW50aWZpZXJzLg0KPiA+ DQo+ID4gICAgICAgICAgc3ViLW9wdGlvbnMNCj4gPg0KPiA+ICAgICAgICAgICAgIEEgc2VyaWVz IG9mIHN1Yi1vcHRpb25zIGNhcnJ5aW5nIE1JUDYgYm9vdHN0cmFwDQo+ID4gICAgICAgICAgICAg aW5mb3JtYXRpb24uDQo+DQo+IFdoeSBpcyBpZC10eXBlIGZpZWxkIG5lZWRlZCBoZXJlPyBKdXN0 IHRvIGJlIGFibGUgdG8gcmVwbHkgdG8gdGhlDQo+IHJlcXVlc3RlZCBvcHRpb24/IFRoYXQgZG9l cyBub3Qgc2VlbSBzbyB1c2VmdWwsIElNSE8uIE9yIHRvIGJlIGFibGUgdG8NCj4gaW1wbGVtZW50 IHRoZSBTZWN0aW9uIDQuMSBwcm9jZXNzaW5nIHRoYXQgaXMgZGlmZmVyZW50IGRlcGVuZGluZyBv bg0KPiB3aGF0IHR5cGUgb2YgbmV0d29yayB3ZSBhcmUgdGFsa2luZyBhYm91dD8gQnV0IHdvdWxk bid0IEhOSURfc2VxIGFuZA0KPiB0aGUgb3JkZXJpbmcgb2Ygb3B0aW9ucyBiZSBzdWZmaWNpZW50 IGZvciB0aGlzPw0KDQpPay4gVGhlIHVzZSBvZiBzZXF1ZW5jZSBudW1iZXIgc2VlbXMgdG8gYmUg ZW5vdWdoLiB3ZSdsbCBkZWxldGUgdGhlDQppZC10eXBlIGZpZWxkIGluIHRoZSBITiBpbmZvcm1h dGlvbiBvcHRpb24uDQoNCj4gPiAgICBXaGVuIHRoZSBtb2JpbGUgbm9kZSByZWNlaXZlcyBhIFJl cGx5IG1lc3NhZ2UgZnJvbSB0aGUgREhDUCBzZXJ2ZXINCj4gPiAgICBhbmQgZ2V0cyBtb3JlIHRo YW4gb25lIGhvbWUgbmV0d29yayBpbmZvcm1hdGlvbiwgaXQgTVVTVCBoYXZlIGENCj4gPiAgICBz ZWxlY3Rpb24gbWVjaGFuaXNtIHRvIGRldGVybWluZSB3aGljaCBvbmUgdG8gdXNlIGZvciBlc3Rh Ymxpc2hpbmcgYQ0KPiA+ICAgIE1vYmlsZSBJUHY2IHNlc3Npb24uICBGb3IgZXhhbXBsZSwgaWYg dGhlIG1vYmlsZSBub2RlIGFjcXVpcmVzIGJvdGgNCj4gPiAgICBJUHY2IGFkZHJlc3MgYW5kIEZR RE4gb2YgdGhlIGhvbWUgYWdlbnQsIGl0IG1heSB0cnkgdG8gdXNlIHRoZQ0KPiA+ICAgIGFkZHJl c3MgaW5mb3JtYXRpb24gb2YgdGhlIGhvbWUgYWdlbnQgZmlyc3QuDQo+DQo+IEkgYWdyZWUgdGhh dCBhIHNlbGVjdGlvbiBtZWNoYW5pc20gaXMgbmVlZGVkLiBCdXQgaXMgY2xlYXIgaG93IEkgY2Fu DQo+IGV2YWx1YXRlIGFuIGltcGxlbWVudGF0aW9uJ3MgY29uZm9ybWFuY2UgdG8gdGhlIE1VU1Qg YWJvdmUuIEl0IG1pZ2h0DQo+IGJlIGJldHRlciB0byBzaW1wbHkgZW51bWVyYXRlIGluIHRoaXMg ZHJhZnQgd2hhdCB0aGUgb3JkZXIgc2hvdWxkIGJlLA0KPiBhbmQgd2hldGhlciBtdWx0aXBsZSBp biBwYXJhbGxlbCBjb250YWN0IGF0dGVtcHRzIGFyZQ0KPiByZXF1aXJlZC9hbGxvd2VkL2Rpc2Nv dXJhZ2VkLiBUaGUgc3Vic2VxdWVudCB0ZXh0IGRvZXMgZG8gdGhpcywgYXQNCj4gbGVhc3QgdG8g YW4gZXh0ZW50LiBJdHMgbm90IGNsZWFyIHRoYXQgdGhlIE1VU1QgYWJvdmUgaXMgbmVlZGVkIGlm IHRoZQ0KPiB0ZXh0IGlzIGNvbXBsZXRlLg0KDQpPay4gVGhlICJNVVNUIiB3aWxsIGJlIHJlbGF4 ZWQgaW50byAicmVjb21tZW5kZWQiLg0KUmVnYXJkaW5nIHRoZSBvcHRpb24gb3JkZXJpbmcsIHdl IGdvdCB0aGUgZmVlZGJhY2sgZnJvbSBESEMgV0cgdGhhdA0KdGhlIGRlcGVuZGVuY3kgb2YgdGhl IG9wdGlvbiBvcmRlcmluZyBpcyBub3QgYSByZWNvbW1lbmRlZCBhcHByb2FjaA0KYW5kIHRoZSBz dHJpY3Qgb3JkZXJpbmcgb2YgdGhlIG9wdGlvbnMgc2hvdWxkIG5vdCBiZSBzdGlwdWxhdGVkIGlu IHRoZQ0KZG9jdW1lbnQuIFNvIHdlIGRlY2lkZWQgdG8gYXZvaWQgdGhlIHVzZSBvZiBvcHRpb24g b3JkZXJpbmcgYW5kIGRlZmluZQ0Kc2VxdWVuY2UgbnVtYmVycyBpbiB0aGUgb3B0aW9ucyBpbnN0 ZWFkLg0KDQo+ID4gICAgSG93ZXZlciwgaG93IGxvbmcgdGhlIE5BUyBzaG91bGQga2VlcA0KPiA+ ICAgIHRoZSBob21lIGluZm9ybWF0aW9uIGRlcGVuZHMgb24gdGhlIGFkbWluaXN0cmF0b3IncyBw b2xpY3kuICBXaGVuIHRoZQ0KPiA+ICAgIE5BUyBkb2VzIG5vdCBrZWVwIHRoZSBob21lIGluZm9y bWF0aW9uIGZvciB0aGUgcmVxdWVzdGluZyBtb2JpbGUgbm9kZQ0KPiA+ICAgIGF0IHRoZSB0aW1l IG9mIHJlY2VpdmluZyB0aGUgSW5mb3JtYXRpb24gUmVxdWVzdCBmcm9tIHRoZSBtb2JpbGUNCj4g PiAgICBub2RlLCBpdCBtYXkgdHJ5IHRvIGFjcXVpcmUgdGhlIGluZm9ybWF0aW9uIGJ5IGludGVy YWN0aW5nIHdpdGggYSBBQUENCj4gPiAgICBzZXJ2ZXIgYWdhaW4gdGhyb3VnaCBzb21lIG90aGVy IG1lY2hhbmlzbXMgd2hpY2ggYXJlIG5vdCBpbiB0aGUgc2NvcGUNCj4gPiAgICBvZiB0aGlzIGRv Y3VtZW50DQo+DQo+IEJ1dCBzdWNoIG1lY2hhbmlzbXMgZG8gbm90IGV4aXN0IGluIHRoZSBnZW5l cmFsIGNhc2UuIEkgd291bGQNCj4gcmVjb21tZW5kIHNpbXBseSByZXF1aXJpbmcgdGhhdCB0aGUg TkFTIG5lZWRzIHRvIHN0b3JlIHRoZQ0KPiBpbmZvcm1hdGlvbi4gSW4gYW55IGNhc2UsIGEgTkFT IGlzIHJlcXVpcmVkIHRvIGtub3cgYWJvdXQgdGhlIHNlc3Npb25zDQo+IGl0IGhhcy4NCg0KDQpP ay4gV2UnbGwgcmVwbGFjZSB0aGUgYWJvdmUgcGFyYWdyYXBoIGFzIGZvbGxvd3MuDQoNCg0KIiAg IFRoZSBOQVMgaXMgcmVxdWlyZWQgdG8gc3RvcmUgdGhlIGhvbWUgaW5mb3JtYXRpb24gZm9yIHRo ZSBtb2JpbGUgbm9kZSB3aGljaA0KIGlzIGF0dGFjaGVkIGludG8gaXRzZWxmIHNvIHRoYXQgaXQg Y2FuIHByb3ZpZGUgdGhlIGluZm9ybWF0aW9uIGF0IHRoZSB0aW1lIG9mDQogcmVjZWl2aW5nIHRo ZSBJbmZvcm1hdGlvbi1yZXF1ZXN0IGZyb20gdGhlIG1vYmlsZSBub2RlIg0KDQo+ID4gNC4yLiAg TkFTL0RIQ1AgUmVsYXkgQWdlbnQgQmVoYXZpb3INCj4gPg0KPiA+ICAgIFRoZSBOQVMgYW5kIHRo ZSBESENQIHJlbGF5IGFnZW50IGFyZSBhc3N1bWVkIHRvIGJlIGNvbGxvY2F0ZWQgaW4gdGhpcw0K PiA+ICAgIHNvbHV0aW9uLg0KPg0KPiBUaGlzIGxpbWl0YXRpb24gbmVlZHMgdG8gYmUgc3RhdGVk IHVwZnJvbnQsIGluIHRoZSBJbnRyb2R1Y3Rpb24uDQo+DQo+IChBbmQgdGhlIGxpbWl0YXRpb24g ZG9lcyBub3QgYXBwZWFyIHRvIGJlIGV4YWN0bHkgd2hhdCB5b3Ugc2F5IGFib3ZlLg0KPiBQcmVz dW1hYmx5IHR5cGUgMCBob21lIGFnZW50cyBjYW4gYmUgcmVxdWVzdGVkIHdpdGhvdXQgYW55IHJl bGF5cy4pDQoNCk9rLiBUaGUgZGVzY3JpcHRpb24gd2lsbCBiZSBtb3ZlZCB0byBlYXJsaWVyIHNl Y3Rpb24sIFNlY3Rpb24gMw0KYmVjYXVzZSBTZWN0aW9uIDEgb25seSBkZXNjcmliZXMgdGhlIG5l Y2Vzc2FpdHkgb2YgdGhlIHByb3Bvc2VkIHNjaGVtZQ0Kd2l0aG91dCBtZW50aW9uaW5nIERIQ1B2 NiBpdHNlbGYuIFRoZSBzZW50ZW5jZSBpcyBhbHNvIHJld3JpdGVkIGFzIHRoZQ0KYmVsb3c6DQoN CiIgVGhlIE5BUyBhbmQgdGhlIERIQ1AgcmVsYXkgYWdlbnQgYXJlIGFzc3VtZWQgdG8gYmUgY29s bG9jYXRlZCBpbiB0aGlzDQpzb2x1dGlvbi4gSW4gdGhlIG5ldHdvcmsgd2hlcmUgdGhlIE5BUyBp cyBub3QgY2xsb2NhdGVkIHdpdGggdGhlIHRoZSBESENQDQpyZWxheSBhZ2VudCwgdGhlIERIQ1Ag c2VydmVyIHdpbGwgcHJvdmlkZSB0aGUgaG9tZSBpbmZvcm1hdGlvbiB3aGljaCBoYXMNCg0KYmVl biBwcmVjb25maWd1cmVkIGJ5IHRoZSBhZG1pbmlzdHJhdG9yIG9yIHdoaWNoIGlzIGFjcXVpcmVk IHRocm91Z2ggdGhlDQoNCi0gSGlkZSBxdW90ZWQgdGV4dCAtDQptZWNoYW5pc20gdGhhdCBpcyBu b3QgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQuIg0KDQo+IEVkaXRvcmlhbDoNCj4NCj4gPiAg ICAgICAgICAgIE9QVElPTl9NSVA2LUhOSUQgKFRCRCkNCj4gRG8geW91IHJlYWxseSBoYXZlIHRv IG1peCB1bmRlcnNjb3JlIGFuZCBkYXNoIGluIHRoZSBzYW1lIHN5bWJvbD8NCg0KT2suIFdlJ2xs IGNoYW5nZSBvcHRpb24gY29kZXMgaW50byBPUFRJT05fTUlQNl9ITklEIGFuZCBPUFRJT05fTUlQ Nl9ITklORi4NCg0KLSBCZXN0IFJlZ2FyZHMsDQpIZWVqaW4uDQo= --===============1319505052== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1319505052==-- From mip6-bounces@ietf.org Wed Oct 31 03:30:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In7zd-0002Ux-Nj; Wed, 31 Oct 2007 03:28:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In7zb-0002Us-I0 for mip6@ietf.org; Wed, 31 Oct 2007 03:27:59 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In7zZ-0006Ak-5Y for mip6@ietf.org; Wed, 31 Oct 2007 03:27:59 -0400 X-AuditID: c10cb581-0000121800001430-50-47282e760443 Received: from stingray.eu.tieto.com ([192.176.143.13]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 08:27:50 +0100 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 08:27:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 Oct 2007 08:27:51 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DSMIP and IKEv2 Thread-Index: Acgbj4ur6oSm6MEiSRCZcgoFUgxI/A== From: To: , , X-OriginalArrivalTime: 31 Oct 2007 07:27:55.0165 (UTC) FILETIME=[8DB2FCD0:01C81B8F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d926c18f94eda32f0a6732c7d97b75a Cc: Subject: [Mip6] DSMIP and IKEv2 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1757168545==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1757168545== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81B8F.8C0E1979" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81B8F.8C0E1979 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vijay, Hesham I do not have the strength to go into each and every individual mail. Hesham, RFC 3948 and IKEv2 NAT traversal implies automatic update of the port numbers at the gateway side (node not behind a NAT) and=20 the DoS issues was considered when the RFC's was written.=20 The DoS attack requires the MiTM to continuously intercept all traffic from the MN and this kind of DoS there is no remedy against anyway. Let us not here question the NAT traversal mechs of IKEv2 and RFC 3948. Given the people who made it, it is safe ! Vijay: ESP tunneling works in both scenarios. I have tried to explain that in numerous earlier mails. In Situation 1 it requires extra tunneling : IPv4 UDP IPv6 ESP tunnel IPv6 payload and IKEv2 to know nothing about anything but the inner Ipv6 layer. I haven't understood Vidya's point why this doesn't work. This may change things, of course. But I think that it is both difficult to implement, unmodular and unwise not to build with IPSec and IKEv2 traversality mechanisms. In Situation 2, it requires some tricky interaction in between the MIP and the IKE/IPSec modules and then on top of that NAT and RFC 3948 nat traversal. I have tried to explain this in earlier emails. Now I am lazy and I am just copying from one of those: ****** > =3D> Yes I understand that, but I'm talking about this: > MN has address 10.0.0.1 > A. MN's NATTED address for IKE: 61.0.0.1 outer port 30000 > B. MN's NATTED address for DSMIP 61.0.0.100 outer port 40000 >=20 > Given that IKE doesn't know anything about B, can it still=20 > negotiate an SA > for DSMIP to send a BU? This is what I'm trying to understand. As much > detail on the IKE messages as possible please.=20 >=20 The IPSec SA that is used to protect the BU should be ESP transport on IPv6 level. Therefore IKE and IPSEc does not need to know anything about the outer UDP and IPv4 encapsulation of DSMIP. As IKE and IPSec does not need to know anything about the destination option and the routing header in standard MIP. IKE can negotiate ESP transport SAs given the right IPv6 selectors=20 (MN v6HoA and HA v6 address, protocol =3D MH of BU type)=20 in the IKE payload. Details: New IKE_SA and IPSec SA establishment situation: IKE messages, as they arrive at IKE/HA, appears as if the arrive from=20 the address set A destined for HA v4 address and port 4500. But transport SA negotiations is not dependent on the=20 endpoint addresses of the IKE connection. [Tunnel SAs however are !!] First there is the IKE_SA_INIT exchange (one message going back and forth) which establishes the IKE_SA credentials. The IKE_SA is established between address set A and HAv4 adresss and port 4500. Secondly there is the IKE_AUTH exchange (one message going back and forth). This exchange authenticates the first exchange as well as it negotiates=20 a child IPSEC SA, which in this case will be an ESP Ipv6 anchored transport IPSec SA. The IPSec SA is established based on the traffic selectors and the SA material (crypto algorithms and such) proposed by the initiator and included in the IKE message contents, the traffic selector will in this situation say MN v6HoA, HA v6 address and MH type BU. The IPSEC SA may also be established as a child to an existing IKE_SA, in this situation we only have one message exchange carrying the same selector set, SA material and more as above. In both cases, again to stress, the transport SA is by no means related to the characteristics of the underlying connection from address set A to HAv4 addresss and port 4500. > >=20 > > I am not entirely sure what you mean. If you mean whether IKE can > > negotiate > > an IPSEC ESP SA that takes an Ipv6 (or an Ipv4 packet)=20 > > packet, encrypts > > it and append and Ipv4 header, UDP header to DSMIP port and ESP=20 > > header (in reverse order), then I don't think that standard=20 > > IKE can do > > that over port 4500. > >=20 > > If that it what you mean, then I may suddenly understand why=20 > > we fail to > > understand one another. > > If you want the IPSec tunneled packets to look as if they=20 > > were destined > > for the DSMIP port, then forget about everything I have=20 > > said. >=20 > =3D> I'm not sure if we're on the same page here. You're saying=20 > that you can > send a BU secured with ESP, using DSMIP ports, correct? I.e.=20 > using the same > numbers above: > src =3D 10.0.0.1 > dst =3D HAv4 > UDP src port =3D 15000 dst port =3D DSMIPv6port > src6 =3D HoA > dst6 =3D HA6 > ESP > BU >=20 > Is this correct? My question above is how did you setup this SA? The SA is set-up as described above,=20 if it has not been set-up before the MN moved. Most likely it is set-up prior to the move. And in this situation, as it is not bound to anything=20 but the IPv6 addresses of the MN and the HA, it will survive the move until=20 the associated IKE_SA dies or the IPSec_SA needs to be re-keyed. The associated IKE_SA needs to be refreshed and updated=20 regularly as does all IPSec SA's under it. But it takes some time before IKE calls a peer out and=20 tears down the IKE_SA and the IPSEc SA's, so the SA should work after the movement. Yes there are corner cases, but let's not go there. All this is no different from standard Mobile Ipv6. Based on the BU, the HA may update the address of the MN end-point in the IKE_SA and the tunnel IPSec SAs. Further the HA (DSMIP code) will know whether=20 this is sufficient depending on whether there is NAT or not. If there is no NAT now, we are done. But the above step may* include changing the IKE_SA from an IKE_SA with NAT to an IKE_SA with no NAT as well as it may* include changing all RFC 3948 IPSEC tunnels associated with the IKE_SA to standard IPSEc tunnel SAs with no NAT. * for the situation where there was a NAT before the move. All this may also include changing the IP address version, if we are moving from Ipv4 to Ipv6 or the other way around. Now assume that there is a NAT now. The HA (DSMIP code) must make sure that the nature of the IKE_SA and the associated IPSec tunnel SAs is put in accordance with the fact that there's a NAT. If there was no NAT before this means changing the nature of the IKE_SA to an IKE_SA with NAT and changing all tunnel IPSEC SAs to RFC 3948 ones. The DSMIP does not need to keep track of whether there was a NAT before, only it must ensure that everything now is in accordance with the fact that there is a NAT. Now we are set to update the MN address and=20 port end-point information in the IKE_SA and in the RFC 3948 tunnel SAs.=20 This can be done in two ways: 1. IKE dead peer detection: If the MN sends an appropriately authenticated IKE dead peer detection packet [inserted: with appropriate NAT detection options] when it has received the BACK, this will automatically make the IKE at the HA update the IKE_SA and all associated IPSec 3948 Sas with the correct port and addressed of the MN as mapped by the NAT. This to the IKE entity at the HA corresponds to the situation whether the NAT has changed its mappings and the above reaction is a SHOULD in RFC 4306 (Section 2.23). 2. If there is payload to be sent towards the HA via an IPSEc 3948 tunnel SA, the receipt of this packet at the HA should result in the same updating being done by the HA. Now as a MN may not always have a IPSec tunnel SA to the HA, we cannot rely on 2. as a general mechanism. Further it should be stressed that this does not mean that the RTT delay for IPSec tunneled packets is only 1 RTT, because in the reverse direction from HA to MN, the ports and addresses are first being updated after the receipt of the tunneled packet at the HA, thus 1,5 RTT (not 2 RTT, but not 1 RTT either). Instead of doing all this complex (but standard compliant) fiddling, one could also use MOBIKE to move the endpoint of the IKE_SA and the associated tunnel SAs, but it may not be so nice to have to require MOBIKE (?) A third alternative is no rerun IKE entirely and re-negotiate all SAs after the BU/BACK exchange. Again the delay caused only impacts secure traffic. Karen ************************************************************************ ***************** Karen Egede Nielsen System Manager TietoEnator Corporation IP Solutions, Telecom & Media Skanderborgvej 232, 8260 Viby J, DK-Denmark Phone: +45 89385100 Fax: +45 89385101 Direct Phone / Mobile +45 25134336 E-mail: karen.nielsen@tietoenator.com ************************************************************************ ***************** www.tietoenator.com =20 Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You. ------_=_NextPart_001_01C81B8F.8C0E1979 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DSMIP and IKEv2

Hi Vijay, Hesham

I do not have the strength to go into = each and every individual mail.

Hesham, RFC 3948 and IKEv2 NAT = traversal implies automatic update
of the port numbers at the gateway = side (node not behind a NAT) and
the DoS issues was considered when the = RFC's was written.
The DoS attack requires the MiTM to = continuously intercept all traffic from the MN
and this kind of DoS there is no = remedy against anyway.

Let us not here question the NAT = traversal mechs of IKEv2 and RFC 3948. Given the people
who made it, it is safe !

Vijay:
ESP tunneling works in both scenarios. = I have tried to explain that in numerous
earlier mails.

In Situation 1 it requires extra = tunneling :
IPv4
UDP
IPv6
ESP tunnel
IPv6
payload

and IKEv2 to know nothing about = anything but the inner Ipv6 layer.

I haven't understood Vidya's point why = this doesn't work. This may change things, of course.

But I think that it is both difficult = to implement, unmodular and unwise not to
build with IPSec and IKEv2 = traversality mechanisms.

In Situation 2, it requires some tricky = interaction in between the MIP and the IKE/IPSec modules
and then on top of that NAT and RFC = 3948 nat traversal.
I have tried to explain this in = earlier emails. Now I am lazy and I am just copying from one of = those:

******

> =3D> Yes I understand = that, but I'm talking about this:
> MN has address = 10.0.0.1
> A. MN's NATTED address for = IKE: 61.0.0.1 outer port 30000
> B. MN's NATTED address for = DSMIP 61.0.0.100 outer port 40000
>
> Given that IKE doesn't know = anything about B, can it still
> negotiate an SA
> for DSMIP to send a BU? = This is what I'm trying to understand. As much
> detail on the IKE messages = as possible please.
>

The IPSec SA that is used to = protect the BU should be ESP transport on
IPv6 level.
Therefore IKE and IPSEc does not = need to know anything about the outer
UDP and IPv4 encapsulation of = DSMIP.
As IKE and IPSec does not need = to know anything about the destination
option and
the routing header in standard = MIP.

IKE can negotiate ESP transport = SAs given the right IPv6 selectors
(MN v6HoA and HA v6 address, = protocol =3D MH of BU type)
in the IKE payload.

Details:

New IKE_SA and IPSec SA = establishment situation:

IKE messages, as they arrive at = IKE/HA, appears as if the arrive from
the address set A destined for = HA v4 address and port 4500.
But transport SA negotiations is = not dependent on the
endpoint addresses of the IKE = connection. [Tunnel SAs however are !!]

First there is the IKE_SA_INIT = exchange (one message going back and
forth)
which establishes the IKE_SA = credentials. The IKE_SA is established
between
address set A and HAv4 adresss = and port 4500.

Secondly there is the IKE_AUTH = exchange (one message going back and
forth).
This exchange authenticates the = first exchange as well as it negotiates
a child IPSEC SA, which in this = case will be an ESP Ipv6 anchored
transport IPSec SA.
The IPSec SA is established = based on the traffic selectors and the SA
material (crypto algorithms and = such)
proposed by the initiator and = included in the IKE message contents, the
traffic selector will in this = situation say
MN v6HoA, HA v6 address and MH = type BU.

The IPSEC SA may also be = established as a child to an existing IKE_SA,
in this situation
we only have one message = exchange carrying the same selector set, SA
material and more as = above.

In both cases, again to stress, = the transport SA is by no means related
to the
characteristics of the = underlying connection from address set A to HAv4
addresss and port 4500.


>  >
>  > I am not = entirely sure what you mean. If you mean whether IKE can
>  > negotiate
>  > an IPSEC ESP SA = that takes an Ipv6 (or an Ipv4 packet)
>  > packet, = encrypts
>  > it and append = and Ipv4 header, UDP header to DSMIP port and ESP
>  > header (in = reverse order), then I don't think that standard
>  > IKE can = do
>  > that over port = 4500.
>  >
>  > If that it what = you mean, then I may suddenly understand why
>  > we fail = to
>  > understand one = another.
>  > If you want the = IPSec tunneled packets to look as if they
>  > were = destined
>  > for the DSMIP = port, then forget about everything I have
>  > said.
>
> =3D> I'm not sure if = we're on the same page here. You're saying
> that you can
> send a BU secured with ESP, = using DSMIP ports, correct? I.e.
> using the same
> numbers above:
> src =3D 10.0.0.1
> dst =3D HAv4
> UDP src port =3D 15000 dst = port =3D DSMIPv6port
> src6 =3D HoA
> dst6 =3D HA6
> ESP
> BU
>
> Is this correct? My = question above is how did you setup this SA?

The SA is set-up as described = above,
if it has not been set-up before = the MN moved.
Most likely it is set-up prior = to the move.
And in this situation, as it is = not bound to anything
but the IPv6 addresses of the MN = and the HA,
it will survive the move until =
the associated IKE_SA dies or = the IPSec_SA needs to be re-keyed.

The associated IKE_SA needs to be = refreshed and updated
regularly as does all IPSec SA's = under it. But
it takes some time before IKE = calls a peer out and
tears down the IKE_SA and the = IPSEc SA's, so the
SA should work after the = movement.
Yes there are corner cases, but = let's not go there.
All this is no different from = standard Mobile Ipv6.

Based on the BU, the HA may = update the address
of the MN end-point in the = IKE_SA and the tunnel IPSec SAs.
Further the HA (DSMIP code) will = know whether
this is sufficient depending on = whether there is NAT or not.

If there is no NAT now, we are = done. But the above step may* include
changing the
IKE_SA from an IKE_SA with NAT = to an IKE_SA with no NAT as well as it
may* include
changing all RFC 3948 IPSEC = tunnels associated with the IKE_SA to
standard IPSEc tunnel SAs
with no NAT.

* for the situation where there = was a NAT before the move.

All this may also include = changing the IP address version, if we are
moving from Ipv4
to Ipv6 or the other way = around.

Now assume that there is a NAT = now.

The HA (DSMIP code) must make = sure that the nature
of the IKE_SA and the associated = IPSec tunnel SAs is put in accordance
with the fact that there's a = NAT. If there was no NAT before this means
changing
the nature of the IKE_SA to an = IKE_SA with NAT and changing all tunnel
IPSEC SAs to RFC 3948 = ones.

The DSMIP does not need to keep = track of whether there was a NAT before,
only it must ensure that
everything now is in accordance = with the fact that there is a NAT.

Now we are set to update the MN = address and
port end-point information in = the IKE_SA and in
the RFC 3948 tunnel SAs.

This can be done in two = ways:

1. IKE dead peer = detection:

If the MN sends an appropriately = authenticated IKE dead peer detection
packet [inserted: with = appropriate NAT detection options] when it has received the BACK,
this will automatically make the = IKE at the HA update the IKE_SA and all
associated IPSec 3948 Sas with = the correct
port and addressed of the MN as = mapped by the NAT.

This to the IKE entity at the HA = corresponds to the situation whether
the NAT has changed its = mappings
and the above reaction is a = SHOULD in RFC 4306 (Section 2.23).

2. If there is payload to be sent = towards the HA via an IPSEc 3948
tunnel SA, the receipt of
this packet at the HA should = result in the same updating being done by
the HA.

Now as a MN may not always have a = IPSec tunnel SA to the HA, we cannot
rely on 2. as a general = mechanism.
Further it should be stressed = that this does not mean that the RTT delay
for IPSec tunneled packets is = only 1 RTT,
because in the reverse direction = from HA to MN, the ports and addresses
are first being updated after = the receipt
of the tunneled packet at the = HA, thus 1,5 RTT (not 2 RTT, but not 1 RTT
either).

Instead of doing all this complex = (but standard compliant) fiddling, one
could also use MOBIKE to move = the endpoint
of the IKE_SA and the associated = tunnel SAs, but it may not be so nice
to have to require MOBIKE = (?)

A third alternative is no rerun = IKE entirely and re-negotiate all SAs
after the BU/BACK exchange. = Again
the delay caused only impacts = secure traffic.

Karen

**********************************************************= *******************************
Karen Egede Nielsen
System Manager
TietoEnator Corporation
IP Solutions, Telecom & Media
Skanderborgvej 232, 8260 Viby J, DK-Denmark
Phone: +45 89385100
Fax: +45 89385101
Direct Phone / Mobile +45 25134336
E-mail: karen.nielsen@tietoenator.com
**********************************************************= *******************************
www.tietoenator.com 

Please note: = The information contained in this message may be legally privileged and = confidential and protected from disclosure. If the reader of this = message is not the intended recipient, you are hereby notified that any = unauthorised use, distribution or copying of this communication is = strictly prohibited. If you have received this communication in error, = please notify us immediately by replying to the message and deleting it = from your computer. Thank You.


------_=_NextPart_001_01C81B8F.8C0E1979-- --===============1757168545== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1757168545==-- From mip6-bounces@ietf.org Wed Oct 31 14:12:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InI20-0006OR-Mc; Wed, 31 Oct 2007 14:11:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InI1z-0006IX-19 for mip6@ietf.org; Wed, 31 Oct 2007 14:11:07 -0400 Received: from wr-out-0506.google.com ([64.233.184.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InI1o-00032v-Bb for mip6@ietf.org; Wed, 31 Oct 2007 14:11:02 -0400 Received: by wr-out-0506.google.com with SMTP id 70so130607wra for ; Wed, 31 Oct 2007 11:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; bh=ieSiWPFYJsN0FRGf8z43/VO8F6yNepRqopWpbXrmpXo=; b=oihyKZ+5qpLlIQNH42+OfCPjDyc17xKUbUGhQAzQTkQCffPXRMz+AWL3O5MDpdTajSwBdi7ysL4N4Y/+NdenexSbKaY3HY8XmiYie3fESPpkFgNR/GxL45nK1WzOefCZ/IeV5v6EyP4UBBb4Ik6YElhhazRMaZwtkaObUlg63FI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=cKOchEs+ThG+IWdBzacJalPqe8Ce2d09BmVK5QbWfAsKqU69zUqkmVYy6D8gW8XGMJORzGYw8usgJ52S9UIqKjxEyAfNOXA0UydryjJfwhYpTTxn6mZzyPqcOU07u8mH+tsIPP2DHGoJd9/WdEGshPEhAvyHtaSrlmSmqkgzRPM= Received: by 10.142.135.9 with SMTP id i9mr2192456wfd.1193854239578; Wed, 31 Oct 2007 11:10:39 -0700 (PDT) Received: by 10.70.117.20 with HTTP; Wed, 31 Oct 2007 11:10:39 -0700 (PDT) Message-ID: <18a603a60710311110k4acc17f4o6ea3257744f3c28f@mail.gmail.com> Date: Wed, 31 Oct 2007 19:10:39 +0100 From: "Pars Mutaf" To: int-area@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: mip6@ietf.org Subject: [Mip6] IP host pairing X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1301495511==" Errors-To: mip6-bounces@ietf.org --===============1301495511== Content-Type: multipart/alternative; boundary="----=_Part_10278_24866135.1193854239477" ------=_Part_10278_24866135.1193854239477 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline [Resending invitation - Thanks Jari Arkko for saying OK] IP host pairing problem statement In the current model of operation (phone number privacy obligates it), cell phone users exchange their phone numbers upon user contact. This model is likely to persist in IP telephony, yet under-exploited and can be extended using an IP protocol. Upon their meeting, an "IP host pairing" protocol can allow two cell phone users to: 1. Exchange their SIP URIs, mobile IPv6 home addresses, and possibly other information. 2. Establish an IPsec security association using IKEv2. under user control, i.e. _if accepted_ by the users. For example, one user will initiate a pairing request, and the target user's phone display the initiator user's human name and ask for approval. Since there is user contact, IKEv2 authentication can be less challenging than the general case. I.e., a global PKI hierarchy is probably not needed. Solutions like password-based IKEv2 authentication can be applied. Human name certificates can be applicable, certificate revocation may not be needed, and human name collisions may not be harmful in this context. Certificates may be signed by the cellular operators for example, or PGP-like web of trust solutions may be applicable. An IP-layer pairing solution can also allow for re-pairing or updating the pairing state through the Internet. The users may change their SIP URIs and/or Mobile IPv6 home addresses or other information. The users will need to update these informations without waiting until their next meeting. Or, they may need additional information which was not previously exchanged when there was user contact. == Interested people are welcome to the mailing list for this topic: (we are 20 people for the moment and need more especially from security and mobility areas) https://www1.ietf.org/mailman/listinfo/humanresolvers ------=_Part_10278_24866135.1193854239477 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline [Resending invitation - Thanks Jari Arkko for saying OK]


                  IP host pairing problem statement

In the current model of operation (phone number privacy obligates it),
cell phone users exchange their phone numbers upon user contact. This
model is likely to persist in IP telephony, yet under-exploited and can be
extended using an IP protocol. Upon their meeting, an "IP host pairing"
protocol can allow two cell phone users to:

  1. Exchange their SIP URIs, mobile IPv6 home addresses, and possibly
     other information.
  2. Establish an IPsec security association using IKEv2.

under user control, i.e. _if accepted_ by the users. For example, one
user will initiate a pairing request, and the target user's phone display
the initiator user's human name and ask for approval.

Since there is user contact, IKEv2 authentication can be less challenging
than the general case. I.e., a global PKI hierarchy is probably not
needed. Solutions like password-based IKEv2 authentication can be applied.
Human name certificates can be applicable, certificate revocation may not
be needed, and human name collisions may not be harmful in this context.
Certificates may be signed by the cellular operators for example, or
PGP-like web of trust solutions may be applicable.

An IP-layer pairing solution can also allow for re-pairing or updating
the pairing state through the Internet. The users may change their
SIP URIs and/or Mobile IPv6 home addresses or other information. The users
will need to update these informations without waiting until their next
meeting. Or, they may need additional information which was not previously
exchanged when there was user contact.

==
Interested people are welcome to the mailing list for this topic:
(we are 20 people for the moment and need more especially from security
and mobility areas)

https://www1.ietf.org/mailman/listinfo/humanresolvers

------=_Part_10278_24866135.1193854239477-- --===============1301495511== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1301495511==-- From mip6-bounces@ietf.org Wed Oct 31 18:54:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMQJ-0006RC-J4; Wed, 31 Oct 2007 18:52:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMQG-0006PT-Iq; Wed, 31 Oct 2007 18:52:28 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InMQG-0004Y8-2w; Wed, 31 Oct 2007 18:52:28 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id 65F23E9EDC; Wed, 31 Oct 2007 15:52:27 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20071031225227.65F23E9EDC@bosco.isi.edu> Date: Wed, 31 Oct 2007 15:52:27 -0700 (PDT) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: mip6@ietf.org, rfc-editor@rfc-editor.org Subject: [Mip6] RFC 5026 on Mobile IPv6 Bootstrapping in Split Scenario X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5026 Title: Mobile IPv6 Bootstrapping in Split Scenario Author: G. Giaretta, Ed., J. Kempf, V. Devarapalli, Ed. Status: Standards Track Date: October 2007 Mailbox: gerardog@qualcomm.com, kempf@docomolabs-usa.com, vijay.devarapalli@azairenet.com Pages: 28 Characters: 63138 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mip6-bootstrapping-split-07.txt URL: http://www.rfc-editor.org/rfc/rfc5026.txt A Mobile IPv6 node requires a Home Agent address, a home address, and IPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a Mobile IPv6 node can bootstrap this information from non-topological information and security credentials pre-configured on the Mobile Node. The solution defined in this document solves the split scenario described in the Mobile IPv6 bootstrapping problem statement in RFC 4640. The split scenario refers to the case where the Mobile Node's mobility service is authorized by a different service provider than basic network access. The solution described in this document is also generically applicable to any bootstrapping case, since other scenarios are more specific realizations of the split scenario. [STANDARDS TRACK] This document is a product of the Mobility for IPv6 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6