From mobike-bounces@machshav.com Thu Nov 01 21:47:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inlcu-0004y2-Uh for mobike-archive@lists.ietf.org; Thu, 01 Nov 2007 21:47:12 -0400 Received: from machshav.com ([198.180.150.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Inlcj-0002sw-Qq for mobike-archive@lists.ietf.org; Thu, 01 Nov 2007 21:47:07 -0400 Received: by machshav.com (Postfix, from userid 512) id 4A9455E2; Fri, 2 Nov 2007 01:46:41 +0000 (GMT) Received: from machshav.com (localhost [IPv6:::1]) by machshav.com (Postfix) with ESMTP id C272A5A7; Fri, 2 Nov 2007 01:46:38 +0000 (GMT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1BBBD5B3; Fri, 2 Nov 2007 01:46:34 +0000 (GMT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by machshav.com (Postfix) with ESMTP id AF374182 for ; Fri, 2 Nov 2007 01:46:31 +0000 (GMT) Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lA21kTtO026553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 Nov 2007 18:46:29 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lA21kT4F010767; Thu, 1 Nov 2007 18:46:29 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Nov 2007 18:46:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Nov 2007 18:46:26 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TS updates in MOBIKE Thread-Index: Acgc8i6S1HkJvYhqS3+HfTzyPE2Eqg== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 02 Nov 2007 01:46:28.0979 (UTC) FILETIME=[2FCE9430:01C81CF2] Cc: ipsec@ietf.org Subject: [Mobike] TS updates in MOBIKE X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Hi, RFC4555 only allows updates to tunnel endpoint addresses and not selectors, etc. Does anyone know why TS updates are not permitted? If MOBIKE allowed what an SA rekey would allow, what is the problem? Thanks, Vidya _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Nov 02 01:26:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inp2x-0004Up-Ft for mobike-archive@lists.ietf.org; Fri, 02 Nov 2007 01:26:19 -0400 Received: from machshav.com ([198.180.150.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Inp2m-0000Wy-CK for mobike-archive@lists.ietf.org; Fri, 02 Nov 2007 01:26:14 -0400 Received: by machshav.com (Postfix, from userid 512) id 07AED60D; Fri, 2 Nov 2007 05:25:55 +0000 (GMT) Received: from machshav.com (localhost [IPv6:::1]) by machshav.com (Postfix) with ESMTP id 676275BD; Fri, 2 Nov 2007 05:25:54 +0000 (GMT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 39BDA5BF; Fri, 2 Nov 2007 05:25:53 +0000 (GMT) Received: from smtp.piuha.net (unknown [193.234.218.130]) by machshav.com (Postfix) with ESMTP id A9D355AD for ; Fri, 2 Nov 2007 05:25:52 +0000 (GMT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 4D3851986C6; Fri, 2 Nov 2007 07:25:42 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id E547C19867C; Fri, 2 Nov 2007 07:25:41 +0200 (EET) Message-ID: <472AB4D5.6050809@piuha.net> Date: Fri, 02 Nov 2007 07:25:41 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: "Narayanan, Vidya" References: In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipsec@ietf.org, mobike@machshav.com Subject: Re: [Mobike] TS updates in MOBIKE X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Presumably because MOBIKE is a mobility and multihoming facility for IPsec clients and gateways, i.e., you can change the outer IP addresses. Its not a general SA renegotiation facility. Yes, it could be done, but I'm not sure that's really within the scope of the feature. Unless we are talking about extension to deal with transport mode, which has been something at least a few people were interested in. Jari Narayanan, Vidya kirjoitti: > Hi, > RFC4555 only allows updates to tunnel endpoint addresses and not > selectors, etc. Does anyone know why TS updates are not permitted? If > MOBIKE allowed what an SA rekey would allow, what is the problem? > > Thanks, > Vidya > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Nov 02 13:44:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io0Yy-0006go-Ek for mobike-archive@lists.ietf.org; Fri, 02 Nov 2007 13:44:08 -0400 Received: from machshav.com ([198.180.150.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Io0Yn-00072S-Ai for mobike-archive@lists.ietf.org; Fri, 02 Nov 2007 13:44:03 -0400 Received: by machshav.com (Postfix, from userid 512) id AD4A2627; Fri, 2 Nov 2007 17:43:39 +0000 (GMT) Received: from machshav.com (localhost [IPv6:::1]) by machshav.com (Postfix) with ESMTP id 049D75AE; Fri, 2 Nov 2007 17:43:37 +0000 (GMT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D9B465C2; Fri, 2 Nov 2007 17:43:33 +0000 (GMT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by machshav.com (Postfix) with ESMTP id 504665A8 for ; Fri, 2 Nov 2007 17:43:31 +0000 (GMT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lA2Hh7iC019654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Nov 2007 10:43:08 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lA2Hh4JB023550; Fri, 2 Nov 2007 10:43:06 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Nov 2007 10:43:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 2 Nov 2007 10:43:03 -0700 Message-ID: In-Reply-To: <472AB4D5.6050809@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mobike] TS updates in MOBIKE Thread-Index: AcgdEPPLpNWDqHT8QaGkDqNG2bCfqwAZGlpA References: <472AB4D5.6050809@piuha.net> From: "Narayanan, Vidya" To: "Jari Arkko" X-OriginalArrivalTime: 02 Nov 2007 17:43:05.0945 (UTC) FILETIME=[D3108C90:01C81D77] Cc: ipsec@ietf.org, mobike@machshav.com Subject: Re: [Mobike] TS updates in MOBIKE X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Hi Jari, > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Thursday, November 01, 2007 10:26 PM > To: Narayanan, Vidya > Cc: mobike@machshav.com; ipsec@ietf.org > Subject: Re: [Mobike] TS updates in MOBIKE > > Presumably because MOBIKE is a mobility and multihoming > facility for IPsec clients and gateways, i.e., you can change > the outer IP addresses. Its not a general SA renegotiation facility. > Yes, I understand that that is the purpose of MOBIKE. But, I don't see a good reason to prevent other updates from happening as part of that same exchange. For e.g., let's say that when my address changes, I want to update the SA (or rekey) to start encrypting some additional traffic (fitting different selector criteria) using the same SA - the initiator now has to do separate MOBIKE and rekeying exchanges, which is not really efficient. > Yes, it could be done, but I'm not sure that's really within > the scope of the feature. Unless we are talking about > extension to deal with transport mode, which has been > something at least a few people were interested in. > I think the above point of updating the SAs applies equally to transport and tunnel mode, but, extending MOBIKE for transport mode is independently useful in my view. Regards, Vidya > Jari > > Narayanan, Vidya kirjoitti: > > Hi, > > RFC4555 only allows updates to tunnel endpoint addresses and not > > selectors, etc. Does anyone know why TS updates are not > permitted? > > If MOBIKE allowed what an SA rekey would allow, what is the problem? > > > > Thanks, > > Vidya > > _______________________________________________ > > Mobike mailing list > > Mobike@machshav.com > > https://www.machshav.com/mailman/listinfo.cgi/mobike > > > > > > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Nov 02 18:00:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io4ZU-0000MU-D3 for mobike-archive@lists.ietf.org; Fri, 02 Nov 2007 18:00:56 -0400 Received: from machshav.com ([198.180.150.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Io4ZH-0002Q9-17 for mobike-archive@lists.ietf.org; Fri, 02 Nov 2007 18:00:51 -0400 Received: by machshav.com (Postfix, from userid 512) id A1499629; Fri, 2 Nov 2007 22:00:22 +0000 (GMT) Received: from machshav.com (localhost [IPv6:::1]) by machshav.com (Postfix) with ESMTP id E57F8610; Fri, 2 Nov 2007 22:00:20 +0000 (GMT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9871561B; Fri, 2 Nov 2007 22:00:19 +0000 (GMT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id D7D6A5B3 for ; Fri, 2 Nov 2007 22:00:16 +0000 (GMT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id lA2M00GI020665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Nov 2007 00:00:00 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id lA2DiEK8009079; Fri, 2 Nov 2007 15:44:14 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18219.10670.837747.9511@fireball.kivinen.iki.fi> Date: Fri, 2 Nov 2007 15:44:14 +0200 From: Tero Kivinen To: "Narayanan, Vidya" In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: ipsec@ietf.org, mobike@machshav.com Subject: [Mobike] TS updates in MOBIKE X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com X-Spam-Score: 1.9 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Narayanan, Vidya writes: > RFC4555 only allows updates to tunnel endpoint addresses and not > selectors, etc. Yes, as that was outside the charter of the mobike. > Does anyone know why TS updates are not permitted? It is already done by the IKEv2 protocol, with fast and efficient exchange called CREATE_CHILD_SA... I.e. if you need it simply, create new SA with new traffic selectors, and delete the old one. > If MOBIKE allowed what an SA rekey would allow, what is the problem? All traffic going through the SA would usually stop, as it would not know it needs to change the IP addresses, thus it would still be using the original addresses, and it wouldn't fit to the new SA. I.e. as the idea is that the for example TCP streams running inside the IPsec SA using mobike, keeps exactly same IP addresses all the time, so the TCP do not notice the movement at all. When outer addresses change, the inner addresses stay same, and TCP will only see those inner addresses it will stay happy. If those inner addresses would change then TCP streams running on old addresses would be broken and connections would be lost unless the TCP stack was also modified to update the addresses. So in mobike case there is no need to update the inner addresses, and if someone makes some real world scenario where such thing is needed CREATE_CHILD_SA will solve the problem for him... -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Nov 04 21:19:16 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IorYa-0004fw-PI for mobike-archive@lists.ietf.org; Sun, 04 Nov 2007 21:19:16 -0500 Received: from machshav.com ([198.180.150.44]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IorYa-0008F1-2f for mobike-archive@lists.ietf.org; Sun, 04 Nov 2007 21:19:16 -0500 Received: by machshav.com (Postfix, from userid 512) id 171F9622; Mon, 5 Nov 2007 02:19:00 +0000 (GMT) Received: from machshav.com (localhost [IPv6:::1]) by machshav.com (Postfix) with ESMTP id ECDCD61D; Mon, 5 Nov 2007 02:18:56 +0000 (GMT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 20738620; Mon, 5 Nov 2007 02:18:52 +0000 (GMT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by machshav.com (Postfix) with ESMTP id 4E789617 for ; Mon, 5 Nov 2007 02:18:48 +0000 (GMT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lA52Hrq5019444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 4 Nov 2007 18:17:53 -0800 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lA52HqSD026941; Sun, 4 Nov 2007 18:17:52 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Nov 2007 18:17:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 4 Nov 2007 18:17:49 -0800 Message-ID: In-Reply-To: <472B7BBA.90604@certicom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] RE: [Mobike] TS updates in MOBIKE Thread-Index: Acgdhyh46Ed7ifDcRp2Zf7CzlqGpGgByBkYg References: <472AB4D5.6050809@piuha.net> <472B7BBA.90604@certicom.com> From: "Narayanan, Vidya" To: "Chinh Nguyen" X-OriginalArrivalTime: 05 Nov 2007 02:17:52.0369 (UTC) FILETIME=[11A25610:01C81F52] Cc: ipsec@ietf.org, mobike@machshav.com, Jari Arkko Subject: Re: [Mobike] [IPsec] RE: TS updates in MOBIKE X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Chinh, Steve, Tero, Thanks for all the responses. I'm just taking Chinh's email here to make a few observations. > -----Original Message----- > From: Chinh Nguyen [mailto:cnguyen@certicom.com] > Sent: Friday, November 02, 2007 12:34 PM > To: Narayanan, Vidya > Cc: Jari Arkko; ipsec@ietf.org; mobike@machshav.com > Subject: Re: [IPsec] RE: [Mobike] TS updates in MOBIKE > > Efficiency is overrated. > Well, not that overrated over licensed wireless spectrum :) > But all joking aside, the UPDATE_SA notify payload is part of > an informational exchange. Informationals do not contain the > necessary payloads to "update an SA" such as TS, KE, and even > SA payloads. > Yes, that is true. I guess what I was really asking was what you were getting at immediately below. > The alternative is to allow the UPDATE_SA notify payload to > be part of a CREATE_CHILD_SA message. If so, it must be > further specified that there are now 2 ways to UPDATE_SA: a > regular end-point update via an informational, and a > end-point + TS + [etc.] update via a create child sa. > Yes, but, I'm not sure if that's a big deal. It is, after all, a notify payload and the processing of the payload itself doesn't change. So, in essence, we would just be lifting the mandate to only allow it to be carried in an informational exchange. > Since this is a reasonably major change to the MOBIKE spec, > which is already an RFC, you may need a compelling use-case scenario. > The use case that I presently have in mind is the following. IPsec is used in some cases to protect Mobile IPv6 (MIP6) signaling. Some systems differentiate between trusted accesses and untrusted accesses and while IPsec is always used for MIP6 signaling protection in both cases, additional data protection using IPsec may be needed over untrusted access networks (between the same endpoints). When a mobile is moving from a trusted to untrusted access, its IP address changes, but, it also, at the same time, needs to update its SA to start protecting all traffic. At the moment, the mobile, just to handle this handoff case, needs to do a MIP6 signaling exchange, a MOBIKE exchange and a CREATE_CHILD_SA exchange. The first two are unavoidable and can happen in parallel, while the third one has to occur after the MOBIKE exchange completes. This is a latency hit in the critical path that can be avoided if the UPDATE_SA notify payload can be part of the CREATE_CHILD_SA exchange. > A saving of 2 additional packets (for the extra rekey to > change the TS) may not be sufficient reason to blur the > current functional boundaries. > Well, depending on the environment we are talking about, byte savings and particularly latency becomes important. Does the removal (or relaxing) of these tight functional boundaries really cause any issue? If not, I think allowing this can really help some use cases like the above. Regards, Vidya > Chinh > > -- > http://www.certicom.com > > Narayanan, Vidya wrote: > > Hi Jari, > > > >> -----Original Message----- > >> From: Jari Arkko [mailto:jari.arkko@piuha.net] > >> Sent: Thursday, November 01, 2007 10:26 PM > >> To: Narayanan, Vidya > >> Cc: mobike@machshav.com; ipsec@ietf.org > >> Subject: Re: [Mobike] TS updates in MOBIKE > >> > >> Presumably because MOBIKE is a mobility and multihoming > facility for > >> IPsec clients and gateways, i.e., you can change the outer IP > >> addresses. Its not a general SA renegotiation facility. > >> > > > > Yes, I understand that that is the purpose of MOBIKE. But, I don't > > see a good reason to prevent other updates from happening > as part of > > that same exchange. For e.g., let's say that when my > address changes, > > I want to update the SA (or rekey) to start encrypting some > additional > > traffic (fitting different selector criteria) using the > same SA - the > > initiator now has to do separate MOBIKE and rekeying > exchanges, which > > is not really efficient. > > > >> Yes, it could be done, but I'm not sure that's really within the > >> scope of the feature. Unless we are talking about > extension to deal > >> with transport mode, which has been something at least a > few people > >> were interested in. > >> > > > > I think the above point of updating the SAs applies equally to > > transport and tunnel mode, but, extending MOBIKE for > transport mode is > > independently useful in my view. > > > > Regards, > > Vidya > > > > > >> Jari > >> > >> Narayanan, Vidya kirjoitti: > >>> Hi, > >>> RFC4555 only allows updates to tunnel endpoint addresses and not > >>> selectors, etc. Does anyone know why TS updates are not > >> permitted? > >>> If MOBIKE allowed what an SA rekey would allow, what is > the problem? > >>> > >>> Thanks, > >>> Vidya > >>> _______________________________________________ > >>> Mobike mailing list > >>> Mobike@machshav.com > >>> https://www.machshav.com/mailman/listinfo.cgi/mobike > >>> > >>> > >>> > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 05 02:24:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IowKB-0007OC-DA for mobike-archive@lists.ietf.org; Mon, 05 Nov 2007 02:24:43 -0500 Received: from machshav.com ([198.180.150.44]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IowKB-000697-1F for mobike-archive@lists.ietf.org; Mon, 05 Nov 2007 02:24:43 -0500 Received: by machshav.com (Postfix, from userid 512) id E0A4B631; Mon, 5 Nov 2007 07:24:06 +0000 (GMT) Received: from machshav.com (localhost [IPv6:::1]) by machshav.com (Postfix) with ESMTP id 4A2445A2; Mon, 5 Nov 2007 07:24:03 +0000 (GMT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D133961D; Mon, 5 Nov 2007 07:24:00 +0000 (GMT) Received: from mgw-ext12.nokia.com (smtp.nokia.com [131.228.20.171]) by machshav.com (Postfix) with ESMTP id 24A2B16E for ; Mon, 5 Nov 2007 07:23:58 +0000 (GMT) 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 lA57MbfJ001573; Mon, 5 Nov 2007 09:23:07 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 09:22:57 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 09:22:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Nov 2007 09:22:56 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mobike] [IPsec] RE: TS updates in MOBIKE Thread-Index: Acgdhyh46Ed7ifDcRp2Zf7CzlqGpGgByBkYgAAtBpWA= References: <472AB4D5.6050809@piuha.net><472B7BBA.90604@certicom.com> From: To: X-OriginalArrivalTime: 05 Nov 2007 07:22:58.0003 (UTC) FILETIME=[B0A46A30:01C81F7C] X-Nokia-AV: Clean Cc: ipsec@ietf.org, mobike@machshav.com Subject: Re: [Mobike] [IPsec] RE: TS updates in MOBIKE X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Vidya Narayanan wrote: > The use case that I presently have in mind is the following. IPsec > is used in some cases to protect Mobile IPv6 (MIP6) signaling. Some > systems differentiate between trusted accesses and untrusted > accesses and while IPsec is always used for MIP6 signaling > protection in both cases, additional data protection using IPsec may > be needed over untrusted access networks (between the same > endpoints). When a mobile is moving from a trusted to untrusted > access, its IP address changes, but, it also, at the same time, > needs to update its SA to start protecting all traffic. At the > moment, the mobile, just to handle this handoff case, needs to do a > MIP6 signaling exchange, a MOBIKE exchange and a CREATE_CHILD_SA > exchange. The first two are unavoidable and can happen in parallel, > while the third one has to occur after the MOBIKE exchange > completes. This is a latency hit in the critical path that can be > avoided if the UPDATE_SA notify payload can be part of the > CREATE_CHILD_SA exchange. If the IKE implementation supports window size larger than 1, can't the Informational exchange (with UPDATE_SA notify payload) and CREATE_CHILD_SA exchange occur in parallel, too? Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 05 09:12:33 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip2gr-0003Ue-Gw for mobike-archive@lists.ietf.org; Mon, 05 Nov 2007 09:12:33 -0500 Received: from machshav.com ([198.180.150.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip2gq-0007gA-9q for mobike-archive@lists.ietf.org; Mon, 05 Nov 2007 09:12:33 -0500 Received: by machshav.com (Postfix, from userid 512) id DE68E64E; Mon, 5 Nov 2007 14:12:30 +0000 (GMT) Received: from machshav.com (localhost [IPv6:::1]) by machshav.com (Postfix) with ESMTP id 9B26963F; Mon, 5 Nov 2007 14:12:28 +0000 (GMT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E9EAD641; Mon, 5 Nov 2007 14:12:27 +0000 (GMT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 38D1463F for ; Mon, 5 Nov 2007 14:12:25 +0000 (GMT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id lA5EC9Zs011927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Nov 2007 16:12:09 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id lA5EC6fl013090; Mon, 5 Nov 2007 16:12:06 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18223.9398.444891.399526@fireball.kivinen.iki.fi> Date: Mon, 5 Nov 2007 16:12:06 +0200 From: Tero Kivinen To: "Narayanan, Vidya" In-Reply-To: References: <472AB4D5.6050809@piuha.net> <472B7BBA.90604@certicom.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Cc: Chinh Nguyen , ipsec@ietf.org, mobike@machshav.com Subject: Re: [Mobike] [IPsec] RE: TS updates in MOBIKE X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com X-Spam-Score: -4.0 (----) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Narayanan, Vidya writes: > The use case that I presently have in mind is the following. IPsec is > used in some cases to protect Mobile IPv6 (MIP6) signaling. Some > systems differentiate between trusted accesses and untrusted accesses > and while IPsec is always used for MIP6 signaling protection in both > cases, additional data protection using IPsec may be needed over > untrusted access networks (between the same endpoints). When a mobile > is moving from a trusted to untrusted access, its IP address changes, > but, it also, at the same time, needs to update its SA to start > protecting all traffic. At the moment, the mobile, just to handle this > handoff case, needs to do a MIP6 signaling exchange, a MOBIKE exchange > and a CREATE_CHILD_SA exchange. The first two are unavoidable and can > happen in parallel, while the third one has to occur after the MOBIKE > exchange completes. This is a latency hit in the critical path that can > be avoided if the UPDATE_SA notify payload can be part of the > CREATE_CHILD_SA exchange. Why it cannot happen in paralleal with UPDATE_SA exchange? IKEv2 already has mechanisms defined for using bigger window for IKEv2, so you just need to enable using of window size of 2 or larger in the IKEv2, to be able to do UPDATE_SA and CREATE_CHILD_SA in paralleal, thus now latency hit at all. Or is there some other reason they cannot be done in paralleal? > Well, depending on the environment we are talking about, byte savings > and particularly latency becomes important. There is no latency problem, so the only problem is the extra 80 bytes sent and received. > Does the removal (or relaxing) of these tight functional boundaries > really cause any issue? If not, I think allowing this can really > help some use cases like the above. As there is already efficient ways to do that in the IKEv2, I do not see any reason to add another different way to get the same results only to save 160 bytes every time transition from trusted to untrusted network happens (most likely at maximum few times per day...) -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 06 20:32:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpZm7-0004oZ-Am for mobike-archive@lists.ietf.org; Tue, 06 Nov 2007 20:32:11 -0500 Received: from machshav.com ([198.180.150.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpZm3-0000Zh-P2 for mobike-archive@lists.ietf.org; Tue, 06 Nov 2007 20:32:11 -0500 Received: by machshav.com (Postfix, from userid 512) id 831DD5F1; Wed, 7 Nov 2007 01:32:07 +0000 (GMT) Received: from machshav.com (localhost [IPv6:::1]) by machshav.com (Postfix) with ESMTP id C59F2637; Wed, 7 Nov 2007 01:32:04 +0000 (GMT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2A60F633; Wed, 7 Nov 2007 01:32:00 +0000 (GMT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by machshav.com (Postfix) with ESMTP id 7BD4F5A9 for ; Wed, 7 Nov 2007 01:31:55 +0000 (GMT) Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lA71Vd1o014790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Nov 2007 17:31:39 -0800 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 lA71VZBE021733; Tue, 6 Nov 2007 17:31:35 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 17:31:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Nov 2007 17:31:33 -0800 Message-ID: In-Reply-To: <472F7734.4050503@certicom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] RE: [Mobike] TS updates in MOBIKE Thread-Index: Acgf5syB0YfBqdo9TNOEfZ7KUUGM3QA9o6Xw References: <472AB4D5.6050809@piuha.net> <472B7BBA.90604@certicom.com> <18223.9398.444891.399526@fireball.kivinen.iki.fi> <472F7734.4050503@certicom.com> From: "Narayanan, Vidya" To: "Chinh Nguyen" , "Tero Kivinen" X-OriginalArrivalTime: 07 Nov 2007 01:31:35.0452 (UTC) FILETIME=[EF49EDC0:01C820DD] Cc: ipsec@ietf.org, mobike@machshav.com Subject: Re: [Mobike] [IPsec] RE: TS updates in MOBIKE X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d > > > > Why it cannot happen in paralleal with UPDATE_SA exchange? IKEv2 > > already has mechanisms defined for using bigger window for > IKEv2, so > > you just need to enable using of window size of 2 or larger in the > > IKEv2, to be able to do UPDATE_SA and CREATE_CHILD_SA in paralleal, > > thus now latency hit at all. Or is there some other reason > they cannot > > be done in paralleal? > > A IKEv2 peer may choose to reject a CREATE_CHILD_SA if it > arrives from an "unknown" endpoint (SPIs + src/dst addresses > are used to track IKEv2 exchanges). In such case, the > CREATE_CHILD_SA will fail if a. the CREATE_CHILD_SA arrives > before the UPDATE_SA exchange or b. the CREATE_CHILD_SA > arrives while the peer is doing a route check to complete the > UPDATE_SA exchange. > Yes, this is what I was getting at. > However, this can be mitigated by having the IKEv2 peer use > only the SPIs to track IKEv2 exchanges and ignore src/dst addresses. > This gives the impression that the IP address to which the IKE_SA is tied is not important. That is the address that is going to serve as the tunnel endpoint for tunnel mode SAs and hence, has some consequence. I would think that typical implementations reject CREATE_CHILD_SA requests for rekeying an SA, sent from a different IP address than to which the IKE_SA is currently tied - is that not true? RFC4306 is not clear about this. Thanks, Vidya _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 07 04:48:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IphWF-0002p0-BX for mobike-archive@lists.ietf.org; Wed, 07 Nov 2007 04:48:19 -0500 Received: from machshav.com ([198.180.150.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IphWD-0000ot-6R for mobike-archive@lists.ietf.org; Wed, 07 Nov 2007 04:48:19 -0500 Received: by machshav.com (Postfix, from userid 512) id 03BC05E0; Wed, 7 Nov 2007 09:48:17 +0000 (GMT) Received: from machshav.com (localhost [IPv6:::1]) by machshav.com (Postfix) with ESMTP id 213B461D; Wed, 7 Nov 2007 09:48:15 +0000 (GMT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DA3E15E1; Wed, 7 Nov 2007 09:48:10 +0000 (GMT) Received: from mgw-ext13.nokia.com (smtp.nokia.com [131.228.20.172]) by machshav.com (Postfix) with ESMTP id 440985DE for ; Wed, 7 Nov 2007 09:48:08 +0000 (GMT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA79lqwL006908; Wed, 7 Nov 2007 11:47:53 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 11:47:08 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 11:47:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Nov 2007 11:47:07 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] RE: [Mobike] TS updates in MOBIKE Thread-Index: Acgf5syB0YfBqdo9TNOEfZ7KUUGM3QA9o6XwABFShoA= References: <472AB4D5.6050809@piuha.net> <472B7BBA.90604@certicom.com> <18223.9398.444891.399526@fireball.kivinen.iki.fi><472F7734.4050503@certicom.com> From: To: X-OriginalArrivalTime: 07 Nov 2007 09:47:08.0904 (UTC) FILETIME=[29CEA680:01C82123] X-Nokia-AV: Clean Cc: ipsec@ietf.org, mobike@machshav.com Subject: Re: [Mobike] [IPsec] RE: TS updates in MOBIKE X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Vidya Narayanan wrote: > This gives the impression that the IP address to which the IKE_SA is > tied is not important. That is the address that is going to serve > as the tunnel endpoint for tunnel mode SAs and hence, has some > consequence. I would think that typical implementations reject > CREATE_CHILD_SA requests for rekeying an SA, sent from a different > IP address than to which the IKE_SA is currently tied - is that not > true? RFC4306 is not clear about this. We faced this question when designing MOBIKE, and resolved it as follows (RFC 4555, Section 3.3): When an IPsec SA is created, the tunnel header IP addresses (and port, if doing UDP encapsulation) are taken from the IKE_SA, not the IP header of the IKEv2 message requesting the IPsec SA. The addresses in the IKE_SA are initialized from the IP header of the first IKE_AUTH request. In other words: the CREATE_CHILD_SA request is not rejected, and the reply is still sent back to the address the packet came from; but the tunnel endpoints are initialized from stored information (which can be updated by UPDATE_SA_ADDRESSES). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 07 09:12:33 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipldx-0004LE-4R for mobike-archive@lists.ietf.org; Wed, 07 Nov 2007 09:12:33 -0500 Received: from machshav.com ([198.180.150.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipldu-00026k-W1 for mobike-archive@lists.ietf.org; Wed, 07 Nov 2007 09:12:33 -0500 Received: by machshav.com (Postfix, from userid 512) id 89A47641; Wed, 7 Nov 2007 14:12:30 +0000 (GMT) Received: from machshav.com (localhost [IPv6:::1]) by machshav.com (Postfix) with ESMTP id C9A63610; Wed, 7 Nov 2007 14:12:28 +0000 (GMT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 34883617; Wed, 7 Nov 2007 14:12:27 +0000 (GMT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 6F10E60F for ; Wed, 7 Nov 2007 14:12:25 +0000 (GMT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id lA7ECBXN011948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Nov 2007 16:12:11 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id lA7EC7ux001481; Wed, 7 Nov 2007 16:12:07 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18225.51127.907222.10175@fireball.kivinen.iki.fi> Date: Wed, 7 Nov 2007 16:12:07 +0200 From: Tero Kivinen To: Chinh Nguyen In-Reply-To: <472F7734.4050503@certicom.com> References: <472AB4D5.6050809@piuha.net> <472B7BBA.90604@certicom.com> <18223.9398.444891.399526@fireball.kivinen.iki.fi> <472F7734.4050503@certicom.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 4 min Cc: ipsec@ietf.org, mobike@machshav.com Subject: Re: [Mobike] [IPsec] RE: TS updates in MOBIKE X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com X-Spam-Score: -4.0 (----) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Chinh Nguyen writes: > A IKEv2 peer may choose to reject a CREATE_CHILD_SA if it arrives from > an "unknown" endpoint (SPIs + src/dst addresses are used to track IKEv2 > exchanges). In such case, the CREATE_CHILD_SA will fail if a. the > CREATE_CHILD_SA arrives before the UPDATE_SA exchange or b. the > CREATE_CHILD_SA arrives while the peer is doing a route check to > complete the UPDATE_SA exchange. With proper mobike implementations there should not be any such problems. The outer addresses should not be used for policy enforcements, as it is using valid IKE SA to send that CREATE_CHILD_SA. If the CREATE_CHILD_SA arrives while doing return routability check, that should not cause any problems either. > However, this can be mitigated by having the IKEv2 peer use only the > SPIs to track IKEv2 exchanges and ignore src/dst addresses. If you are using mobike, you do ingore outer src/dst addresses anyways (or at least do not use them to enforce any kind of policy, you of course use them to detect movement etc). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 07 17:01:51 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipsy7-0003gX-S2 for mobike-archive@lists.ietf.org; Wed, 07 Nov 2007 17:01:51 -0500 Received: from machshav.com ([198.180.150.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipsy2-0004RE-LA for mobike-archive@lists.ietf.org; Wed, 07 Nov 2007 17:01:51 -0500 Received: by machshav.com (Postfix, from userid 512) id 59F8660D; Wed, 7 Nov 2007 22:01:46 +0000 (GMT) Received: from machshav.com (localhost [IPv6:::1]) by machshav.com (Postfix) with ESMTP id 16B53633; Wed, 7 Nov 2007 22:01:43 +0000 (GMT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9DF6560F; Wed, 7 Nov 2007 22:01:38 +0000 (GMT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id D1E825BB for ; Wed, 7 Nov 2007 22:01:34 +0000 (GMT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id lA7M00jO007066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2007 00:00:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id lA7EO3bU028620; Wed, 7 Nov 2007 16:24:03 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18225.51843.197031.515912@fireball.kivinen.iki.fi> Date: Wed, 7 Nov 2007 16:24:03 +0200 From: Tero Kivinen To: "Narayanan, Vidya" In-Reply-To: References: <472AB4D5.6050809@piuha.net> <472B7BBA.90604@certicom.com> <18223.9398.444891.399526@fireball.kivinen.iki.fi> <472F7734.4050503@certicom.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 4 min Cc: Chinh Nguyen , ipsec@ietf.org, mobike@machshav.com Subject: Re: [Mobike] [IPsec] RE: TS updates in MOBIKE X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com X-Spam-Score: -2.1 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Narayanan, Vidya writes: > This gives the impression that the IP address to which the IKE_SA is > tied is not important. That is the address that is going to serve as > the tunnel endpoint for tunnel mode SAs and hence, has some consequence. > I would think that typical implementations reject CREATE_CHILD_SA > requests for rekeying an SA, sent from a different IP address than to > which the IKE_SA is currently tied - is that not true? RFC4306 is not > clear about this. Check the RFC4555 instead of RFC4306. With mobike all existing IPsec SAs do get updated with new outer addresses with UPDATE_SA_ADDRESSES, so it does not matter what the outer IP adresses were when the IPsec SA was created. Also it is normal operation to get packets in with different outer address to IKE SA when using MOBIKE. This happens for example when you start to do UPDATE_SA_ADDRESSES, but can happen also with any other IKEv2 packet. This is because other end might not be able to send UPDATE_SA_ADDRESSES because it first needs to finish other ongoing exchange on the IKEv2 SA in case the window size is only 1. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike