From mobike-bounces@machshav.com Thu Sep 01 02:48:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAirh-0001qQ-Ao for mobike-archive@megatron.ietf.org; Thu, 01 Sep 2005 02:48:01 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28699 for ; Thu, 1 Sep 2005 02:47:59 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A1B71FB282; Thu, 1 Sep 2005 02:47:55 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5C5DAFB27C; Thu, 1 Sep 2005 02:47:53 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 41363FB27D; Thu, 1 Sep 2005 02:47:52 -0400 (EDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by machshav.com (Postfix) with ESMTP id 99165FB277 for ; Thu, 1 Sep 2005 02:47:51 -0400 (EDT) Received: from [10.0.0.182] (kame199.kame.net [203.178.141.199]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id C542A4C0BA; Thu, 1 Sep 2005 15:47:40 +0900 (JST) Date: Thu, 01 Sep 2005 15:47:35 +0900 From: Shinta Sugimoto To: Subject: Re: [Mobike] Issue 38: editorial comments (was: comments on draft-ietf-mobike-protocol-01.txt) In-Reply-To: References: Message-Id: <20050901154330.5082.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Hello Pasi, Thank you for the clarification. On Wed, 31 Aug 2005 14:36:09 +0300 wrote: > > Thanks for your comments! I've filed them as issues 38 and 39. > Quick answers to your editorial comments first: > > > - Section 2.3 (Changing addresses in IPsec SAs), 3rd bullet, > > it says "If there are outstanding IKEv2 requests, continues > > retransmitting them using the addresses in the IKE_SA (the new > > addresses)." It is unclear to me what the "outstanding IKEv2 > > requests" are. > > It means IKEv2 requests for which the initiator has not yet > received a reply (I'll try to clarify this in version -02). > This could happen if the need to change addresses appears > while we're doing e.g. rekeying or dead peer detection. OK, understood. Regards, Shinta _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 01 03:13:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAjG2-0008NY-5c for mobike-archive@megatron.ietf.org; Thu, 01 Sep 2005 03:13:10 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00925 for ; Thu, 1 Sep 2005 03:13:08 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E7DA3FB283; Thu, 1 Sep 2005 03:07:52 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2CEBFFB27C; Thu, 1 Sep 2005 03:07:50 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2EEF5FB27D; Thu, 1 Sep 2005 03:07:48 -0400 (EDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by machshav.com (Postfix) with ESMTP id 56157FB277 for ; Thu, 1 Sep 2005 03:07:46 -0400 (EDT) Received: from [10.0.0.182] (kame199.kame.net [203.178.141.199]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 9E3DB4C828; Thu, 1 Sep 2005 16:07:45 +0900 (JST) Date: Thu, 01 Sep 2005 16:07:40 +0900 From: Shinta Sugimoto To: Subject: Re: [Mobike] issue 39 (was: comments on draft-ietf-mobike-protocol-01.txt) In-Reply-To: References: Message-Id: <20050901154743.5085.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Hello again, On Wed, 31 Aug 2005 16:06:31 +0300 wrote: > Shinta Sugimoto writes: > > > > Hello, > > > > I read draft-ietf-mobike-protocol-01.txt and had following > > comments/questions. > > > > Technical Comments/Questions: > > > > - Section 2.3 (Changing addresses in IPsec SAs) I need > > clarification on how address change functions in MOBIKE. First > > of all, does UPDATE_SA_ADDRESSES take effect on more than one > > address changes ? Or it's supposed to update a single address? > > It updates the one source and one destination address in > IKE and IPsec SAs (the src/dst addresss that is currently > used for outgoing packets). OK. > > Probably I am confusing the purpose of UPDATE_SA_ADDRESSES > > and ADDITIONAL_*_ADDRESS. In my understanding, > > UPDATE_SA_ADDRESSES is for updating the preferred address, > > which means that IKE_SA and IPsec SA (only matched one) are > > the target of the address update. OTOH, ADDITIONAL_*_ADDRESS > > is for updating (requesting its peer to update) the peer > > address set. Do I get it right? > > Yes, I think you got it right (although the protocol document > does not currently use the term "peer address set"). This set is > used as input for address pair selection (on initiator side), > and possibly when responder address changes (although the > details need some clarification here...) OK. > > One more question: Should the initiator make all the CHILD_SAs > > inactive which are associated with the IKE_SA whose "pending_update" > > flag is set ? > > Why should it? (Continuing using those CHILD_SAs should work > just fine, since in 2401bis the responder uses only the SPI for > locating the inbound IPsec SA.) I see. I came to understand that there should be no problem with initiator sending/receiving packets with new address right after the address change. I need to synchronize my mind with RFC2401bis... Thank you for the clarification. Regards, Shinta _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 01 04:36:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAkYZ-0004GS-Jf for mobike-archive@megatron.ietf.org; Thu, 01 Sep 2005 04:36:24 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04189 for ; Thu, 1 Sep 2005 04:36:20 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1D26AFB283; Thu, 1 Sep 2005 04:36:21 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B446BFB27D; Thu, 1 Sep 2005 04:36:19 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C10F6FB281; Thu, 1 Sep 2005 04:36:17 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 79894FB27C for ; Thu, 1 Sep 2005 04:36:16 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j818ZbwF023986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2005 11:35:37 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j818ZbVP013509; Thu, 1 Sep 2005 11:35:37 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17174.48473.89004.76759@fireball.kivinen.iki.fi> Date: Thu, 1 Sep 2005 11:35:37 +0300 From: Tero Kivinen To: "Mohan Parthasarathy" Subject: Re: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection In-Reply-To: <005701c5ae91$c36d5360$7401a8c0@adithya> References: <00d501c5a2d9$fd280af0$6f01a8c0@adithya> <4302C505.4020703@piuha.net> <005201c5a45e$331ee130$6701a8c0@adithya> <17157.47348.409165.539403@fireball.kivinen.iki.fi> <430D976F.5060508@piuha.net> <005701c5ae91$c36d5360$7401a8c0@adithya> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: mobike@machshav.com, Pasi.Eronen@nokia.com, Jari Arkko X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Mohan Parthasarathy writes: > > One could also support ESP-based updates on devices > > that can do this, and say "this feature is not supported" > > on others -- we are still talking about a corner case. > > But people may have different opinions as to how > > important support for this is under all circumstances. > > > If you do IKEv2 like updates, then you need a separate PATH_TEST > message (outside the SA) so that PATH_TEST does not cause updates > to SA. By requiring an explicit update, we avoid a separate PATH_TEST > message. Is that an advantage ? I think it is advantage, if we do not need to implement separate PATH_TEST. It makes the protocol cleaner. The separate PATH_TEST has a feeling of a hack for me. Also it will localize the policy decisions on the IP-address changes to one place, so the policy will be same regardless why we change the address. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 01 08:27:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAoAa-0003yP-HR for mobike-archive@megatron.ietf.org; Thu, 01 Sep 2005 08:27:52 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00672 for ; Thu, 1 Sep 2005 08:27:46 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id CA0AAFB290; Thu, 1 Sep 2005 08:27:47 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6FBA1FB282; Thu, 1 Sep 2005 08:27:40 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DB785FB283; Thu, 1 Sep 2005 08:27:38 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id 18C63FB281 for ; Thu, 1 Sep 2005 08:27:38 -0400 (EDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j81CRVjU022061; Thu, 1 Sep 2005 15:27:34 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Sep 2005 15:27:33 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Sep 2005 15:27:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection Date: Thu, 1 Sep 2005 15:27:32 +0300 Message-ID: Thread-Topic: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection Thread-Index: AcWukdxVr4J8azeySA2qljz8izp+lQAXaorw From: To: , X-OriginalArrivalTime: 01 Sep 2005 12:27:32.0928 (UTC) FILETIME=[86F16C00:01C5AEF0] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Mohan Parthasarathy wrote: > If you do IKEv2 like updates, then you need a separate PATH_TEST > message (outside the SA) so that PATH_TEST does not cause updates to > SA. By requiring an explicit update, we avoid a separate PATH_TEST > message. Is that an advantage ? Actually, we need a separate PATH_TEST message even with the explicit update if we want to be able to do path testing at any time without the possibility of disrupting things. (And IMHO having a separate path test message that does nothing else would also make MOBIKE easier to understand, even though it may require a couple of more lines in code.) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 01 08:50:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAoWc-0007RW-1L for mobike-archive@megatron.ietf.org; Thu, 01 Sep 2005 08:50:38 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01449 for ; Thu, 1 Sep 2005 08:50:34 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E575CFB28D; Thu, 1 Sep 2005 08:50:33 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1D3AFFB283; Thu, 1 Sep 2005 08:50:30 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5570AFB285; Thu, 1 Sep 2005 08:50:28 -0400 (EDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by machshav.com (Postfix) with ESMTP id 66BDCFB282 for ; Thu, 1 Sep 2005 08:50:27 -0400 (EDT) Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 01 Sep 2005 05:50:25 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,160,1122879600"; d="scan'208"; a="8107354:sNHT22305252" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j81CoDQt026784; Thu, 1 Sep 2005 08:50:21 -0400 (EDT) Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 08:50:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection Date: Thu, 1 Sep 2005 08:50:19 -0400 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD685EC7B@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection Thread-Index: AcWpXG6PlSpK62b4RqqKyN+Aw5MTvgFln3Ew From: "Stephane Beaulieu (stephane)" To: "Jari Arkko" , "Tero Kivinen" X-OriginalArrivalTime: 01 Sep 2005 12:50:20.0280 (UTC) FILETIME=[B5F2C780:01C5AEF3] Cc: mobike@machshav.com, Mohan Parthasarathy , Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable I would prefer to avoid sending periodic probes (option 3). Even though the HW may not be capable of detecting and performing IP/port changes *today*, they will be able to do it in the future (especially if we make it a requirement for them). It's not like if Mobike is going to be mass deployed tomorrow. This is going to take a long time to bake and test. Start working with your HW vendors now, and let's do it right the first time. Those who ship before the HW is ready can document this corner case, or solve it via some less efficient SW workaround (for now). I'd rather take the performance hit for BETA than forever... I vote option 1. Stephane. > -----Original Message----- > From: mobike-bounces@machshav.com=20 > [mailto:mobike-bounces@machshav.com] On Behalf Of Jari Arkko > Sent: Thursday, August 25, 2005 6:03 AM > To: Tero Kivinen > Cc: Pasi.Eronen@nokia.com; Mohan Parthasarathy; mobike@machshav.com > Subject: Re: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT=20 > reboot detection >=20 > Tero Kivinen wrote: >=20 > >Thats why I am saying alternate 3 is better, as it requires less=20 > >changes or updates to the hardware. > > =20 > > > One could also support ESP-based updates on devices that can=20 > do this, and say "this feature is not supported" > on others -- we are still talking about a corner case. > But people may have different opinions as to how important=20 > support for this is under all circumstances. >=20 > --Jari >=20 > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 01 08:53:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAoZB-0000Wx-AK for mobike-archive@megatron.ietf.org; Thu, 01 Sep 2005 08:53:17 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01544 for ; Thu, 1 Sep 2005 08:53:12 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 64607FB292; Thu, 1 Sep 2005 08:53:14 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 549FAFB289; Thu, 1 Sep 2005 08:53:12 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 134E5FB28B; Thu, 1 Sep 2005 08:53:10 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id BEEC7FB285 for ; Thu, 1 Sep 2005 08:53:08 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j81CqUMi027300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2005 15:52:30 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j81CqUqt028031; Thu, 1 Sep 2005 15:52:30 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17174.63886.213335.775376@fireball.kivinen.iki.fi> Date: Thu, 1 Sep 2005 15:52:30 +0300 From: Tero Kivinen To: Subject: RE: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: mohanp@sbcglobal.net, mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > Actually, we need a separate PATH_TEST message even with the explicit > update if we want to be able to do path testing at any time without > the possibility of disrupting things. You mean the case, where we have decided to move to new address, but that new address breaks down after us testing it and after we sent update to it, but before we get reply back to it? I think we do not disrupt things more even if we use the IKE SA update message for testing the path. The path is already broken, so we cannot disrupt it more. After we get the IKE SA update message through, we have then already fixed the situation, with separate path test we still need to wait one more extra round trip to fix the situation (i.e we first use the PATH_TEST to find the working path, and then send the packet to that address, compared to using the IKE SA update message to do the path test, and that will immediately fix the situation when the correct path is found (or in case of unidirectional paths, then we need to wait the another round trip, i.e. for the second address update to reach the host)). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 01 08:56:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAocZ-00031l-Er for mobike-archive@megatron.ietf.org; Thu, 01 Sep 2005 08:56:47 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01662 for ; Thu, 1 Sep 2005 08:56:43 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5D52AFB290; Thu, 1 Sep 2005 08:56:45 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F32ABFB281; Thu, 1 Sep 2005 08:56:43 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B3FD4FB28D; Thu, 1 Sep 2005 08:56:41 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 0CE03FB281 for ; Thu, 1 Sep 2005 08:56:41 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 709D889852; Thu, 1 Sep 2005 15:56:37 +0300 (EEST) Message-ID: <4316FA91.2090307@piuha.net> Date: Thu, 01 Sep 2005 15:56:49 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 36: unacceptable addresses (was: confirming consensus on issues from Paris) References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: >Jari Arkko wrote: > > > >>Issue 36: Unacceptable addresses. There are cases where the >>initiator does not know which one of the retransmitted >>requests was really the one seen by the responder and resulted >>in the unacceptable address error. Pasi's solution for this is >>to send a new request in this (corner) case. >> >> > >(Back from vacation, and working on MOBIKE again...) > >I started editing the draft to make this change, but then >noticed the functionality is actually already there. Version >-01 says > > o If a new address change occurs while waiting for the > response, starts again from the first step (and ignores > responses to this UPDATE_SA_ADDRESSES request). > >So in the ambiguous situation (UPDATE_SA_ADDRESSES request has >been sent using several different src/dst addresses, and we >don't know which of them was unacceptable), it already says >we ignore the response and a new request is sent. > >(But I'll clarify this in -02; also the response is not really >totally ignored, just not processed by MOBIKE.) > > Works for me. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 01 09:05:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAolJ-00077x-64 for mobike-archive@megatron.ietf.org; Thu, 01 Sep 2005 09:05:49 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02129 for ; Thu, 1 Sep 2005 09:05:45 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 67125FB297; Thu, 1 Sep 2005 09:05:46 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 61BC7FB28A; Thu, 1 Sep 2005 09:05:42 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4BF60FB28D; Thu, 1 Sep 2005 09:05:40 -0400 (EDT) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id 644CDFB289 for ; Thu, 1 Sep 2005 09:05:39 -0400 (EDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j81D4tWo003010; Thu, 1 Sep 2005 16:04:55 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Sep 2005 16:05:35 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Sep 2005 16:05:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection Date: Thu, 1 Sep 2005 16:05:34 +0300 Message-ID: Thread-Topic: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection Thread-Index: AcWpXG6PlSpK62b4RqqKyN+Aw5MTvgFln3EwAABpuLA= From: To: X-OriginalArrivalTime: 01 Sep 2005 13:05:34.0420 (UTC) FILETIME=[D6D17940:01C5AEF5] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Stephane Beaulieu wrote: >=20 > I would prefer to avoid sending periodic probes (option 3). Note that these periodic probes are already present in normal IKEv2; option 3 just piggy-backs additional information (NAT detection payloads) to the same messages. =20 > Even though the HW may not be capable of detecting and > performing IP/port changes *today*, they will be able to do it > in the future (especially if we make it a requirement for > them). >=20 > It's not like if Mobike is going to be mass deployed tomorrow. > This is going to take a long time to bake and test. Start > working with your HW vendors now, and let's do it right the > first time. Those who ship before the HW is ready can > document this corner case, or solve it via some less efficient > SW workaround (for now). I'd rather take the performance hit > for BETA than forever... >=20 > I vote option 1. Since the same messages are sent in normal IKEv2 as well,=20 option 3 has a performance hit (on gateway load) only if=20 choosing it causes the users to change the timer values for DPD ("X" in my IETF63 slides; essentially how long to accept a situation where we have only outgoing traffic before getting suspicious and starting DPD).=20 This is what I was initially worried about as well (choosing=20 option 3 would lead to users choosing significantly smaller=20 values for X), but I'm not so sure anymore this would happen... Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 01 09:09:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAop5-0000JE-2h for mobike-archive@megatron.ietf.org; Thu, 01 Sep 2005 09:09:43 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02358 for ; Thu, 1 Sep 2005 09:09:38 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 0992BFB29F; Thu, 1 Sep 2005 09:09:35 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2BBFFFB28D; Thu, 1 Sep 2005 09:09:30 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C12E7FB290; Thu, 1 Sep 2005 09:09:28 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 6FF3EFB28B for ; Thu, 1 Sep 2005 09:09:27 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j81D7wq3023668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2005 16:07:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j81D7wLq024312; Thu, 1 Sep 2005 16:07:58 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17174.64814.336958.942462@fireball.kivinen.iki.fi> Date: Thu, 1 Sep 2005 16:07:58 +0300 From: Tero Kivinen To: "Stephane Beaulieu (stephane)" Subject: RE: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection In-Reply-To: <13E3DA8B48E17D4C96D261A36A23FCD685EC7B@xmb-rtp-208.amer.cisco.com> References: <13E3DA8B48E17D4C96D261A36A23FCD685EC7B@xmb-rtp-208.amer.cisco.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 15 min Cc: mobike@machshav.com, Pasi.Eronen@nokia.com, Mohan Parthasarathy , Jari Arkko X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Stephane Beaulieu \(stephane\) writes: > I would prefer to avoid sending periodic probes (option 3). We are sending them anyways if there is no traffic (IKE SA dead peer detection). The difference is that in option 1 those probes are only used to detect if the other peer is alive, and in option 3 they also make sure that the other end the correct NAT-T mapping in addition to test that the other peer is alive. The amount and timers for those packets should be same, but Pasi was little bit concerned that some adminstrators might want to configure the timers shorter in case we select option 3 to allow faster recovery of lost NAT mappings. I myself thing that this is such corner case that I do not think anybody will configure the timers shorter because of that. The option 3 packets will be few bytes bigger than the option 1 packets, but actually the size difference is lost in the padding (at least for AES cipher). Both of them are small, i.e. about 100 bytes (ip 20 + udp 8 + ike 28 + encr header 4 + iv 16 + empty or 8 byte notify plus padding 16 + 12). In addition to that IKE SA dead peer detection payloads, there is the normal NAT-T keepalive packets going on, which are again same in both option 1 and 3. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 01 09:53:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EApVl-0002Hg-Nc for mobike-archive@megatron.ietf.org; Thu, 01 Sep 2005 09:53:50 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04847 for ; Thu, 1 Sep 2005 09:53:46 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id BBF5CFB2A0; Thu, 1 Sep 2005 09:53:44 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 36F63FB29D; Thu, 1 Sep 2005 09:53:43 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7CBC6FB29E; Thu, 1 Sep 2005 09:53:41 -0400 (EDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by machshav.com (Postfix) with ESMTP id 3A204FB297 for ; Thu, 1 Sep 2005 09:53:40 -0400 (EDT) Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 01 Sep 2005 09:53:40 -0400 X-IronPort-AV: i="3.96,160,1122868800"; d="scan'208"; a="68650382:sNHT33390974" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j81DqpRP011005; Thu, 1 Sep 2005 09:53:36 -0400 (EDT) Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 09:53:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection Date: Thu, 1 Sep 2005 09:53:26 -0400 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD685EC8C@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection Thread-Index: AcWu9nZYGo+odCQDSdCixKMiEuHYywAAg2Gw From: "Stephane Beaulieu (stephane)" To: "Tero Kivinen" X-OriginalArrivalTime: 01 Sep 2005 13:53:27.0539 (UTC) FILETIME=[8754A430:01C5AEFC] Cc: mobike@machshav.com, Pasi.Eronen@nokia.com, Mohan Parthasarathy , Jari Arkko X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Tero, Pasi, Not really. DPD's are only sent *if* one suspects that the peer is no longer receiving pkts. What we've seen in the real world is that in a span of a 24 hour VPN RA connection, you'll probably only see about 20-100 DPD messages (which are usually clustered in groups during high web-usage times). So, DPDs are not periodic. Having said that, I don't see why probes would need to be periodic either. If you suspect the pkts aren't getting to your peer, then send the DPD/mobike probe. Otherwise, don't send anything. If we can agree on this, then I'm OK with probes. Stephane. > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi]=20 > Sent: Thursday, September 01, 2005 9:08 AM > To: Stephane Beaulieu (stephane) > Cc: Jari Arkko; Pasi.Eronen@nokia.com; Mohan Parthasarathy;=20 > mobike@machshav.com > Subject: RE: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT=20 > reboot detection >=20 > Stephane Beaulieu \(stephane\) writes: > > I would prefer to avoid sending periodic probes (option 3). >=20 > We are sending them anyways if there is no traffic (IKE SA=20 > dead peer detection). The difference is that in option 1=20 > those probes are only used to detect if the other peer is=20 > alive, and in option 3 they also make sure that the other end=20 > the correct NAT-T mapping in addition to test that the other=20 > peer is alive. The amount and timers for those packets should=20 > be same, but Pasi was little bit concerned that some=20 > adminstrators might want to configure the timers shorter in=20 > case we select option 3 to allow faster recovery of lost NAT=20 > mappings. I myself thing that this is such corner case that I=20 > do not think anybody will configure the timers shorter=20 > because of that. >=20 > The option 3 packets will be few bytes bigger than the option=20 > 1 packets, but actually the size difference is lost in the=20 > padding (at least for AES cipher). Both of them are small,=20 > i.e. about 100 bytes (ip 20 + udp 8 + ike 28 + encr header 4=20 > + iv 16 + empty or 8 byte notify plus padding 16 + 12). >=20 > In addition to that IKE SA dead peer detection payloads,=20 > there is the normal NAT-T keepalive packets going on, which=20 > are again same in both option 1 and 3. > -- > kivinen@safenet-inc.com >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 01 10:12:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EApo6-0007Ek-8A for mobike-archive@megatron.ietf.org; Thu, 01 Sep 2005 10:12:46 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06320 for ; Thu, 1 Sep 2005 10:12:44 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4FB19FB2A3; Thu, 1 Sep 2005 10:12:44 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 992C7FB29F; Thu, 1 Sep 2005 10:12:42 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 16054FB2A0; Thu, 1 Sep 2005 10:12:41 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id CAF6BFB29E for ; Thu, 1 Sep 2005 10:12:39 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6543089852; Thu, 1 Sep 2005 17:10:52 +0300 (EEST) Message-ID: <43170BEC.1050600@piuha.net> Date: Thu, 01 Sep 2005 17:10:52 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] issue 39 (was: comments on draft-ietf-mobike-protocol-01.txt) References: <20050901154743.5085.SHINTA@sfc.wide.ad.jp> In-Reply-To: <20050901154743.5085.SHINTA@sfc.wide.ad.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Looks like you can close #39, Pasi. --Jari Shinta Sugimoto wrote: >Hello again, > >On Wed, 31 Aug 2005 16:06:31 +0300 > wrote: > > > >>Shinta Sugimoto writes: >> >> >>>Hello, >>> >>>I read draft-ietf-mobike-protocol-01.txt and had following >>>comments/questions. >>> >>>Technical Comments/Questions: >>> >>>- Section 2.3 (Changing addresses in IPsec SAs) I need >>>clarification on how address change functions in MOBIKE. First >>>of all, does UPDATE_SA_ADDRESSES take effect on more than one >>>address changes ? Or it's supposed to update a single address? >>> >>> >>It updates the one source and one destination address in >>IKE and IPsec SAs (the src/dst addresss that is currently >>used for outgoing packets). >> >> > >OK. > > > >>>Probably I am confusing the purpose of UPDATE_SA_ADDRESSES >>>and ADDITIONAL_*_ADDRESS. In my understanding, >>>UPDATE_SA_ADDRESSES is for updating the preferred address, >>>which means that IKE_SA and IPsec SA (only matched one) are >>>the target of the address update. OTOH, ADDITIONAL_*_ADDRESS >>>is for updating (requesting its peer to update) the peer >>>address set. Do I get it right? >>> >>> >>Yes, I think you got it right (although the protocol document >>does not currently use the term "peer address set"). This set is >>used as input for address pair selection (on initiator side), >>and possibly when responder address changes (although the >>details need some clarification here...) >> >> > >OK. > > > >>>One more question: Should the initiator make all the CHILD_SAs >>>inactive which are associated with the IKE_SA whose "pending_update" >>>flag is set ? >>> >>> >>Why should it? (Continuing using those CHILD_SAs should work >>just fine, since in 2401bis the responder uses only the SPI for >>locating the inbound IPsec SA.) >> >> > >I see. I came to understand that there should be no problem with >initiator sending/receiving packets with new address right after >the address change. I need to synchronize my mind with RFC2401bis... >Thank you for the clarification. > > >Regards, >Shinta > >_______________________________________________ >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 Thu Sep 01 10:16:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EApru-0000Wh-C0 for mobike-archive@megatron.ietf.org; Thu, 01 Sep 2005 10:16:42 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06676 for ; Thu, 1 Sep 2005 10:16:40 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 45C63FB2A4; Thu, 1 Sep 2005 10:16:39 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 752A9FB28B; Thu, 1 Sep 2005 10:16:37 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9D140FB2A0; Thu, 1 Sep 2005 10:16:36 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 24FE2FB249 for ; Thu, 1 Sep 2005 10:16:36 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B1C1489852; Thu, 1 Sep 2005 17:16:17 +0300 (EEST) Message-ID: <43170D3B.8010104@piuha.net> Date: Thu, 01 Sep 2005 17:16:27 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 38: editorial comments References: <20050901154330.5082.SHINTA@sfc.wide.ad.jp> In-Reply-To: <20050901154330.5082.SHINTA@sfc.wide.ad.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit And close #38 too (and change the document as agreed). --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 01 10:33:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAq7s-0001yS-8d for mobike-archive@megatron.ietf.org; Thu, 01 Sep 2005 10:33:12 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07945 for ; Thu, 1 Sep 2005 10:33:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 70F59FB2AB; Thu, 1 Sep 2005 10:33:10 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4313EFB2A4; Thu, 1 Sep 2005 10:33:09 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9377EFB2A8; Thu, 1 Sep 2005 10:33:07 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id C2626FB2A4 for ; Thu, 1 Sep 2005 10:33:05 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5CC9989852; Thu, 1 Sep 2005 17:32:46 +0300 (EEST) Message-ID: <4317110F.4010502@piuha.net> Date: Thu, 01 Sep 2005 17:32:47 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi Eronen Subject: Re: [Mobike] confirming consensus on issues from Paris References: <4300DB19.30403@piuha.net> In-Reply-To: <4300DB19.30403@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit This is the result of our list + meeting consensus: o Issues 22, 24, 35, 37 closed as described in the Aug 15th e-mail that I sent. o Issue 36 is closed, but as Pasi noted later there's already some of this text in the draft. Some clarification will be in -02. o Issue 27 is closed, with revised text after Tero's comments. The final text is in my e-mails from Aug 16th and 25th. --Jari Jari Arkko wrote: > Issue 22: NAT preventation name. The current name > of the payload is NAT_PREVENTION, which has led > people to believe that we're actually disabling NATs. > Unfortunately, we can only achieve the detection of > a NAT and refuse to operate over such a link. The > proposal is to change the name of the payload (and > the corresponding error) to more descriptive ones. > I believe we can leave the details to the editor, > but names such as NO_NAT_POLICY and DISALLOW_NATS > have been suggested. > > Issue 24: This is a duplicate of issue 22. > > Issue 35: Version numbers -- the proposal that we > came up with in the meeting was that if we move the > mobike-supported negotiation to the second pair of > messages (see issue 37), then the length of the messages > is not such an issue. As a result, we can use plain payload > without a version number. > > Issue 36: Unacceptable addresses. There are cases > where the initiator does not know which one of the > retransmitted requests was really the one seen by the > responder and resulted in the unacceptable address > error. Pasi's solution for this is to send a new request > in this (corner) case. > > Issue 37: Move MOBIKE supported notification from > IKEv2_SA_INIT to AUTH exchange. Lessens the > fragmentation problem, and allows also per-use > mobike usage policy. > > Issue 27: I'll send a separate e-mail about this, > as text is needed. > > Issue 34: ---"---, as more discussion may be needed. > > Pasi's meeting slides for the issue discussion and > minutes can be found from > http://www3.ietf.org/proceedings/05aug/slides/mobike-2.pdf > http://www.machshav.com/pipermail/mobike/2005-August/000912.html > > Please respond by Monday 22nd August. > > --Jari > > _______________________________________________ > 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 Thu Sep 01 12:51:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAsHf-0006VQ-K2 for mobike-archive@megatron.ietf.org; Thu, 01 Sep 2005 12:51:27 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14478 for ; Thu, 1 Sep 2005 12:51:24 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5F251FB292; Thu, 1 Sep 2005 12:51:22 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1B88FFB28D; Thu, 1 Sep 2005 12:51:21 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9B4C5FB290; Thu, 1 Sep 2005 12:51:19 -0400 (EDT) Received: from web80606.mail.yahoo.com (web80606.mail.yahoo.com [66.218.79.95]) by machshav.com (Postfix) with SMTP id 5398AFB28B for ; Thu, 1 Sep 2005 12:51:18 -0400 (EDT) Received: (qmail 50685 invoked by uid 60001); 1 Sep 2005 16:51:17 -0000 Message-ID: <20050901165117.50683.qmail@web80606.mail.yahoo.com> Received: from [206.132.194.3] by web80606.mail.yahoo.com via HTTP; Thu, 01 Sep 2005 09:51:17 PDT Date: Thu, 1 Sep 2005 09:51:17 -0700 (PDT) From: Mohan Parthasarathy Subject: RE: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection To: Tero Kivinen , "Stephane Beaulieu (stephane)" In-Reply-To: <17174.64814.336958.942462@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Pasi.Eronen@nokia.com, Jari Arkko , Mohan Parthasarathy , mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 8bit > Stephane Beaulieu \(stephane\) writes: > > I would prefer to avoid sending periodic probes > (option 3). > > We are sending them anyways if there is no traffic > (IKE SA dead peer > detection). > Hmm.. with MOBIKE, you might also send to detect new paths or previously failed cheap-paths etc. So, if my current path is working, i might still send probes (not in the sense of DPD because the peer is not dead) to find out *good* path. Perhaps, this won't be sent at the frequency of DPD i guess. Note that there is a pontential for the information to become stale if you constantly probe so that you can be ready with the new path information when the next failure happens. But if you know a priori that you want to use a particular path and that path is not working currently, you switch immediately. Would this be more frequent than DPD ? Depends on the traffic pattern i guess. -mohan >The difference is that in option 1 those > probes are only > used to detect if the other peer is alive, and in > option 3 they also > make sure that the other end the correct NAT-T > mapping in addition to > test that the other peer is alive. The amount and > timers for those > packets should be same, but Pasi was little bit > concerned that some > adminstrators might want to configure the timers > shorter in case we > select option 3 to allow faster recovery of lost NAT > mappings. I > myself thing that this is such corner case that I do > not think anybody > will configure the timers shorter because of that. > > The option 3 packets will be few bytes bigger than > the option 1 > packets, but actually the size difference is lost in > the padding (at > least for AES cipher). Both of them are small, i.e. > about 100 bytes > (ip 20 + udp 8 + ike 28 + encr header 4 + iv 16 + > empty or 8 byte > notify plus padding 16 + 12). > > In addition to that IKE SA dead peer detection > payloads, there is the > normal NAT-T keepalive packets going on, which are > again same in both > option 1 and 3. > -- > kivinen@safenet-inc.com > _______________________________________________ > 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 Thu Sep 01 13:12:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAsbk-0004Au-6N for mobike-archive@megatron.ietf.org; Thu, 01 Sep 2005 13:12:12 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15491 for ; Thu, 1 Sep 2005 13:12:08 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 050AAFB299; Thu, 1 Sep 2005 13:12:08 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7D3F9FB290; Thu, 1 Sep 2005 13:12:05 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 262A5FB291; Thu, 1 Sep 2005 13:12:04 -0400 (EDT) Received: from web80606.mail.yahoo.com (web80606.mail.yahoo.com [66.218.79.95]) by machshav.com (Postfix) with SMTP id 712AEFB23C for ; Thu, 1 Sep 2005 13:12:03 -0400 (EDT) Received: (qmail 55221 invoked by uid 60001); 1 Sep 2005 17:12:03 -0000 Message-ID: <20050901171203.55219.qmail@web80606.mail.yahoo.com> Received: from [206.132.194.3] by web80606.mail.yahoo.com via HTTP; Thu, 01 Sep 2005 10:12:03 PDT Date: Thu, 1 Sep 2005 10:12:03 -0700 (PDT) From: Mohan Parthasarathy Subject: RE: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection To: Tero Kivinen , Pasi.Eronen@nokia.com In-Reply-To: <17174.63886.213335.775376@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: mohanp@sbcglobal.net, mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 8bit --- Tero Kivinen wrote: > Pasi.Eronen@nokia.com writes: > > Actually, we need a separate PATH_TEST message > even with the explicit > > update if we want to be able to do path testing at > any time without > > the possibility of disrupting things. > > You mean the case, where we have decided to move to > new address, but > that new address breaks down after us testing it and > after we sent > update to it, but before we get reply back to it? I > think we do not > disrupt things more even if we use the IKE SA update > message for > testing the path. The path is already broken, so we > cannot disrupt it > more. After we get the IKE SA update message > through, we have then > already fixed the situation, with separate path test > we still need to > wait one more extra round trip to fix the situation > (i.e we first use > the PATH_TEST to find the working path, and then > send the packet to > that address, compared to using the IKE SA update > message to do the > path test, and that will immediately fix the > situation when the > correct path is found (or in case of unidirectional > paths, then we > need to wait the another round trip, i.e. for the > second address > update to reach the host)). The only time this won't work is when the window is already closed. In that case, you retransmit with new address and then on getting a response, send an IKE message with the UPDATE_SA_ADDRESS payload. This is the same as sending PATH_TEST message and then use the results of PATH_TEST message for sending the IKE message. -mohan > -- > kivinen@safenet-inc.com > _______________________________________________ > 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 Sep 02 03:51:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB6KM-0001oV-RD for mobike-archive@megatron.ietf.org; Fri, 02 Sep 2005 03:51:11 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20851 for ; Fri, 2 Sep 2005 03:51:09 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id AD6EDFB281; Fri, 2 Sep 2005 03:51:07 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 57893FB249; Fri, 2 Sep 2005 03:50:59 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4853BFB266; Fri, 2 Sep 2005 03:50:56 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id EFD8FFB246 for ; Fri, 2 Sep 2005 03:50:54 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j827o7SD000265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Sep 2005 10:50:07 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j827nwEF001668; Fri, 2 Sep 2005 10:49:58 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17176.1062.123233.856635@fireball.kivinen.iki.fi> Date: Fri, 2 Sep 2005 10:49:58 +0300 From: Tero Kivinen To: "Stephane Beaulieu (stephane)" Subject: RE: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection In-Reply-To: <13E3DA8B48E17D4C96D261A36A23FCD685EC8C@xmb-rtp-208.amer.cisco.com> References: <13E3DA8B48E17D4C96D261A36A23FCD685EC8C@xmb-rtp-208.amer.cisco.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 7 min Cc: mobike@machshav.com, Pasi.Eronen@nokia.com, Mohan Parthasarathy , Jari Arkko X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Stephane Beaulieu \(stephane\) writes: > DPD's are only sent *if* one suspects that the peer is no longer > receiving pkts. What we've seen in the real world is that in a span of Actually no, it is sent if you suspect the other peer is dead, and you might suspect it being dead because multiple reasons. One reason is the lack of packets from the other end. Another reason might be the ICMP message or some other indication from the network. So if you suspect the other peer is dead, you test it with DPD packet. This handling is identical with normal IKEv2, and NAT-T, and both alternative 1 and 3. The only difference is that in alternative 3 you notice NAT box booting (or NAT mapping disappearing) by the lack of packets from the other end. I.e. you notice that you are not getting any responses back thus you start DPD as normally, and with this DPD you also request the other end to make sure that the IP address and port number the other peer is using matches the ones in the NAT mapping. > a 24 hour VPN RA connection, you'll probably only see about 20-100 DPD > messages (which are usually clustered in groups during high web-usage > times). If there is traffic going on in both directions then you do not ever see DPD packets. You only see DPD packets when you do not receive packets from the other end (either it being dead or it being idle). > So, DPDs are not periodic. True, the original description was misleading because of that. > Having said that, I don't see why probes would need to be periodic > either. If you suspect the pkts aren't getting to your peer, then send > the DPD/mobike probe. Otherwise, don't send anything. If we can agree > on this, then I'm OK with probes. This is the case with alternative 3. I.e. they are not periodic, they are only sent when the host behind NAT (initiator) detects that it is not receiving anything from the other end (perhaps because the NAT reboot or something), and that DPD will then also be used to fix the NAT mapping in the other peer (i.e. do the similar update that alternative 1 does for all packets, here we simply explicitly request the other end to fix the situation). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Sep 02 03:54:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB6Nb-0003We-6o for mobike-archive@megatron.ietf.org; Fri, 02 Sep 2005 03:54:31 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21026 for ; Fri, 2 Sep 2005 03:54:28 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E8692FB277; Fri, 2 Sep 2005 03:54:28 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 870D7FB266; Fri, 2 Sep 2005 03:54:27 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2C6F4FB277; Fri, 2 Sep 2005 03:54:25 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 21541FB249 for ; Fri, 2 Sep 2005 03:54:24 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j827qrXN010799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Sep 2005 10:52:53 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j827qrT6027577; Fri, 2 Sep 2005 10:52:53 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17176.1237.764588.986604@fireball.kivinen.iki.fi> Date: Fri, 2 Sep 2005 10:52:53 +0300 From: Tero Kivinen To: Mohan Parthasarathy Subject: RE: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection In-Reply-To: <20050901165117.50683.qmail@web80606.mail.yahoo.com> References: <17174.64814.336958.942462@fireball.kivinen.iki.fi> <20050901165117.50683.qmail@web80606.mail.yahoo.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 2 min Cc: mobike@machshav.com, Jari Arkko , Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Mohan Parthasarathy writes: > Hmm.. with MOBIKE, you might also send to detect new > paths or previously failed cheap-paths etc. So, if my > current path is working, i might still send probes > (not in the sense of DPD because the peer is not dead) > to find out *good* path. Perhaps, this won't be sent > at the frequency of DPD i guess. The actual packets might be identical, but they are not DPD packets, they are path test packets because of the function they perform is different... -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Sep 02 04:07:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB6aM-0000r4-DE for mobike-archive@megatron.ietf.org; Fri, 02 Sep 2005 04:07:42 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21631 for ; Fri, 2 Sep 2005 04:07:40 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 704CFFB27D; Fri, 2 Sep 2005 04:07:39 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B5DEFFB246; Fri, 2 Sep 2005 04:07:34 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BBE0CFB249; Fri, 2 Sep 2005 04:07:32 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 2787AFB240 for ; Fri, 2 Sep 2005 04:07:32 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 80BBC89852; Fri, 2 Sep 2005 11:07:30 +0300 (EEST) Message-ID: <4318084E.3080505@piuha.net> Date: Fri, 02 Sep 2005 11:07:42 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection References: <13E3DA8B48E17D4C96D261A36A23FCD685EC8C@xmb-rtp-208.amer.cisco.com> <17176.1062.123233.856635@fireball.kivinen.iki.fi> In-Reply-To: <17176.1062.123233.856635@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Mohan Parthasarathy , Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Tero Kivinen wrote: > >This is the case with alternative 3. I.e. they are not periodic, they >are only sent when the host behind NAT (initiator) detects that it is >not receiving anything (snip) > True. But I guess you could say that when your device is idle, the probes are being sent and are periodic... how much that matters is a matter of opinion. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Sep 02 07:56:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBA9T-0002Tu-FZ for mobike-archive@megatron.ietf.org; Fri, 02 Sep 2005 07:56:11 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01269 for ; Fri, 2 Sep 2005 07:56:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 828ADFB27C; Fri, 2 Sep 2005 07:56:09 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B4113FB249; Fri, 2 Sep 2005 07:56:07 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 055C4FB266; Fri, 2 Sep 2005 07:56:05 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by machshav.com (Postfix) with ESMTP id 57AA9FB246 for ; Fri, 2 Sep 2005 07:56:03 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 02 Sep 2005 04:56:03 -0700 X-IronPort-AV: i="3.96,163,1122879600"; d="scan'208"; a="338317999:sNHT34255056" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j82BtpQQ021750; Fri, 2 Sep 2005 04:55:57 -0700 (PDT) Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Sep 2005 07:55:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection Date: Fri, 2 Sep 2005 07:55:54 -0400 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD685EDDF@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection Thread-Index: AcWvkyF7jMl+3I/CRVeq+AF+RjYR1gAIXChw From: "Stephane Beaulieu (stephane)" To: "Tero Kivinen" X-OriginalArrivalTime: 02 Sep 2005 11:55:55.0767 (UTC) FILETIME=[468F6070:01C5AFB5] Cc: mobike@machshav.com, Pasi.Eronen@nokia.com, Mohan Parthasarathy , Jari Arkko X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable OK. Sounds like we are in agreement. If a host suspects that his peer is dead (or the path is dead), then he sends a DPD/mobike probe. It's worth noting that a host MAY use the arrival of a packet which seems to have wrong IP or port (due to possible NAT mapping change) to trigger this process. This IMO, is the best of both worlds. Stephane. =20 > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi]=20 > Sent: Friday, September 02, 2005 3:50 AM > To: Stephane Beaulieu (stephane) > Cc: Jari Arkko; Pasi.Eronen@nokia.com; Mohan Parthasarathy;=20 > mobike@machshav.com > Subject: RE: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT=20 > reboot detection >=20 > Stephane Beaulieu \(stephane\) writes: > > DPD's are only sent *if* one suspects that the peer is no longer=20 > > receiving pkts. What we've seen in the real world is that=20 > in a span=20 > > of >=20 > Actually no, it is sent if you suspect the other peer is=20 > dead, and you might suspect it being dead because multiple=20 > reasons. One reason is the lack of packets from the other=20 > end. Another reason might be the ICMP message or some other=20 > indication from the network. >=20 > So if you suspect the other peer is dead, you test it with DPD packet. > This handling is identical with normal IKEv2, and NAT-T, and=20 > both alternative 1 and 3. >=20 > The only difference is that in alternative 3 you notice NAT=20 > box booting (or NAT mapping disappearing) by the lack of=20 > packets from the other end. I.e. you notice that you are not=20 > getting any responses back thus you start DPD as normally,=20 > and with this DPD you also request the other end to make sure=20 > that the IP address and port number the other peer is using=20 > matches the ones in the NAT mapping. >=20 > > a 24 hour VPN RA connection, you'll probably only see about=20 > 20-100 DPD=20 > > messages (which are usually clustered in groups during high=20 > web-usage=20 > > times). >=20 > If there is traffic going on in both directions then you do=20 > not ever see DPD packets. You only see DPD packets when you=20 > do not receive packets from the other end (either it being=20 > dead or it being idle).=20 >=20 > > So, DPDs are not periodic. >=20 > True, the original description was misleading because of that. >=20 > > Having said that, I don't see why probes would need to be periodic=20 > > either. If you suspect the pkts aren't getting to your peer, then=20 > > send the DPD/mobike probe. Otherwise, don't send anything.=20 > If we can=20 > > agree on this, then I'm OK with probes. >=20 > This is the case with alternative 3. I.e. they are not=20 > periodic, they are only sent when the host behind NAT=20 > (initiator) detects that it is not receiving anything from=20 > the other end (perhaps because the NAT reboot or something),=20 > and that DPD will then also be used to fix the NAT mapping in=20 > the other peer (i.e. do the similar update that alternative 1=20 > does for all packets, here we simply explicitly request the=20 > other end to fix the situation). > -- > kivinen@safenet-inc.com >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Sep 02 07:59:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBACW-00041R-Bl for mobike-archive@megatron.ietf.org; Fri, 02 Sep 2005 07:59:20 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01369 for ; Fri, 2 Sep 2005 07:59:18 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 29633FB281; Fri, 2 Sep 2005 07:59:15 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 33183FB266; Fri, 2 Sep 2005 07:59:12 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 55CE2FB27C; Fri, 2 Sep 2005 07:59:10 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by machshav.com (Postfix) with ESMTP id B2ADBFB249 for ; Fri, 2 Sep 2005 07:59:09 -0400 (EDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 02 Sep 2005 04:59:09 -0700 X-IronPort-AV: i="3.96,163,1122879600"; d="scan'208"; a="338318486:sNHT31255476" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j82Bx30J019647; Fri, 2 Sep 2005 04:59:04 -0700 (PDT) Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Sep 2005 07:59:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection Date: Fri, 2 Sep 2005 07:59:04 -0400 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD685EDE0@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection Thread-Index: AcWvlXC+JkjZFypvQ92Sqg4W7Ke0IQAH9d+A From: "Stephane Beaulieu (stephane)" To: "Jari Arkko" , "Tero Kivinen" X-OriginalArrivalTime: 02 Sep 2005 11:59:05.0859 (UTC) FILETIME=[B7DD1D30:01C5AFB5] Cc: mobike@machshav.com, Mohan Parthasarathy , Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable > reboot detection >=20 > Tero Kivinen wrote: >=20 > > > >This is the case with alternative 3. I.e. they are not=20 > periodic, they=20 > >are only sent when the host behind NAT (initiator) detects=20 > that it is=20 > >not receiving anything (snip) > > > True. But I guess you could say that when your device is=20 > idle, the probes are being sent and are periodic... how much=20 > that matters is a matter of opinion. I don't understand why this has to be the case. With DPD, if you have no packets to send (i.e. you are idle), you don't do DPD. You only do DPD if you've sent X number of packets in the last Y seconds, and have not received any in the same span of time. The only situation where this ends up being periodic is when you're sending uni-directional traffic (which is rare in the real world). Stephane. >=20 > --Jari >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Sep 02 08:05:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBAIj-0006zF-FT for mobike-archive@megatron.ietf.org; Fri, 02 Sep 2005 08:05:45 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02134 for ; Fri, 2 Sep 2005 08:05:43 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D5103FB281; Fri, 2 Sep 2005 08:05:42 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5B153FB27D; Fri, 2 Sep 2005 08:05:41 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1BAE8FB27D; Fri, 2 Sep 2005 08:05:40 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 61FBAFB266 for ; Fri, 2 Sep 2005 08:05:39 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D420889852; Fri, 2 Sep 2005 15:05:37 +0300 (EEST) Message-ID: <4318401E.3040807@piuha.net> Date: Fri, 02 Sep 2005 15:05:50 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Stephane Beaulieu (stephane)" Subject: Re: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection References: <13E3DA8B48E17D4C96D261A36A23FCD685EDE0@xmb-rtp-208.amer.cisco.com> In-Reply-To: <13E3DA8B48E17D4C96D261A36A23FCD685EDE0@xmb-rtp-208.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pasi.Eronen@nokia.com, Mohan Parthasarathy , mobike@machshav.com, Tero Kivinen X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Stephane Beaulieu (stephane) wrote: >>True. But I guess you could say that when your device is >>idle, the probes are being sent and are periodic... how much >>that matters is a matter of opinion. >> >> >I don't understand why this has to be the case. With DPD, if you have >no packets to send (i.e. you are idle), you don't do DPD. You only do >DPD if you've sent X number of packets in the last Y seconds, and have >not received any in the same span of time. The only situation where >this ends up being periodic is when you're sending uni-directional >traffic (which is rare in the real world). > > Sorry, I wasn't quite correct. It seems that we have one timer for the case that there is traffic but we don't seem to be getting answers. If we have no traffic to send then we also have a timer, but the frequency of the probes is much higher, and perhaps less likely to be an issue. Finally, we have NAT keepalive but that's a separate issue. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Sep 07 06:05:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECwny-0007Ky-36 for mobike-archive@megatron.ietf.org; Wed, 07 Sep 2005 06:05:22 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08074 for ; Wed, 7 Sep 2005 06:05:19 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 0E242FB286; Wed, 7 Sep 2005 06:05:17 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 31776FB262; Wed, 7 Sep 2005 06:05:13 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 20C5EFB282; Wed, 7 Sep 2005 06:05:12 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id CEFD3FB24A for ; Wed, 7 Sep 2005 06:05:10 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 883A8898A1 for ; Wed, 7 Sep 2005 13:05:06 +0300 (EEST) Message-ID: <431EBB5E.7050405@piuha.net> Date: Wed, 07 Sep 2005 13:05:18 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mobike@machshav.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] issue 34 proposal X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit This is a suggestion for a potential resolution of issue 34. First, it seems that issue 34 is really about two separate problems: Part a: How do we survive NAT reboots? ESP vs. IKE update? Part b: Do we have a separate path test message or not? For part a, we have discussed probing frequencies and hardware issues. List discussion on the probing seems to converge to the conclusion that IKE-based messages for this purpose would be OK. I'm not sure if we have come to any conclusion on the hardware/implementation problem issues: There's a difference where IKE-based messaging does not need hardware support for ESP address changes. On the other hand we're not quite sure if lack of hardware support is an issue for the ESP-based approach either -- hardware evolves while deployment of new features is ongoing. And as we are talking about a special case to begin with, it may not be critical to have this support in all devices at all times. For part b, we have discussed whether the separate message is easier to describe or not, and whether the separate message can be sent in cases where additional IKE messages would have to be delayed due to the usual IKE processing rules (e.g., when connectivity breaks during an already ongoing movement operation). In the latter discussion, it seems that we came to the conclusion that if this happens, the worst that can happen is delay of one roundtrip. Based on the above I'd like to suggest that we pick IKE based messages for NAT reboot/change detection, and IKE messages for the path testing. Comments? I asked Pasi to write some text for this, see below. 2.X Changes in NAT Mappings IKEv2 performs Dead Peer Detection (DPD) if there has recently been only outgoing traffic on all of the SAs associated with the IKE_SA. In MOBIKE, these messages can also be used to detect if NAT mappings have changed (for example, if the keepalive internal is too long, or the NAT box is rebooted). More specifically, if both peers support both this specification and NAT Traversal, NAT_DETECTION_*_IP payloads MAY be included in any INFORMATIONAL request; if the request includes them, the responder MUST also include them in the response (but no other action is taken, unless otherwise specified). When the original initiator is behind a NAT, it SHOULD include these payloads in DPD messages, and compare the received NAT_DETECTION_DESTINATION_IP payload with the value from the previous UPDATE_SA_ADDRESSES response (or the IKE_SA_INIT response). If the values do not match, the IP address and/or port seen by the responder has changed, and the initiator SHOULD send UPDATE_SA_ADDRESSES as described in Section 2.3. When MOBIKE is in use, the host not behind a NAT SHOULD NOT use the dynamic updates specified in [IKEv2] Section 2.23 (where the peer address and port is updated from the last valid authenticated packet). This ensures that both peers have a consistent view of when addresses are to be changed, and prevents conflicts between MOBIKE-originated updates and NAT-T dynamic updates. It also means that an INFORMATIONAL exchange that does not contain UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be used for, e.g., testing whether a particular path works. (And remove Section 2.5 about separate PATH_TEST exchange.) _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Sep 07 10:18:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED0kl-00039W-Is for mobike-archive@megatron.ietf.org; Wed, 07 Sep 2005 10:18:19 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22388 for ; Wed, 7 Sep 2005 10:18:17 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 48204FB240; Wed, 7 Sep 2005 10:18:17 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D7E83FB24A; Wed, 7 Sep 2005 10:18:15 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DBEAFFB262; Wed, 7 Sep 2005 10:18:13 -0400 (EDT) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id 66003FB240 for ; Wed, 7 Sep 2005 10:16:57 -0400 (EDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j87EGrWH000930; Wed, 7 Sep 2005 17:16:54 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Sep 2005 17:16:51 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Sep 2005 17:16:52 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issue 34 proposal Date: Wed, 7 Sep 2005 17:16:55 +0300 Message-ID: Thread-Topic: [Mobike] issue 34 proposal Thread-Index: AcWzk95E9N22diIgQxy2jjFmBaFccAAIYUCg From: To: , X-OriginalArrivalTime: 07 Sep 2005 14:16:52.0059 (UTC) FILETIME=[CAF7E2B0:01C5B3B6] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Although I have earlier supported the "dynamic updates" approach, I'm starting to think that handling this with explicit IKE-level messages might be easier. Since we already send the DPD messages anyway, allowing them to contain NAT_DETECTION=20 payloads is very simple (and might be worth doing even if we=20 chose dynamic updates, the two are not totally exclusive). And if we do this, then there isn't that much need for a separate path test message, so perhaps it's simpler to leave it out... So I support your proposal on issue 34. Best regards, Pasi > -----Original Message----- > From: ext Jari Arkko > Sent: Wednesday, September 07, 2005 1:05 PM > To: mobike@machshav.com > Subject: [Mobike] issue 34 proposal >=20 >=20 > This is a suggestion for a potential resolution of issue 34. > First, it seems that issue 34 is really about two separate > problems: >=20 > Part a: How do we survive NAT reboots? ESP vs. IKE update? > Part b: Do we have a separate path test message or not? >=20 > For part a, we have discussed probing frequencies and hardware > issues. List discussion on the probing seems to converge to > the conclusion that IKE-based messages for this purpose would > be OK. I'm not sure if we have come to any conclusion on the > hardware/implementation problem issues: There's a difference > where IKE-based messaging does not need hardware support > for ESP address changes. On the other hand we're not quite > sure if lack of hardware support is an issue for the ESP-based > approach either -- hardware evolves while deployment of new > features is ongoing. And as we are talking about a special case > to begin with, it may not be critical to have this support in > all devices at all times. >=20 > For part b, we have discussed whether the separate message > is easier to describe or not, and whether the separate message > can be sent in cases where additional IKE messages would have > to be delayed due to the usual IKE processing rules (e.g., when > connectivity breaks during an already ongoing movement operation). > In the latter discussion, it seems that we came to the conclusion > that if this happens, the worst that can happen is delay of > one roundtrip. >=20 > Based on the above I'd like to suggest that we pick > IKE based messages for NAT reboot/change detection, > and IKE messages for the path testing. Comments? >=20 > I asked Pasi to write some text for this, see below. >=20 > 2.X Changes in NAT Mappings >=20 > IKEv2 performs Dead Peer Detection (DPD) if there has recently been > only outgoing traffic on all of the SAs associated with the IKE_SA. >=20 > In MOBIKE, these messages can also be used to detect if NAT > mappings have changed (for example, if the keepalive internal is > too long, or the NAT box is rebooted). More specifically, if both > peers support both this specification and NAT Traversal, > NAT_DETECTION_*_IP payloads MAY be included in any INFORMATIONAL > request; if the request includes them, the responder MUST also > include them in the response (but no other action is taken, unless > otherwise specified). >=20 > When the original initiator is behind a NAT, it SHOULD include > these payloads in DPD messages, and compare the received > NAT_DETECTION_DESTINATION_IP payload with the value from the > previous UPDATE_SA_ADDRESSES response (or the IKE_SA_INIT > response). If the values do not match, the IP address and/or port > seen by the responder has changed, and the initiator SHOULD send > UPDATE_SA_ADDRESSES as described in Section 2.3. >=20 > When MOBIKE is in use, the host not behind a NAT SHOULD NOT use the > dynamic updates specified in [IKEv2] Section 2.23 (where the peer > address and port is updated from the last valid authenticated > packet). This ensures that both peers have a consistent view of > when addresses are to be changed, and prevents conflicts between > MOBIKE-originated updates and NAT-T dynamic updates. It also means > that an INFORMATIONAL exchange that does not contain > UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be > used for, e.g., testing whether a particular path works. >=20 > (And remove Section 2.5 about separate PATH_TEST exchange.) _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From optimumintl@ilse.nl Wed Sep 07 11:15:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED1eO-0006tP-ES for mobike-archive@megatron.ietf.org; Wed, 07 Sep 2005 11:15:48 -0400 Received: from surf.ilse.net (pip0-2.ilse.nl [62.69.162.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25520 for ; Wed, 7 Sep 2005 11:15:45 -0400 (EDT) From: optimumintl@ilse.nl Received: (from www@localhost) by surf.ilse.net (8.12.9/8.11.1) id j87F8U73090597; Wed, 7 Sep 2005 17:08:30 +0200 (CEST) (envelope-from optimumintl@ilse.nl) Date: Wed, 7 Sep 2005 17:08:30 +0200 (CEST) Subject: Winning Notification/ Congratulation!!! X-Priority: 3 (Normal) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--948ff74ddbcf6218777b16ac840a6502" Content-Transfer-Encoding: 8bit Message-Id: <62.166.232.22_431f026e5de721126105710_optimumintl@ilse.nl> X-Checksum: aff89f87f759c50bb232ea30c2d8a516 X-Mailer: PEBKAC id:10T This is a multi-part message in MIME format. ----948ff74ddbcf6218777b16ac840a6502 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit OPTIMUM PROMOTIONS INTERNATIONAL Laan van Hoornwijck 55 2289 DG Rijswijk, Netherlands. Customerlijn: 0031-616 140 596 Fax: 31-84-719-0398 From: The Lottery Coordinator, International Promotions/Prize Award Department YOUR EMAIL WON THE 1ST CATEGORY EMAIL BALLOT AWARD FOR THE YEAR 2005, $1.5M (FINAL NOTICE). CONGRATULATION!!! Dear Winner, Congratulations as we bring to your notice the results of the Email Ballot Bonanza 'A' draw 1st Category of the OPTIMUM PROMOTIONS NL. We are happy to inform you that you have emerged a winner under the 1st Category, which is part of our promotional draws. The draws were held on the 1st of September 2005 and results are being officially announced today. Participants were selected through a computer ballot exercise where your email address attached to ticket number 025/078742; with serial number 05908 drew the lucky numbers 25-35-09-74-82, and consequently won the lottery in the First Category. REFERENCE NUMBER: NAP/2031/8161/04; BATCH NUMBER: R3/A312-59. You have therefore been approved of a lump sum pay out of $1.500,000.00(One million five hundred thousand Dollars) which is the winning payout for Category A winners.This is from the total prize money of 12,900,000.00 US Dollars (Twelve million, nine hundred thousand USD) shared among the international winners in our 1st - 4th categories. This lottery program was organized by our group of philanthropist promoted and sponsored by Mr. Bill Gates of Microsoft Inc, eminent personalities like the Sultan of Brunei, Multi Choice and other corporate organizations. This lottery program was organized to improve the use of computer software and for the benefit of every Microsoft user. We hope with part of your prize, you will support our enormous programs around the world as we wish to align you in advance. CONGRATULATIONS!!! NOTE that your funds is now deposited with funds remittance department and insured to the real value for transfer to you. Due to mix up of some numbers and names, we ask that you keep your winning information confidential until your claims has been processed and your money transfered to you. This is part of our security protocol to avoid double claiming or unscrupulous acts by participants / non participants in this lottery program. Please contact your claims agent immediately for due processing and remittance of your prize money to a designated account of your choice: CONTACT THE CLAIMS AGENTS!! Prize Remittance Dept, (Transfer Manager) Mr. Martin Goodman. (English Speaking). CUSTOMER-TEL: 0031-616 140 596. Fax: 0031-84-719-0398 REPLY-EMAIL: awardclaimsfile1@web2mail.com uptimumpromotionsnl@excite.com You are advised to contact the above by email or fax on receiving this notice, confirming by tel.contact with winning details.Failure to comply may warrant to disqualification.NOTE: Remember to quote your Batch and Reference number in every one of your correspondences with your claims agent.Congratulations once again from all our staff. For further explanations call the customers service telephone number above. Sincerely, Mrs.Christine De Voort THE LOTTERY CO-ORDINATOR, OPTIMUM PROMOTIONS NL. N.B: Any breach in confidentiality on the part of the winner will result to disqualification. Please note that all prize must be claimed within 14 days of reciept of this notification.Anybody under the age of 18 is automatically disqualified and can not proceed with claims. ----948ff74ddbcf6218777b16ac840a6502-- From mobike-bounces@machshav.com Wed Sep 07 12:21:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED2fY-0008OD-Pc for mobike-archive@megatron.ietf.org; Wed, 07 Sep 2005 12:21:04 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00024 for ; Wed, 7 Sep 2005 12:21:01 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B2159FB285; Wed, 7 Sep 2005 12:21:01 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8E1D7FB262; Wed, 7 Sep 2005 12:20:58 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EDEB3FB27D; Wed, 7 Sep 2005 12:20:55 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id 6A8E8FB24A for ; Wed, 7 Sep 2005 12:20:54 -0400 (EDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j87GKnTp024733; Wed, 7 Sep 2005 19:20:51 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Sep 2005 19:20:46 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Sep 2005 19:20:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40) Date: Wed, 7 Sep 2005 19:20:46 +0300 Message-ID: Thread-Topic: [Mobike] about draft-ietf-mobike-protocol-01.txt Thread-Index: AcWWmWnxqt88lU0tRnSCdDw03FSlpgdLo/1Q From: To: , X-OriginalArrivalTime: 07 Sep 2005 16:20:46.0716 (UTC) FILETIME=[1A5E83C0:01C5B3C8] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable My apologies for the long delay (I was on vacation most of August, and your email somehow slipped through my mind). I've now filed your comments as issue 40 (although since you had quite many comments, some of them might need separate issue numbers later). > - IMHO the WG should pay (again) more attention to its > charter: multihoming support is in it and to mention > multihoming just before explaining it has nothing to do with > the main scenario (and in fact with the document) is not > right. So please really fix the Abstract! Ok, I'll try to rephrase this in the next version. > - motivation 2nd paragraph: the "another example" is a very > limited view of what multihoming support needs. I'd like to > see the mobike protocol supporting simultaneous multiple peer > addresses. (I use the term "peer address" from pki4ipsec > documents because it could not confused with addresses in > traffic selectors). Since the first version of MOBIKE only deals with the outer (tunnel header) addresses, using multiple addresses for an IPsec SA simultaneously would probably mean either load balancing (explicitly ruled out in the WG charter) or sending copies of a single ESP packet over several paths (nobody has expressed any interest in this so far). But this is probably not what you meant... ? > - in 2.1 the NAT_XXX_IP notifications are mandatory because it > is the way the IP addresses in the IP header can be protected > against en route modification (what I called the transient NAT > attack). As the NAT_DETECTION_* could be interpreted as NAT-T > is supported the NAT prevention stuff was introduced... This > doesn't matter as soon as the IP addresses which will become > the initial peer addresses are reflected in an integrity > check. You're right, I forgot to show the NAT_PREVENTION notification in Section 2.1 (Section 2.6 did say that it's also included in IKE_SA_INIT). I'll fix this... > - in 2.2 why the ADDITIONAL_*_ADDRESS are limited to IKE_AUTH? > (2.4 is too far, please add a pointer to it) Ok, I'll add a pointer. > - IMHO we need the capability to remove addresses too. Some > care should be taken if we remove all or "important" > addresses. (same: pointer to 2.4) We already have the _capability_ to remove addresses (you send a new address list that does not contain the address you want to remove). The same capability could be implemented by more complex protocol mechanisms, but I don't currently see any reason to do so... >- 2.2 is enough to make the transport mode with mobike I-D=20 > applicable, so we should progress it? A good question, I'll leave this to the WG chairs... > - in 2.3 the SPD entries have to be updated too or expired SAs > will be renewed with wrong addresses. I'll add a clarification about this (where exactly the addressses have to be updated depends a lot on the implementation; e.g. the VPN client I have on my PC treats the IPsec tunnel as a virtual interface, and stores some of the information RFC 2401 would call "SPD" in what the implementation calls "routing table"). > - in 2.3 it should be clearer that NAT_XXX notifications are > mandatory. Do you mean the NAT_DETECTION_*_IP or NAT_PREVENTION notifications? Currently the idea is that if you support NAT-T, you include NAT_DETECTION_*_IP payloads; if you don't want NAT-T and do want the "NAT prevention" feature, you include NAT_PREVENTION (but not NAT_DETECTION_*). > - the link between 2.2 and 2.3 is not explained because the > new addresses are taken from the IP header. BTW I am afraid > the main scenario is the only supported scenario as a > consequence... Could you give a concrete example of a scenario that can't be done currently? > - another limitation of 2.3 is it cannot update selectively a > subset of SAs: again a case only is handled! Yes, and this is intentional (there was rough consensus in issue 8 to do it this way -- if you want to update a subset of SAs, you need to have several IKE_SAs). > - in 2.4 the case where there is a UPDATE_SA_ADDRESSES before > should be explained. I propose to explain that the current > peer addresses are IKE_SA parameters and the > UPDATE_SA_ADDRESSES echange defines their initial values. I'll try to clarify 2.4 in the next version.. > - the address update by the responder is a bit complex. It > seems to work but I am afraid it should be hard to explain, so > I'd like to get a simpler mechanism (IMHO this is again a > symptom of mobility vs multihoming problem of the document). I agree the explanation is quite complex. I'll try to simplify it in the next version... > - 2.7 is not sound with 2.3 (IMHO the problem is in the > wording because the way a NAT_PREVENTION can be associated > with a UPDATE_SA_ADDRESSES is clear but is not as described in > 2.7). BTW I agree with the TBD (:-). Quite right. I'll work on this for -02. > - section 4 misses one of the mobility specific points: the > initiator peer address (the MN care-of address) is > dynamic/unknown so could not be verified by the responder (VPN > server). This is why the protection performed by NAT_XXX > notifications are necessary (BTW I have no concern to make it > mandatory even in pure multihoming cases). I'm updating the security considerations section in the next version (see also issues 27 and 28), I hope the new text better takes this into account. > - the fact the ingress filtering works for UPDATE_SA_ADDRESSES > because the new addresses are from the IP header should be > mentioned (as a justification of this choice or as a > point-to-solve if the choice will be changed). Good point, I'll add this to the security considerations section. > - requires !=3D SHOULD. BTW I am against the idea to make MOBIKE > less efficient than mobility just because of the FUD of third > party flooding attacks. I fully agree that these flooding attacks are mostly FUD, and I would not mind changing the "return routability check SHOULD be done before updating.." to a MAY or something. But on the other hand, you can ignore the SHOULD if want, too. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 02:49:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDGDa-0005su-Ns for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 02:49:07 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02557 for ; Thu, 8 Sep 2005 02:49:04 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A88C0FB24A; Thu, 8 Sep 2005 02:48:57 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8921FFB24A; Thu, 8 Sep 2005 02:48:54 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DD74DFB262; Thu, 8 Sep 2005 02:48:52 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id 9CA01FB246; Thu, 8 Sep 2005 02:48:51 -0400 (EDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j886mju9028699; Thu, 8 Sep 2005 09:48:48 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Sep 2005 09:48:47 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Sep 2005 09:48:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issue 34 proposal Date: Thu, 8 Sep 2005 09:48:46 +0300 Message-ID: <1FBB41C090940F4C8BA37F3E536689199D8087@trebe101.NOE.Nokia.com> Thread-Topic: [Mobike] issue 34 proposal Thread-Index: AcWzk95E9N22diIgQxy2jjFmBaFccAAIYUCgACKjZpA= From: To: , , X-OriginalArrivalTime: 08 Sep 2005 06:48:46.0728 (UTC) FILETIME=[5C79B080:01C5B441] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Hi, there is one situation where "dynamic updates" has clear advantage: voice. Dynamic updates survives much faster=20 than IKE approach and call would stay up. And yes, I know VoIP is out of the scope, but still IPsec is used to protect voice traffic as well, and if possible that should be taken into account. Regards, Mika > -----Original Message----- > From: mobike-bounces@machshav.com [mailto:mobike-bounces@machshav.com] > Sent: 07 September, 2005 17:17 > To: jari.arkko@piuha.net; mobike@machshav.com > Subject: RE: [Mobike] issue 34 proposal >=20 >=20 > Although I have earlier supported the "dynamic updates" > approach, I'm starting to think that handling this with explicit > IKE-level messages might be easier. Since we already send > the DPD messages anyway, allowing them to contain NAT_DETECTION=20 > payloads is very simple (and might be worth doing even if we=20 > chose dynamic updates, the two are not totally exclusive). >=20 > And if we do this, then there isn't that much need for a separate > path test message, so perhaps it's simpler to leave it out... >=20 > So I support your proposal on issue 34. >=20 > Best regards, > Pasi >=20 > > -----Original Message----- > > From: ext Jari Arkko > > Sent: Wednesday, September 07, 2005 1:05 PM > > To: mobike@machshav.com > > Subject: [Mobike] issue 34 proposal > >=20 > >=20 > > This is a suggestion for a potential resolution of issue 34. > > First, it seems that issue 34 is really about two separate > > problems: > >=20 > > Part a: How do we survive NAT reboots? ESP vs. IKE update? > > Part b: Do we have a separate path test message or not? > >=20 > > For part a, we have discussed probing frequencies and hardware > > issues. List discussion on the probing seems to converge to > > the conclusion that IKE-based messages for this purpose would > > be OK. I'm not sure if we have come to any conclusion on the > > hardware/implementation problem issues: There's a difference > > where IKE-based messaging does not need hardware support > > for ESP address changes. On the other hand we're not quite > > sure if lack of hardware support is an issue for the ESP-based > > approach either -- hardware evolves while deployment of new > > features is ongoing. And as we are talking about a special case > > to begin with, it may not be critical to have this support in > > all devices at all times. > >=20 > > For part b, we have discussed whether the separate message > > is easier to describe or not, and whether the separate message > > can be sent in cases where additional IKE messages would have > > to be delayed due to the usual IKE processing rules (e.g., when > > connectivity breaks during an already ongoing movement operation). > > In the latter discussion, it seems that we came to the conclusion > > that if this happens, the worst that can happen is delay of > > one roundtrip. > >=20 > > Based on the above I'd like to suggest that we pick > > IKE based messages for NAT reboot/change detection, > > and IKE messages for the path testing. Comments? > >=20 > > I asked Pasi to write some text for this, see below. > >=20 > > 2.X Changes in NAT Mappings > >=20 > > IKEv2 performs Dead Peer Detection (DPD) if there has=20 > recently been > > only outgoing traffic on all of the SAs associated with=20 > the IKE_SA. > >=20 > > In MOBIKE, these messages can also be used to detect if NAT > > mappings have changed (for example, if the keepalive internal is > > too long, or the NAT box is rebooted). More=20 > specifically, if both > > peers support both this specification and NAT Traversal, > > NAT_DETECTION_*_IP payloads MAY be included in any INFORMATIONAL > > request; if the request includes them, the responder MUST also > > include them in the response (but no other action is=20 > taken, unless > > otherwise specified). > >=20 > > When the original initiator is behind a NAT, it SHOULD include > > these payloads in DPD messages, and compare the received > > NAT_DETECTION_DESTINATION_IP payload with the value from the > > previous UPDATE_SA_ADDRESSES response (or the IKE_SA_INIT > > response). If the values do not match, the IP address=20 > and/or port > > seen by the responder has changed, and the initiator SHOULD send > > UPDATE_SA_ADDRESSES as described in Section 2.3. > >=20 > > When MOBIKE is in use, the host not behind a NAT SHOULD=20 > NOT use the > > dynamic updates specified in [IKEv2] Section 2.23 (where the peer > > address and port is updated from the last valid authenticated > > packet). This ensures that both peers have a consistent view of > > when addresses are to be changed, and prevents conflicts between > > MOBIKE-originated updates and NAT-T dynamic updates. It=20 > also means > > that an INFORMATIONAL exchange that does not contain > > UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be > > used for, e.g., testing whether a particular path works. > >=20 > > (And remove Section 2.5 about separate PATH_TEST exchange.) > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 04:20:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDHdr-0001oN-0i for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 04:20:19 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06800 for ; Thu, 8 Sep 2005 04:20:16 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 163D1FB285; Thu, 8 Sep 2005 04:20:15 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 095F5FB277; Thu, 8 Sep 2005 04:20:11 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D3818FB27D; Thu, 8 Sep 2005 04:20:09 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 981D0FB262 for ; Thu, 8 Sep 2005 04:20:08 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 13FEB89848; Thu, 8 Sep 2005 11:20:01 +0300 (EEST) Message-ID: <431FF43C.4090103@piuha.net> Date: Thu, 08 Sep 2005 11:20:12 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mika.Joutsenvirta@nokia.com Subject: Re: [Mobike] issue 34 proposal References: <1FBB41C090940F4C8BA37F3E536689199D8087@trebe101.NOE.Nokia.com> In-Reply-To: <1FBB41C090940F4C8BA37F3E536689199D8087@trebe101.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Mika.Joutsenvirta@nokia.com wrote: >Hi, > >there is one situation where "dynamic updates" has clear >advantage: voice. Dynamic updates survives much faster >than IKE approach and call would stay up. > >And yes, I know VoIP is out of the scope, but still IPsec is used to >protect voice traffic as well, and if possible that should be taken >into account. > > VoIP is not necessarily out of scope. The group's intention is not to develop a protocol that goes together with a large set of optimizations for various scenarios (like in Mobile IPv6, for instance). But its still OK to choose our base mechanisms in a manner that covers as many application needs as possible, even VoIP. Re: specific issue with dynamic updates. If I recall Pasi's text correctly, it said "SHOULD NOT" for using the dynamic updates -- this means that it would still be possible for, say, a MOBIKE-based IMS phone to go against the SHOULD NOT and use the dynamic updates, given that the importance of this was determined to be high in the given environment. However, I would like to remind that the path testing, MOBIKE mechanisms, DPD, dynamic updates, other L3 mechanisms are not the best option when fast detection is desired. They are necessary when (a) there are no other mechanisms and when (b) problems occur somewhere along the path and not the first link. However, it seems to me that most practical problems occur on the first link and are detectable by L2 indications, IPv6 NUD and the like. Many path problems also have a more permanent nature (e.g., firewall doesn't let you through) that allows them to be avoided by the path test mechanism. In conclusion I think MOBIKE can work pretty efficiently when it comes to first link problems and permanent path problems. The dynamic updates would help, but only in the case of rebooting/forgetful NATs. (I'm not saying thats not important, just trying to quantify the impact.) --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 04:28:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDHlt-0003lx-Av for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 04:28:37 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07067 for ; Thu, 8 Sep 2005 04:28:33 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 0FEEDFB28A; Thu, 8 Sep 2005 04:28:35 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1E524FB24A; Thu, 8 Sep 2005 04:28:29 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C308EFB262; Thu, 8 Sep 2005 04:28:27 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 93B23FB249 for ; Thu, 8 Sep 2005 04:28:26 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j888S9U05051; Thu, 8 Sep 2005 10:28:09 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j888S8oX003364; Thu, 8 Sep 2005 10:28:08 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509080828.j888S8oX003364@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko Subject: Re: [Mobike] issue 34 proposal In-reply-to: Your message of Wed, 07 Sep 2005 13:05:18 +0300. <431EBB5E.7050405@piuha.net> Date: Thu, 08 Sep 2005 10:28:08 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: This is a suggestion for a potential resolution of issue 34. First, it seems that issue 34 is really about two separate problems: Part a: How do we survive NAT reboots? ESP vs. IKE update? Based on the above I'd like to suggest that we pick IKE based messages for NAT reboot/change detection, and IKE messages for the path testing. Comments? => note that I disagree. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 05:23:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDId4-0006ru-BI for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 05:23:34 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08997 for ; Thu, 8 Sep 2005 05:23:30 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3D80CFB282; Thu, 8 Sep 2005 05:23:27 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3D5ABFB262; Thu, 8 Sep 2005 05:23:25 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7141FFB282; Thu, 8 Sep 2005 05:23:23 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id D5C7AFB24A for ; Thu, 8 Sep 2005 05:23:22 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3F99089848; Thu, 8 Sep 2005 12:23:22 +0300 (EEST) Message-ID: <43200316.8020004@piuha.net> Date: Thu, 08 Sep 2005 12:23:34 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] issue 34 proposal References: <200509080828.j888S8oX003364@givry.rennes.enst-bretagne.fr> In-Reply-To: <200509080828.j888S8oX003364@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Francis Dupont wrote: >=> note that I disagree. > > Ok. Can you expand the above a bit with some reasons and/or alternative proposals? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 05:58:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDJBC-0005o5-JS for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 05:58:50 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10032 for ; Thu, 8 Sep 2005 05:58:47 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id CABBBFB28A; Thu, 8 Sep 2005 05:58:47 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E764BFB277; Thu, 8 Sep 2005 05:58:43 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3FE64FB282; Thu, 8 Sep 2005 05:58:42 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 57828FB262 for ; Thu, 8 Sep 2005 05:58:40 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j889wSU12128; Thu, 8 Sep 2005 11:58:28 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j889wSWP004315; Thu, 8 Sep 2005 11:58:28 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509080958.j889wSWP004315@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40) In-reply-to: Your message of Wed, 07 Sep 2005 19:20:46 +0300. Date: Thu, 08 Sep 2005 11:58:28 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: My apologies for the long delay (I was on vacation most of August, and your email somehow slipped through my mind). I've now filed your comments as issue 40 (although since you had quite many comments, some of them might need separate issue numbers later). > - IMHO the WG should pay (again) more attention to its > charter: multihoming support is in it and to mention > multihoming just before explaining it has nothing to do with > the main scenario (and in fact with the document) is not > right. So please really fix the Abstract! Ok, I'll try to rephrase this in the next version. => I am afraid that the issue is not only on wording, i.e., if you change the wording to reflect the real goal of the document we'll be in real trouble with the charter (the IETF one). > - motivation 2nd paragraph: the "another example" is a very > limited view of what multihoming support needs. I'd like to > see the mobike protocol supporting simultaneous multiple peer > addresses. (I use the term "peer address" from pki4ipsec > documents because it could not confused with addresses in > traffic selectors). Since the first version of MOBIKE only deals with the outer (tunnel header) addresses, using multiple addresses for an IPsec SA simultaneously would probably mean either load balancing (explicitly ruled out in the WG charter) or sending copies of a single ESP packet over several paths (nobody has expressed any interest in this so far). But this is probably not what you meant... ? => no, I mean simultaneous multiple peer addresses for different IPsec SAs, something I've called the SCTP model for multihoming (note it is not only for SCTP, it was just accurately described in SCTP documents). > - IMHO we need the capability to remove addresses too. Some > care should be taken if we remove all or "important" > addresses. (same: pointer to 2.4) We already have the _capability_ to remove addresses => this is covered by my "pointer to 2.4". IMHO some introduction statements will be fine... > - in 2.3 the SPD entries have to be updated too or expired SAs > will be renewed with wrong addresses. I'll add a clarification about this (where exactly the addressses have to be updated depends a lot on the implementation; e.g. the VPN client I have on my PC treats the IPsec tunnel as a virtual interface, and stores some of the information RFC 2401 would call "SPD" in what the implementation calls "routing table"). => IMHO there is no choice here: the formal description is in 2401bis and we have to use it even when we know the implementations have only to provide the same behavior and can use very different structures. > - in 2.3 it should be clearer that NAT_XXX notifications are > mandatory. Do you mean the NAT_DETECTION_*_IP or NAT_PREVENTION notifications? => yes. Currently the idea is that if you support NAT-T, you include NAT_DETECTION_*_IP payloads; if you don't want NAT-T and do want the "NAT prevention" feature, you include NAT_PREVENTION (but not NAT_DETECTION_*). => I agree, my concern is there must be no case without any NAT_XXX. > - the link between 2.2 and 2.3 is not explained because the > new addresses are taken from the IP header. BTW I am afraid > the main scenario is the only supported scenario as a > consequence... Could you give a concrete example of a scenario that can't be done currently? => multihoming. > - another limitation of 2.3 is it cannot update selectively a > subset of SAs: again a case only is handled! Yes, and this is intentional (there was rough consensus in issue 8 to do it this way -- if you want to update a subset of SAs, you need to have several IKE_SAs). => the problem is if the intention is not to support multihoming (and it seems there is a rough consensus about this :-) the charter must be updated. Or we'll get IESG comments or even an appeal about the document and its lack of support for anything else than mobility. > - requires != SHOULD. BTW I am against the idea to make MOBIKE > less efficient than mobility just because of the FUD of third > party flooding attacks. I fully agree that these flooding attacks are mostly FUD, and I would not mind changing the "return routability check SHOULD be done before updating.." to a MAY or something. But on the other hand, you can ignore the SHOULD if want, too. => as I wrote the term here is "requires" which is stronger than the SHOULD we agree about. Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 08:20:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDLOK-0002wV-DB for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 08:20:32 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15638 for ; Thu, 8 Sep 2005 08:20:30 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 86177FB262; Thu, 8 Sep 2005 08:20:26 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6865BFB246; Thu, 8 Sep 2005 08:20:22 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 556EBFB249; Thu, 8 Sep 2005 08:20:20 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 11B25FB23E for ; Thu, 8 Sep 2005 08:20:19 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j88CJLGg020920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2005 15:19:21 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j88CJDJV025455; Thu, 8 Sep 2005 15:19:13 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17184.11328.996959.416029@fireball.kivinen.iki.fi> Date: Thu, 8 Sep 2005 15:19:12 +0300 From: Tero Kivinen To: Jari Arkko Subject: [Mobike] issue 34 proposal In-Reply-To: <431EBB5E.7050405@piuha.net> References: <431EBB5E.7050405@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari Arkko writes: > Based on the above I'd like to suggest that we pick > IKE based messages for NAT reboot/change detection, > and IKE messages for the path testing. Comments? I am in favor of this approach... (as people already probably know :-) > 2.X Changes in NAT Mappings > > IKEv2 performs Dead Peer Detection (DPD) if there has recently been > only outgoing traffic on all of the SAs associated with the IKE_SA. > > In MOBIKE, these messages can also be used to detect if NAT > mappings have changed (for example, if the keepalive internal is > too long, or the NAT box is rebooted). More specifically, if both > peers support both this specification and NAT Traversal, > NAT_DETECTION_*_IP payloads MAY be included in any INFORMATIONAL > request; if the request includes them, the responder MUST also > include them in the response (but no other action is taken, unless > otherwise specified). > > When the original initiator is behind a NAT, it SHOULD include > these payloads in DPD messages, and compare the received > NAT_DETECTION_DESTINATION_IP payload with the value from the > previous UPDATE_SA_ADDRESSES response (or the IKE_SA_INIT > response). If the values do not match, the IP address and/or port > seen by the responder has changed, and the initiator SHOULD send > UPDATE_SA_ADDRESSES as described in Section 2.3. Note, that original initiator can also save one round trip (and one exchange) if he adds both NAT_DETECTION_*_IP and UPDATE_SA_ADDRESSES notifies to the DPD messages. If the addresses have not changed then the UPDATE_SA_ADDRESSES is no-op thus only wasting 8 bytes in the DPD. If the addresses have changed because of the NAT mapping disappearing, then it saves the one round trip and makes the recovery faster. I think it is already allowed in the protocol, as it does say that we proces UPDATE_SA_ADDRESSES notification in any INFORMATIONAL exchange, but it might be good to notify this possibility here too. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 09:02:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDM3F-0004Hg-NP for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 09:02:49 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18170 for ; Thu, 8 Sep 2005 09:02:47 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B9120FB262; Thu, 8 Sep 2005 09:02:47 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B054AFB246; Thu, 8 Sep 2005 09:02:46 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 83CE9FB249; Thu, 8 Sep 2005 09:02:45 -0400 (EDT) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id 8ACDAFB23E for ; Thu, 8 Sep 2005 09:02:44 -0400 (EDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j88D1BN0031839; Thu, 8 Sep 2005 16:01:17 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Sep 2005 16:02:41 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Sep 2005 16:02:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40) Date: Thu, 8 Sep 2005 16:02:36 +0300 Message-ID: Thread-Topic: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40) Thread-Index: AcW0XAGpDwAm5GEZT1akYG7euANcJwAGC6IA From: To: X-OriginalArrivalTime: 08 Sep 2005 13:02:40.0979 (UTC) FILETIME=[9854BA30:01C5B475] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Francis Dupont wrote: > > - motivation 2nd paragraph: the "another example" is a very > > limited view of what multihoming support needs. I'd like to > > see the mobike protocol supporting simultaneous multiple peer > > addresses. (I use the term "peer address" from pki4ipsec > > documents because it could not confused with addresses in > > traffic selectors). > =20 > Since the first version of MOBIKE only deals with the outer > (tunnel header) addresses, using multiple addresses for an IPsec > SA simultaneously would probably mean either load balancing > (explicitly ruled out in the WG charter) or sending copies of a > single ESP packet over several paths (nobody has expressed any > interest in this so far). > =20 > But this is probably not what you meant... ? > =20 > =3D> no, I mean simultaneous multiple peer addresses for different > IPsec SAs, something I've called the SCTP model for multihoming > (note it is not only for SCTP, it was just accurately described > in SCTP documents). The current protocol already supports this functionality. There=20 are several different ways how this functionality could be=20 implemented in the protocol, and in issue 8 there was rough consensus to choose one of them (if you want different addresses=20 for different IPsec SAs, you can do so by creating IKE_SAs). > > - the link between 2.2 and 2.3 is not explained because the > > new addresses are taken from the IP header. BTW I am afraid > > the main scenario is the only supported scenario as a > > consequence... > =20 > Could you give a concrete example of a scenario that can't be > done currently? > =20 > =3D> multihoming. I do not agree. We just chose to implement multihoming support=20 in a slightly different way than SCTP did. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 09:05:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDM6D-0004oV-3m for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 09:05:53 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18367 for ; Thu, 8 Sep 2005 09:05:50 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 2323AFB284; Thu, 8 Sep 2005 09:05:49 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DB31AFB246; Thu, 8 Sep 2005 09:05:42 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0AD23FB249; Thu, 8 Sep 2005 09:05:41 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id AD1B0FB23E; Thu, 8 Sep 2005 09:05:39 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j88D4gVQ016114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2005 16:04:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j88D4gdR024482; Thu, 8 Sep 2005 16:04:42 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17184.14058.518318.692302@fireball.kivinen.iki.fi> Date: Thu, 8 Sep 2005 16:04:42 +0300 From: Tero Kivinen To: Subject: RE: [Mobike] issue 34 proposal In-Reply-To: <1FBB41C090940F4C8BA37F3E536689199D8087@trebe101.NOE.Nokia.com> References: <1FBB41C090940F4C8BA37F3E536689199D8087@trebe101.NOE.Nokia.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 7 min Cc: mobike-bounces@machshav.com, mobike@machshav.com, jari.arkko@piuha.net X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Mika.Joutsenvirta@nokia.com writes: > there is one situation where "dynamic updates" has clear > advantage: voice. Dynamic updates survives much faster > than IKE approach and call would stay up. NAT rebooting will cause probably tens of seconds or even minutes of network lossage anyways, so that will normally cause people to break the connection and try to reconnect before that. I think most of my friends will usually allow about 2-10 seconds of bad connection in gsm phone, before they will hang up and redial trying to fix the problem. Most of the NATs boot much slower than that. > And yes, I know VoIP is out of the scope, but still IPsec is used to > protect voice traffic as well, and if possible that should be taken > into account. I do not think VoIP makes any difference here. If the NAT is really rebootted, it does not really matter if the connection is restored in 120 seconds (when the first ESP packet reaches the other end after NAT if finally up), or if it takes little longer before the DPD kicks in. Another case of causing NAT mapping disappearing is the too long keepalive, but that should not really matter in VoIP traffic, as there is traffic going on fast enough to keep the NAT mappings up. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 09:12:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDMCB-00071r-Cz for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 09:12:03 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18653 for ; Thu, 8 Sep 2005 09:12:01 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C0CADFB262; Thu, 8 Sep 2005 09:11:58 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D6384FB246; Thu, 8 Sep 2005 09:11:51 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D6F03FB249; Thu, 8 Sep 2005 09:11:49 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id AC7B2FB23E for ; Thu, 8 Sep 2005 09:11:47 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 82C1D89848; Thu, 8 Sep 2005 16:11:46 +0300 (EEST) Message-ID: <4320389E.7060908@piuha.net> Date: Thu, 08 Sep 2005 16:11:58 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Francis.Dupont@enst-bretagne.fr X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit This slipped away from my processing queue too, sorry Francis. Many thanks however for your careful review, it seems that you caught many issues that will lead to a document change. Here are some comments and suggested changes, embedded in Pasi's comments. >My apologies for the long delay (I was on vacation most of >August, and your email somehow slipped through my mind). I've >now filed your comments as issue 40 (although since you had >quite many comments, some of them might need separate issue >numbers later). > > > >>- IMHO the WG should pay (again) more attention to its >>charter: multihoming support is in it and to mention >>multihoming just before explaining it has nothing to do with >>the main scenario (and in fact with the document) is not >>right. So please really fix the Abstract! >> >> > >Ok, I'll try to rephrase this in the next version. > > Here's a suggested edit: ... MOBIKE is making it possible for a remote access VPN user to move from one address to another while keeping the connection with the VPN gateway active. => ... MOBIKE is making it possible for a remote access VPN user to maintain a single VPN connection with a gateway, despite moving from one address to another or having multiple addresses. Similar change in Section 1.1. Is there anything else Francis? >>- motivation 2nd paragraph: the "another example" is a very >>limited view of what multihoming support needs. I'd like to >>see the mobike protocol supporting simultaneous multiple peer >>addresses. (I use the term "peer address" from pki4ipsec >>documents because it could not confused with addresses in >>traffic selectors). >> >> > >Since the first version of MOBIKE only deals with the outer >(tunnel header) addresses, using multiple addresses for an IPsec >SA simultaneously would probably mean either load balancing >(explicitly ruled out in the WG charter) or sending copies of a >single ESP packet over several paths (nobody has expressed any >interest in this so far). > >But this is probably not what you meant... ? > > The charter indeed limits us to "failover" semantics of multihoming. But perhaps this is about IPsec SA movement granularity? But we already discussed that earlier and arrived at a conclusion. >>- in 2.1 the NAT_XXX_IP notifications are mandatory because it >>is the way the IP addresses in the IP header can be protected >>against en route modification (what I called the transient NAT >>attack). As the NAT_DETECTION_* could be interpreted as NAT-T >>is supported the NAT prevention stuff was introduced... This >>doesn't matter as soon as the IP addresses which will become >>the initial peer addresses are reflected in an integrity >>check. >> >> > >You're right, I forgot to show the NAT_PREVENTION notification >in Section 2.1 (Section 2.6 did say that it's also included in >IKE_SA_INIT). I'll fix this... > > Sounds clear. >>- in 2.2 why the ADDITIONAL_*_ADDRESS are limited to IKE_AUTH? >>(2.4 is too far, please add a pointer to it) >> >> > >Ok, I'll add a pointer. > > > >>- IMHO we need the capability to remove addresses too. Some >>care should be taken if we remove all or "important" >>addresses. (same: pointer to 2.4) >> >> > >We already have the _capability_ to remove addresses (you send a >new address list that does not contain the address you want to >remove). The same capability could be implemented by more >complex protocol mechanisms, but I don't currently see any >reason to do so... > > I tend to agree that its better to have a single mechanism that simply replaces the set, rather than a "diff" scheme. The latter would work better when there's a very large set of addresses, but I think simplicity is more valuable than covering that case. In any case, we know that there are other limitations in our technology for dealing with large address sets, e.g, ability to probe for a working address pair. > > >>- 2.2 is enough to make the transport mode with mobike I-D >>applicable, so we should progress it? >> >> > >A good question, I'll leave this to the WG chairs... > > I'm not sure I understand how Section 2.2 specifically helps this, but I think our plan is to work on the transport mode document once we finish this one -- and we are hopefully not too far off from this. I'd like to do a WGLC in September, and if all goes well we might be finished prior to Vancouver -- so get your transport mode document polished so that we'll have something to discuss there! >>- in 2.3 the SPD entries have to be updated too or expired SAs >>will be renewed with wrong addresses. >> >> > >I'll add a clarification about this (where exactly the >addressses have to be updated depends a lot on the >implementation; e.g. the VPN client I have on my PC treats the >IPsec tunnel as a virtual interface, and stores some of the >information RFC 2401 would call "SPD" in what the implementation >calls "routing table"). > > Hm. I'm not sure I understand this. I thought SPD deals with the unprotected packets, rather than the outer addresses, which I think we are working with. I would understand the SPD entry update if we were talking about transport mode, however. >>- in 2.3 it should be clearer that NAT_XXX notifications are >>mandatory. >> >> > >Do you mean the NAT_DETECTION_*_IP or NAT_PREVENTION >notifications? > >Currently the idea is that if you support NAT-T, you include >NAT_DETECTION_*_IP payloads; if you don't want NAT-T and do want >the "NAT prevention" feature, you include NAT_PREVENTION (but >not NAT_DETECTION_*). > > The document does not appear to say this explicitly, or did I miss something? Add text... >>- the link between 2.2 and 2.3 is not explained because the >>new addresses are taken from the IP header. BTW I am afraid >>the main scenario is the only supported scenario as a >>consequence... >> >> > >Could you give a concrete example of a scenario that can't be >done currently? > > I think the link is explained. 2.2 says: "The recipient stores this information, but no other action is taken at this time." Presumably somewhere else we have text about what to do when you fail. Suggestion: unless we can see a more specific case where there's a problem, I don't see a need to change the document on this point. >>- another limitation of 2.3 is it cannot update selectively a >>subset of SAs: again a case only is handled! >> >> > >Yes, and this is intentional (there was rough consensus in issue >8 to do it this way -- if you want to update a subset of SAs, >you need to have several IKE_SAs). > > Yes. Btw, we do intend to be fairly strict about re-opening issues. (We will re-open an issue only if we detect a new and/or serious technical problem.) >> - in 2.4 the case where there is a UPDATE_SA_ADDRESSES before >> should be explained. I propose to explain that the current >> peer addresses are IKE_SA parameters and the >> UPDATE_SA_ADDRESSES echange defines their initial values. >> >> > >I'll try to clarify 2.4 in the next version.. > > Ok. >>- the address update by the responder is a bit complex. It >>seems to work but I am afraid it should be hard to explain, so >>I'd like to get a simpler mechanism (IMHO this is again a >>symptom of mobility vs multihoming problem of the document). >> >> > >I agree the explanation is quite complex. I'll try to simplify >it in the next version... > > Ok. > > >>- 2.7 is not sound with 2.3 (IMHO the problem is in the >>wording because the way a NAT_PREVENTION can be associated >>with a UPDATE_SA_ADDRESSES is clear but is not as described in >>2.7). BTW I agree with the TBD (:-). >> >> > >Quite right. I'll work on this for -02. > > Ok. > > >>- section 4 misses one of the mobility specific points: the >>initiator peer address (the MN care-of address) is >>dynamic/unknown so could not be verified by the responder (VPN >>server). This is why the protection performed by NAT_XXX >>notifications are necessary (BTW I have no concern to make it >>mandatory even in pure multihoming cases). >> >> > >I'm updating the security considerations section in the next >version (see also issues 27 and 28), I hope the new text better >takes this into account. > > Good. > > >>- the fact the ingress filtering works for UPDATE_SA_ADDRESSES >>because the new addresses are from the IP header should be >>mentioned (as a justification of this choice or as a >>point-to-solve if the choice will be changed). >> >> > >Good point, I'll add this to the security considerations >section. > > Right. > > >>- requires != SHOULD. BTW I am against the idea to make MOBIKE >>less efficient than mobility just because of the FUD of third >>party flooding attacks. >> >> > >I fully agree that these flooding attacks are mostly FUD, and I >would not mind changing the "return routability check SHOULD be >done before updating.." to a MAY or something. But on the other >hand, you can ignore the SHOULD if want, too. > > We have existing consensus on this issue. Lets work with that and not re-open that one. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 09:16:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDMG0-0007pY-Ht for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 09:16:01 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18740 for ; Thu, 8 Sep 2005 09:15:58 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 0E77BFB24A; Thu, 8 Sep 2005 09:15:59 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AE2DCFB246; Thu, 8 Sep 2005 09:15:57 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 97A3DFB249; Thu, 8 Sep 2005 09:15:55 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 9007CFB23E for ; Thu, 8 Sep 2005 09:15:54 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id EB39389848; Thu, 8 Sep 2005 16:15:53 +0300 (EEST) Message-ID: <43203995.7060409@piuha.net> Date: Thu, 08 Sep 2005 16:16:05 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Francis.Dupont@enst-bretagne.fr X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: >Francis Dupont wrote: > > > >> > - motivation 2nd paragraph: the "another example" is a very >> > limited view of what multihoming support needs. I'd like to >> > see the mobike protocol supporting simultaneous multiple peer >> > addresses. (I use the term "peer address" from pki4ipsec >> > documents because it could not confused with addresses in >> > traffic selectors). >> >> Since the first version of MOBIKE only deals with the outer >> (tunnel header) addresses, using multiple addresses for an IPsec >> SA simultaneously would probably mean either load balancing >> (explicitly ruled out in the WG charter) or sending copies of a >> single ESP packet over several paths (nobody has expressed any >> interest in this so far). >> >> But this is probably not what you meant... ? >> >>=> no, I mean simultaneous multiple peer addresses for different >>IPsec SAs, something I've called the SCTP model for multihoming >>(note it is not only for SCTP, it was just accurately described >>in SCTP documents). >> >> > >The current protocol already supports this functionality. There >are several different ways how this functionality could be >implemented in the protocol, and in issue 8 there was rough >consensus to choose one of them (if you want different addresses >for different IPsec SAs, you can do so by creating IKE_SAs). > > Right. But what I'm missing still is a statement somewhere in the document that says we can have multiple IKE SAs in parallel and that if there's MOBIKE-related changes then those changes apply only to the IKE SA on which those changes were communicated. This may be obvious, but I think its good to write it down anyway. >> > - the link between 2.2 and 2.3 is not explained because the >> > new addresses are taken from the IP header. BTW I am afraid >> > the main scenario is the only supported scenario as a >> > consequence... >> >> Could you give a concrete example of a scenario that can't be >> done currently? >> >>=> multihoming. >> >> > >I do not agree. We just chose to implement multihoming support >in a slightly different way than SCTP did. > > Yes. And I believe what we are doing matches well with our charter, too. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 09:19:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDMJE-0008Ma-Nv for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 09:19:20 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18924 for ; Thu, 8 Sep 2005 09:19:18 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7EAACFB282; Thu, 8 Sep 2005 09:19:16 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A228CFB246; Thu, 8 Sep 2005 09:19:11 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C25D1FB249; Thu, 8 Sep 2005 09:19:09 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 60072FB23E for ; Thu, 8 Sep 2005 09:19:08 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j88DIEbb009804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2005 16:18:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j88DIEbg027469; Thu, 8 Sep 2005 16:18:14 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17184.14870.172689.595483@fireball.kivinen.iki.fi> Date: Thu, 8 Sep 2005 16:18:14 +0300 From: Tero Kivinen To: Francis Dupont Subject: Re: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40) In-Reply-To: <200509080958.j889wSWP004315@givry.rennes.enst-bretagne.fr> References: <200509080958.j889wSWP004315@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 7 min Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Francis Dupont writes: > > - in 2.3 the SPD entries have to be updated too or expired SAs > > will be renewed with wrong addresses. > > I'll add a clarification about this (where exactly the > addressses have to be updated depends a lot on the > implementation; e.g. the VPN client I have on my PC treats the > IPsec tunnel as a virtual interface, and stores some of the > information RFC 2401 would call "SPD" in what the implementation > calls "routing table"). > > => IMHO there is no choice here: the formal description is in 2401bis > and we have to use it even when we know the implementations have only > to provide the same behavior and can use very different structures. The 2401bis describes one way of implementing IPsec, it is not the only way to do it. It itself says: "The model described below is nominal; implementations need not match details of this model as presented, but the external behavior of implementations MUST correspond to the externally observable characteristics of this model in order to be compliant." Also the mobike extends some aspects of IPsec in way that they cannot be expressed as rfc2401bis PAD/SPD/SAD model (i.e dynamic updating of the PAD, SPD, SAD etc databases for example), thus implementations supporting 2401bis and mobike need to make extensions to the PAD/SPD/SAD. Thus Pasi's clarifications of the what possible tables or databases needs to be updated in when the addresses are changed should be in this document, and it does not need to be restricted in the 2401bis language and model. It should include the 2401bis model too when applicable, but it can also provide other implementaqtion instructions. > > - another limitation of 2.3 is it cannot update selectively a > > subset of SAs: again a case only is handled! > > Yes, and this is intentional (there was rough consensus in issue > 8 to do it this way -- if you want to update a subset of SAs, > you need to have several IKE_SAs). > > => the problem is if the intention is not to support multihoming > (and it seems there is a rough consensus about this :-) the charter > must be updated. Or we'll get IESG comments or even an appeal > about the document and its lack of support for anything else > than mobility. We do support multihoming, we do not support simultaneous use of multiple addresses (as it would be load balacing that was explictly forbidden by the charter). We do allow traffic to move from one interface to the another (that is not mobility, it is multihoming). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 09:44:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDMhp-0006VV-Ro for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 09:44:46 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19878 for ; Thu, 8 Sep 2005 09:44:42 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 099EDFB277; Thu, 8 Sep 2005 09:44:40 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 99E37FB246; Thu, 8 Sep 2005 09:44:37 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DDB9AFB249; Thu, 8 Sep 2005 09:44:35 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 93E11FB23E for ; Thu, 8 Sep 2005 09:44:34 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j88DiQU27243; Thu, 8 Sep 2005 15:44:26 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j88DiQcI006118; Thu, 8 Sep 2005 15:44:26 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509081344.j88DiQcI006118@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko Subject: Re: [Mobike] issue 34 proposal In-reply-to: Your message of Thu, 08 Sep 2005 12:23:34 +0300. <43200316.8020004@piuha.net> Date: Thu, 08 Sep 2005 15:44:26 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: Francis Dupont wrote: >=> note that I disagree. Ok. Can you expand the above a bit with some reasons and/or alternative proposals? => I am for making the standard mechanism for IKEv2/NAT-T (update by ESP) simply mandatory in MOBIKE environments (option 1bis). This is not against the charter (no new things for NAT-T) and can be considered as a MOBIKE profile compatible with the "mainstream" IKEv2. Regards Francis.Dupont@enst-bretagne.fr PS: I don't buy the hardware argument (nor such hardware :-). _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 10:04:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDN0m-0002hu-5b for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 10:04:20 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20913 for ; Thu, 8 Sep 2005 10:04:16 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A3C82FB277; Thu, 8 Sep 2005 10:04:14 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 28154FB246; Thu, 8 Sep 2005 10:04:13 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 30BE0FB249; Thu, 8 Sep 2005 10:04:11 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 94AC6FB23E for ; Thu, 8 Sep 2005 10:04:10 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E7BA489848; Thu, 8 Sep 2005 17:04:09 +0300 (EEST) Message-ID: <432044E5.1000102@piuha.net> Date: Thu, 08 Sep 2005 17:04:21 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] issue 34 proposal References: <200509081344.j88DiQcI006118@givry.rennes.enst-bretagne.fr> In-Reply-To: <200509081344.j88DiQcI006118@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit >=> I am for making the standard mechanism for IKEv2/NAT-T (update >by ESP) simply mandatory in MOBIKE environments (option 1bis). >This is not against the charter (no new things for NAT-T) and >can be considered as a MOBIKE profile compatible with the >"mainstream" IKEv2. > I agree that none of the alternatives break our charter. But can you explain more about why you think 1bis is better than the other options? Or is your argument that it is a smaller impact to NAT-T than the other options? >PS: I don't buy the hardware argument (nor such hardware :-). > > Heh :-) --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 10:38:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDNY0-0003ap-FO for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 10:38:40 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23566 for ; Thu, 8 Sep 2005 10:38:37 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 39A28FB277; Thu, 8 Sep 2005 10:38:35 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A0BD5FB246; Thu, 8 Sep 2005 10:38:32 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E3EE3FB249; Thu, 8 Sep 2005 10:38:30 -0400 (EDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by machshav.com (Postfix) with ESMTP id D0B8FFB23E for ; Thu, 8 Sep 2005 10:38:29 -0400 (EDT) Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 08 Sep 2005 10:37:30 -0400 X-IronPort-AV: i="3.96,179,1122868800"; d="scan'208"; a="69460697:sNHT30686072" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j88EbOT8022078; Thu, 8 Sep 2005 10:37:26 -0400 (EDT) Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Sep 2005 10:37:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issue 34 proposal Date: Thu, 8 Sep 2005 10:37:13 -0400 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD685F834@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Mobike] issue 34 proposal Thread-Index: AcW0e5b86pTAIVV/Q6mvQEeV8lUAoQAAfOAA From: "Stephane Beaulieu (stephane)" To: "Francis Dupont" , "Jari Arkko" X-OriginalArrivalTime: 08 Sep 2005 14:37:15.0100 (UTC) FILETIME=[CE5EE1C0:01C5B482] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable >=20 > In your previous mail you wrote: >=20 > Francis Dupont wrote: > =20 > >=3D> note that I disagree. >=20 > Ok. Can you expand the above a bit with > some reasons and/or alternative proposals? > =20 > =3D> I am for making the standard mechanism for IKEv2/NAT-T=20 > (update by ESP) simply mandatory in MOBIKE environments (option 1bis). > This is not against the charter (no new things for NAT-T) and=20 > can be considered as a MOBIKE profile compatible with the=20 > "mainstream" IKEv2. Francis, Can't both be done? If I notice that packets are coming in using a SPI for which the IP/port doesn't match what I expect, can't I just process them anyway, and update my sadb? There doesn't appear anything interoperability wise to stop you from doing this. If you update, you recover NOW. If you wait for DPD/NAT-T, it will take longer, but still eventually update. It means more code to write (since we have to be able to handle 2 different ways of changing NAT mappings), but it does satisfy both camps. Stephane. >=20 > Regards >=20 > Francis.Dupont@enst-bretagne.fr >=20 > PS: I don't buy the hardware argument (nor such hardware :-). > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 11:24:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDOFr-0006iB-B2 for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 11:24:00 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26268 for ; Thu, 8 Sep 2005 11:23:55 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A496BFB24A; Thu, 8 Sep 2005 11:23:52 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6D271FB24A; Thu, 8 Sep 2005 11:23:47 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7FB96FB262; Thu, 8 Sep 2005 11:23:45 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 2812FFB246 for ; Thu, 8 Sep 2005 11:23:44 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j88FNYU02883; Thu, 8 Sep 2005 17:23:34 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j88FNYmF006724; Thu, 8 Sep 2005 17:23:34 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509081523.j88FNYmF006724@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40) In-reply-to: Your message of Thu, 08 Sep 2005 16:02:36 +0300. Date: Thu, 08 Sep 2005 17:23:34 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: > => no, I mean simultaneous multiple peer addresses for different > IPsec SAs, something I've called the SCTP model for multihoming > (note it is not only for SCTP, it was just accurately described > in SCTP documents). The current protocol already supports this functionality. There are several different ways how this functionality could be implemented in the protocol, and in issue 8 there was rough consensus to choose one of them (if you want different addresses for different IPsec SAs, you can do so by creating IKE_SAs). => so MOBIKE handles multihoming the same way than TCP when we expect according to the WG charter more something like SCTP. > Could you give a concrete example of a scenario that can't be > done currently? > > => multihoming. I do not agree. We just chose to implement multihoming support in a slightly different way than SCTP did. => what is the real difference between MOBIKE multihoming support and IKEv2 multihoming support, and, more important, is this difference enough? Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 11:27:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDOJM-0007rF-AB for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 11:27:36 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26455 for ; Thu, 8 Sep 2005 11:27:32 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 75993FB277; Thu, 8 Sep 2005 11:27:33 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7D094FB262; Thu, 8 Sep 2005 11:27:26 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5133EFB262; Thu, 8 Sep 2005 11:27:22 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id A8BCEFB246; Thu, 8 Sep 2005 11:27:20 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j88FR7U03254; Thu, 8 Sep 2005 17:27:07 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j88FR8xd006762; Thu, 8 Sep 2005 17:27:08 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509081527.j88FR8xd006762@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen Subject: Re: [Mobike] issue 34 proposal In-reply-to: Your message of Thu, 08 Sep 2005 16:04:42 +0300. <17184.14058.518318.692302@fireball.kivinen.iki.fi> Date: Thu, 08 Sep 2005 17:27:08 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike-bounces@machshav.com, jari.arkko@piuha.net, mobike@machshav.com, Mika.Joutsenvirta@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: Mika.Joutsenvirta@nokia.com writes: > there is one situation where "dynamic updates" has clear > advantage: voice. Dynamic updates survives much faster > than IKE approach and call would stay up. NAT rebooting will cause probably tens of seconds or even minutes of network lossage anyways, so that will normally cause people to break the connection and try to reconnect before that. I think most of my friends will usually allow about 2-10 seconds of bad connection in gsm phone, before they will hang up and redial trying to fix the problem. Most of the NATs boot much slower than that. => here NAT rebooting includes NAT loosing its state and unfortunately this kind of events is more frequent and fast. Another case of causing NAT mapping disappearing is the too long keepalive, but that should not really matter in VoIP traffic, as there is traffic going on fast enough to keep the NAT mappings up. => another case so there still are other cases... Regards Francis.Dupont@enst-bretagne.fr PS: please don't forget that NAT traversal is explicitely outside the WG charter. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 11:34:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDOPs-0001cR-2R for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 11:34:20 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26806 for ; Thu, 8 Sep 2005 11:34:16 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B3822FB27D; Thu, 8 Sep 2005 11:34:16 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3A13AFB246; Thu, 8 Sep 2005 11:34:13 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 40929FB249; Thu, 8 Sep 2005 11:34:11 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id E73D9FB23E for ; Thu, 8 Sep 2005 11:34:09 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j88FY2U03704; Thu, 8 Sep 2005 17:34:02 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j88FY2nI006848; Thu, 8 Sep 2005 17:34:02 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509081534.j88FY2nI006848@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko Subject: Re: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40) In-reply-to: Your message of Thu, 08 Sep 2005 16:16:05 +0300. <43203995.7060409@piuha.net> Date: Thu, 08 Sep 2005 17:34:02 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: Right. But what I'm missing still is a statement somewhere in the document that says we can have multiple IKE SAs in parallel and that if there's MOBIKE-related changes then those changes apply only to the IKE SA on which those changes were communicated. This may be obvious, but I think its good to write it down anyway. => yes, if we'd like to kill multihoming it is better to dig a grave (:-). >I do not agree. We just chose to implement multihoming support >in a slightly different way than SCTP did. Yes. And I believe what we are doing matches well with our charter, too. => I strongly object: only a part of the charter matches, and I am not talking about the NAT traversal stuff which does match but a forbidden part. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 11:42:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDOY2-0003Ol-TN for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 11:42:47 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27130 for ; Thu, 8 Sep 2005 11:42:42 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 82CD4FB277; Thu, 8 Sep 2005 11:42:44 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 14067FB246; Thu, 8 Sep 2005 11:42:43 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4D78CFB249; Thu, 8 Sep 2005 11:42:41 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id EB7B8FB23E for ; Thu, 8 Sep 2005 11:42:39 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j88FgRU04042; Thu, 8 Sep 2005 17:42:27 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j88FgRc5006900; Thu, 8 Sep 2005 17:42:27 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509081542.j88FgRc5006900@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen Subject: Re: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40) In-reply-to: Your message of Thu, 08 Sep 2005 16:18:14 +0300. <17184.14870.172689.595483@fireball.kivinen.iki.fi> Date: Thu, 08 Sep 2005 17:42:27 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: It should include the 2401bis model too when applicable, but it can also provide other implementation instructions. => I agree with this conclusion including its keywords. We do support multihoming, we do not support simultaneous use of multiple addresses (as it would be load balacing that was explictly forbidden by the charter). => I can't see why you believe that multiple addresses implies load balancing, so I can't understand why you miss the fact that multiple addresses is the way multihoming is handled in IPv6. We do allow traffic to move from one interface to the another (that is not mobility, it is multihoming). => this is not multihomong, it is a small and not essential part of what is called multihoming (which is fortunately defined at the IETF, cf MULTI6 WG & its successor(s)). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 11:52:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDOhi-0005kp-14 for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 11:52:46 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27890 for ; Thu, 8 Sep 2005 11:52:41 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E940AFB282; Thu, 8 Sep 2005 11:52:39 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1F4BEFB24A; Thu, 8 Sep 2005 11:52:38 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F05EDFB249; Thu, 8 Sep 2005 11:52:35 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id A3E68FB23E for ; Thu, 8 Sep 2005 11:52:34 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j88FqQU05095; Thu, 8 Sep 2005 17:52:26 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j88FqRU7006997; Thu, 8 Sep 2005 17:52:27 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509081552.j88FqRU7006997@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko Subject: Re: [Mobike] issue 34 proposal In-reply-to: Your message of Thu, 08 Sep 2005 17:04:21 +0300. <432044E5.1000102@piuha.net> Date: Thu, 08 Sep 2005 17:52:27 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: >=> I am for making the standard mechanism for IKEv2/NAT-T (update >by ESP) simply mandatory in MOBIKE environments (option 1bis). >This is not against the charter (no new things for NAT-T) and >can be considered as a MOBIKE profile compatible with the >"mainstream" IKEv2. > I agree that none of the alternatives break our charter. => I am not so sure... But can you explain more about why you think 1bis is better than the other options? => because someone who wants to deal with a NAT loosing its state will simply implement the ESP update as it is recommend by the IKEv2 spec, with or without MOBIKE. Or is your argument that it is a smaller impact to NAT-T than the other options? => it has no impact, it is just a profile. It says if you have both MOBIKE and NAT-T then you must have a good NAT-T, not the minimal one. Regards Francis.Dupont@enst-bretagne.fr PS: BTW an advantage of 1bis is it doesn't mismatch with current NAT-T recommendations, i.e., ESP update and >=2 can be a bit hard to live together. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 12:04:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDOtF-0000He-E9 for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 12:04:41 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29586 for ; Thu, 8 Sep 2005 12:04:37 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D9C1EFB282; Thu, 8 Sep 2005 12:04:35 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D276CFB24A; Thu, 8 Sep 2005 12:04:32 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CBD9AFB262; Thu, 8 Sep 2005 12:04:30 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 67970FB246 for ; Thu, 8 Sep 2005 12:04:29 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j88G4JU06146; Thu, 8 Sep 2005 18:04:19 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j88G4Jhf007104; Thu, 8 Sep 2005 18:04:19 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509081604.j88G4Jhf007104@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Stephane Beaulieu (stephane)" Subject: Re: [Mobike] issue 34 proposal In-reply-to: Your message of Thu, 08 Sep 2005 10:37:13 EDT. <13E3DA8B48E17D4C96D261A36A23FCD685F834@xmb-rtp-208.amer.cisco.com> Date: Thu, 08 Sep 2005 18:04:19 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Jari Arkko X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: Can't both be done? => yes but the standard NAT-T mechanism is the ESP update and I don't see why we have to replace it. If I notice that packets are coming in using a SPI for which the IP/port doesn't match what I expect, can't I just process them anyway, and update my sadb? There doesn't appear anything interoperability wise to stop you from doing this. => just options >=2 If you update, you recover NOW. If you wait for DPD/NAT-T, it will take longer, but still eventually update. => or you don't restrict the SPI to ESP, i.e., you handle all the port 4500 packets. BTW you don't need to get the IKE SA SPI from IKE (nor any SPIs in fact), you just have to cache the address/port per SPI and to detect changes. It means more code to write (since we have to be able to handle 2 different ways of changing NAT mappings), but it does satisfy both camps. => I am afraid this is no easy to code... In fact, IMHO the issue is the #34 tries to mix implicit and explicit updates which is a bad design. This is why I still believe we should have kept MOBIKE and NAT-T separated. Regards Francis.Dupont@enst-bretagne.fr PS: I believe the peer behind the NAT has to send some ESP packets from time to time even it has no traffic in order to keep the state in the NAT(s). This seems a better way to ensure the ESP update than to add a DPD-like mechanism for IKE processed at the level. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 13:49:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDQWW-00067c-GP for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 13:49:20 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05738 for ; Thu, 8 Sep 2005 13:49:18 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4B62EFB282; Thu, 8 Sep 2005 13:49:15 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8E7ABFB246; Thu, 8 Sep 2005 13:49:10 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 40DC7FB24A; Thu, 8 Sep 2005 13:49:08 -0400 (EDT) Received: from web80601.mail.yahoo.com (web80601.mail.yahoo.com [66.218.79.90]) by machshav.com (Postfix) with SMTP id 2D677FB23E for ; Thu, 8 Sep 2005 13:49:07 -0400 (EDT) Received: (qmail 41324 invoked by uid 60001); 8 Sep 2005 17:49:06 -0000 Message-ID: <20050908174906.41322.qmail@web80601.mail.yahoo.com> Received: from [206.132.194.3] by web80601.mail.yahoo.com via HTTP; Thu, 08 Sep 2005 10:49:06 PDT Date: Thu, 8 Sep 2005 10:49:06 -0700 (PDT) From: Mohan Parthasarathy Subject: Re: [Mobike] issue 34 proposal To: Francis Dupont , Tero Kivinen In-Reply-To: <200509081527.j88FR8xd006762@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: mobike-bounces@machshav.com, mobike@machshav.com, jari.arkko@piuha.net, Mika.Joutsenvirta@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 8bit > > PS: please don't forget that NAT traversal is > explicitely outside > the WG charter. I don't know what this means. Do you mean to say MOBIKE should not care about NATs ? The "issue 34" is about a specific case of dynamic updates which also has an impact on PATH_TEST messages. So, just arguing about dynamic updates alone does not get us anywhere. -mohan > _______________________________________________ > 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 Thu Sep 08 14:02:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDQjd-0001V8-1j for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 14:02:53 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06494 for ; Thu, 8 Sep 2005 14:02:51 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A2A69FB262; Thu, 8 Sep 2005 14:02:51 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 20815FB246; Thu, 8 Sep 2005 14:02:50 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2A5B4FB249; Thu, 8 Sep 2005 14:02:48 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id 20317FB23E; Thu, 8 Sep 2005 14:02:47 -0400 (EDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j88I2jMM008392; Thu, 8 Sep 2005 21:02:46 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Sep 2005 21:02:45 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Sep 2005 21:02:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issue 34 proposal Date: Thu, 8 Sep 2005 21:02:44 +0300 Message-ID: <1FBB41C090940F4C8BA37F3E536689199D808A@trebe101.NOE.Nokia.com> Thread-Topic: [Mobike] issue 34 proposal Thread-Index: AcW0dhA8KlQA64rUS0G625u7qk/ZUgAKGH2w From: To: X-OriginalArrivalTime: 08 Sep 2005 18:02:44.0963 (UTC) FILETIME=[838AAB30:01C5B49F] Cc: mobike-bounces@machshav.com, mobike@machshav.com, jari.arkko@piuha.net X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Right, this and the explanation from Jari makes it clear that there isn't that much advantage in "dynamic updates". So IKE approach is=20 fine with me.=20 And for path testing, I don't see why separate path_test message should be used (implemented), so I support IKE version here too. Mika -----Original Message----- From: ext Tero Kivinen [mailto:kivinen@iki.fi] Sent: 08 September, 2005 16:05 To: Joutsenvirta Mika (Nokia-TP/Tampere) Cc: mobike-bounces@machshav.com; jari.arkko@piuha.net; mobike@machshav.com Subject: RE: [Mobike] issue 34 proposal Mika.Joutsenvirta@nokia.com writes: > there is one situation where "dynamic updates" has clear > advantage: voice. Dynamic updates survives much faster=20 > than IKE approach and call would stay up. NAT rebooting will cause probably tens of seconds or even minutes of network lossage anyways, so that will normally cause people to break the connection and try to reconnect before that. I think most of my friends will usually allow about 2-10 seconds of bad connection in gsm phone, before they will hang up and redial trying to fix the problem. Most of the NATs boot much slower than that. > And yes, I know VoIP is out of the scope, but still IPsec is used to > protect voice traffic as well, and if possible that should be taken > into account. I do not think VoIP makes any difference here. If the NAT is really rebootted, it does not really matter if the connection is restored in 120 seconds (when the first ESP packet reaches the other end after NAT if finally up), or if it takes little longer before the DPD kicks in. Another case of causing NAT mapping disappearing is the too long keepalive, but that should not really matter in VoIP traffic, as there is traffic going on fast enough to keep the NAT mappings up. --=20 kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 17:58:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDUPo-0005ll-9E for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 17:58:40 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20551 for ; Thu, 8 Sep 2005 17:58:35 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A55C1FB24A; Thu, 8 Sep 2005 17:58:32 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A07A5FB246; Thu, 8 Sep 2005 17:58:29 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C461EFB249; Thu, 8 Sep 2005 17:58:27 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 4137FFB23E; Thu, 8 Sep 2005 17:58:26 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j88LwEj05884; Thu, 8 Sep 2005 23:58:14 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j88LwEUl008273; Thu, 8 Sep 2005 23:58:14 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509082158.j88LwEUl008273@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mohan Parthasarathy Subject: Re: [Mobike] issue 34 proposal In-reply-to: Your message of Thu, 08 Sep 2005 10:49:06 PDT. <20050908174906.41322.qmail@web80601.mail.yahoo.com> Date: Thu, 08 Sep 2005 23:58:14 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike-bounces@machshav.com, mobike@machshav.com, jari.arkko@piuha.net, Mika.Joutsenvirta@nokia.com, Tero Kivinen X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: > PS: please don't forget that NAT traversal is > explicitely outside > the WG charter. I don't know what this means. => simply: In particular, the WG shall NOT develop mechanisms for the following functions: o IP address changes done by third parties (NATs, firewalls etc). In particular, MOBIKE shall not replace or modify IKEv2 NAT traversal function. MOBIKE handles IP address changes initiated by one of the endpoints of the security associations. NAT traversal handles other address changes. MOBIKE should not be tightly coupled with the NAT traversal function, but it is necessary to specify in which cases (if any) they can be used together, and how they interact. So this discussion itself is in the charter (last statement) but some proposed solutions can be outside. Do you mean to say MOBIKE should not care about NATs ? => I mean it should care only inside the limits described in the charter. The "issue 34" is about a specific case of dynamic updates which also has an impact on PATH_TEST messages. So, just arguing about dynamic updates alone does not get us anywhere. => one can consider than #34 is about the interaction between MOBIKE and NAT-T in cases they are used together. Regards Francis.Dupont@enst-bretagne.fr PS: http://www.ietf.org/html.charters/mobike-charter.html _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 08 22:03:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDYEM-0006qH-QB for mobike-archive@megatron.ietf.org; Thu, 08 Sep 2005 22:03:07 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10659 for ; Thu, 8 Sep 2005 22:03:02 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9E426FB27D; Thu, 8 Sep 2005 22:02:59 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B2102FB246; Thu, 8 Sep 2005 22:02:56 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A4D1AFB24A; Thu, 8 Sep 2005 22:02:55 -0400 (EDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by machshav.com (Postfix) with SMTP id 80FDFFB240 for ; Thu, 8 Sep 2005 22:02:54 -0400 (EDT) Received: (qmail 50103 invoked from network); 9 Sep 2005 02:02:53 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.56.102 with login) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 9 Sep 2005 02:02:52 -0000 Message-ID: <00dd01c5b4e2$91ca9af0$6601a8c0@adithya> From: "Mohan Parthasarathy" To: "Francis Dupont" References: <200509082158.j88LwEUl008273@givry.rennes.enst-bretagne.fr> Subject: Re: [Mobike] issue 34 proposal Date: Thu, 8 Sep 2005 19:02:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: jari.arkko@piuha.net, mobike@machshav.com, Tero Kivinen , Mika.Joutsenvirta@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > In your previous mail you wrote: > > > PS: please don't forget that NAT traversal is > > explicitely outside > > the WG charter. > > I don't know what this means. > > => simply: In particular, the WG shall NOT develop mechanisms for the > following functions: > > o IP address changes done by third parties (NATs, firewalls etc). In > particular, MOBIKE shall not replace or modify IKEv2 NAT traversal > function. MOBIKE handles IP address changes initiated by one of the > endpoints of the security associations. NAT traversal handles other > address changes. MOBIKE should not be tightly coupled with the NAT > traversal function, but it is necessary to specify in which cases > (if any) they can be used together, and how they interact. > > So this discussion itself is in the charter (last statement) but > some proposed solutions can be outside. > > Do you mean to say MOBIKE should not care about NATs ? > > => I mean it should care only inside the limits described in the charter. > To me the charter is too restrictive and the above paragraph is very ambiguous. It would be a waste of time discussing it now. > The "issue 34" is > about a specific case of dynamic updates which also > has an impact on PATH_TEST messages. So, just arguing > about dynamic updates alone does not get us anywhere. > > => one can consider than #34 is about the interaction between MOBIKE > and NAT-T in cases they are used together. > No, it is more than that. If you use implicit updates (as in IKEv2 NAT-T), then you also need a mechanism to prevent implicit updates so that you can find working path between the peers. We have discussed enough on this topic now :-) -mohan > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: http://www.ietf.org/html.charters/mobike-charter.html > _______________________________________________ > 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 Sep 09 04:46:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDeWb-0004aP-2s for mobike-archive@megatron.ietf.org; Fri, 09 Sep 2005 04:46:22 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17681 for ; Fri, 9 Sep 2005 04:46:17 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id DD2A5FB277; Fri, 9 Sep 2005 04:46:13 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B955FFB246; Fri, 9 Sep 2005 04:46:11 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 54997FB24A; Fri, 9 Sep 2005 04:46:10 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id ECE3DFB240 for ; Fri, 9 Sep 2005 04:46:08 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j898ia9f019565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Sep 2005 11:44:36 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j898iNAR004710; Fri, 9 Sep 2005 11:44:23 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17185.19303.688194.419759@fireball.kivinen.iki.fi> Date: Fri, 9 Sep 2005 11:44:23 +0300 From: Tero Kivinen To: "Stephane Beaulieu (stephane)" Subject: RE: [Mobike] issue 34 proposal In-Reply-To: <13E3DA8B48E17D4C96D261A36A23FCD685F834@xmb-rtp-208.amer.cisco.com> References: <13E3DA8B48E17D4C96D261A36A23FCD685F834@xmb-rtp-208.amer.cisco.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 57 min Cc: mobike@machshav.com, Jari Arkko , Francis Dupont X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Stephane Beaulieu (stephane) writes: > Can't both be done? If I notice that packets are coming in using a SPI > for which the IP/port doesn't match what I expect, can't I just process > them anyway, and update my sadb? There doesn't appear anything > interoperability wise to stop you from doing this. If you update, you > recover NOW. If you wait for DPD/NAT-T, it will take longer, but still > eventually update. For ESP packets you could do that, but for IKE packets you need separate path test exchange if you do that, as then you cannot probe if the path is working with IKE packet, as the probe can break the link (it would cause traffic to move to that address pair and if that address pair was unidirectional the connection would be lost because of that). > It means more code to write (since we have to be able to handle 2 > different ways of changing NAT mappings), but it does satisfy both > camps. Why would you want to write more code just to cover very corner case? We do not expect the NATs be rebooted or loosing mappings regularly, it might happen to some people every few months or so, and some people will probably never see that. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Sep 09 06:03:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDfiw-0003qb-FT for mobike-archive@megatron.ietf.org; Fri, 09 Sep 2005 06:03:10 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21453 for ; Fri, 9 Sep 2005 06:03:06 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C0422FB27D; Fri, 9 Sep 2005 06:02:54 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3A0F2FB246; Fri, 9 Sep 2005 06:02:54 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 384F1FB24A; Fri, 9 Sep 2005 06:02:52 -0400 (EDT) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id 51CCEFB240 for ; Fri, 9 Sep 2005 06:02:51 -0400 (EDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j89A1kfw009110 for ; Fri, 9 Sep 2005 13:01:51 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Sep 2005 13:02:46 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Sep 2005 13:02:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Sep 2005 13:02:29 +0300 Message-ID: Thread-Topic: Issue 41: Mandate NAT prevention if not doing NAT-T? Thread-Index: AcW1JaAlxJwEUStoQUyQ43q/UpjVtw== From: To: X-OriginalArrivalTime: 09 Sep 2005 10:02:46.0194 (UTC) FILETIME=[A08D0120:01C5B525] Subject: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable (I've split this away from issue 40.) The current version of the protocol draft does not require hosts=20 that do not support NAT-T to use the "NAT prevention" feature. Francis has suggested that this "middle ground" should be eliminated; in other words, the initiator would always include either NAT_DETECTION_*_IP (if it supports NAT-T) or NAT_PREVENTION (it it doesn't) in all IKE_SA_INIT and UPDATE_SA_ADDRESSES messages. Any comments about this? My gut feeling is that we should keep this middle ground; after all, implementations that don't bother to implement NAT-T and UDP encapsulation can still work through (manually configured) static NATs and some types of IPv4/v6 translators. NAT_PREVENTION also creates a denial-of-service vulnerability even when no malicious attackers are present: a misconfiguration or introduction of a non-malicious translator causes the peers not to use that path (and if it was the only one, connection fails). Or as I put in my IETF63 slides, this is a "trade-off between DoS-ing yourself and religious beliefs". In my opinion, we don't need to settle this trade-off in the protocol spec by saying "MUST use NAT prevention if not using NAT-T": the functionality is available for those who really want to use it (and understanding NAT_PREVENTION is mandatory for the responder). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Sep 09 08:06:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDheP-0002t9-3I for mobike-archive@megatron.ietf.org; Fri, 09 Sep 2005 08:06:37 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27461 for ; Fri, 9 Sep 2005 08:06:35 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 057D6FB277; Fri, 9 Sep 2005 08:06:33 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8262EFB246; Fri, 9 Sep 2005 08:06:31 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5E557FB24A; Fri, 9 Sep 2005 08:06:29 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by machshav.com (Postfix) with ESMTP id 41F8CFB240 for ; Fri, 9 Sep 2005 08:06:27 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 09 Sep 2005 05:06:25 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j89C6CKG021797; Fri, 9 Sep 2005 05:06:18 -0700 (PDT) Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Sep 2005 08:06:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issue 34 proposal Date: Fri, 9 Sep 2005 08:06:15 -0400 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD685FA6A@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Mobike] issue 34 proposal Thread-Index: AcW1GvC0rpB4zPGuQ0OCrgbK4WXH/QAGJ2TQ From: "Stephane Beaulieu (stephane)" To: "Tero Kivinen" X-OriginalArrivalTime: 09 Sep 2005 12:06:16.0919 (UTC) FILETIME=[E1AFE670:01C5B536] Cc: mobike@machshav.com, Jari Arkko , Francis Dupont X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable =20 >=20 > Stephane Beaulieu (stephane) writes: > > Can't both be done? If I notice that packets are coming in using a=20 > > SPI for which the IP/port doesn't match what I expect, can't I just=20 > > process them anyway, and update my sadb? There doesn't appear=20 > > anything interoperability wise to stop you from doing this. If you=20 > > update, you recover NOW. If you wait for DPD/NAT-T, it will take=20 > > longer, but still eventually update. >=20 > For ESP packets you could do that, but for IKE packets you=20 > need separate path test exchange if you do that, as then you=20 > cannot probe if the path is working with IKE packet, as the=20 > probe can break the link (it would cause traffic to move to=20 > that address pair and if that address pair was unidirectional=20 > the connection would be lost because of that).=20 Not sure I follow your second point. You're saying that the original NAT mapping was bi-directional, but after the reboot, a new NAT mapping was given but this one is uniderctional? I admit my experience with NAT is limited, but I have never seen this happen. I have however seen NAT mappings get lost many, many times. >=20 > > It means more code to write (since we have to be able to handle 2=20 > > different ways of changing NAT mappings), but it does satisfy both=20 > > camps. >=20 > Why would you want to write more code just to cover very corner case? Job security :) Nah, seriously though, I prefer the automatic updates because of the speed of recovery. Though you claim that NAT mapping drops are rare, my experience is different. Yes, they might be rare enough, but every time it happens, I have to spend 1 hour looking through customer's syslogs to figure out why things stopped working. I hate doing that ! :) BTW, have you seen the number of home/SOHO router/NAT boxes you can buy today for about $5. Reliability is not the first word that comes to mind. I'm willing to implement it both ways because the cost/complexity is fairly low, and I can see how doing it via ESP detection only might be more difficult for some vendors. >=20 > We do not expect the NATs be rebooted or loosing mappings=20 > regularly, it might happen to some people every few months or=20 > so, and some people will probably never see that. > -- > kivinen@safenet-inc.com >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Sep 09 10:17:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDjhF-0006EM-Rp for mobike-archive@megatron.ietf.org; Fri, 09 Sep 2005 10:17:41 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05291 for ; Fri, 9 Sep 2005 10:17:39 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id AC15EFB27D; Fri, 9 Sep 2005 10:17:36 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D6D4CFB246; Fri, 9 Sep 2005 10:17:32 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7F422FB24A; Fri, 9 Sep 2005 10:17:31 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 2F6C2FB240 for ; Fri, 9 Sep 2005 10:17:25 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j89EFHha012285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Sep 2005 17:15:17 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j89EF8q6008167; Fri, 9 Sep 2005 17:15:08 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17185.39148.232665.100290@fireball.kivinen.iki.fi> Date: Fri, 9 Sep 2005 17:15:08 +0300 From: Tero Kivinen To: "Stephane Beaulieu (stephane)" Subject: RE: [Mobike] issue 34 proposal In-Reply-To: <13E3DA8B48E17D4C96D261A36A23FCD685FA6A@xmb-rtp-208.amer.cisco.com> References: <13E3DA8B48E17D4C96D261A36A23FCD685FA6A@xmb-rtp-208.amer.cisco.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 20 min X-Total-Time: 20 min Cc: Jari Arkko , mobike@machshav.com, Francis Dupont X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Stephane Beaulieu (stephane) writes: > > For ESP packets you could do that, but for IKE packets you > > need separate path test exchange if you do that, as then you > > cannot probe if the path is working with IKE packet, as the > > probe can break the link (it would cause traffic to move to > > that address pair and if that address pair was unidirectional > > the connection would be lost because of that). > > Not sure I follow your second point. > > You're saying that the original NAT mapping was bi-directional, but > after the reboot, a new NAT mapping was given but this one is > uniderctional? I admit my experience with NAT is limited, but I have > never seen this happen. > When the NAT mapping is lost most commonly it can only be recreated from the behind of NAT. This will create bi-directional mapping. The problem with the automatic updating of the address pair when receiving valid packet from the remote end is that if you have working address pair A1, B1 (with NAT), and you are using it. You also have another address pair A2, B1 (with or without NAT) and you do not know if it works yet. So now if you send IKEv2 probe packet with A2, B1 to the remote host, the remote host will notice that this is valid packet for the IKEv2 SA, thus it will move the traffic immediately to that A2, B1 pair when receiving that packet. Now if that A2, B1 path happened to be uni-directional for some reason, so the reply packets B1, A2 will not get through then we managed to cause connection problem while we still had completely valid and working address pair A1, B1. Even when we later retransmit that packet to A1, B1 address pair, the other peer now notices as this retransmission, and replays its old answer back. It might not update the mapping at that point (it is not clear from the ikev2 draft wheather replays should be consider "valid authenticated packet"). If we disable the IKEv2 automatic updating of the remote peers address, then we can send that probe packet, and it will not cause any connection problems. After a while when we notice that we are not getting reply back, we retransmit that using other addresses, i.e. A1, B1, and other end would then reply to us to B1, A1 address and the exchange is finished. I would actually say that replay is not "valid authenticated packet" as it would be too easy for the attacker to grab one "valid authenticated packet" from the link, modify the IP headers and the replay that every second, to make sure the traffic is all the time redirected to the host he wants to attack. > I have however seen NAT mappings get lost many, many times. Was the problem there NAT rebootting, or too long keepalives or something else? > BTW, have you seen the number of home/SOHO router/NAT boxes you can buy > today for about $5. Reliability is not the first word that comes to > mind. True, but in that case I would assume they know who to blame... :-) Still most of those small NAT boxes have enough memory and so small amount of traffic that they do not have really reason to remove NAT mappings very fast. And I do not think they crash that often. Again if they crash that will cause long delay anyways. > I'm willing to implement it both ways because the cost/complexity is > fairly low, and I can see how doing it via ESP detection only might be > more difficult for some vendors. So perhaps we should say you MUST NOT do automatic update with IKEv2 packets (breaks the probing), but you MAY do it for ESP packets? It will add the another module causing address updates, and you need to make sure the policy for the MOBIKE and that automatic update module are same. I really like the explicit address update because it will put the all policy decision about address changes in exactly one place, i.e in the MOBIKE module. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Sep 09 10:43:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDk6M-0002dO-Ah for mobike-archive@megatron.ietf.org; Fri, 09 Sep 2005 10:43:38 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06808 for ; Fri, 9 Sep 2005 10:43:35 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4D18DFB283; Fri, 9 Sep 2005 10:43:36 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8CD1DFB24A; Fri, 9 Sep 2005 10:43:34 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E5392FB277; Fri, 9 Sep 2005 10:43:32 -0400 (EDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by machshav.com (Postfix) with ESMTP id 415C8FB240 for ; Fri, 9 Sep 2005 10:43:30 -0400 (EDT) Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 09 Sep 2005 10:43:27 -0400 X-IronPort-AV: i="3.96,182,1122868800"; d="scan'208"; a="69618736:sNHT36139492" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j89EhGTC017237; Fri, 9 Sep 2005 10:43:22 -0400 (EDT) Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Sep 2005 10:43:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issue 34 proposal Date: Fri, 9 Sep 2005 10:43:08 -0400 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD68E3F5D@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Mobike] issue 34 proposal Thread-Index: AcW1SUZhXa1KgC4TTb68AY9XDBJgDgAASSYA From: "Stephane Beaulieu (stephane)" To: "Tero Kivinen" X-OriginalArrivalTime: 09 Sep 2005 14:43:09.0166 (UTC) FILETIME=[CBD2D0E0:01C5B54C] Cc: Jari Arkko , mobike@machshav.com, Francis Dupont X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable =20 >=20 > Stephane Beaulieu (stephane) writes: > > > For ESP packets you could do that, but for IKE packets you need=20 > > > separate path test exchange if you do that, as then you=20 > cannot probe=20 > > > if the path is working with IKE packet, as the probe can=20 > break the=20 > > > link (it would cause traffic to move to that address pair and if=20 > > > that address pair was unidirectional the connection would be lost=20 > > > because of that). > >=20 > > Not sure I follow your second point. > >=20 > > You're saying that the original NAT mapping was bi-directional, but=20 > > after the reboot, a new NAT mapping was given but this one is=20 > > uniderctional? I admit my experience with NAT is limited,=20 > but I have=20 > > never seen this happen. > >=20 >=20 > When the NAT mapping is lost most commonly it can only be=20 > recreated from the behind of NAT. This will create=20 > bi-directional mapping. >=20 > The problem with the automatic updating of the address pair=20 > when receiving valid packet from the remote end is that if=20 > you have working address pair A1, B1 (with NAT), and you are=20 > using it. You also have another address pair A2, B1 (with or=20 > without NAT) and you do not know if it works yet. So now if=20 > you send IKEv2 probe packet with A2, B1 to the remote host,=20 > the remote host will notice that this is valid packet for the=20 > IKEv2 SA, thus it will move the traffic immediately to that=20 > A2, B1 pair when receiving that packet. OK. So you're assuming that when we dectect a port change at the ESP layer, then we'll send probes to all possible paths. I was not making this assumption. >=20 > Now if that A2, B1 path happened to be uni-directional for=20 > some reason, so the reply packets B1, A2 will not get through=20 > then we managed to cause connection problem while we still=20 > had completely valid and working address pair A1, B1. Even=20 > when we later retransmit that packet to A1, B1 address pair,=20 > the other peer now notices as this retransmission, and=20 > replays its old answer back. It might not update the mapping=20 > at that point (it is not clear from the ikev2 draft wheather=20 > replays should be consider "valid authenticated packet"). >=20 > If we disable the IKEv2 automatic updating of the remote=20 > peers address, then we can send that probe packet, and it=20 > will not cause any connection problems. After a while when we=20 > notice that we are not getting reply back, we retransmit that=20 > using other addresses, i.e. A1, B1, and other end would then=20 > reply to us to B1, A1 address and the exchange is finished. >=20 > I would actually say that replay is not "valid authenticated packet" > as it would be too easy for the attacker to grab one "valid=20 > authenticated packet" from the link, modify the IP headers=20 > and the replay that every second, to make sure the traffic is=20 > all the time redirected to the host he wants to attack.=20 This is a good point. An attacker could fool us into changing our database just by modifying our outer headers. I hadn't thought of this. I think what you're saying is that the only way to prevent this, is to do a probe to 'confirm' the peer's new address, but that doing so might cause you to choose a bad path. Could you not do a probe (or some other exchange) JUST to the new address to verify that the peer is indeed reacheable on this new IP/port?. Of course you'd have to rate-limit this to avoid someone forcing you to build/send endless probes. >=20 > > I have however seen NAT mappings get lost many, many times. >=20 > Was the problem there NAT rebootting, or too long keepalives=20 > or something else?=20 I've seen it all :) =20 >=20 > > BTW, have you seen the number of home/SOHO router/NAT boxes you can=20 > > buy today for about $5. Reliability is not the first word=20 > that comes=20 > > to mind. >=20 > True, but in that case I would assume they know who to=20 > blame... :-) Still most of those small NAT boxes have enough=20 > memory and so small amount of traffic that they do not have=20 > really reason to remove NAT mappings very fast. And I do not=20 > think they crash that often. Again if they crash that will=20 > cause long delay anyways. Who are you going to call though? The guy who sold you a $10,000 box with a support contract, or some 1-800- support number which is now disconnected. ;) >=20 > > I'm willing to implement it both ways because the=20 > cost/complexity is=20 > > fairly low, and I can see how doing it via ESP detection=20 > only might be=20 > > more difficult for some vendors. >=20 > So perhaps we should say you MUST NOT do automatic update=20 > with IKEv2 packets (breaks the probing), but you MAY do it=20 > for ESP packets? It will add the another module causing=20 > address updates, and you need to make sure the policy for the=20 > MOBIKE and that automatic update module are same. >=20 > I really like the explicit address update because it will put=20 > the all policy decision about address changes in exactly one=20 > place, i.e in the MOBIKE module. It would be ideal, but I would also like to be able to recover from badly-behaving NAT boxes, if we can with a relatively low cost. > -- > kivinen@safenet-inc.com >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Sep 09 12:34:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDlpH-0003L2-N0 for mobike-archive@megatron.ietf.org; Fri, 09 Sep 2005 12:34:07 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13118 for ; Fri, 9 Sep 2005 12:34:04 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E2D16FB27D; Fri, 9 Sep 2005 12:34:01 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AE038FB246; Fri, 9 Sep 2005 12:34:00 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4477AFB24A; Fri, 9 Sep 2005 12:33:59 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id BF4ACFB240 for ; Fri, 9 Sep 2005 12:33:57 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j89GXjR29056; Fri, 9 Sep 2005 18:33:45 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j89GXiEd012512; Fri, 9 Sep 2005 18:33:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509091633.j89GXiEd012512@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? In-reply-to: Your message of Fri, 09 Sep 2005 13:02:29 +0300. Date: Fri, 09 Sep 2005 18:33:44 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: (I've split this away from issue 40.) The current version of the protocol draft does not require hosts that do not support NAT-T to use the "NAT prevention" feature. Francis has suggested that this "middle ground" should be eliminated; in other words, the initiator would always include either NAT_DETECTION_*_IP (if it supports NAT-T) or NAT_PREVENTION (it it doesn't) in all IKE_SA_INIT and UPDATE_SA_ADDRESSES messages. => you should explain why I'd like to eliminate this "middle ground": if none of the NAT_DETECTION_*_IP and NAT_PREVENTION is used, the addresses in the IP header are not protected because they are not "reflected" inside an IKE message. This opens the door at what I call the pseudo-transient NAT attack: an attacker in the path can patch headers in order to redirect the IPsec traffic to another node, usually in order to flood it. (it is pseudo-NAT because it acts like a NAT, it is transient because it has to be on the path only for some messages) Any comments about this? My gut feeling is that we should keep this middle ground; after all, implementations that don't bother to implement NAT-T and UDP encapsulation can still work through (manually configured) static NATs and some types of IPv4/v6 translators. NAT_PREVENTION also creates a denial-of-service vulnerability even when no malicious attackers are present: a misconfiguration or introduction of a non-malicious translator causes the peers not to use that path (and if it was the only one, connection fails). => my concern is there can be a malicious translator. Perhaps it is a bit paranoid but IMHO a security protocol has to be. Or as I put in my IETF63 slides, this is a "trade-off between DoS-ing yourself and religious beliefs". In my opinion, we don't need to settle this trade-off in the protocol spec by saying "MUST use NAT prevention if not using NAT-T": the functionality is available for those who really want to use it (and understanding NAT_PREVENTION is mandatory for the responder). => it seems you advocate for a SHOULD? Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Sep 10 03:52:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EE09t-0001gL-48 for mobike-archive@megatron.ietf.org; Sat, 10 Sep 2005 03:52:21 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21728 for ; Sat, 10 Sep 2005 03:52:17 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 2C2DEFB283; Sat, 10 Sep 2005 03:52:17 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 641B7FB277; Sat, 10 Sep 2005 03:52:16 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8A8A8FB27D; Sat, 10 Sep 2005 03:52:14 -0400 (EDT) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id 94507FB246 for ; Sat, 10 Sep 2005 03:52:13 -0400 (EDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8A7q7vN010027; Sat, 10 Sep 2005 10:52:09 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Sep 2005 10:52:07 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Sep 2005 10:52:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? Date: Sat, 10 Sep 2005 10:52:06 +0300 Message-ID: Thread-Topic: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? Thread-Index: AcW1XGPvqrBfRm4LRzyqGfNywKdEdQAf4iCA From: To: X-OriginalArrivalTime: 10 Sep 2005 07:52:08.0282 (UTC) FILETIME=[8B344BA0:01C5B5DC] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Francis Dupont wrote: =20 > =3D> you should explain why I'd like to eliminate this "middle > ground": if none of the NAT_DETECTION_*_IP and NAT_PREVENTION is > used, the addresses in the IP header are not protected because they > are not "reflected" inside an IKE message. This opens the door at > what I call the pseudo-transient NAT attack: an attacker in the path > can patch headers in order to redirect the IPsec traffic to another > node, usually in order to flood it. (it is pseudo-NAT because it > acts like a NAT, it is transient because it has to be on the path > only for some messages) Normal IKEv2 also has this problem, and nobody so far has complained that IKEv2 would be too insecure (well, except you, perhaps). IMHO=20 we shouldn't waste time solving imaginary problems that are not problems in the real world... > Or as I put in my IETF63 slides, this is a "trade-off=20 > between DoS-ing yourself and religious beliefs". In my opinion,=20 > we don't need to settle this trade-off in the protocol spec by=20 > saying "MUST use NAT prevention if not using NAT-T": the=20 > functionality is available for those who really want to use it=20 > (and understanding NAT_PREVENTION is mandatory for the responder). > =20 > =3D> it seems you advocate for a SHOULD? No, I advocate for "NAT prevention SHOULD NOT be enabled by default", since it is much more likely to DoS yourself than prevent any attacks. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Sep 10 05:56:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EE25l-0002kA-TO for mobike-archive@megatron.ietf.org; Sat, 10 Sep 2005 05:56:13 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25602 for ; Sat, 10 Sep 2005 05:56:01 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A17BAFB28A; Sat, 10 Sep 2005 05:55:58 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B053AFB27D; Sat, 10 Sep 2005 05:55:52 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 38DC2FB282; Sat, 10 Sep 2005 05:55:51 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id B2AFEFB277 for ; Sat, 10 Sep 2005 05:55:49 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8A9td316785; Sat, 10 Sep 2005 11:55:39 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8A9tdId016118; Sat, 10 Sep 2005 11:55:39 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509100955.j8A9tdId016118@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? In-reply-to: Your message of Sat, 10 Sep 2005 10:52:06 +0300. Date: Sat, 10 Sep 2005 11:55:39 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: Normal IKEv2 also has this problem, and nobody so far has complained that IKEv2 would be too insecure (well, except you, perhaps). => the default policy is to check the addresses in the IP header against identity and certificate payloads (cf the pki4ipsec I-D) so the problem appears only in some scenarios where MOBIKE is useful... IMHO we shouldn't waste time solving imaginary problems that are not problems in the real world... => if you need an exploit this can be done... If you need better examples of imaginary problems where we've already wasted time solving them I can give one. > => it seems you advocate for a SHOULD? No, I advocate for "NAT prevention SHOULD NOT be enabled by default", since it is much more likely to DoS yourself than prevent any attacks. => perhaps you consider that IPv6 is not (yet) the real world but IPv6 folks do *not* want this "SHOULD NOT" at all. As there is no NAT in IPv6 NAT prevention DoSes nobody and prevents an easy DoS attack. And if you'd like to speak about the real world, I'd like to know the proportion of implentations supporting NAT traversal by default for IPv4. IMHO we likely get NAT detection for IPv4 and NAT prevention for IPv6, solving the #41 in a way we can both agree about. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Sep 11 04:49:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EENWk-000257-Rr for mobike-archive@megatron.ietf.org; Sun, 11 Sep 2005 04:49:33 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24802 for ; Sun, 11 Sep 2005 04:49:19 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 32CC4FB28E; Sun, 11 Sep 2005 04:49:11 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 79A6FFB289; Sun, 11 Sep 2005 04:49:08 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A71A6FB28A; Sun, 11 Sep 2005 04:49:07 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id D7A8CFB283 for ; Sun, 11 Sep 2005 04:49:05 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8B8mt213376; Sun, 11 Sep 2005 10:48:55 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8B8mrrK019014; Sun, 11 Sep 2005 10:48:54 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509110848.j8B8mrrK019014@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko Subject: Re: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40) In-reply-to: Your message of Thu, 08 Sep 2005 16:11:58 +0300. <4320389E.7060908@piuha.net> Date: Sun, 11 Sep 2005 10:48:53 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: Here are some comments and suggested changes, embedded in Pasi's comments. Here's a suggested edit: ... MOBIKE is making it possible for a remote access VPN user to move from one address to another while keeping the connection with the VPN gateway active. => ... MOBIKE is making it possible for a remote access VPN user to maintain a single VPN connection with a gateway, despite moving from one address to another or having multiple addresses. Similar change in Section 1.1. Is there anything else Francis? => are you joking? Either we really take multihoming into account or we don't claim we deal with more than mobility. The charter indeed limits us to "failover" semantics of multihoming. => you already know that I don't argue for load balancing but for support of what I call the SCTP model of multihoming. But perhaps this is about IPsec SA movement granularity? => yes But we already discussed that earlier and arrived at a conclusion. => this is this conclusion I contest. BTW the charter explicitely mentions SCTP so either we fix the charter or we follow it or we make clear the document describes a partial solution and the work about the full solution will be done later (i.e., a change in the milestones). I tend to agree that its better to have a single mechanism that simply replaces the set, rather than a "diff" scheme. The latter would work better when there's a very large set of addresses, but I think simplicity is more valuable than covering that case. => this is a matter of taste. I am not convinced that sending the whole set at any change is really simpler than sending diffs but both give the same capability... In any case, we know that there are other limitations in our technology for dealing with large address sets, e.g, ability to probe for a working address pair. => this is just a side-effect of the "IKE will do everything by itself" direction which of course can't deal with large address sets. I'm not sure I understand how Section 2.2 specifically helps this, => Section 2.2 is about the management of a peer address set and the transport document relies only on this mechanism. so get your transport mode document polished so that we'll have something to discuss there! => IMHO the wording can be better (help me!), the references shall be fixed as soon as the protocol is published, I can't see something else. Hm. I'm not sure I understand this. I thought SPD deals with the unprotected packets, rather than the outer addresses, which I think we are working with. => the SPD-S entries have two main parts: - conditions: traffic selectors which are translated into TS payloads - an action, i.e., parameters for the protection with the IPsec protocol to use, ..., and the tunnel endpoint addresses. In the ASN.1 syntax we get: SPDEntry->IPsecEntry->processing->TunnelOptions->TunnelAddresses I would understand the SPD entry update if we were talking about transport mode, however. => no, this is explicitely about the tunnel mode and we speak about SPD entries only because this is the place the tunnel endpoint addresses are in the 2401bis formal description (this is why we also speak about better implementation dependent hints). >>- in 2.3 it should be clearer that NAT_XXX notifications are >>mandatory. => I should have written recommended, i.e., a SHOULD but not a MUST. Yes. Btw, we do intend to be fairly strict about re-opening issues. (We will re-open an issue only if we detect a new and/or serious technical problem.) => I'll ask the IESG what to do when a WG ignores its IETF charter. My concern here is we can't work about SCTP/multihoming support in IKEv2 (RFC 3554 for IKEv2 for instance) because it is in the MOBIKE charter. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 12 05:49:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEkwX-0006CC-P8 for mobike-archive@megatron.ietf.org; Mon, 12 Sep 2005 05:49:44 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07536 for ; Mon, 12 Sep 2005 05:49:32 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7BB14FB281; Mon, 12 Sep 2005 05:49:28 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 877C1FB27C; Mon, 12 Sep 2005 05:49:27 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9ABA5FB27D; Mon, 12 Sep 2005 05:49:25 -0400 (EDT) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id ABA30FB277 for ; Mon, 12 Sep 2005 05:49:24 -0400 (EDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8C9lgkc000410; Mon, 12 Sep 2005 12:47:43 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Sep 2005 12:49:18 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Sep 2005 12:49:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40) Date: Mon, 12 Sep 2005 12:49:17 +0300 Message-ID: Thread-Topic: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40) Thread-Index: AcW2rbLOizCOfeOuSnWg7RHgV/NVBAAz7ODQ From: To: X-OriginalArrivalTime: 12 Sep 2005 09:49:18.0608 (UTC) FILETIME=[3E6E6900:01C5B77F] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Francis Dupont wrote: > =3D> this is this conclusion I contest. BTW the charter explicitely > mentions SCTP so either we fix the charter or we follow it or we > make clear the document describes a partial solution and the work > about the full solution will be done later (i.e., a change in the > milestones). The WG charter lists six different issues for the WG to work=20 on. I don't think anyone has claimed that the first document, draft-ietf-mobike-protocol, will address all of them (and this fact should be pretty obvious to anyone who reads the draft). But I can add a note saying this more explicitly... > =3D> I'll ask the IESG what to do when a WG ignores its IETF charter. > My concern here is we can't work about SCTP/multihoming support > in IKEv2 (RFC 3554 for IKEv2 for instance) because it is in the > MOBIKE charter. I don't think splitting the work to several physical documents is "ignoring the charter"; neither is finishing some of those documents before others. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 12 07:52:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEmr8-00064p-Om for mobike-archive@megatron.ietf.org; Mon, 12 Sep 2005 07:52:17 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12707 for ; Mon, 12 Sep 2005 07:52:05 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 70452FB289; Mon, 12 Sep 2005 07:52:02 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DA1EAFB27F; Mon, 12 Sep 2005 07:52:01 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7BB58FB284; Mon, 12 Sep 2005 07:51:58 -0400 (EDT) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id 6AE3DFB27D for ; Mon, 12 Sep 2005 07:51:57 -0400 (EDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8CBosZL019253 for ; Mon, 12 Sep 2005 14:50:56 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Sep 2005 14:51:55 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Sep 2005 14:51:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Sep 2005 14:51:54 +0300 Message-ID: Thread-Topic: draft-ietf-mobike-protocol-02 Thread-Index: AcW3kF7tHdZgMsm9R+u9yQ/sVW83nw== From: To: X-OriginalArrivalTime: 12 Sep 2005 11:51:55.0497 (UTC) FILETIME=[5F7A9590:01C5B790] Subject: [Mobike] draft-ietf-mobike-protocol-02 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Hi everyone, I've submitted a new version of the protocol document to the secretariat; before it appears in the official I-D directory,=20 a temporary copy is available from http://people.nokia.net/~pasi/TEMP-draft-ietf-mobike-protocol-02.txt This version does _not_ claim to handle all the open issues (and we don't yet have rough consensus on how to handle them, either). I just wanted to get some kind of intermediate snapshot out so we can close=20 the less controversial issues. Especially the text on issue 34 should=20 be considered only a suggestion, and we may yet revert back to the -01 text depending on what decision we reach.=20 Here's the change log from Appendix A: o Moved MOBIKE_SUPPORTED from IKE_SA_INIT to IKE_AUTH (issues 35, 37). o Changed terminology related to NAT prohibition (issues 22, 24). o Rewrote much of the ADDITIONAL_*_ADDRESS text, added NO_ADDITIONAL_ADDRESSES notification. o Use NAT detection payloads to detect changes in NAT mappings (issue 34). o Removed separate PATH_TEST message (issue 34). o Clarified processing of UNACCEPTABLE_ADDRESSES when request has been sent using several different addresses (issue 36). o Clarified changing of ports 500/4500 (issue 33). o Updated security considerations (issues 27 and 28). o No need to include COOKIE2 in non-RR messages (issue 32). o Many editorial fixes and clarifications (issue 38, 40). o Use the terms initiator and responder more consistently. o Clarified that this document does not solve all problems in MOBIKE WG charter (issue 40). Comments are welcome! (please include the issue number in the=20 subject line when replying) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 12 09:06:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEo0k-0002OW-4g for mobike-archive@megatron.ietf.org; Mon, 12 Sep 2005 09:06:24 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16849 for ; Mon, 12 Sep 2005 09:06:03 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C4B38FB28A; Mon, 12 Sep 2005 09:06:01 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 24BF1FB27D; Mon, 12 Sep 2005 09:05:57 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9EC54FB282; Mon, 12 Sep 2005 09:05:55 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 3B5BBFB27D for ; Mon, 12 Sep 2005 09:05:54 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3584289848; Mon, 12 Sep 2005 16:05:52 +0300 (EEST) Message-ID: <43257D3C.5050207@piuha.net> Date: Mon, 12 Sep 2005 16:06:04 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Francis.Dupont@enst-bretagne.fr X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: >No, I advocate for "NAT prevention SHOULD NOT be enabled by default", >since it is much more likely to DoS yourself than prevent any attacks. > > This isn't necessarily the case. The most likely dos-yourself scenario is not enabling NAT traversal, because NATs exists in almost all public network access. Unless I'm mistaken, plain old ESP does not get through the most widely deployed NAT types. There's the small likelihood that you have some atypical NAT in between, and there NAT prevention makes a difference in the final outcome. But the typical case dominates, so we're essentially debating whether the failure in this configuration has a 95% or 96% probability of occurring... --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 12 09:15:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEo9f-0003gW-5Q for mobike-archive@megatron.ietf.org; Mon, 12 Sep 2005 09:15:29 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17176 for ; Mon, 12 Sep 2005 09:15:08 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 599AAFB28E; Mon, 12 Sep 2005 09:15:06 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 34D64FB27F; Mon, 12 Sep 2005 09:15:04 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B8FE8FB283; Mon, 12 Sep 2005 09:15:02 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 199FDFB27C for ; Mon, 12 Sep 2005 09:15:02 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 72EB489848; Mon, 12 Sep 2005 16:15:01 +0300 (EEST) Message-ID: <43257F62.4050702@piuha.net> Date: Mon, 12 Sep 2005 16:15:14 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? References: <200509100955.j8A9tdId016118@givry.rennes.enst-bretagne.fr> In-Reply-To: <200509100955.j8A9tdId016118@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit >=> perhaps you consider that IPv6 is not (yet) the real world but >IPv6 folks do *not* want this "SHOULD NOT" at all. As there is no NAT >in IPv6 NAT prevention DoSes nobody and prevents an easy DoS attack. > >And if you'd like to speak about the real world, I'd like to know >the proportion of implentations supporting NAT traversal by default >for IPv4. IMHO we likely get NAT detection for IPv4 and NAT prevention >for IPv6, solving the #41 in a way we can both agree about. > > Is there an IPv6 - IPv4 translation type where the middle ground would be useful even for an IPv6 host? If not, I would suggest leaving the middle ground away from v6 but allowing it in v4. ("NAT preventation SHOULD be enabled by default in IPv6 if NAT traversal is not enabled.") If yes, then I think the current text might suffice. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 12 09:56:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEomm-0001aA-CW for mobike-archive@megatron.ietf.org; Mon, 12 Sep 2005 09:56:01 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18665 for ; Mon, 12 Sep 2005 09:55:41 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1471DFB290; Mon, 12 Sep 2005 09:55:42 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AAD9AFB285; Mon, 12 Sep 2005 09:55:40 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C70E3FB28B; Mon, 12 Sep 2005 09:55:39 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 09783FB282 for ; Mon, 12 Sep 2005 09:55:39 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5D23189848; Mon, 12 Sep 2005 16:55:38 +0300 (EEST) Message-ID: <432588E7.8010301@piuha.net> Date: Mon, 12 Sep 2005 16:55:51 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40) References: <200509081523.j88FNYmF006724@givry.rennes.enst-bretagne.fr> In-Reply-To: <200509081523.j88FNYmF006724@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit >=> what is the real difference between MOBIKE multihoming support >and IKEv2 multihoming support, and, more important, is this difference >enough? > > My understanding of this difference is that in our current proposal, the peers can register their alternative addresses and failover to the other addresses if there's a connectivity problem in the currently used address. (I don't think you can do this in basic IKEv2, and personally, I think its a good tradeoff in terms of functionality vs. effort and configuration.) This is what I call the "failover" multihoming model. In the SCTP multihoming model we can choose more independently where to send data, even if there's still the concept of a primary (default) path. In the load balancing multihoming model we can send even the same stream over multiple paths, and still perform appropriate load balancing, congestion avoidance, and acknowledgement tasks. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 12 09:57:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEonv-0001o8-CW for mobike-archive@megatron.ietf.org; Mon, 12 Sep 2005 09:57:03 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18735 for ; Mon, 12 Sep 2005 09:56:53 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E6B8AFB297; Mon, 12 Sep 2005 09:56:53 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 42C23FB27D; Mon, 12 Sep 2005 09:56:52 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2DD7FFB27F; Mon, 12 Sep 2005 09:56:50 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 9B031FB27C for ; Mon, 12 Sep 2005 09:56:48 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C753389848; Mon, 12 Sep 2005 16:56:47 +0300 (EEST) Message-ID: <4325892C.8040201@piuha.net> Date: Mon, 12 Sep 2005 16:57:00 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40) References: <200509110848.j8B8mrrK019014@givry.rennes.enst-bretagne.fr> In-Reply-To: <200509110848.j8B8mrrK019014@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Francis Dupont wrote: >=> are you joking? Either we really take multihoming into account >or we don't claim we deal with more than mobility. > > Francis, it seems that we have multiple definitions of multihoming. Or multiple levels of support we could provide. I think it would be more productive to argue what type of multihoming to support, than to argue that we do or don't support multihoming. I suspect that the group's desire to do any specific type of multihoming relates very much to the expected usage. >=> you already know that I don't argue for load balancing but >for support of what I call the SCTP model of multihoming. > > Ok. > But perhaps this is about IPsec SA movement granularity? > >=> yes > > But we already discussed that earlier and arrived at a conclusion. > >=> this is this conclusion I contest. > Yes. But I'm sure you also understand that we can't keep on arguing over an issue for ever, we need to make decisions at certain points in time, even if sometimes there are people who disagree with those decisions. >BTW the charter explicitely >mentions SCTP so either we fix the charter or we follow it or we >make clear the document describes a partial solution and the work >about the full solution will be done later (i.e., a change in the >milestones). > > I think we have a pending milestone change coming in any case. E.g., what's the timeplan and interest for reduced tunnel overhead and pfkey work? Should the transport doc be in the milestones? I see the SCTP support as one of the use cases in the charter, along with the main use case of roaming VPN users. My understanding has been that we are not required to cover everything that we need to do in one document. Indeed the transport document has already been discussed as an extension over base MOBIKE. > so get your transport mode document polished so that we'll have > something to discuss there! > >=> IMHO the wording can be better (help me!), the references >shall be fixed as soon as the protocol is published, I can't see >something else. > > Ok. I'll take a look. > Hm. I'm not sure I understand this. I thought SPD > deals with the unprotected packets, rather than the > outer addresses, which I think we are working with. > >=> the SPD-S entries have two main parts: > - conditions: traffic selectors which are translated into TS payloads > - an action, i.e., parameters for the protection with the IPsec > protocol to use, ..., and the tunnel endpoint addresses. >In the ASN.1 syntax we get: >SPDEntry->IPsecEntry->processing->TunnelOptions->TunnelAddresses > > I would understand the SPD entry update if we > were talking about transport mode, however. > >=> no, this is explicitely about the tunnel mode and we speak about >SPD entries only because this is the place the tunnel endpoint >addresses are in the 2401bis formal description (this is why >we also speak about better implementation dependent hints). > > Ok. Thanks for the clarification. >=> I'll ask the IESG what to do when a WG ignores its IETF charter. >My concern here is we can't work about SCTP/multihoming support >in IKEv2 (RFC 3554 for IKEv2 for instance) because it is in the >MOBIKE charter. > > The charter allows and requires us to work on SCTP support. But it does not promise that our first document delivers this support. In fact, the charter makes it quite clear what the main scenario is. This should not prevent later support for SCTP, Mobile IP and other specific applications, however. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 12 10:22:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEpCw-0007OB-00 for mobike-archive@megatron.ietf.org; Mon, 12 Sep 2005 10:22:54 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21520 for ; Mon, 12 Sep 2005 10:22:43 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D8A1FFB29D; Mon, 12 Sep 2005 10:22:33 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 86F66FB293; Mon, 12 Sep 2005 10:22:32 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3CA6AFB298; Mon, 12 Sep 2005 10:22:31 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id A317DFB292 for ; Mon, 12 Sep 2005 10:22:30 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0A76589848; Mon, 12 Sep 2005 17:22:25 +0300 (EEST) Message-ID: <43258F2D.3020806@piuha.net> Date: Mon, 12 Sep 2005 17:22:37 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] issue 34 proposal References: <200509081527.j88FR8xd006762@givry.rennes.enst-bretagne.fr> In-Reply-To: <200509081527.j88FR8xd006762@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Francis Dupont wrote: >=> here NAT rebooting includes NAT loosing its state and unfortunately >this kind of events is more frequent and fast. > > This is true. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 12 11:11:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEpxd-0007jX-Qf for mobike-archive@megatron.ietf.org; Mon, 12 Sep 2005 11:11:10 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25077 for ; Mon, 12 Sep 2005 11:11:06 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A69A8FB28B; Mon, 12 Sep 2005 11:11:06 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F2BBCFB283; Mon, 12 Sep 2005 11:11:05 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 895AFFB284; Mon, 12 Sep 2005 11:11:03 -0400 (EDT) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id B7DA4FB282 for ; Mon, 12 Sep 2005 11:11:02 -0400 (EDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8CFA0c1014825; Mon, 12 Sep 2005 18:10:01 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Sep 2005 18:11:00 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Sep 2005 18:11:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? Date: Mon, 12 Sep 2005 18:10:59 +0300 Message-ID: Thread-Topic: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? Thread-Index: AcW3nBQEx3HRLHHHSA+fivpZp6VFwQADznkg From: To: X-OriginalArrivalTime: 12 Sep 2005 15:11:00.0247 (UTC) FILETIME=[2F1ACA70:01C5B7AC] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Jari Arkko wrote: > Is there an IPv6 - IPv4 translation type where the middle > ground would be useful even for an IPv6 host? >=20 > If not, I would suggest leaving the middle ground away > from v6 but allowing it in v4. ("NAT preventation SHOULD > be enabled by default in IPv6 if NAT traversal is not enabled.") >=20 > If yes, then I think the current text might suffice. To me it looks like IKEv2 w/tunnel mode IPsec could work through "Basic-NAT-PT" type v4/v6 translation [RFC2766] (even if the implementations don't support IKEv2 NAT-T). (But I haven't gone through all the details.) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 12 15:50:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEuK2-0004Yd-7q for mobike-archive@megatron.ietf.org; Mon, 12 Sep 2005 15:50:34 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11899 for ; Mon, 12 Sep 2005 15:50:24 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 68010FB27D; Mon, 12 Sep 2005 15:50:10 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C4CD4FB266; Mon, 12 Sep 2005 15:50:08 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2A4ACFB277; Mon, 12 Sep 2005 15:50:06 -0400 (EDT) Received: from newodin.ietf.org (unknown [132.151.6.50]) by machshav.com (Postfix) with ESMTP id 737D3FB246 for ; Mon, 12 Sep 2005 15:50:05 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EEuJW-0004ES-Vy; Mon, 12 Sep 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 12 Sep 2005 15:50:02 -0400 Cc: mobike@machshav.com Subject: [Mobike] I-D ACTION:draft-ietf-mobike-protocol-02.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IKEv2 Mobility and Multihoming Working Group of the IETF. Title : IKEv2 Mobility and Multihoming Protocol (MOBIKE) Author(s) : P. Eronen Filename : draft-ietf-mobike-protocol-02.txt Pages : 23 Date : 2005-9-12 This document describes the MOBIKE protocol, a mobility and multihoming extension to IKEv2. MOBIKE allows hosts to update the (outer) IP addresses associated with IKE and IPsec Security Associations (SAs). A mobile VPN client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another. Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the currently used one stops working. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobike-protocol-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobike-protocol-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobike-protocol-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-9-12130248.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobike-protocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobike-protocol-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-12130248.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --NextPart-- From mobike-bounces@machshav.com Mon Sep 12 15:51:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEuKn-0004nm-Ha for mobike-archive@megatron.ietf.org; Mon, 12 Sep 2005 15:51:23 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11936 for ; Mon, 12 Sep 2005 15:51:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id EE6B3FB27F; Mon, 12 Sep 2005 15:51:08 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1F87DFB27C; Mon, 12 Sep 2005 15:51:07 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id ED737FB27D; Mon, 12 Sep 2005 15:51:04 -0400 (EDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by machshav.com (Postfix) with SMTP id EB6BBFB266 for ; Mon, 12 Sep 2005 15:51:03 -0400 (EDT) Received: (qmail 13337 invoked from network); 12 Sep 2005 19:51:03 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.57.113 with login) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 12 Sep 2005 19:51:02 -0000 Message-ID: <002a01c5b7d3$494ca770$6701a8c0@adithya> From: "Mohan Parthasarathy" To: "Jari Arkko" , "Francis Dupont" References: <200509100955.j8A9tdId016118@givry.rennes.enst-bretagne.fr> <43257F62.4050702@piuha.net> Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? Date: Mon, 12 Sep 2005 12:50:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: Pasi.Eronen@nokia.com, mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > > >=> perhaps you consider that IPv6 is not (yet) the real world but > >IPv6 folks do *not* want this "SHOULD NOT" at all. As there is no NAT > >in IPv6 NAT prevention DoSes nobody and prevents an easy DoS attack. > > > >And if you'd like to speak about the real world, I'd like to know > >the proportion of implentations supporting NAT traversal by default > >for IPv4. IMHO we likely get NAT detection for IPv4 and NAT prevention > >for IPv6, solving the #41 in a way we can both agree about. > > > > > Is there an IPv6 - IPv4 translation type where the middle > ground would be useful even for an IPv6 host? > > If not, I would suggest leaving the middle ground away > from v6 but allowing it in v4. ("NAT preventation SHOULD > be enabled by default in IPv6 if NAT traversal is not enabled.") > This sounds reasonable to me. -mohan > If yes, then I think the current text might suffice. > > --Jari > > _______________________________________________ > 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 Thu Sep 15 06:41:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFrBj-0001m0-Il for mobike-archive@megatron.ietf.org; Thu, 15 Sep 2005 06:41:55 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02633 for ; Thu, 15 Sep 2005 06:41:51 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 05EB6FB266; Thu, 15 Sep 2005 06:41:49 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 27773FB249; Thu, 15 Sep 2005 06:41:42 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 60837FB24A; Thu, 15 Sep 2005 06:41:41 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id B64E7FB23C for ; Thu, 15 Sep 2005 06:41:40 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 52B3189848; Thu, 15 Sep 2005 13:41:38 +0300 (EEST) Message-ID: <43294FEC.70705@piuha.net> Date: Thu, 15 Sep 2005 13:41:48 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? References: <200509100955.j8A9tdId016118@givry.rennes.enst-bretagne.fr> <43257F62.4050702@piuha.net> <002a01c5b7d3$494ca770$6701a8c0@adithya> In-Reply-To: <002a01c5b7d3$494ca770$6701a8c0@adithya> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pasi.Eronen@nokia.com, mobike@machshav.com, Francis Dupont X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit I think we can close this one. Pasi tells us that there's a possibility that even in IPv6 some of the translation schemes could benefit from this. Even so, it may be quite reasonable to make the IPv6 default on NATs stricter than in IPv4. This seems to be supported by Mohan and Francis (and myself), so with the small number of folks that have participated this discussion, its propbably as close to consensus as we are going to get. So, I think we can make the document leave the middle ground away from v6 but allowing it in v4. ("NAT preventation SHOULD be enabled by default in IPv6 if NAT traversal is not enabled.", or words to that effect.) --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 15 07:06:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFrZ1-00089D-V9 for mobike-archive@megatron.ietf.org; Thu, 15 Sep 2005 07:06:00 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03672 for ; Thu, 15 Sep 2005 07:05:56 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5C873FB284; Thu, 15 Sep 2005 07:05:54 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4E139FB24A; Thu, 15 Sep 2005 07:05:48 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C1B97FB266; Thu, 15 Sep 2005 07:05:46 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 22C76FB249 for ; Thu, 15 Sep 2005 07:05:46 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5A2E489848; Thu, 15 Sep 2005 14:05:35 +0300 (EEST) Message-ID: <43295582.5080001@piuha.net> Date: Thu, 15 Sep 2005 14:05:38 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Mobike] issue 34 proposal References: <13E3DA8B48E17D4C96D261A36A23FCD685FA6A@xmb-rtp-208.amer.cisco.com> <17185.39148.232665.100290@fireball.kivinen.iki.fi> In-Reply-To: <17185.39148.232665.100290@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Tero Kivinen wrote: >So perhaps we should say you MUST NOT do automatic update with IKEv2 >packets (breaks the probing), but you MAY do it for ESP packets? > > This would work for me (and the complexity cost would be only on those implementations that actually do the MAY). --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 15 07:22:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFrpG-0004Lr-LQ for mobike-archive@megatron.ietf.org; Thu, 15 Sep 2005 07:22:46 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04279 for ; Thu, 15 Sep 2005 07:22:43 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A6CBEFB282; Thu, 15 Sep 2005 07:22:43 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3873EFB27F; Thu, 15 Sep 2005 07:22:43 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0D23EFB280; Thu, 15 Sep 2005 07:22:42 -0400 (EDT) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id 26356FB24A for ; Thu, 15 Sep 2005 07:22:41 -0400 (EDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8FBLYLw007301 for ; Thu, 15 Sep 2005 14:21:35 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Sep 2005 14:22:38 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Sep 2005 14:22:38 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issue 34 proposal Date: Thu, 15 Sep 2005 14:22:37 +0300 Message-ID: Thread-Topic: [Mobike] issue 34 proposal Thread-Index: AcW55bGRFbOLbUIISMGznRpsfUyD7gAAf5dA From: To: X-OriginalArrivalTime: 15 Sep 2005 11:22:38.0417 (UTC) FILETIME=[C76AB410:01C5B9E7] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Jari Arkko wrote: >=20 > Tero Kivinen wrote: >=20 > >So perhaps we should say you MUST NOT do automatic update with IKEv2 > >packets (breaks the probing), but you MAY do it for ESP packets?=20 > > =20 > > > This would work for me (and the complexity cost would be > only on those implementations that actually do the MAY). Sounds reasonable to me as well. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 15 07:54:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFsJi-00047U-87 for mobike-archive@megatron.ietf.org; Thu, 15 Sep 2005 07:54:14 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05557 for ; Thu, 15 Sep 2005 07:54:11 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 924A3FB27F; Thu, 15 Sep 2005 07:54:10 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2947AFB249; Thu, 15 Sep 2005 07:54:09 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4D1F8FB24A; Thu, 15 Sep 2005 07:54:07 -0400 (EDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by machshav.com (Postfix) with ESMTP id 02A62FB246 for ; Thu, 15 Sep 2005 07:54:06 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 15 Sep 2005 04:54:06 -0700 X-IronPort-AV: i="3.97,112,1125903600"; d="scan'208"; a="659968400:sNHT31463374" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8FBs24V001138; Thu, 15 Sep 2005 04:54:02 -0700 (PDT) From: stephane@cisco.com Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Sep 2005 07:54:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issue 34 proposal Date: Thu, 15 Sep 2005 07:54:00 -0400 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD68E4BA6@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Mobike] issue 34 proposal Thread-Index: AcW55bGRFbOLbUIISMGznRpsfUyD7gAAf5dAAADMCRA= To: , "Tero Kivinen" , "Jari Arkko" X-OriginalArrivalTime: 15 Sep 2005 11:54:01.0991 (UTC) FILETIME=[2A1D4970:01C5B9EC] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Just to clarify... If one does detect NAT change at ESP layer, what does one do? Do we do a return routability check on the new address before updating it's SADB? It would seem logical, but just want to make sure we're on the same page. Stephane.=20 > -----Original Message----- > From: mobike-bounces@machshav.com=20 > [mailto:mobike-bounces@machshav.com] On Behalf Of=20 > Pasi.Eronen@nokia.com > Sent: Thursday, September 15, 2005 7:23 AM > To: mobike@machshav.com > Subject: RE: [Mobike] issue 34 proposal >=20 > Jari Arkko wrote: > >=20 > > Tero Kivinen wrote: > >=20 > > >So perhaps we should say you MUST NOT do automatic update=20 > with IKEv2=20 > > >packets (breaks the probing), but you MAY do it for ESP packets? > > > =20 > > > > > This would work for me (and the complexity cost would be=20 > only on those=20 > > implementations that actually do the MAY). >=20 > Sounds reasonable to me as well. >=20 > Best regards, > Pasi > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 15 15:59:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFzsv-0002nE-En for mobike-archive@megatron.ietf.org; Thu, 15 Sep 2005 15:59:05 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02056 for ; Thu, 15 Sep 2005 15:58:59 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id ACD67FB27F; Thu, 15 Sep 2005 15:58:56 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BE709FB249; Thu, 15 Sep 2005 15:58:54 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1FEFCFB262; Thu, 15 Sep 2005 15:58:53 -0400 (EDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by machshav.com (Postfix) with SMTP id 3A61EFB246 for ; Thu, 15 Sep 2005 15:58:52 -0400 (EDT) Received: (qmail 12623 invoked from network); 15 Sep 2005 19:58:51 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.160.53.93 with login) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 15 Sep 2005 19:58:51 -0000 Message-ID: <002201c5ba2f$e154fdc0$6701a8c0@adithya> From: "Mohan Parthasarathy" To: "Jari Arkko" , "Tero Kivinen" References: <13E3DA8B48E17D4C96D261A36A23FCD685FA6A@xmb-rtp-208.amer.cisco.com><17185.39148.232665.100290@fireball.kivinen.iki.fi> <43295582.5080001@piuha.net> Subject: Re: [Mobike] issue 34 proposal Date: Thu, 15 Sep 2005 12:58:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > > >So perhaps we should say you MUST NOT do automatic update with IKEv2 > >packets (breaks the probing), but you MAY do it for ESP packets? > > > > > This would work for me (and the complexity cost would be > only on those implementations that actually do the MAY). > Agreed. -mohan > --Jari > > _______________________________________________ > 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 Thu Sep 15 16:02:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFzwU-0004RV-Ba for mobike-archive@megatron.ietf.org; Thu, 15 Sep 2005 16:02:47 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03025 for ; Thu, 15 Sep 2005 16:02:43 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 50567FB249; Thu, 15 Sep 2005 16:02:40 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4C3E9FB23E; Thu, 15 Sep 2005 16:02:37 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 456CAFB262; Thu, 15 Sep 2005 16:02:36 -0400 (EDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by machshav.com (Postfix) with SMTP id 58D11FB246 for ; Thu, 15 Sep 2005 16:02:35 -0400 (EDT) Received: (qmail 34871 invoked from network); 15 Sep 2005 20:02:34 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.160.53.93 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 15 Sep 2005 20:02:34 -0000 Message-ID: <002801c5ba30$66772cd0$6701a8c0@adithya> From: "Mohan Parthasarathy" To: , , "Tero Kivinen" , "Jari Arkko" References: <13E3DA8B48E17D4C96D261A36A23FCD68E4BA6@xmb-rtp-208.amer.cisco.com> Subject: Re: [Mobike] issue 34 proposal Date: Thu, 15 Sep 2005 13:02:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit I am assuming NAT change at ESP layer follows IKEv2 NAT-T i.e no return routability check. Otherwise, the speedup obtained by the traditional IKEv2 NAT-T is lost and there is no point in having this mechanism at all. -mohan ----- Original Message ----- From: To: ; "Tero Kivinen" ; "Jari Arkko" Cc: Sent: Thursday, September 15, 2005 4:54 AM Subject: RE: [Mobike] issue 34 proposal Just to clarify... If one does detect NAT change at ESP layer, what does one do? Do we do a return routability check on the new address before updating it's SADB? It would seem logical, but just want to make sure we're on the same page. Stephane. > -----Original Message----- > From: mobike-bounces@machshav.com > [mailto:mobike-bounces@machshav.com] On Behalf Of > Pasi.Eronen@nokia.com > Sent: Thursday, September 15, 2005 7:23 AM > To: mobike@machshav.com > Subject: RE: [Mobike] issue 34 proposal > > Jari Arkko wrote: > > > > Tero Kivinen wrote: > > > > >So perhaps we should say you MUST NOT do automatic update > with IKEv2 > > >packets (breaks the probing), but you MAY do it for ESP packets? > > > > > > > > This would work for me (and the complexity cost would be > only on those > > implementations that actually do the MAY). > > Sounds reasonable to me as well. > > Best regards, > Pasi > _______________________________________________ > 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 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 15 16:24:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG0Hr-0002Tx-0V for mobike-archive@megatron.ietf.org; Thu, 15 Sep 2005 16:24:51 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08562 for ; Thu, 15 Sep 2005 16:24:48 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 87F0DFB281; Thu, 15 Sep 2005 16:24:47 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BDA39FB280; Thu, 15 Sep 2005 16:24:44 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A024DFB280; Thu, 15 Sep 2005 16:24:42 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 087C8FB262 for ; Thu, 15 Sep 2005 16:24:41 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9C4C189848; Thu, 15 Sep 2005 23:24:39 +0300 (EEST) Message-ID: <4329D789.8050908@piuha.net> Date: Thu, 15 Sep 2005 23:20:25 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy Subject: Re: [Mobike] issue 34 proposal References: <13E3DA8B48E17D4C96D261A36A23FCD68E4BA6@xmb-rtp-208.amer.cisco.com> <002801c5ba30$66772cd0$6701a8c0@adithya> In-Reply-To: <002801c5ba30$66772cd0$6701a8c0@adithya> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Pasi.Eronen@nokia.com, Tero Kivinen X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit I think most of the speedup is in the detection part. --Jari Mohan Parthasarathy wrote: >I am assuming NAT change at ESP layer follows IKEv2 NAT-T i.e no return routability >check. Otherwise, the speedup obtained by the traditional IKEv2 NAT-T is lost and >there is no point in having this mechanism at all. > >-mohan > >----- Original Message ----- >From: >To: ; "Tero Kivinen" ; "Jari Arkko" >Cc: >Sent: Thursday, September 15, 2005 4:54 AM >Subject: RE: [Mobike] issue 34 proposal > > >Just to clarify... > >If one does detect NAT change at ESP layer, what does one do? > >Do we do a return routability check on the new address before updating >it's SADB? It would seem logical, but just want to make sure we're on >the same page. > >Stephane. > > > >>-----Original Message----- >>From: mobike-bounces@machshav.com >>[mailto:mobike-bounces@machshav.com] On Behalf Of >>Pasi.Eronen@nokia.com >>Sent: Thursday, September 15, 2005 7:23 AM >>To: mobike@machshav.com >>Subject: RE: [Mobike] issue 34 proposal >> >>Jari Arkko wrote: >> >> >>>Tero Kivinen wrote: >>> >>> >>> >>>>So perhaps we should say you MUST NOT do automatic update >>>> >>>> >>with IKEv2 >> >> >>>>packets (breaks the probing), but you MAY do it for ESP packets? >>>> >>>> >>>> >>>> >>>This would work for me (and the complexity cost would be >>> >>> >>only on those >> >> >>>implementations that actually do the MAY). >>> >>> >>Sounds reasonable to me as well. >> >>Best regards, >>Pasi >>_______________________________________________ >>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 > > > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Sep 16 00:41:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG825-0003an-QY for mobike-archive@megatron.ietf.org; Fri, 16 Sep 2005 00:41:06 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09993 for ; Fri, 16 Sep 2005 00:41:01 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id CA149FB282; Fri, 16 Sep 2005 00:41:00 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C563BFB249; Fri, 16 Sep 2005 00:40:54 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 00DEAFB262; Fri, 16 Sep 2005 00:40:53 -0400 (EDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by machshav.com (Postfix) with SMTP id F0300FB246 for ; Fri, 16 Sep 2005 00:40:51 -0400 (EDT) Received: (qmail 6634 invoked from network); 16 Sep 2005 04:40:51 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.160.53.93 with login) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 16 Sep 2005 04:40:51 -0000 Message-ID: <016c01c5ba78$cff8ad30$6701a8c0@adithya> From: "Mohan Parthasarathy" To: "Jari Arkko" References: <13E3DA8B48E17D4C96D261A36A23FCD68E4BA6@xmb-rtp-208.amer.cisco.com><002801c5ba30$66772cd0$6701a8c0@adithya> <4329D789.8050908@piuha.net> Subject: Re: [Mobike] issue 34 proposal Date: Thu, 15 Sep 2005 21:40:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: Pasi.Eronen@nokia.com, mobike@machshav.com, Tero Kivinen X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > I think most of the speedup is in the detection part. > Eventually, you want to recover faster too, right ? If it is going to take a roundtrip extra compared to IKEv2 NAT-T before you can use the address, how slower it is compared with the explicit update ? -mohan > --Jari > > Mohan Parthasarathy wrote: > > >I am assuming NAT change at ESP layer follows IKEv2 NAT-T i.e no return routability > >check. Otherwise, the speedup obtained by the traditional IKEv2 NAT-T is lost and > >there is no point in having this mechanism at all. > > > >-mohan > > > >----- Original Message ----- > >From: > >To: ; "Tero Kivinen" ; "Jari Arkko" > >Cc: > >Sent: Thursday, September 15, 2005 4:54 AM > >Subject: RE: [Mobike] issue 34 proposal > > > > > >Just to clarify... > > > >If one does detect NAT change at ESP layer, what does one do? > > > >Do we do a return routability check on the new address before updating > >it's SADB? It would seem logical, but just want to make sure we're on > >the same page. > > > >Stephane. > > > > > > > >>-----Original Message----- > >>From: mobike-bounces@machshav.com > >>[mailto:mobike-bounces@machshav.com] On Behalf Of > >>Pasi.Eronen@nokia.com > >>Sent: Thursday, September 15, 2005 7:23 AM > >>To: mobike@machshav.com > >>Subject: RE: [Mobike] issue 34 proposal > >> > >>Jari Arkko wrote: > >> > >> > >>>Tero Kivinen wrote: > >>> > >>> > >>> > >>>>So perhaps we should say you MUST NOT do automatic update > >>>> > >>>> > >>with IKEv2 > >> > >> > >>>>packets (breaks the probing), but you MAY do it for ESP packets? > >>>> > >>>> > >>>> > >>>> > >>>This would work for me (and the complexity cost would be > >>> > >>> > >>only on those > >> > >> > >>>implementations that actually do the MAY). > >>> > >>> > >>Sounds reasonable to me as well. > >> > >>Best regards, > >>Pasi > >>_______________________________________________ > >>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 > > > > > > > > > > _______________________________________________ > 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 Mon Sep 19 02:12:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHEt9-0005Ye-Lk for mobike-archive@megatron.ietf.org; Mon, 19 Sep 2005 02:12:27 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29119 for ; Mon, 19 Sep 2005 02:12:25 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 44A94FB280; Mon, 19 Sep 2005 02:12:26 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C12BCFB266; Mon, 19 Sep 2005 02:12:24 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8142AFB27F; Mon, 19 Sep 2005 02:12:23 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 4EDC9FB24A for ; Mon, 19 Sep 2005 02:12:22 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7015089852; Mon, 19 Sep 2005 09:12:21 +0300 (EEST) Message-ID: <432E56D0.3050906@piuha.net> Date: Mon, 19 Sep 2005 09:12:32 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pekka Savola Subject: [Mobike] FW: external mobike-protocol-02 review (editorial) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit (The editorial comments part) ---------- Forwarded message ---------- Date: Fri, 16 Sep 2005 14:22:53 +0300 (EEST) From: Pekka Savola To: mobike@machshav.com Subject: external mobike-protocol-02 review editorial --------- The initiator uses the set of responder addresses as an input to its address selection policy; it may at some later point decide to move the IPsec traffic to one of these addresses using the procedure described in Section 2.3. The responder normally does not use the set of initiator addresses for anything: the addresses are used only when the responder's own addresses change. ==> the last sentence needs a forward reference (Section 2.3.4 in my proposal). Such information itself MUST NOT be used to conclude than an update is needed: instead, the initiator SHOULD trigger dead peer detection. ==> I suggest adding explicit ref to DPD, especially when written in all-lowercase. The description in the rest of this section assumes that the initiator has already decided what the new addresses should be. When this decision has been made, the initiator o Updates the IKE_SA and the IPsec SAs associated with this IKE_SA with the new addresses, and sets the "pending_update" flag in the IKE_SA. ==> s/initiator/initiator:/ (and similar elsewhere) ==> personally, I might have just repeated the "initiator" in each bullet, but this is correct as well. o When the window size allows, sends an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification payload (which does not contain any data), and clears the "pending_update" flag. Initiator Responder ----------- ----------- HDR, SK { N(UPDATE_SA_ADDRESSES), [N(NAT_DETECTION_*_IP)], [N(NO_NATS_ALLOWED)], [N(COOKIE2)] } --> ==> s/flag/flag, for example as follows:/ (or something like..) <-- HDR, SK { [N(NAT_DETECTION_*_IP)], [N(COOKIE2)], } ==> s/COOKIE2)],/COOKIE2)]/ MOBIKE payload relating to updating addresses are encrypted, integrity protected, and replay protected using the IKE_SA. ==> s/are/is/ or s/payload/payloads/ However, security associations originally created for the protection of a specific flow between specific addresses may be moved through MOBIKE. ==> "moved" seems a bit odd choice for a word here? to use MOBIKE are configured in a manner that takes into account that a single security association can be used through different paths at different times. ==> maybe s/paths/paths of varying security properties/ to spell it out loud again reply is received, MOBIKE will usually consider the path working;if ==> s/;/; / -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 19 02:11:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHEsU-0005Ky-Ri for mobike-archive@megatron.ietf.org; Mon, 19 Sep 2005 02:11:49 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28442 for ; Mon, 19 Sep 2005 02:11:44 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 30C66FB280; Mon, 19 Sep 2005 02:11:41 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D4D6EFB24A; Mon, 19 Sep 2005 02:11:34 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4547DFB266; Mon, 19 Sep 2005 02:11:33 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 0115FFB249 for ; Mon, 19 Sep 2005 02:11:31 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C8F2589852; Mon, 19 Sep 2005 09:11:29 +0300 (EEST) Message-ID: <432E569C.1030406@piuha.net> Date: Mon, 19 Sep 2005 09:11:40 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pekka Savola Subject: [Mobike] FW: external mobike-protocol-02 review (technical) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit (Forwarding this because Pekka is not a subscriber on the list. And breaking to smaller pieces to get by the 10K limit...) ---------- Forwarded message ---------- Date: Fri, 16 Sep 2005 14:22:53 +0300 (EEST) From: Pekka Savola To: mobike@machshav.com Subject: external mobike-protocol-02 review Hi, (Note: I'm not subscribed) Jari asked me to review the MOBIKE protocol. Beware, I'm not really familiar with IKE, so there are probably things I have wrong or have missed. In any case, I thought the document was in a good shape and written in a manner where it should be easy to get interoperable implementations. It's also short -- good. What troubled me a bit was a significant number of forward references to other places in the spec, but this is understandable in the interest of avoiding text duplication. meta-issues ----------- It is assumed that issues such as transport mode (updating traffic selectors), PFKEY extensions, and tunnel overhead reduction will be handled in separate documents. ==> is transport mode even in the scope of the WG? I thought not, but the charter doesn't seem conclusive either way.. substantial ----------- Note that if some of the initiator's interfaces are behind a NAT (from the responder's point of view), the addresses received by the responder will be incorrect. This means the procedure for changing responder addresses described in Section 2.4 does not fully work when the initiator is behind a NAT. [...] ==> this is probably something that needs more air time. What does "does not fully work" mean? This also probably applies to the responder, though in different ways. This may also have security implications (exposing internal topology), and it may affect address selection (if for example smaller scope addresses are preferable, but actually belong to different sites). This probably needs a bunch of more analysis... This specification requires the use of return routability tests (under certain conditions) to limit the duration of any "third party bombing" attacks by off-path (relative to the victim) attackers. ==> this is not true. The spec only says RR _SHOULD_ be done before updating the SAs. There is no "MUST" for RR (whether before or after), but a "MAY skip" under certain conditions. The normativeness requirements need to be reviewed. Further, the procedures for handling the payloads (sections 2.3 and 2.4) should include a bullet point on RR tests and a pointer to 2.5. When the initiator is behind a NAT, it SHOULD include these payloads in DPD messages, and compare the received ... When MOBIKE is in use, the host not behind a NAT SHOULD NOT use the dynamic updates specified ... ==> How does the MOBIKE code know whether you're behind a NAT? Is this done automatically as part of IKEv2 NAT detection? Note that the spec doesn't seem to require running NAT presence detection so with current spec this can't be done. To give the initiator enough time to detect the error, the responder SHOULD use relatively long timeout intervals when, for instance, retransmitting IKEv2 requests or deciding whether to initiate dead peer detection. ==> "relatively long timeout intervals" is pretty ambiguous. While this may not affect the interoperability, shouldn't we be a bit more precise what kind of order of magnitude we're talking about here? Seconds? Ten seconds? 30 sec? Minutes? 10 minutes? Hours? The data associated with this notification is the SHA-1 hash [FIPS180-2] of the following data: ==> this spec is not algorithm-agile. (I can't find the ref right now where this is encouraged.) In this case, maybe it doesn't need to be considering the impact (I don't take a stance on that) -- but this probably deserves at least brief discussion in the security considerations section. semi-editorial -------------- ==> there seem to be a number of assumptions scattered throughout the document (e.g., relating to the responder not being behind a NAT) -- maybe it would be useful to put these as a new subsection of the Introduction? ==> I would also consider splitting out 2.3 in subsections for readability and more exact references. For example, initiator's first steps could be 2.3.1, Responder's reply 2.3.2, initiator's reply 2.3.3, and the exception 2.3.4. ==> It might make sense to spell out, probably in section 1.2, that apparently (AFAICS) the initiator never tells the responder which addresses it takes to use. It just sends UPDATE_SA_ADDRESSES with the updated addresses (inmplicit update). HDR, SK { IDi, [CERT], [IDr], AUTH, [CP(CFG_REQUEST)] SAi2, TSi, TSr, N(MOBIKE_SUPPORTED), [N(ADDITIONAL_*_ADDRESS)+] --> ==> this raises a minor issue of the normativeness of this spec with regard to the non-MOBIKE -related IKE payloads. The above exchange is just an example; some other payloads could be included as well, or some listed above could be omitted. Also the optional/mandatory status might change. Perhaps the document could give a short disclaimer about the IKE exchange examples. o The initiator receives a NAT_DETECTION_DESTINATION_IP payload that does not match the previous UPDATE_SA_ADDRESSES response (see Section 2.6 for a more detailed description). ==> In some cases, you use NAT_DETECTION_*_IP and in some NAT_DETECTION_DESTINATION_IP. I guess this is intentional, but I'd still review the cases carefully.. o Determines whether it has already received a newer UPDATE_SA_ADDRESSES request than this one (if the responder uses a window size greater than one, it is possible that requests are received out of order). If it has, a response message is sent, but no other action is taken. ==> at first, it was not clear to me what "a response message" referred to. An unspecified response? Probably you meant the normal response specified a few bullets down but this was not unambiguous. There is one additional issue that must be taken into account. If the INFORMATIONAL request has been sent to several different addresses (i.e., the destination address in the IKE_SA has been updated after the request was first sent), ... ==> s/If the/If the same/ (?) ==> this is actually a good issue in more general. Is it worth the effort to do so in the first place? That is, couldn't we just specify that the requests be sent with different cookies for each destination. I don't think a hash is computationally all that expensive. That would simplify the spec and eliminate an extra roundtrip in some cases. IKEv2 requires that if an IPsec endpoint discovers a NAT between it and its correspondent, it MUST send all subsequent traffic to and from port 4500. To simplify things, implementations that support both this specification and NAT Traversal MUST change to port 4500 if the correspondent also supports both, even if no NAT was detected between them (this way, there is no need to change the ports later). ==> While this seems to be a logical place to talk about this, I'm troubled. The title is "NAT Prohibition". What about MOBIKE implementations which don't implement NAT prohibition (I guess that's OK). The above requirement is more general though -- not really anything to with NAT prohibition. These kind of more generic requirements should be placed in a much more prominent place in the spec. NO_NATS_ALLOWED payloads can also be included when changing the addresses of IPsec SAs (see Section 2.3) and updating the additional addresses (see Section 2.4). An initiator using this "NAT prohibition" feature includes a NO_NATS_ALLOWED payload in all address update messages. ==> s/includes/MUST include/ or..? 3.1 MOBIKE_SUPPORTED Notification Payload ==> note that the IKEv2 spec refers these as "Notify Payloads" (at least in some places of the spec; "Notification" is also mentioned though)..? The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY- IANA(16396..40959). ==> per http://www.ietf.org/internet-drafts/draft-narten-iana-considerations-rfc2434bis-02.txt, thse types should be named TBD-BY-IANA1, ...., TBD-BY-IANAN (or something like that), so we know IANA has assigned a separate value for each and it can be easily search-n-replaced. I'd also suggest dropping the assignment range from here, and giving that guidance in IANA Considerations. of the stack, such as properly dealing with ICMP errors [ICMPAttacks] ==> some folks may argue that what ICMPattacks proposes may not be "proper". So, maybe find a different word for "proper", or use something like "as validating ICMP errors" which takes no stance on whether it's useful or not. [IPsecArch] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), March 2005. ==> this should probably be under normative refs? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 19 06:41:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHJ5T-0002O5-BW for mobike-archive@megatron.ietf.org; Mon, 19 Sep 2005 06:41:27 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10994 for ; Mon, 19 Sep 2005 06:41:23 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id BFA4AFB27F; Mon, 19 Sep 2005 06:41:24 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F0128FB24A; Mon, 19 Sep 2005 06:41:22 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 440F1FB266; Mon, 19 Sep 2005 06:41:21 -0400 (EDT) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id B597DFB246 for ; Mon, 19 Sep 2005 06:41:19 -0400 (EDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8JAdJmD032502; Mon, 19 Sep 2005 13:39:19 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Sep 2005 13:40:30 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Sep 2005 13:40:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] FW: external mobike-protocol-02 review (editorial) (issue 43) Date: Mon, 19 Sep 2005 13:40:14 +0300 Message-ID: Thread-Topic: [Mobike] FW: external mobike-protocol-02 review (editorial) Thread-Index: AcW84TSC9gbGCEGpSfew0Kk7nyO0rwAJROCA From: To: X-OriginalArrivalTime: 19 Sep 2005 10:40:14.0630 (UTC) FILETIME=[84DA9C60:01C5BD06] Cc: pekkas@netcore.fi X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Thanks for catching these... they are now filed as issue 43, and I will take them into account in version -03. Best regards, Pasi > -----Original Message----- > From: mobike-bounces@machshav.com=20 > [mailto:mobike-bounces@machshav.com]On > Behalf Of ext Jari Arkko > Sent: Monday, September 19, 2005 9:13 AM > To: MOBIKE Mailing List > Cc: Pekka Savola > Subject: [Mobike] FW: external mobike-protocol-02 review (editorial) >=20 >=20 > (The editorial comments part) >=20 > ---------- Forwarded message ---------- > Date: Fri, 16 Sep 2005 14:22:53 +0300 (EEST) > From: Pekka Savola > To: mobike@machshav.com > Subject: external mobike-protocol-02 review >=20 > editorial > --------- >=20 > The initiator uses the set of responder addresses as an=20 > input to its > address selection policy; it may at some later point decide to move > the IPsec traffic to one of these addresses using the procedure > described in Section 2.3. The responder normally does not use the > set of initiator addresses for anything: the addresses are=20 > used only > when the responder's own addresses change. >=20 > =3D=3D> the last sentence needs a forward reference (Section 2.3.4 in = my > proposal). >=20 > Such information itself MUST NOT be used to conclude than > an update is needed: instead, the initiator SHOULD trigger=20 > dead peer > detection. >=20 > =3D=3D> I suggest adding explicit ref to DPD, especially when written = in > all-lowercase. >=20 > The description in the rest of this section assumes that the > initiator has already decided what the new addresses=20 > should be. When > this decision has been made, the initiator >=20 > o Updates the IKE_SA and the IPsec SAs associated with this IKE_SA > with the new addresses, and sets the "pending_update"=20 > flag in the > IKE_SA. >=20 > =3D=3D> s/initiator/initiator:/ (and similar elsewhere) > =3D=3D> personally, I might have just repeated the "initiator" in=20 > each bullet, > but this is correct as well. >=20 > o When the window size allows, sends an INFORMATIONAL request > containing the UPDATE_SA_ADDRESSES notification payload (which > does not contain any data), and clears the=20 > "pending_update" flag. >=20 > Initiator Responder > ----------- ----------- > HDR, SK { N(UPDATE_SA_ADDRESSES), > [N(NAT_DETECTION_*_IP)], > [N(NO_NATS_ALLOWED)], > [N(COOKIE2)] } --> >=20 > =3D=3D> s/flag/flag, for example as follows:/ (or something like..) >=20 > <-- HDR, SK { [N(NAT_DETECTION_*_IP)], > [N(COOKIE2)], } > =3D=3D> s/COOKIE2)],/COOKIE2)]/ >=20 > MOBIKE payload relating to updating addresses are encrypted, > integrity protected, and replay protected using the IKE_SA. >=20 > =3D=3D> s/are/is/ or s/payload/payloads/ >=20 > However, security associations originally created for the=20 > protection > of a specific flow between specific addresses may be moved through > MOBIKE. >=20 > =3D=3D> "moved" seems a bit odd choice for a word here? >=20 > to use MOBIKE are configured in a manner that takes into=20 > account that > a single security association can be used through=20 > different paths at > different times. >=20 > =3D=3D> maybe s/paths/paths of varying security properties/ to=20 > spell it out > loud again >=20 > reply is received, MOBIKE will usually consider the path working;if >=20 > =3D=3D> s/;/; / >=20 >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 19 10:54:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHN2a-0005He-U3 for mobike-archive@megatron.ietf.org; Mon, 19 Sep 2005 10:54:45 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26199 for ; Mon, 19 Sep 2005 10:54:40 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id F3FB3FB284; Mon, 19 Sep 2005 10:54:33 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C8E81FB281; Mon, 19 Sep 2005 10:54:32 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 15D77FB282; Mon, 19 Sep 2005 10:54:31 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id B90A6FB27C for ; Mon, 19 Sep 2005 10:54:29 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8JErr802371; Mon, 19 Sep 2005 16:53:53 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8JErqNW065041; Mon, 19 Sep 2005 16:53:53 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509191453.j8JErqNW065041@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? In-reply-to: Your message of Mon, 12 Sep 2005 16:15:14 +0300. <43257F62.4050702@piuha.net> Date: Mon, 19 Sep 2005 16:53:52 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: Is there an IPv6 - IPv4 translation type where the middle ground would be useful even for an IPv6 host? => Mobike is not supposed to support the crossed-version case. If not, I would suggest leaving the middle ground away from v6 but allowing it in v4. ("NAT preventation SHOULD be enabled by default in IPv6 if NAT traversal is not enabled.") => I don't like to keep a security hole in a default policy. If yes, then I think the current text might suffice. => I find something strange: when I signaled the issue to Mobile IP folks (the issue is common to signalings with NAT traversal), they changed immediately their specs to mitigate the issue (cf RFC 3519). When I signal it to IPsec folks, it seems it is not a real issue. Usually, arrogance is more for French guys... So, please do what is needed, and don't believe I'll try to delay IKEv2 with this (i.e., now it is a Mobike issue). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 19 10:58:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHN67-00064i-DU for mobike-archive@megatron.ietf.org; Mon, 19 Sep 2005 10:58:23 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26892 for ; Mon, 19 Sep 2005 10:58:18 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 33BF2FB286; Mon, 19 Sep 2005 10:58:19 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 75E57FB282; Mon, 19 Sep 2005 10:58:16 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B67DAFB284; Mon, 19 Sep 2005 10:58:14 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 6425CFB281 for ; Mon, 19 Sep 2005 10:58:13 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8JEvg802862; Mon, 19 Sep 2005 16:57:42 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8JEvgom065079; Mon, 19 Sep 2005 16:57:42 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509191457.j8JEvgom065079@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko Subject: Re: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40) In-reply-to: Your message of Mon, 12 Sep 2005 16:55:51 +0300. <432588E7.8010301@piuha.net> Date: Mon, 19 Sep 2005 16:57:42 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: >=> what is the real difference between MOBIKE multihoming support >and IKEv2 multihoming support, and, more important, is this difference >enough? My understanding of this difference is that in our current proposal, the peers can register their alternative addresses and failover to the other addresses if there's a connectivity problem in the currently used address. (I don't think you can do this in basic IKEv2, and personally, I think its a good tradeoff in terms of functionality vs. effort and configuration.) This is what I call the "failover" multihoming model. In the SCTP multihoming model we can choose more independently where to send data, even if there's still the concept of a primary (default) path. In the load balancing multihoming model we can send even the same stream over multiple paths, and still perform appropriate load balancing, congestion avoidance, and acknowledgement tasks. => fine definition. My concern is the SCTP model and SCTP itself is in the charter, so according to its own charter the WG doesn't provide *yet* a good enough support to multihoming... Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 19 11:07:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHNF4-0001ID-1h for mobike-archive@megatron.ietf.org; Mon, 19 Sep 2005 11:07:38 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29237 for ; Mon, 19 Sep 2005 11:07:33 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7573BFB283; Mon, 19 Sep 2005 11:07:31 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4B8F7FB281; Mon, 19 Sep 2005 11:07:29 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 693F4FB282; Mon, 19 Sep 2005 11:07:27 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 18B8BFB27C for ; Mon, 19 Sep 2005 11:07:26 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8JF6rG03641; Mon, 19 Sep 2005 17:06:53 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8JF6rl8065143; Mon, 19 Sep 2005 17:06:53 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509191506.j8JF6rl8065143@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko Subject: Re: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40) In-reply-to: Your message of Mon, 12 Sep 2005 16:57:00 +0300. <4325892C.8040201@piuha.net> Date: Mon, 19 Sep 2005 17:06:53 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: Francis, it seems that we have multiple definitions of multihoming. => failover, SCTP-like and load balancing (cf your previous message). I suspect that the group's desire to do any specific type of multihoming relates very much to the expected usage. Yes. But I'm sure you also understand that we can't keep on arguing over an issue for ever, we need to make decisions at certain points in time, even if sometimes there are people who disagree with those decisions. => you have to choose a position, for instance fix the charter. You should not use contradictory arguments to answer to my issue. I think we have a pending milestone change coming in any case. E.g., what's the timeplan and interest for reduced tunnel overhead and pfkey work? Should the transport doc be in the milestones? I see the SCTP support as one of the use cases in the charter, along with the main use case of roaming VPN users. My understanding has been that we are not required to cover everything that we need to do in one document. => so the issue is "closed" only for the current document? Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 19 11:13:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHNKx-0003sZ-8o for mobike-archive@megatron.ietf.org; Mon, 19 Sep 2005 11:13:43 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01025 for ; Mon, 19 Sep 2005 11:13:39 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 21C36FB284; Mon, 19 Sep 2005 11:13:41 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B33E9FB281; Mon, 19 Sep 2005 11:13:39 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 571FAFB282; Mon, 19 Sep 2005 11:13:38 -0400 (EDT) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id CDD4EFB27C for ; Mon, 19 Sep 2005 11:13:36 -0400 (EDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8JFDYNA003771; Mon, 19 Sep 2005 18:13:34 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Sep 2005 18:13:34 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Sep 2005 18:13:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? Date: Mon, 19 Sep 2005 18:13:33 +0300 Message-ID: Thread-Topic: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? Thread-Index: AcW9Kh4ps1s9BJBcRTmu7Pa8cZx6IAAAYHbA From: To: X-OriginalArrivalTime: 19 Sep 2005 15:13:34.0511 (UTC) FILETIME=[B3F1DBF0:01C5BD2C] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Francis Dupont wrote: > =3D> I find something strange: when I signaled the issue to > Mobile IP folks (the issue is common to signalings with NAT > traversal), they changed immediately their specs to mitigate > the issue (cf RFC 3519). When I signal it to IPsec folks, it > seems it is not a real issue. Usually, arrogance is more for > French guys... So, please do what is needed, and don't believe > I'll try to delay IKEv2 with this (i.e., now it is a Mobike > issue). I'm curious, how exactly does RFC 3519 mitigate this issue? Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 19 11:15:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHNMT-0004gj-Tz for mobike-archive@megatron.ietf.org; Mon, 19 Sep 2005 11:15:18 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01473 for ; Mon, 19 Sep 2005 11:15:13 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 94F7DFB284; Mon, 19 Sep 2005 11:15:14 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 685BAFB281; Mon, 19 Sep 2005 11:15:13 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F3032FB282; Mon, 19 Sep 2005 11:15:11 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id C4C94FB27C for ; Mon, 19 Sep 2005 11:15:10 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8JFF1G04572; Mon, 19 Sep 2005 17:15:01 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8JFF1pt065198; Mon, 19 Sep 2005 17:15:02 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509191515.j8JFF1pt065198@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? In-reply-to: Your message of Mon, 12 Sep 2005 18:10:59 +0300. Date: Mon, 19 Sep 2005 17:15:01 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, jari.arkko@piuha.net X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: To me it looks like IKEv2 w/tunnel mode IPsec could work through "Basic-NAT-PT" type v4/v6 translation [RFC2766] (even if the implementations don't support IKEv2 NAT-T). (But I haven't gone through all the details.) => for instance how the NAT-PT translates the inner header (:-). Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 19 11:25:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHNWX-0003ig-OH for mobike-archive@megatron.ietf.org; Mon, 19 Sep 2005 11:25:41 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02966 for ; Mon, 19 Sep 2005 11:25:35 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id DA98AFB285; Mon, 19 Sep 2005 11:25:36 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CA566FB282; Mon, 19 Sep 2005 11:25:35 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E14A0FB283; Mon, 19 Sep 2005 11:25:33 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 83627FB281 for ; Mon, 19 Sep 2005 11:25:32 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8JFPPG05214; Mon, 19 Sep 2005 17:25:25 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8JFPPP2065325; Mon, 19 Sep 2005 17:25:25 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509191525.j8JFPPP2065325@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? In-reply-to: Your message of Mon, 19 Sep 2005 18:13:33 +0300. Date: Mon, 19 Sep 2005 17:25:25 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: I'm curious, how exactly does RFC 3519 mitigate this issue? => short lifetimes (so the attacker has to stay and increases its chance to be caught). The whole thing is explained in the security considerations... Francis.Dupont@enst-bretagne.fr PS: mobike has no binding lifetimes (nor in fact bindings, its support is for readdressing not mobility). _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 19 11:42:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHNmZ-0008Hp-Kx for mobike-archive@megatron.ietf.org; Mon, 19 Sep 2005 11:42:15 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03801 for ; Mon, 19 Sep 2005 11:42:11 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 59116FB285; Mon, 19 Sep 2005 11:42:13 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3B15EFB282; Mon, 19 Sep 2005 11:42:12 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CBA0DFB283; Mon, 19 Sep 2005 11:42:10 -0400 (EDT) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id E8FC0FB281 for ; Mon, 19 Sep 2005 11:42:09 -0400 (EDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8JFesnI012966; Mon, 19 Sep 2005 18:40:55 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Sep 2005 18:42:07 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Sep 2005 18:42:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? Date: Mon, 19 Sep 2005 18:42:06 +0300 Message-ID: Thread-Topic: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? Thread-Index: AcW9LnSruY/ZLdXfSVu+rBbIvufouQAAQI+A From: To: X-OriginalArrivalTime: 19 Sep 2005 15:42:07.0423 (UTC) FILETIME=[B0EB7CF0:01C5BD30] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Francis Dupont wrote: > In your previous mail you wrote: >=20 > I'm curious, how exactly does RFC 3519 mitigate this issue? > =20 > =3D> short lifetimes (so the attacker has to stay and increases its > chance to be caught). The whole thing is explained in the security > considerations... >=20 > Francis.Dupont@enst-bretagne.fr >=20 > PS: mobike has no binding lifetimes (nor in fact bindings, its=20 > support is for readdressing not mobility). There's also an important difference to MIP4: there the tunnel is not encrypted, so redirecting the traffic allows the attacker to eavesdrop and modify the packets.=20 In MOBIKE, this is mainly a DoS thing, and although we don't have binding lifetimes, we do have dead peer detection and=20 return routability check that force the attacker to stay there to continue the attack forever. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 19 11:46:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHNqk-0001HM-A2 for mobike-archive@megatron.ietf.org; Mon, 19 Sep 2005 11:46:34 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03978 for ; Mon, 19 Sep 2005 11:46:30 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C682EFB285; Mon, 19 Sep 2005 11:46:29 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C54F7FB282; Mon, 19 Sep 2005 11:46:28 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A39C5FB283; Mon, 19 Sep 2005 11:46:27 -0400 (EDT) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id C0C4FFB281 for ; Mon, 19 Sep 2005 11:46:26 -0400 (EDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8JFkJeK012263; Mon, 19 Sep 2005 18:46:24 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Sep 2005 18:46:23 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Sep 2005 18:46:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? Date: Mon, 19 Sep 2005 18:46:22 +0300 Message-ID: Thread-Topic: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? Thread-Index: AcW9LQbQAJyDRwXmQRiYcvC+FzV+FAAAAthA From: To: , X-OriginalArrivalTime: 19 Sep 2005 15:46:23.0337 (UTC) FILETIME=[4974DD90:01C5BD31] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Francis Dupont wrote: > In your previous mail you wrote: >=20 > To me it looks like IKEv2 w/tunnel mode IPsec could work through > "Basic-NAT-PT" type v4/v6 translation [RFC2766] (even if the > implementations don't support IKEv2 NAT-T). > =20 > (But I haven't gone through all the details.) > =20 > =3D> for instance how the NAT-PT translates the inner header (:-). Well, it can't do that, of course -- but it's not necessarily needed, because there's no need for the IP versions in inner and outer headers to match. Consider a case where we have a "remote access" VPN client connected=20 to, say, IPv6-only GPRS/UMTS network, and a corporate VPN gateway connected to IPv4 Internet (and presumably some IPv4 "intranet" or=20 other protected network). If the IPv6 network has "Basic-NAT-PT" deployed, the client could contact the gateway as usual (obtaining a new IPv4 address from the protected network using configuration payloads, etc.). While I'm not very familiar with NAT-PT, to me it looks like this would actually work just fine with normal IKEv2 (without NAT-T); and the change you're proposing would forbid that (or force the use of IKEv2 NAT-Traversal also for IPv6 :-) (Well, that would be needed anyway once someone starts=20 deploying IPv6 NATs :-) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 19 11:58:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHO2L-0004RZ-Cc for mobike-archive@megatron.ietf.org; Mon, 19 Sep 2005 11:58:33 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04594 for ; Mon, 19 Sep 2005 11:58:29 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 8FB2AFB283; Mon, 19 Sep 2005 11:58:30 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B783EFB281; Mon, 19 Sep 2005 11:58:28 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B3754FB282; Mon, 19 Sep 2005 11:58:26 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 4A2E9FB27C for ; Mon, 19 Sep 2005 11:58:25 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8JFw4M08581; Mon, 19 Sep 2005 17:58:04 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8JFw3Op065579; Mon, 19 Sep 2005 17:58:04 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509191558.j8JFw3Op065579@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? In-reply-to: Your message of Mon, 19 Sep 2005 18:42:06 +0300. Date: Mon, 19 Sep 2005 17:58:03 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: > PS: mobike has no binding lifetimes (nor in fact bindings, its > support is for readdressing not mobility). There's also an important difference to MIP4: there the tunnel is not encrypted, so redirecting the traffic allows the attacker to eavesdrop and modify the packets. => the main attack is to redirect a lot of traffic to a third party in order to overload it or its access network... BTW IPsec doesn't imply encrypted (even to encrypt is usually no more expensive so the option is very often taken by default). In MOBIKE, this is mainly a DoS thing, => yes, and for DoS to be encrypted is better! I am afraid the common traffic between two SGs is larger than between MN and HA. and although we don't have binding lifetimes, we do have dead peer detection and => dead peer detection can be less than enough (cf bogus keepalive stuff in RFC 3519). return routability check that force the attacker to stay there to continue the attack forever. => yes, mobile ip and mobike have different weapons. My concern is they share the same issue but the WGs react in very different ways. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 19 12:18:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHOLq-00089f-NR for mobike-archive@megatron.ietf.org; Mon, 19 Sep 2005 12:18:42 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05616 for ; Mon, 19 Sep 2005 12:18:39 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 07EC9FB285; Mon, 19 Sep 2005 12:18:40 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 632ACFB282; Mon, 19 Sep 2005 12:18:37 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DA126FB283; Mon, 19 Sep 2005 12:18:35 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 617C9FB281 for ; Mon, 19 Sep 2005 12:18:34 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8JGILM10829; Mon, 19 Sep 2005 18:18:22 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8JGIMVq065654; Mon, 19 Sep 2005 18:18:22 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509191618.j8JGIMVq065654@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? In-reply-to: Your message of Mon, 19 Sep 2005 18:46:22 +0300. Date: Mon, 19 Sep 2005 18:18:22 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: > => for instance how the NAT-PT translates the inner header (:-). Well, it can't do that, of course -- but it's not necessarily needed, because there's no need for the IP versions in inner and outer headers to match. => if the inner header doesn't need to be translated I recommend to use something else than NAT-PT. BTW many implementations don't support crossed-version tunnels (they should but they don't!) Consider a case where we have a "remote access" VPN client connected to, say, IPv6-only GPRS/UMTS network, and a corporate VPN gateway connected to IPv4 Internet (and presumably some IPv4 "intranet" or other protected network). If the IPv6 network has "Basic-NAT-PT" deployed, the client could contact the gateway as usual (obtaining a new IPv4 address from the protected network using configuration payloads, etc.). => you are using IPsec tunnels as a transition mechanism and in the real world it works only with NAT-T. While I'm not very familiar with NAT-PT, to me it looks like this would actually work just fine with normal IKEv2 (without NAT-T); => IMHO you need NAT-T exactly for the same usual reasons. and the change you're proposing would forbid that (or force the use of IKEv2 NAT-Traversal also for IPv6 :-) => it is not a real IPv6 and NAT-T is needed... (Well, that would be needed anyway once someone starts deploying IPv6 NATs :-) => there is no need for IPv6 NATs (this subject is as popular in IPv6 lists than changing text for something for RFCs in the IETF one :-). PS: the standard solution for your example is to tunnel IPv4 over IPv6 (DTSM & co). When you add IPsec you have the choice between double encapsulation or to NAT-PT the outer header (seems simpler but you get all the NAT and NAT-PT issues...). Regards Francis.Dupont@enst-bretagne.fr PS: NAT-PT is enough problematic that it is being made historic. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 19 13:00:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHP02-0003tK-Fh for mobike-archive@megatron.ietf.org; Mon, 19 Sep 2005 13:00:17 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07477 for ; Mon, 19 Sep 2005 13:00:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9F0E8FB283; Mon, 19 Sep 2005 13:00:12 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 99B79FB27C; Mon, 19 Sep 2005 13:00:05 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D7B20FB282; Mon, 19 Sep 2005 12:31:38 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id 6B1DCFB27C for ; Mon, 19 Sep 2005 12:31:36 -0400 (EDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8JGVXG1005171; Mon, 19 Sep 2005 19:31:35 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Sep 2005 19:31:34 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Sep 2005 19:31:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] FW: external mobike-protocol-02 review (technical) (issue 42) Date: Mon, 19 Sep 2005 19:31:33 +0300 Message-ID: Thread-Topic: [Mobike] FW: external mobike-protocol-02 review (technical) Thread-Index: AcW84R2Sl9ll7016SbCh231LdQ2HGgAVhkpg From: To: X-OriginalArrivalTime: 19 Sep 2005 16:31:34.0391 (UTC) FILETIME=[995EE070:01C5BD37] X-Mailman-Approved-At: Mon, 19 Sep 2005 13:00:03 -0400 Cc: pekkas@netcore.fi X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: >=20 > (Note: I'm not subscribed) >=20 > Jari asked me to review the MOBIKE protocol. Beware, I'm not > really familiar with IKE, so there are probably things I have > wrong or have missed. Thanks for your thorough review! (I've filed it as issue #43). > In any case, I thought the document was in a good shape and > written in a manner where it should be easy to get > interoperable implementations. It's also short -- good. What > troubled me a bit was a significant number of forward > references to other places in the spec, but this is > understandable in the interest of avoiding text duplication. >=20 >=20 > meta-issues > ----------- > It is assumed that issues such as transport mode (updating > traffic selectors), PFKEY extensions, and tunnel overhead > reduction will be handled in separate documents. >=20 > =3D=3D> is transport mode even in the scope of the WG? I thought=20 > not, but the charter doesn't seem conclusive either way.. Well, this sentence in the draft was not intended as an opinion either way; only as a note that regardless of whether it's in the WG scope or not, it's certainly not within the scope of this document :-) > substantial > ----------- >=20 > Note that if some of the initiator's interfaces are behind a > NAT (from the responder's point of view), the addresses > received by the responder will be incorrect. This means the > procedure for changing responder addresses described in > Section 2.4 does not fully work when the initiator is behind > a NAT. [...] >=20 > =3D=3D> this is probably something that needs more air time. What > does "does not fully work" mean? This also probably applies to > the responder, though in different ways. This may also have > security implications (exposing internal topology), and it may > affect address selection (if for example smaller scope > addresses are preferable, but actually belong to different > sites). This probably needs a bunch of more analysis... Yes, this is something that probably deserves a slightly longer explanation (but I don't think we should spend too much time on it). How about this? 1.3 MOBIKE and Network Address Translation (NAT) In some MOBIKE scenarios the network may contain NATs or stateful packet filters (for brevity, the rest of this document talks simply about NATs). The NAT Traversal feature specified in [IKEv2] allows IKEv2 to work through NATs in many cases, and MOBIKE can leverage this functionality: when the addresses used for IPsec SAs are changed, MOBIKE can enable or disable IKEv2 NAT Traversal as needed. Nevertheless, there are some limitations. NATs usually introduce an asymmetry in the network: packets reaching the NAT from the "inside" are treated differently from packets coming from the "outside". This asymmetry leads to restrictions on what MOBIKE can do. To give a concrete example, consider a situation where both peers have only a single address, and the initiator is behind a NAT. If the responder's address now changes, it needs to send a packet to the initiator using its new address. However, if the NAT is, for instance, of the "restricted cone" type (see [STUN] for one description of different NAT types), this is not possible: the NAT will drop packets sent from the new address (unless the initiator has previously sent a packet to that address -- which it cannot do until it knows the address). For simplicity, MOBIKE does not attempt to handle all possible NAT- related scenarios. Instead, MOBIKE assumes that if NATs are present, the initiator is the party "behind" the NAT, and does not fully support the case where the responder's addresses change. "Does not fully support" means that no special effort is made to support this functionality. However, if the alternative is losing connectivity completely, the responder can still attempt to proceed with the change, and depending on, e.g., the exact type of NAT, it may succeed. However, analyzing the exact circumstances when this will or will not work is not done in this document. > This specification requires the use of return routability > tests (under certain conditions) to limit the duration of > any "third party bombing" attacks by off-path (relative to > the victim) attackers. >=20 > =3D=3D> this is not true. The spec only says RR _SHOULD_ be done > before updating the SAs. There is no "MUST" for RR (whether > before or after), but a "MAY skip" under certain conditions. > The normativeness requirements need to be reviewed. =20 Yes, the security considerations text needs to be fixed. > Further, the procedures for handling the payloads (sections 2.3 > and 2.4) should include a bullet point on RR tests and a > pointer to 2.5. Section 2.3 already has this for the responder; I'll add this for the initiator as well.. > When the initiator is behind a NAT, it SHOULD include these=20 > payloads in DPD messages, and compare the received ... >=20 > When MOBIKE is in use, the host not behind a NAT SHOULD NOT=20 > use the dynamic updates specified ... >=20 > =3D=3D> How does the MOBIKE code know whether you're behind a NAT? > Is this done automatically as part of IKEv2 NAT detection? > Note that the spec doesn't seem to require running NAT presence > detection so with current spec this can't be done. Yes, this is done by IKEv2 NAT Traversal already (so saying that it must be done would be redundant). > To give the initiator enough time to detect the error, the=20 > responder SHOULD use relatively long timeout intervals when,=20 > for instance, retransmitting IKEv2 requests or deciding whether=20 > to initiate dead peer detection. >=20 > =3D=3D> "relatively long timeout intervals" is pretty ambiguous. > While this may not affect the interoperability, shouldn't we be > a bit more precise what kind of order of magnitude we're > talking about here? Seconds? Ten seconds? 30 sec? Minutes? > 10 minutes? Hours? This is to some degree also a matter of local policy... but I guess it would be useful to at least give a reasonable example. Tero, do you have an opinion about what would a good recommendation be? Maybe something like "While no specific timeout lengths are required, it is suggested that responders continue retransmitting IKEv2 requests for at least five minutes before giving up." > The data associated with this notification is the SHA-1=20 > hash [FIPS180-2] of the following data: >=20 > =3D=3D> this spec is not algorithm-agile. (I can't find the ref > right now where this is encouraged.) In this case, maybe it > doesn't need to be considering the impact (I don't take a > stance on that) -- but this probably deserves at least brief > discussion in the security considerations section. This part is basically copied from IKEv2 NAT detection payloads, which also use SHA-1 (and IKEv2 spec didn't include any discussion about this either).... However, here the situation might actually be slightly different, since the security implications of NAT_DETECTION_*_IP payloads and NO_NATS_ALLOWED are different. The simplest solution might be just to place the IP addresses in this payload (and mandate comparing them with the IP header)... Any comments from other on this? > semi-editorial > -------------- >=20 > =3D=3D> there seem to be a number of assumptions scattered > throughout the document (e.g., relating to the responder not > being behind a NAT) -- maybe it would be useful to put these as > a new subsection of the Introduction? This particular assumption is actually mentioned in the Introduction section (and gets better treatment in the proposed NAT text above). Were there any others you had in mind..? > =3D=3D> I would also consider splitting out 2.3 in subsections for > readability and more exact references. For example, > initiator's first steps could be 2.3.1, Responder's reply > 2.3.2, initiator's reply 2.3.3, and the exception 2.3.4. Hmm... as it's currently organized, I'm not sure if splitting=20 it would actually improve the readability (it might even be confusing if the subsection suddenly changes in the middle of=20 the description). > =3D=3D> It might make sense to spell out, probably in section 1.2, > that apparently (AFAICS) the initiator never tells the > responder which addresses it takes to use. It just sends > UPDATE_SA_ADDRESSES with the updated addresses (inmplicit > update). It does tell the responder, by sending UPDATE_SA_ADDRESSES. I'm not sure how it could be more explicit than this...? (Or are you referring to the detail that the addresses are not contained inside the IKEv2 payload, but in the IP header?) > HDR, SK { IDi, [CERT], [IDr], AUTH, > [CP(CFG_REQUEST)] > SAi2, TSi, TSr, > N(MOBIKE_SUPPORTED), > [N(ADDITIONAL_*_ADDRESS)+] --> >=20 > =3D=3D> this raises a minor issue of the normativeness of this spec > with regard to the non-MOBIKE -related IKE payloads. The above > exchange is just an example; some other payloads could be > included as well, or some listed above could be omitted. Also > the optional/mandatory status might change. Perhaps the > document could give a short disclaimer about the IKE exchange > examples. Right... How about adding this: In some cases, the diagrams also show what payloads defined in [IKEv2] would be typically included in, for instance, the IKE_AUTH exchange. These payloads are shown for illustrative purposes only; see [IKEv2] for an authoritative description. to section 1.3, after the first paragraph? > o The initiator receives a NAT_DETECTION_DESTINATION_IP=20 > payload that does not match the previous UPDATE_SA_ADDRESSES=20 > response (see Section 2.6 for a more detailed description). >=20 > =3D=3D> In some cases, you use NAT_DETECTION_*_IP and in some > NAT_DETECTION_DESTINATION_IP. I guess this is intentional,=20 > but I'd still review the cases carefully.. I went through all the occurrences of these terms, and it seems they were all correct. > o Determines whether it has already received a newer > UPDATE_SA_ADDRESSES request than this one (if the=20 > responder uses a window size greater than one, it is=20 > possible that requests are received out of order). =20 > If it has, a response message is sent, but no other=20 > action is taken. >=20 > =3D=3D> at first, it was not clear to me what "a response message" > referred to. An unspecified response? Probably you meant the > normal response specified a few bullets down but this was not > unambiguous. Ok, I'll clarify this. > There is one additional issue that must be taken into account. > If the INFORMATIONAL request has been sent to several different > addresses (i.e., the destination address in the IKE_SA has been > updated after the request was first sent), ... >=20 > =3D=3D> s/If the/If the same/ (?) Yes, that's right. > =3D=3D> this is actually a good issue in more general. Is it worth > the effort to do so in the first place? That is, couldn't we > just specify that the requests be sent with different cookies > for each destination. I don't think a hash is computationally > all that expensive. That would simplify the spec and eliminate > an extra roundtrip in some cases. This would require everyone to support large "window sizes", and based on feedback we've received from implementors, most of them don't plan to support anything else than 1. (MOBIKE in general would be _much_ simpler if the designers of IKEv2 had done the reliability/windowing parts slightly=20 differently...:-) > IKEv2 requires that if an IPsec endpoint discovers a NAT > between it and its correspondent, it MUST send all > subsequent traffic to and from port 4500. To simplify > things, implementations that support both this specification > and NAT Traversal MUST change to port 4500 if the > correspondent also supports both, even if no NAT was > detected between them (this way, there is no need to change > the ports later). >=20 > =3D=3D> While this seems to be a logical place to talk about this, > I'm troubled. The title is "NAT Prohibition". What about > MOBIKE implementations which don't implement NAT prohibition (I > guess that's OK). The above requirement is more general though > -- not really anything to with NAT prohibition. These kind of > more generic requirements should be placed in a much more > prominent place in the spec. Hmm... yes, you're right, this should be somewhere else.=20 Logically it would also belong earlier in the text; I'll try to find a new place for it. > NO_NATS_ALLOWED payloads can also be included when changing > the addresses of IPsec SAs (see Section 2.3) and updating > the additional addresses (see Section 2.4). An initiator > using this "NAT prohibition" feature includes a > NO_NATS_ALLOWED payload in all address update messages. >=20 > =3D=3D> s/includes/MUST include/ or..? I think "includes" is correct, since it's describing a logical necessity, not a choice (where we could discuss whether it=20 should be a MAY, SHOULD or MUST). =20 > 3.1 MOBIKE_SUPPORTED Notification Payload >=20 > =3D=3D> note that the IKEv2 spec refers these as "Notify Payloads" > (at least in some places of the spec; "Notification" is also > mentioned though)..? The IKEv2 spec is not very consistent in this (for instance, Section 3.10 titled "Notify Payload" later on says "The payload type for the Notification Payload is..."). But I'll try to make the use of "notification", "Notify Payload",=20 and "payload" more consistent in the next version. > The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY- > IANA(16396..40959). >=20 > =3D=3D> per http://www.ietf.org/internet-drafts/draft-narten-iana- > considerations-rfc2434bis-02.txt, >=20 > thse types should be named TBD-BY-IANA1, ...., TBD-BY-IANAN (or > something like that), so we know IANA has assigned a separate > value for each and it can be easily search-n-replaced. > > I'd also suggest dropping the assignment range from here, and=20 > giving that guidance in IANA Considerations. OK, I'll do that... (I'll also add a table in the IANA considerations section summarizing all the new notifications). > of the stack, such as properly dealing with ICMP errors > [ICMPAttacks] > > =3D=3D> some folks may argue that what ICMPattacks proposes may not > be "proper". So, maybe find a different word for "proper", or > use something like "as validating ICMP errors" which takes no > stance on whether it's useful or not. Ok. > [IPsecArch] > Kent, S. and K. Seo, "Security Architecture for the > Internet Protocol", draft-ietf-ipsec-rfc2401bis-06=20 > (work in progress), March 2005. > > =3D=3D> this should probably be under normative refs? Yes. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 19 14:01:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHPx5-0003RY-CQ for mobike-archive@megatron.ietf.org; Mon, 19 Sep 2005 14:01:15 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10788 for ; Mon, 19 Sep 2005 14:01:12 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7F434FB282; Mon, 19 Sep 2005 14:01:12 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 336A5FB27C; Mon, 19 Sep 2005 14:01:11 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 97C27FB280; Mon, 19 Sep 2005 14:01:09 -0400 (EDT) Received: from ns2.academica.fi (ns2.academica.fi [217.64.177.130]) by machshav.com (Postfix) with ESMTP id 87D3FFB27C for ; Mon, 19 Sep 2005 14:01:08 -0400 (EDT) Received: from [82.133.140.118] (ip82-133-140-118.adsl.academica.fi [82.133.140.118]) by ns2.academica.fi (Postfix) with ESMTP id BDC2C257208; Mon, 19 Sep 2005 21:00:23 +0300 (EEST) Message-ID: <432F110E.1070304@iki.fi> Date: Mon, 19 Sep 2005 22:27:10 +0300 From: Sami Vaarala User-Agent: Debian Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? References: <200509191558.j8JFw3Op065579@givry.rennes.enst-bretagne.fr> In-Reply-To: <200509191558.j8JFw3Op065579@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sami.vaarala@iki.fi List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Hi, Francis Dupont wrote: > return routability check that force the attacker to stay there > to continue the attack forever. > > => yes, mobile ip and mobike have different weapons. My concern is > they share the same issue but the WGs react in very different ways. A quick comment: if the attacker stays on the path, doing NAT forever (i.e. allows peers to exchange packets), then it's not really an attack. It's just plain NAT. At least in the MIPv4 context this becomes a relevant attack *only* if the attacker (a) intervenes in the binding establishment stage (acting as a NAT), and (b) then leaves the path. The result is either a defunct binding or a traffic flow redirected to a victim. If the attacker stays on and continues to perform the NAT function, traffic flow is not changed. Is there a difference in MOBIKE? I.e. is this an attack if the attacker stays on the path? Best, -Sami _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 20 00:31:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHZmV-0005v5-DU for mobike-archive@megatron.ietf.org; Tue, 20 Sep 2005 00:31:01 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20467 for ; Tue, 20 Sep 2005 00:30:55 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 0B164FB28D; Tue, 20 Sep 2005 00:30:57 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B4FC1FB286; Tue, 20 Sep 2005 00:30:55 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 92C20FB28A; Tue, 20 Sep 2005 00:30:53 -0400 (EDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by machshav.com (Postfix) with SMTP id A06FEFB281 for ; Tue, 20 Sep 2005 00:30:52 -0400 (EDT) Received: (qmail 64086 invoked from network); 20 Sep 2005 04:30:50 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.163.213.6 with login) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 20 Sep 2005 04:30:49 -0000 Message-ID: <00d501c5bd9c$162c5880$6701a8c0@adithya> From: "Mohan Parthasarathy" To: "Francis Dupont" , "Jari Arkko" References: <200509191457.j8JEvgom065079@givry.rennes.enst-bretagne.fr> Subject: Re: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40) Date: Mon, 19 Sep 2005 21:30:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: Pasi.Eronen@nokia.com, mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > In your previous mail you wrote: > > >=> what is the real difference between MOBIKE multihoming support > >and IKEv2 multihoming support, and, more important, is this difference > >enough? > > My understanding of this difference is that in our current > proposal, the peers can register their alternative addresses > and failover to the other addresses if there's a connectivity > problem in the currently used address. (I don't think you > can do this in basic IKEv2, and personally, I think its a good > tradeoff in terms of functionality vs. effort and configuration.) > This is what I call the "failover" multihoming model. > > In the SCTP multihoming model we can choose more independently > where to send data, even if there's still the concept of a > primary (default) path. > AFAIK (things may have changed recently in SCTP), you try a new path only if the primary path fails. But in SCTP, each side can take the decision independently unlike what we have in MOBIKE today. But the main reason we did it this way in MOBIKE is to make it work with NATs. Also, In MOBIKE, all the IPsec SAs get updated at the same time. There is no such thing in SCTP - each side has its own notion of what address set they can use. Is there any other difference ? > In the load balancing multihoming model we can send even > the same stream over multiple paths, and still perform appropriate > load balancing, congestion avoidance, and acknowledgement > tasks. > > => fine definition. My concern is the SCTP model and SCTP itself > is in the charter, so according to its own charter the WG doesn't > provide *yet* a good enough support to multihoming... > I think we should be very careful about keeping the protocol simple. When the charter was written, i don't think we understood all the details. So, i don't think we should blindly follow the charter. -mohan > Regards > > Francis.Dupont@enst-bretagne.fr > _______________________________________________ > 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 Tue Sep 20 03:10:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHcGa-00048u-FE for mobike-archive@megatron.ietf.org; Tue, 20 Sep 2005 03:10:12 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12161 for ; Tue, 20 Sep 2005 03:10:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 878E1FB28D; Tue, 20 Sep 2005 03:10:08 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E3E49FB286; Tue, 20 Sep 2005 03:10:06 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7E699FB28A; Tue, 20 Sep 2005 03:10:05 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 181F3FB281 for ; Tue, 20 Sep 2005 03:10:04 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8K79sU02248; Tue, 20 Sep 2005 09:09:54 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8K79rp2068857; Tue, 20 Sep 2005 09:09:53 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509200709.j8K79rp2068857@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: sami.vaarala@iki.fi Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? In-reply-to: Your message of Mon, 19 Sep 2005 22:27:10 +0300. <432F110E.1070304@iki.fi> Date: Tue, 20 Sep 2005 09:09:53 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: A quick comment: if the attacker stays on the path, doing NAT forever (i.e. allows peers to exchange packets), then it's not really an attack. It's just plain NAT. => what I call the transient pseudo-NAT differs from a real NAT on: - it stays on the path only for the attack (transient) - it modifies only some packets belonging to a signaling protocol - it redirects a large bunch of traffic controlled by this signaling protocol. At least in the MIPv4 context this becomes a relevant attack *only* if the attacker (a) intervenes in the binding establishment stage (acting as a NAT), and (b) then leaves the path. => yes, this is the idea. One unpleasant property is the attack works better if the signaling is more efficient (i.e., uses less messages). The result is either a defunct binding or a traffic flow redirected to a victim. If the attacker stays on and continues to perform the NAT function, traffic flow is not changed. => the attack I describe is not the bogus NAT one. In mine a small action has a great effect. Is there a difference in MOBIKE? => there is no real difference between IKE and MIP, both are signaling which can be attacked as soon as NAT traversal is enabled. I.e. is this an attack if the attacker stays on the path? => yes but this is a different one. BTW the implicit update of NAT traversal is a good defense against the attack: as soon as a packet from the end behind the NAT is not modified, its peer jumps to the right address. This is one of the reasons I believe the SHOULD for the implicit update can be made stronger. Regards Francis.Dupont@enst-bretagne.fr PS: I explain the attack in draft-dupont-transient-pseudonat-04.txt (expired because my interest is not in the attack itself but to get proper defense in signalings). _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 20 04:25:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHdRa-0007jy-Nv for mobike-archive@megatron.ietf.org; Tue, 20 Sep 2005 04:25:39 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15044 for ; Tue, 20 Sep 2005 04:25:35 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 21F61FB28E; Tue, 20 Sep 2005 04:25:32 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 29FB4FB286; Tue, 20 Sep 2005 04:25:30 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5EE0CFB28A; Tue, 20 Sep 2005 04:25:26 -0400 (EDT) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by machshav.com (Postfix) with ESMTP id 3DABDFB281 for ; Tue, 20 Sep 2005 04:25:25 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.12.10/8.12.10/2004.10.03) with ESMTP id j8K8PLd3009303; Tue, 20 Sep 2005 10:25:21 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by coliposte.enst-bretagne.fr (8.12.10/8.12.10/2004.09.01) with ESMTP id j8K8OBlO009136; Tue, 20 Sep 2005 10:24:12 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8K8O9DY069488; Tue, 20 Sep 2005 10:24:09 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509200824.j8K8O9DY069488@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Mohan Parthasarathy" Subject: Re: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40) In-reply-to: Your message of Mon, 19 Sep 2005 21:30:52 PDT. <00d501c5bd9c$162c5880$6701a8c0@adithya> Date: Tue, 20 Sep 2005 10:24:09 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr Cc: Pasi.Eronen@nokia.com, mobike@machshav.com, Jari Arkko X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: I think we should be very careful about keeping the protocol simple. When the charter was written, i don't think we understood all the details. So, i don't think we should blindly follow the charter. => if the charter is bad we should fix it. BTW IMHO the load balancing definition is not enough accurate: Load balancing. Multihoming is supported only in the sense of failing over to another interface; sending traffic over multiple addresses using the same SA is not supported. There is a place between the failover (first part) and the load balancing itself (second part). In the "host-based multihoming" used for IPv6, one could play with source and destination addresses to get traffic engineering / QoS mapping. This is stronger than the failover style but this is not load balancing because one flow uses only one path at one time. To neglect this multihoming style IMHO is to go against the direction the Internet currently follows... Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 20 06:17:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHfBz-0004hE-8x for mobike-archive@megatron.ietf.org; Tue, 20 Sep 2005 06:17:39 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20619 for ; Tue, 20 Sep 2005 06:17:35 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 48670FB28B; Tue, 20 Sep 2005 06:17:33 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5DD95FB286; Tue, 20 Sep 2005 06:17:31 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C72EAFB28A; Tue, 20 Sep 2005 06:17:29 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 74E08FB281 for ; Tue, 20 Sep 2005 06:17:28 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8KAHGE19811; Tue, 20 Sep 2005 12:17:16 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8KAHEQf070031; Tue, 20 Sep 2005 12:17:14 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509201017.j8KAHEQf070031@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? In-reply-to: Your message of Thu, 15 Sep 2005 13:41:48 +0300. <43294FEC.70705@piuha.net> Date: Tue, 20 Sep 2005 12:17:14 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: Pasi.Eronen@nokia.com, Mohan Parthasarathy , mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: I think we can close this one. => but please explain what will be done for the security problem itself (i.e., don't leave an undocumented security hole). This seems to be supported by Mohan and Francis (and myself), so with the small number of folks => I'll be fair: I won't use this against you (:-). that have participated this discussion, its propbably as close to consensus as we are going to get. => the only consensus we have is a MUST is too strong for IPv4. So, I think we can make the document leave the middle ground away from v6 but allowing it in v4. => this is a MAY for the opposite. ("NAT preventation SHOULD be enabled by default in IPv6 if NAT traversal is not enabled.", or words to that effect.) => this is far from enough! We need something for IPv4 and if it is a MAY for the opposite a good security guideline. BTW I agree with the proposed text, my concern is it is incomplete. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 20 06:23:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHfHb-0005pH-V4 for mobike-archive@megatron.ietf.org; Tue, 20 Sep 2005 06:23:28 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20841 for ; Tue, 20 Sep 2005 06:23:23 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3C0CDFB28E; Tue, 20 Sep 2005 06:23:25 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D173DFB28B; Tue, 20 Sep 2005 06:23:24 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DF45FFB28D; Tue, 20 Sep 2005 06:23:22 -0400 (EDT) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id 05294FB28A for ; Tue, 20 Sep 2005 06:23:21 -0400 (EDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8KALEpK027645; Tue, 20 Sep 2005 13:21:20 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Sep 2005 13:23:16 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Sep 2005 13:23:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? Date: Tue, 20 Sep 2005 13:23:15 +0300 Message-ID: Thread-Topic: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? Thread-Index: AcW9zI0hUNYkg/8GSxWXoBZSTfYPhwAAHoIQ From: To: X-OriginalArrivalTime: 20 Sep 2005 10:23:16.0633 (UTC) FILETIME=[507E5890:01C5BDCD] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Francis Dupont wrote: > BTW I agree with the proposed text, my concern is it is=20 > incomplete. Since you seem to be the one person who thinks this is a=20 serious problem, perhaps you could also provide some new=20 text that better describes the situation? Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 20 06:27:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHfLu-0006lz-Vu for mobike-archive@megatron.ietf.org; Tue, 20 Sep 2005 06:27:55 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20985 for ; Tue, 20 Sep 2005 06:27:50 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1CF82FB28E; Tue, 20 Sep 2005 06:27:50 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7B2DAFB286; Tue, 20 Sep 2005 06:27:47 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D2468FB28A; Tue, 20 Sep 2005 06:27:45 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 97028FB281 for ; Tue, 20 Sep 2005 06:27:44 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8KARRE20621; Tue, 20 Sep 2005 12:27:27 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8KARRXL070095; Tue, 20 Sep 2005 12:27:27 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509201027.j8KARRXL070095@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: stephane@cisco.com Subject: Re: [Mobike] issue 34 proposal In-reply-to: Your message of Thu, 15 Sep 2005 07:54:00 EDT. <13E3DA8B48E17D4C96D261A36A23FCD68E4BA6@xmb-rtp-208.amer.cisco.com> Date: Tue, 20 Sep 2005 12:27:27 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Jari Arkko , Pasi.Eronen@nokia.com, Tero Kivinen X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: If one does detect NAT change at ESP layer, what does one do? Do we do a return routability check on the new address before updating it's SADB? It would seem logical, but just want to make sure we're on the same page. => this is not logical at all! The SADB should be updated ASAP and the RR check doesn't help at all: it only adds delay, if the new address is bad the next packet with a good address will fix the SADB. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 20 07:12:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHg35-0000El-0t for mobike-archive@megatron.ietf.org; Tue, 20 Sep 2005 07:12:31 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22779 for ; Tue, 20 Sep 2005 07:12:26 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id BE811FB28B; Tue, 20 Sep 2005 07:12:28 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 48281FB286; Tue, 20 Sep 2005 07:12:27 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8209EFB28A; Tue, 20 Sep 2005 07:12:25 -0400 (EDT) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by machshav.com (Postfix) with ESMTP id 70DB5FB281 for ; Tue, 20 Sep 2005 07:12:24 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.12.10/8.12.10/2004.10.03) with ESMTP id j8KBCFd3003114; Tue, 20 Sep 2005 13:12:15 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by coliposte.enst-bretagne.fr (8.12.10/8.12.10/2004.09.01) with ESMTP id j8KBBjlO002941; Tue, 20 Sep 2005 13:11:45 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8KBBj8g070347; Tue, 20 Sep 2005 13:11:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509201111.j8KBBj8g070347@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko Subject: Re: [Mobike] issue 34 proposal In-reply-to: Your message of Thu, 15 Sep 2005 23:20:25 +0300. <4329D789.8050908@piuha.net> Date: Tue, 20 Sep 2005 13:11:45 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr Cc: Pasi.Eronen@nokia.com, Mohan Parthasarathy , mobike@machshav.com, Tero Kivinen X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: Mohan Parthasarathy wrote: >I am assuming NAT change at ESP layer follows IKEv2 NAT-T i.e no >return routabilitycheck. Otherwise, the speedup obtained by the >traditional IKEv2 NAT-T is lost and there is no point in having >this mechanism at all. I think most of the speedup is in the detection part. => I believe you mean the detection is more efficient because there are more ESP traffic, because the return routability check cost is one full RTT (without RR check the delay is the mean time between two ESP packets + 1/2 RTT). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 20 07:27:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHgHK-0003Qv-Dg for mobike-archive@megatron.ietf.org; Tue, 20 Sep 2005 07:27:14 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23197 for ; Tue, 20 Sep 2005 07:27:11 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5E845FB28B; Tue, 20 Sep 2005 07:27:11 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5BC2CFB281; Tue, 20 Sep 2005 07:27:10 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 18EB6FB28A; Tue, 20 Sep 2005 07:27:08 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id DA079FB281 for ; Tue, 20 Sep 2005 07:27:06 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8KBQvQ24769; Tue, 20 Sep 2005 13:26:57 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8KBQua6070554; Tue, 20 Sep 2005 13:26:56 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509201126.j8KBQua6070554@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? In-reply-to: Your message of Tue, 20 Sep 2005 13:23:15 +0300. Date: Tue, 20 Sep 2005 13:26:56 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: > BTW I agree with the proposed text, my concern is it is > incomplete. Since you seem to be the one person who thinks this is a => the one is this list... serious problem, => the MIP WG considered it as serious too. perhaps you could also provide some new text that better describes the situation? => I'll take some words from draft-dupont-transient-pseudonat-04.txt where the problem is explained. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 20 07:40:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHgTm-0006nd-VE for mobike-archive@megatron.ietf.org; Tue, 20 Sep 2005 07:40:07 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23622 for ; Tue, 20 Sep 2005 07:40:04 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7A76EFB28B; Tue, 20 Sep 2005 07:40:04 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2CDD4FB286; Tue, 20 Sep 2005 07:40:03 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8F31DFB28A; Tue, 20 Sep 2005 07:40:01 -0400 (EDT) Received: from stinghorn.com (stinghorn.com [194.251.121.66]) by machshav.com (Postfix) with ESMTP id 9771CFB281 for ; Tue, 20 Sep 2005 07:40:00 -0400 (EDT) Received: from [172.20.100.26] ([::ffff:172.20.100.26]) by stinghorn.com with esmtp; Tue, 20 Sep 2005 14:39:44 +0300 id 01AB02E9.432FF500.0000234D Message-ID: <432FF653.4020708@iki.fi> Date: Tue, 20 Sep 2005 14:45:23 +0300 From: Sami Vaarala User-Agent: Debian Thunderbird 1.0.6 (X11/20050802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? References: <200509201126.j8KBQua6070554@givry.rennes.enst-bretagne.fr> In-Reply-To: <200509201126.j8KBQua6070554@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Moi, Francis Dupont wrote: > [...] > Since you seem to be the one person who thinks this is a > > => the one is this list... > > serious problem, > > => the MIP WG considered it as serious too. It's been some time but I believe the reaction in MIP WG was that although the issue is real, it's not terribly serious. Given the location of the attacker (on the path), the attacker has many other modes of attack than just transient traffic forwarding. Because there's little that can be done in MIPv4 w.r.t. this problem, namely just tweaking mobility binding lifetimes, it was documented in RFC 3519 Security Considerations. It's nice-to-know information for an implementor. Of course, having NAT prevention in a NAT traversal document wasn't an option either :-). Moreover, from my viewpoint, NAT prevention is something I don't really understand. The real world is riddled with NATs, and it will probably be the case with IPv6 too despite hope to the contrary. So why make things more brittle? Are transient traffic redirection attacks serious enough to warrant it? Best, -Sami _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 20 08:03:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHgpz-0004Jz-Bf for mobike-archive@megatron.ietf.org; Tue, 20 Sep 2005 08:03:03 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25036 for ; Tue, 20 Sep 2005 08:03:01 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B6893FB28E; Tue, 20 Sep 2005 08:02:59 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 916DCFB286; Tue, 20 Sep 2005 08:02:57 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 6F1EBFB28A; Tue, 20 Sep 2005 08:02:56 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id E2AB2FB281 for ; Tue, 20 Sep 2005 08:02:54 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8KC2jQ27014; Tue, 20 Sep 2005 14:02:45 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8KC2j2V070709; Tue, 20 Sep 2005 14:02:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509201202.j8KC2j2V070709@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Sami Vaarala Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? In-reply-to: Your message of Tue, 20 Sep 2005 14:45:23 +0300. <432FF653.4020708@iki.fi> Date: Tue, 20 Sep 2005 14:02:45 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: Are transient traffic redirection attacks serious enough to warrant it? => you miss the point: the attack is transient, not the traffic redirection. Francis.Dupont@enst-bretagne.fr PS: to be secure is a property security protocols are looking for. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 20 08:17:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHh3c-0008KK-Cs for mobike-archive@megatron.ietf.org; Tue, 20 Sep 2005 08:17:08 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25702 for ; Tue, 20 Sep 2005 08:17:05 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 130EFFB28B; Tue, 20 Sep 2005 08:17:03 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C0A61FB286; Tue, 20 Sep 2005 08:17:00 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 32910FB28A; Tue, 20 Sep 2005 08:16:59 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id E0B1FFB281 for ; Tue, 20 Sep 2005 08:16:57 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8KCGEQ28251; Tue, 20 Sep 2005 14:16:14 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8KCGDK7070830; Tue, 20 Sep 2005 14:16:13 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509201216.j8KCGDK7070830@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] FW: external mobike-protocol-02 review (technical) (issue 42) In-reply-to: Your message of Mon, 19 Sep 2005 19:31:33 +0300. Date: Tue, 20 Sep 2005 14:16:13 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, pekkas@netcore.fi X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: > When the initiator is behind a NAT, it SHOULD include these > payloads in DPD messages, and compare the received ... > > When MOBIKE is in use, the host not behind a NAT SHOULD NOT > use the dynamic updates specified ... > > ==> How does the MOBIKE code know whether you're behind a NAT? > Is this done automatically as part of IKEv2 NAT detection? > Note that the spec doesn't seem to require running NAT presence > detection so with current spec this can't be done. Yes, this is done by IKEv2 NAT Traversal already (so saying that it must be done would be redundant). => you don't answer to the question: it is not required to run NAT presence detection. The simplest solution might be just to place the IP addresses in this payload (and mandate comparing them with the IP header)... Any comments from other on this? => so I am not the one which cares about peer address protection (:-). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 20 08:21:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHh8E-0000rA-7v for mobike-archive@megatron.ietf.org; Tue, 20 Sep 2005 08:21:54 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25869 for ; Tue, 20 Sep 2005 08:21:52 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3AE83FB28E; Tue, 20 Sep 2005 08:21:52 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 25486FB28A; Tue, 20 Sep 2005 08:21:50 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A23A2FB28D; Tue, 20 Sep 2005 08:21:48 -0400 (EDT) Received: from stinghorn.com (stinghorn.com [194.251.121.66]) by machshav.com (Postfix) with ESMTP id D3DA2FB286 for ; Tue, 20 Sep 2005 08:21:47 -0400 (EDT) Received: from [172.20.100.26] ([::ffff:172.20.100.26]) by stinghorn.com with esmtp; Tue, 20 Sep 2005 15:21:41 +0300 id 01AB02EE.432FFED5.0000250D Message-ID: <43300029.5090404@iki.fi> Date: Tue, 20 Sep 2005 15:27:21 +0300 From: Sami Vaarala User-Agent: Debian Thunderbird 1.0.6 (X11/20050802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? References: <200509201202.j8KC2j2V070709@givry.rennes.enst-bretagne.fr> In-Reply-To: <200509201202.j8KC2j2V070709@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pasi.Eronen@nokia.com, mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Francis Dupont wrote: > In your previous mail you wrote: > > Are transient traffic redirection attacks serious enough to warrant it? > > => you miss the point: the attack is transient, not the traffic redirection. In the MIPv4 context the traffic redirection is also transient. When the MN rebinds, the redirection ends. Now, if there is no equivalent mechanism in MOBIKE, the attack is more serious, but from previous mails it seems that this aspect is covered? -Sami _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 20 08:33:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHhJ9-0003oz-E2 for mobike-archive@megatron.ietf.org; Tue, 20 Sep 2005 08:33:11 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26488 for ; Tue, 20 Sep 2005 08:33:08 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D8B8DFB28B; Tue, 20 Sep 2005 08:33:06 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1BF28FB286; Tue, 20 Sep 2005 08:33:05 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 06C23FB28A; Tue, 20 Sep 2005 08:33:01 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id CAB00FB281 for ; Tue, 20 Sep 2005 08:32:59 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8KCWgQ29451; Tue, 20 Sep 2005 14:32:42 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8KCWg7n070911; Tue, 20 Sep 2005 14:32:42 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509201232.j8KCWg7n070911@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? In-reply-to: Your message of Tue, 20 Sep 2005 13:23:15 +0300. Date: Tue, 20 Sep 2005 14:32:42 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com First attempt: IKE uses addresses it runs over, taken from IP headers, as endpoint addresses for IPsec SAs it establishes. If the addresses are left unprotected, an attacker can redirect the IPsec traffic to a third party just modifying the IP header of some IKE messages. Either NAT_DETECTION_*_IP or NO_NATS_ALLOWED detect the modification of the IP header on the path, including this attack. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 20 08:38:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHhOV-0005Bk-KW for mobike-archive@megatron.ietf.org; Tue, 20 Sep 2005 08:38:43 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26698 for ; Tue, 20 Sep 2005 08:38:40 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5A007FB28F; Tue, 20 Sep 2005 08:38:41 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 07C4DFB28B; Tue, 20 Sep 2005 08:38:40 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 09711FB28D; Tue, 20 Sep 2005 08:38:39 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id BA550FB28A for ; Tue, 20 Sep 2005 08:38:37 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8KCcSQ29758; Tue, 20 Sep 2005 14:38:28 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8KCcTFY070976; Tue, 20 Sep 2005 14:38:29 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509201238.j8KCcTFY070976@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Sami Vaarala Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? In-reply-to: Your message of Tue, 20 Sep 2005 15:27:21 +0300. <43300029.5090404@iki.fi> Date: Tue, 20 Sep 2005 14:38:29 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: Pasi.Eronen@nokia.com, mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: Francis Dupont wrote: > In your previous mail you wrote: > > Are transient traffic redirection attacks serious enough to warrant it? > > => you miss the point: the attack is transient, not the traffic > redirection. In the MIPv4 context the traffic redirection is also transient. When the MN rebinds, the redirection ends. => no, it is only short. There is a huge difference between hacking some signaling messages and hacking the traffic flow. Now, if there is no equivalent mechanism in MOBIKE, the attack is more serious, but from previous mails it seems that this aspect is covered? => it is not covered but the situation is different for MOBIKE as explained in previous messages. BTW it seems the current protocol document requires in fact a NAT detection so now there are many reasons to drop the "middle ground", i.e., make NAT traversal or NAT prevention mandatory. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 20 09:36:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHiI8-000546-Lq for mobike-archive@megatron.ietf.org; Tue, 20 Sep 2005 09:36:13 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00029 for ; Tue, 20 Sep 2005 09:36:09 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C9F81FB28D; Tue, 20 Sep 2005 09:36:08 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 281E3FB286; Tue, 20 Sep 2005 09:36:07 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 73BBFFB28A; Tue, 20 Sep 2005 09:36:05 -0400 (EDT) Received: from stinghorn.com (stinghorn.com [194.251.121.66]) by machshav.com (Postfix) with ESMTP id 836CEFB281 for ; Tue, 20 Sep 2005 09:36:04 -0400 (EDT) Received: from [172.20.100.26] ([::ffff:172.20.100.26]) by stinghorn.com with esmtp; Tue, 20 Sep 2005 16:35:54 +0300 id 01AB02F2.4330103A.000027CB Message-ID: <4330118E.7070506@iki.fi> Date: Tue, 20 Sep 2005 16:41:34 +0300 From: Sami Vaarala User-Agent: Debian Thunderbird 1.0.6 (X11/20050802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? References: <200509201238.j8KCcTFY070976@givry.rennes.enst-bretagne.fr> In-Reply-To: <200509201238.j8KCcTFY070976@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pasi.Eronen@nokia.com, mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Hi, > In the MIPv4 context the traffic redirection is also transient. > When the MN rebinds, the redirection ends. > > => no, it is only short. There is a huge difference between hacking > some signaling messages and hacking the traffic flow. Ok, this is a difference of terminology. A couple of minutes worth of redirection compared to the attacker's effort is transient to me :) > Now, if there is no equivalent mechanism in MOBIKE, the attack is > more serious, but from previous mails it seems that this aspect is > covered? > > => it is not covered but the situation is different for MOBIKE as > explained in previous messages. BTW it seems the current protocol > document requires in fact a NAT detection so now there are many > reasons to drop the "middle ground", i.e., make NAT traversal or > NAT prevention mandatory. Ok, this may be. I haven't followed MOBIKE closely and was commenting on the MIPv4 part which I thought to be misrepresented as a serious problem. -Sami _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 20 12:44:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHlES-0006dH-39 for mobike-archive@megatron.ietf.org; Tue, 20 Sep 2005 12:44:36 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13962 for ; Tue, 20 Sep 2005 12:44:31 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D56B8FB28D; Tue, 20 Sep 2005 12:44:32 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id ED9AAFB286; Tue, 20 Sep 2005 12:44:31 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BAF47FB28A; Tue, 20 Sep 2005 12:44:27 -0400 (EDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by machshav.com (Postfix) with ESMTP id 2A02AFB281 for ; Tue, 20 Sep 2005 12:44:27 -0400 (EDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j8KGiJGU026176 for ; Tue, 20 Sep 2005 12:44:19 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8KGiJ2T098534 for ; Tue, 20 Sep 2005 12:44:19 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j8KGiJQS010797 for ; Tue, 20 Sep 2005 12:44:19 -0400 Received: from d27ml101.rchland.ibm.com (d27ml101.rchland.ibm.com [9.10.229.40]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j8KGiIL7010774 for ; Tue, 20 Sep 2005 12:44:19 -0400 From: Dennis Frett To: mobike@machshav.com Message-ID: Date: Tue, 20 Sep 2005 11:44:16 -0500 X-MIMETrack: Serialize by Router on d27ml101/27/M/IBM(Release 6.5.4|March 27, 2005) at 09/20/2005 11:44:18 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Mobike] Dennis Frett/Rochester/IBM is out of the office. X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com I will be out of the office starting 09/20/2005 and will not return until 09/21/2005. Testing my out of office Response. I'm not really out of office today. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 20 12:59:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHlSW-0001lY-Lx for mobike-archive@megatron.ietf.org; Tue, 20 Sep 2005 12:59:10 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14728 for ; Tue, 20 Sep 2005 12:59:04 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 709F0FB28E; Tue, 20 Sep 2005 12:59:05 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 92DC9FB286; Tue, 20 Sep 2005 12:58:59 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 14393FB28A; Tue, 20 Sep 2005 07:03:38 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by machshav.com (Postfix) with ESMTP id EDCD4FB281 for ; Tue, 20 Sep 2005 07:03:34 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8KB3J528752; Tue, 20 Sep 2005 14:03:19 +0300 Date: Tue, 20 Sep 2005 14:03:19 +0300 (EEST) From: Pekka Savola To: Pasi.Eronen@nokia.com Subject: RE: [Mobike] FW: external mobike-protocol-02 review (technical) (issue 42) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 20 Sep 2005 12:58:57 -0400 Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Inline.. (in the interest of brevity, I've removed parts which we agree on explicit response doesn't seem necessary). Let's hope this gets past the size limitations.. On Mon, 19 Sep 2005 Pasi.Eronen@nokia.com wrote: >> substantial >> ----------- >> >> Note that if some of the initiator's interfaces are behind a >> NAT (from the responder's point of view), the addresses >> received by the responder will be incorrect. This means the >> procedure for changing responder addresses described in >> Section 2.4 does not fully work when the initiator is behind >> a NAT. [...] >> >> ==> this is probably something that needs more air time. What >> does "does not fully work" mean? This also probably applies to >> the responder, though in different ways. This may also have >> security implications (exposing internal topology), and it may >> affect address selection (if for example smaller scope >> addresses are preferable, but actually belong to different >> sites). This probably needs a bunch of more analysis... > > Yes, this is something that probably deserves a slightly longer > explanation (but I don't think we should spend too much time on > it). How about this? > > 1.3 MOBIKE and Network Address Translation (NAT) > > In some MOBIKE scenarios the network may contain NATs or stateful > packet filters (for brevity, the rest of this document talks simply > about NATs). The NAT Traversal feature specified in [IKEv2] allows > IKEv2 to work through NATs in many cases, and MOBIKE can leverage > this functionality: when the addresses used for IPsec SAs are > changed, MOBIKE can enable or disable IKEv2 NAT Traversal as needed. > > Nevertheless, there are some limitations. NATs usually introduce an > asymmetry in the network: packets reaching the NAT from the "inside" > are treated differently from packets coming from the "outside". This > asymmetry leads to restrictions on what MOBIKE can do. To give a > concrete example, consider a situation where both peers have only a > single address, and the initiator is behind a NAT. If the > responder's address now changes, it needs to send a packet to the > initiator using its new address. However, if the NAT is, for > instance, of the "restricted cone" type (see [STUN] for one > description of different NAT types), this is not possible: the NAT > will drop packets sent from the new address (unless the initiator has > previously sent a packet to that address -- which it cannot do until > it knows the address). > > For simplicity, MOBIKE does not attempt to handle all possible NAT- > related scenarios. Instead, MOBIKE assumes that if NATs are present, > the initiator is the party "behind" the NAT, and does not fully > support the case where the responder's addresses change. > > "Does not fully support" means that no special effort is made to > support this functionality. However, if the alternative is losing > connectivity completely, the responder can still attempt to proceed > with the change, and depending on, e.g., the exact type of NAT, it > may succeed. However, analyzing the exact circumstances when this > will or will not work is not done in this document. This is good description of some of these problems (suitable in the introduction as you put it), but I'm not sure if it addresses all the open questions. If I understand correctly, if the initiator is behind a NAT with IP address 10.0.0.1, it will tell the responder in MOBIKE exchange that its IP address is 10.0.0.1. At least two issues sprang to my mind: a) some people will be (at least slightly) concerned that MOBIKE will reveal the internal topology of the site. This may or may not be a big issue (especially as probably the most IPsec sessions will go to at least semi-trusted nodes), but if we don't state it now, someone is going to invent a fancy MOBIKE "exploit" 5 years down the road. A sentence or two in a separate paragraph in Security Considerations section would probably be sufficient. b) as the conveyed addresses are used for address selection, there might be issues with that. Let's say, the responder tells it has addresses 20.20.20.20 and 10.0.0.2. The initiator has 10.0.0.1, and possibly 30.30.30.30. The initiator and responder are in different sites (a NAT between them). Now the initiator's address selection policy might get skewed if it'd prefer particular kind of addresses. This may be one issue where an explicit warning might be useful. >> When the initiator is behind a NAT, it SHOULD include these >> payloads in DPD messages, and compare the received ... >> >> When MOBIKE is in use, the host not behind a NAT SHOULD NOT >> use the dynamic updates specified ... >> >> ==> How does the MOBIKE code know whether you're behind a NAT? >> Is this done automatically as part of IKEv2 NAT detection? >> Note that the spec doesn't seem to require running NAT presence >> detection so with current spec this can't be done. > > Yes, this is done by IKEv2 NAT Traversal already (so saying > that it must be done would be redundant). To a person like me who didn't know what kind of NAT detection exchange is done by IKEv2 (and whether that's mandatory to implement or mandatory to enable), this didn't spell out how MOBIKE knows whether it's behind a NAT or not. If it could fit somewhere neatly, it would likely help a bit. > "While no specific timeout lengths are required, it is > suggested that responders continue retransmitting IKEv2 > requests for at least five minutes before giving up." No problem with me, though that doesn't give any help on how aggressive you should be to start with.. >> The data associated with this notification is the SHA-1 >> hash [FIPS180-2] of the following data: >> >> ==> this spec is not algorithm-agile. (I can't find the ref >> right now where this is encouraged.) In this case, maybe it >> doesn't need to be considering the impact (I don't take a >> stance on that) -- but this probably deserves at least brief >> discussion in the security considerations section. > > This part is basically copied from IKEv2 NAT detection payloads, > which also use SHA-1 (and IKEv2 spec didn't include any > discussion about this either).... > > However, here the situation might actually be slightly different, > since the security implications of NAT_DETECTION_*_IP payloads > and NO_NATS_ALLOWED are different. The simplest solution might > be just to place the IP addresses in this payload (and mandate > comparing them with the IP header)... > > Any comments from other on this? As these issues have seen some debate (see the thread starting from http://www1.ietf.org/mail-archive/web/ipv6/current/msg05627.html as an example), this seems to be something that needs to be at least mentioned in security considerations; that may be sufficient, though if one can easily engineer around it without hurting security, that might not be a bad idea either. But the bottom line is that if the algorithm is glued in (which may be OK given that you can only spoof the NAT prohibition), I think it needs to be said explicitly (and it might not hurt to get tentative early review from more folks in the sec area). >> semi-editorial >> -------------- >> >> ==> there seem to be a number of assumptions scattered >> throughout the document (e.g., relating to the responder not >> being behind a NAT) -- maybe it would be useful to put these as >> a new subsection of the Introduction? > > This particular assumption is actually mentioned in the > Introduction section (and gets better treatment in the proposed > NAT text above). Were there any others you had in mind..? Maybe minor ones like the assumptions on what other elements need to be implemented (but which aren't specified here, like address selection), but it may be that those don't need to be mentioned up front. >> ==> I would also consider splitting out 2.3 in subsections for >> readability and more exact references. For example, >> initiator's first steps could be 2.3.1, Responder's reply >> 2.3.2, initiator's reply 2.3.3, and the exception 2.3.4. > > Hmm... as it's currently organized, I'm not sure if splitting > it would actually improve the readability (it might even be > confusing if the subsection suddenly changes in the middle of > the description). If others have no opinion, I'm OK either way. It required a bit more work from the reader to figure out which part of the section you were referring to when saying "see Section 2.3" because that includes a number of different things. Above would have made it shorter and easier to point to, but with more careful reading, the current one should be readable as well. >> ==> It might make sense to spell out, probably in section 1.2, >> that apparently (AFAICS) the initiator never tells the >> responder which addresses it takes to use. It just sends >> UPDATE_SA_ADDRESSES with the updated addresses (inmplicit >> update). > > It does tell the responder, by sending UPDATE_SA_ADDRESSES. > I'm not sure how it could be more explicit than this...? > > (Or are you referring to the detail that the addresses are not > contained inside the IKEv2 payload, but in the IP header?) Exactly, only in the IP header. (I haven't analyzed whether this may or may not open any new threats, because the IP address is not secured as it's from the header.. I think those were described at sufficient length already) >> HDR, SK { IDi, [CERT], [IDr], AUTH, >> [CP(CFG_REQUEST)] >> SAi2, TSi, TSr, >> N(MOBIKE_SUPPORTED), >> [N(ADDITIONAL_*_ADDRESS)+] --> >> >> ==> this raises a minor issue of the normativeness of this spec >> with regard to the non-MOBIKE -related IKE payloads. The above >> exchange is just an example; some other payloads could be >> included as well, or some listed above could be omitted. Also >> the optional/mandatory status might change. Perhaps the >> document could give a short disclaimer about the IKE exchange >> examples. > > Right... How about adding this: > > In some cases, the diagrams also show what payloads defined in > [IKEv2] would be typically included in, for instance, the > IKE_AUTH exchange. These payloads are shown for illustrative > purposes only; see [IKEv2] for an authoritative description. > > to section 1.3, after the first paragraph? Looks excellent. >> ==> this is actually a good issue in more general. Is it worth >> the effort to do so in the first place? That is, couldn't we >> just specify that the requests be sent with different cookies >> for each destination. I don't think a hash is computationally >> all that expensive. That would simplify the spec and eliminate >> an extra roundtrip in some cases. > > This would require everyone to support large "window sizes", and > based on feedback we've received from implementors, most of them > don't plan to support anything else than 1. > > (MOBIKE in general would be _much_ simpler if the designers of > IKEv2 had done the reliability/windowing parts slightly > differently...:-) That's a bit unfortunate but it's fine with me.. >> NO_NATS_ALLOWED payloads can also be included when changing >> the addresses of IPsec SAs (see Section 2.3) and updating >> the additional addresses (see Section 2.4). An initiator >> using this "NAT prohibition" feature includes a >> NO_NATS_ALLOWED payload in all address update messages. >> >> ==> s/includes/MUST include/ or..? > > I think "includes" is correct, since it's describing a logical > necessity, not a choice (where we could discuss whether it > should be a MAY, SHOULD or MUST). My reasoning above was, could an implementer try to optimize the protocol so that it will only send NO_NATS_ALLOWED with some but not all update messages (saving bits). I.e., would the processing be any different for the exchange responder if NO_NATS_ALLOWED was sometimes present and sometimes not. Hence I proposed a MUST implying "if you are going to send NO_NATS_ALLOWED, you have to send it *every time*, instead of just when you feel like it". But if folks want to leave this a bit more open, that's fine with me.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 20 18:23:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHqWX-0003HG-25 for mobike-archive@megatron.ietf.org; Tue, 20 Sep 2005 18:23:37 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10602 for ; Tue, 20 Sep 2005 18:23:32 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7547BFB28F; Tue, 20 Sep 2005 18:23:31 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8EAEBFB28B; Tue, 20 Sep 2005 18:23:28 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B9EECFB28D; Tue, 20 Sep 2005 18:23:26 -0400 (EDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by machshav.com (Postfix) with SMTP id C3EBEFB285 for ; Tue, 20 Sep 2005 18:23:25 -0400 (EDT) Received: (qmail 98701 invoked from network); 20 Sep 2005 22:23:25 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.169.162.58 with login) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 20 Sep 2005 22:23:24 -0000 Message-ID: <00e701c5be31$ed40a980$6701a8c0@adithya> From: "Mohan Parthasarathy" To: , References: Subject: Re: [Mobike] FW: external mobike-protocol-02 review (technical)(issue 42) Date: Tue, 20 Sep 2005 15:23:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: pekkas@netcore.fi X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > The data associated with this notification is the SHA-1 > hash [FIPS180-2] of the following data: > > ==> this spec is not algorithm-agile. (I can't find the ref > right now where this is encouraged.) In this case, maybe it > doesn't need to be considering the impact (I don't take a > stance on that) -- but this probably deserves at least brief > discussion in the security considerations section. This part is basically copied from IKEv2 NAT detection payloads, which also use SHA-1 (and IKEv2 spec didn't include any discussion about this either).... However, here the situation might actually be slightly different, since the security implications of NAT_DETECTION_*_IP payloads and NO_NATS_ALLOWED are different. The simplest solution might be just to place the IP addresses in this payload (and mandate comparing them with the IP header)... Any comments from other on this? ===> The reason IKEv2 NAT detection payloads includes only the hash and not the actual addresses is to hide the internal addresses. But this is lost with MOBIKE because the initiator has to include these addresses in ADDITIONAL_ADDRESS notification. So, including the hash or real address in the notification payloads doesn't matter. To be consistent (as we are using NAT-D payloads from IKEv2), we might as well use the same hash and also not be algo-agile :-) -mohan _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 20 21:01:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHsze-0005p7-Vg for mobike-archive@megatron.ietf.org; Tue, 20 Sep 2005 21:01:51 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18020 for ; Tue, 20 Sep 2005 21:01:48 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id AAFBFFB28E; Tue, 20 Sep 2005 21:01:48 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 97B71FB28B; Tue, 20 Sep 2005 21:01:47 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1C956FB28D; Tue, 20 Sep 2005 21:01:44 -0400 (EDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by machshav.com (Postfix) with ESMTP id 73073FB286 for ; Tue, 20 Sep 2005 21:01:43 -0400 (EDT) Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 20 Sep 2005 18:01:41 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,128,1125903600"; d="scan'208"; a="10551111:sNHT23254176" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8L11aT6028506; Tue, 20 Sep 2005 21:01:37 -0400 (EDT) From: stephane@cisco.com Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 21:01:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issue 34 proposal Date: Tue, 20 Sep 2005 21:01:35 -0400 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD694E93C@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Mobike] issue 34 proposal Thread-Index: AcW9zhQ2gR05G0dGR5SpA8oYx8UmIgAd+e4g To: X-OriginalArrivalTime: 21 Sep 2005 01:01:36.0861 (UTC) FILETIME=[0446F8D0:01C5BE48] Cc: mobike@machshav.com, Jari Arkko , Pasi.Eronen@nokia.com, Tero Kivinen X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable But, couldn't an attacker capture an ESP packet, change the src ip / port, and force us to start sending/flooding packets to an un-suspecting IP addr? At least a RR test would tell us that our 'peer' can indeed recv packets on the new IP. Still has MitM issues on the RR, mind you... Stephane. > -----Original Message----- > From: Francis.Dupont@enst-bretagne.fr=20 > [mailto:Francis.Dupont@enst-bretagne.fr]=20 > Sent: Tuesday, September 20, 2005 6:27 AM > To: Stephane Beaulieu [stephane@cisco.com] > Cc: Pasi.Eronen@nokia.com; Tero Kivinen; Jari Arkko;=20 > mobike@machshav.com > Subject: Re: [Mobike] issue 34 proposal=20 >=20 > In your previous mail you wrote: >=20 > If one does detect NAT change at ESP layer, what does one do? > =20 > Do we do a return routability check on the new address=20 > before updating > it's SADB? It would seem logical, but just want to make=20 > sure we're on > the same page. > =20 > =3D> this is not logical at all! The SADB should be updated=20 > ASAP and the RR check doesn't help at all: it only adds=20 > delay, if the new address is bad the next packet with a good=20 > address will fix the SADB. >=20 > Regards >=20 > Francis.Dupont@enst-bretagne.fr >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Sep 21 04:05:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHzc1-0006Mc-8d for mobike-archive@megatron.ietf.org; Wed, 21 Sep 2005 04:05:53 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04095 for ; Wed, 21 Sep 2005 04:05:51 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 470ACFB291; Wed, 21 Sep 2005 04:05:49 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 965CBFB28E; Wed, 21 Sep 2005 04:05:48 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E417DFB28F; Wed, 21 Sep 2005 04:05:46 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 68EF3FB28B for ; Wed, 21 Sep 2005 04:05:45 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8L85bn18974; Wed, 21 Sep 2005 10:05:37 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8L85b1d075023; Wed, 21 Sep 2005 10:05:37 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509210805.j8L85b1d075023@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola Subject: Re: [Mobike] FW: external mobike-protocol-02 review (technical) (issue 42) In-reply-to: Your message of Tue, 20 Sep 2005 14:03:19 +0300. Date: Wed, 21 Sep 2005 10:05:37 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: a) some people will be (at least slightly) concerned that MOBIKE will reveal the internal topology of the site. This may or may not be a big issue (especially as probably the most IPsec sessions will go to at least semi-trusted nodes), but if we don't state it now, someone is going to invent a fancy MOBIKE "exploit" 5 years down the road. A sentence or two in a separate paragraph in Security Considerations section would probably be sufficient. => IMHO this problem is only for MOBIKE itself (where a private of a node behind a NAT has no meaning, i.e., it can put anything) but not for NAT detection/prevention: I asked why NAT detection uses a hash and not the addresses themselves and the answer was exactly because some people were concerned that NAT detection would reveal the internal topology (so a) applies in the real world). > Yes, this is done by IKEv2 NAT Traversal already (so saying > that it must be done would be redundant). To a person like me who didn't know what kind of NAT detection exchange is done by IKEv2 (and whether that's mandatory to implement or mandatory to enable), this didn't spell out how MOBIKE knows whether it's behind a NAT or not. If it could fit somewhere neatly, it would likely help a bit. => there is a point about this: I'd like to drop the "middle ground", i.e., to make the usage of either NAT detection or NAT prevention mandatory. My idea is to get a mandatory protection of the addresses in IP headers (as they'll become the endpoint addresses of IPsec SAs) but your argument is good too. > (Or are you referring to the detail that the addresses are not > contained inside the IKEv2 payload, but in the IP header?) Exactly, only in the IP header. (I haven't analyzed whether this may or may not open any new threats, because the IP address is not secured as it's from the header.. I think those were described at sufficient length already) => this opens a threat what I called the "transient pseudo-NAT attack" but it is not a new threat, just an ignored threat. BTW, it is easy to fix: the addresses in the IP header should simply be reflected in some way into the IKE payload. This is why I propose to enforce the usage of NAT detection/prevention which does that for the first exchange. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Sep 21 04:29:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHzyj-00054I-SK for mobike-archive@megatron.ietf.org; Wed, 21 Sep 2005 04:29:22 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05076 for ; Wed, 21 Sep 2005 04:29:18 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 8C052FB28E; Wed, 21 Sep 2005 04:29:17 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 14CE0FB28E; Wed, 21 Sep 2005 04:29:12 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 883C1FB28F; Wed, 21 Sep 2005 04:29:10 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 356B4FB28B for ; Wed, 21 Sep 2005 04:29:09 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8L8Son21173; Wed, 21 Sep 2005 10:28:50 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8L8SnfF075256; Wed, 21 Sep 2005 10:28:49 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509210828.j8L8SnfF075256@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: stephane@cisco.com Subject: Re: [Mobike] issue 34 proposal In-reply-to: Your message of Tue, 20 Sep 2005 21:01:35 EDT. <13E3DA8B48E17D4C96D261A36A23FCD694E93C@xmb-rtp-208.amer.cisco.com> Date: Wed, 21 Sep 2005 10:28:49 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: Pasi.Eronen@nokia.com, Jari Arkko , mobike@machshav.com, Tero Kivinen X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: But, couldn't an attacker capture an ESP packet, change the src ip / port, and force us to start sending/flooding packets to an un-suspecting IP addr? => yes but by definition a NAT is out of control (if you can control it the first thing you'll do is to remove it :-) so: - the implicit update is its own defense, i.e., either it is not supported and the attack doesn't work, or it is supported and the first good packet from the node behind the NAT will fix the address - the pseudo-NAT can simply move the direct (i.e., not reflected) traffic to a third party At least a RR test would tell us that our 'peer' can indeed recv packets on the new IP. => not really as: Still has MitM issues on the RR, mind you... => IMHO it is better to rely on ingress filtering: - when it is deployed, it catches the same attacks than RR - when it is not deployed, the attackers have already too many simpler possibilities as the real world can prove everyday... So I think that most of RR "requirements" are only FUD. Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 26 11:11:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJudE-0007q4-Nb for mobike-archive@megatron.ietf.org; Mon, 26 Sep 2005 11:11:04 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07135 for ; Mon, 26 Sep 2005 11:11:01 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 40EFFFB286; Mon, 26 Sep 2005 11:10:57 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6B024FB280; Mon, 26 Sep 2005 11:10:52 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 37C90FB282; Mon, 26 Sep 2005 11:10:50 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 15492FB266 for ; Mon, 26 Sep 2005 11:10:49 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C014789852; Mon, 26 Sep 2005 18:10:42 +0300 (EEST) Message-ID: <43380F7D.7000406@piuha.net> Date: Mon, 26 Sep 2005 18:10:53 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont , Pasi.Eronen@nokia.com References: <200509201232.j8KCWg7n070911@givry.rennes.enst-bretagne.fr> In-Reply-To: <200509201232.j8KCWg7n070911@givry.rennes.enst-bretagne.fr> Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Content-Transfer-Encoding: 7bit First I wrote: >So, I think we can make the document leave the >middle ground away from v6 but allowing it in v4. >("NAT preventation SHOULD be enabled by default >in IPv6 if NAT traversal is not enabled.", or words >to that effect.) > > and then you Francis wrote: >> BTW I agree with the proposed text, my concern is it is >> incomplete. > > and later Pasi writes: >Since you seem to be the one person who thinks this is a >serious problem, perhaps you could also provide some new >text that better describes the situation? > and then you Francis wrote: >IKE uses addresses it runs over, taken from IP headers, as >endpoint addresses for IPsec SAs it establishes. If the >addresses are left unprotected, an attacker can redirect the IPsec >traffic to a third party just modifying the IP header of some IKE messages. >Either NAT_DETECTION_*_IP or NO_NATS_ALLOWED detect the modification >of the IP header on the path, including this attack. > > Looking at this thread, it seems that there seems to be support for our v6 text. We've since then been discussing whether stronger language is needed for v4 as well. Right now I don't see a lot of support for that. But let me ping a couple of mobikers that I see in the same conference as I am, to get their view. The text that your provided above Francis looks like material that could be included in the security considerations section. Of course, we'd have to also mention that under some conditions, the attack is temporary. For instance, if the real node sends packets after the attacker has left, the problem is corrected. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 26 11:29:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuup-00036o-2s for mobike-archive@megatron.ietf.org; Mon, 26 Sep 2005 11:29:15 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14093 for ; Mon, 26 Sep 2005 11:29:11 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E01C0FB289; Mon, 26 Sep 2005 11:29:09 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A8431FB280; Mon, 26 Sep 2005 11:29:05 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0E286FB282; Mon, 26 Sep 2005 11:29:04 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id D5AE3FB266 for ; Mon, 26 Sep 2005 11:29:02 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8QFSrc02853; Mon, 26 Sep 2005 17:28:53 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8QFSrtA004126; Mon, 26 Sep 2005 17:28:53 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509261528.j8QFSrtA004126@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko In-reply-to: Your message of Mon, 26 Sep 2005 18:10:53 +0300. <43380F7D.7000406@piuha.net> Date: Mon, 26 Sep 2005 17:28:53 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit In your previous mail you wrote: The text that your provided above Francis looks like material that could be included in the security considerations section. Of course, we'd have to also mention that under some conditions, the attack is temporary. For instance, if the real node sends packets after the attacker has left, the problem is corrected. => unfortunately this is not true: the problem can be corrected only with an explicit action (an address update to the right address). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 26 11:33:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuz8-0005zq-8e for mobike-archive@megatron.ietf.org; Mon, 26 Sep 2005 11:33:42 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15701 for ; Mon, 26 Sep 2005 11:33:37 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1E13DFB280; Mon, 26 Sep 2005 11:33:35 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 15B27FB280; Mon, 26 Sep 2005 11:33:30 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DBB00FB282; Mon, 26 Sep 2005 11:33:28 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 59884FB266 for ; Mon, 26 Sep 2005 11:33:27 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 78D4189871; Mon, 26 Sep 2005 18:33:26 +0300 (EEST) Message-ID: <433814D1.3080908@piuha.net> Date: Mon, 26 Sep 2005 18:33:37 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola References: In-Reply-To: Cc: mobike@machshav.com, Pasi.Eronen@nokia.com Subject: Re: [Mobike] FW: external mobike-protocol-02 review (technical) (issue 42) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Content-Transfer-Encoding: 7bit Pekka Savola wrote: > a) some people will be (at least slightly) concerned that MOBIKE will > reveal the internal topology of the site. This may or may not be a big > issue (especially as probably the most IPsec sessions will go to at > least semi-trusted nodes), but if we don't state it now, someone is > going to invent a fancy MOBIKE "exploit" 5 years down the road. A > sentence or two in a separate paragraph in Security Considerations > section would probably be sufficient. Agreed. > b) as the conveyed addresses are used for address selection, there > might be issues with that. Let's say, the responder tells it has > addresses 20.20.20.20 and 10.0.0.2. The initiator has 10.0.0.1, and > possibly 30.30.30.30. The initiator and responder are in different > sites (a NAT between them). Now the initiator's address selection > policy might get skewed if it'd prefer particular kind of addresses. > This may be one issue where an explicit warning might be useful. Yes. I'd be even happier if we were able to know which addresses are behind a NAT, but... >> "While no specific timeout lengths are required, it is >> suggested that responders continue retransmitting IKEv2 >> requests for at least five minutes before giving up." > > > No problem with me, though that doesn't give any help on how > aggressive you should be to start with.. This would be useful to specify, I think. > >>> The data associated with this notification is the SHA-1 >>> hash [FIPS180-2] of the following data: >>> >>> ==> this spec is not algorithm-agile. (I can't find the ref >>> right now where this is encouraged.) In this case, maybe it >>> doesn't need to be considering the impact (I don't take a >>> stance on that) -- but this probably deserves at least brief >>> discussion in the security considerations section. >> >> >> This part is basically copied from IKEv2 NAT detection payloads, >> which also use SHA-1 (and IKEv2 spec didn't include any >> discussion about this either).... >> >> However, here the situation might actually be slightly different, >> since the security implications of NAT_DETECTION_*_IP payloads >> and NO_NATS_ALLOWED are different. The simplest solution might >> be just to place the IP addresses in this payload (and mandate >> comparing them with the IP header)... >> >> Any comments from other on this? > > > As these issues have seen some debate (see the thread starting from > http://www1.ietf.org/mail-archive/web/ipv6/current/msg05627.html as an > example), this seems to be something that needs to be at least > mentioned in security considerations; that may be sufficient, though > if one can easily engineer around it without hurting security, that > might not be a bad idea either. > > But the bottom line is that if the algorithm is glued in (which may be > OK given that you can only spoof the NAT prohibition), I think it > needs to be said explicitly (and it might not hurt to get tentative > early review from more folks in the sec area). I think its fine to say the algorithm is "fixed" and that this is something inherited from main IKEv2 spec. But note that there's a difference in the algorithm being fixed as a part of the the protocol versus fixing an algorithm in an identifier (as in Julien's draft that you pointed) - there may be ways of upgrading the protocol but identifier upgrading is much harder. > >>> ==> I would also consider splitting out 2.3 in subsections for >>> readability and more exact references. For example, >>> initiator's first steps could be 2.3.1, Responder's reply >>> 2.3.2, initiator's reply 2.3.3, and the exception 2.3.4. >> >> >> Hmm... as it's currently organized, I'm not sure if splitting >> it would actually improve the readability (it might even be >> confusing if the subsection suddenly changes in the middle of >> the description). > > > If others have no opinion, I'm OK either way. It required a bit more > work from the reader to figure out which part of the section you were > referring to when saying "see Section 2.3" because that includes a > number of different things. Above would have made it shorter and > easier to point to, but with more careful reading, the current one > should be readable as well. Close call, but I think I'd rather see one big section 2.3 than a set of sub-subsections. >> >> I think "includes" is correct, since it's describing a logical >> necessity, not a choice (where we could discuss whether it >> should be a MAY, SHOULD or MUST). > > > My reasoning above was, could an implementer try to optimize the > protocol so that it will only send NO_NATS_ALLOWED with some but not > all update messages (saving bits). I.e., would the processing be any > different for the exchange responder if NO_NATS_ALLOWED was sometimes > present and sometimes not. > > Hence I proposed a MUST implying "if you are going to send > NO_NATS_ALLOWED, you have to send it *every time*, instead of just > when you feel like it". > > But if folks want to leave this a bit more open, that's fine with me.. I'd rather see the if-you-do-this-then-you-need-to-do-it-in-every-message approach. But I'm not sure if there's need for a MUST; SHOULD appears sufficient here. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 27 00:46:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK7MQ-0004L9-OJ for mobike-archive@megatron.ietf.org; Tue, 27 Sep 2005 00:46:35 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00508 for ; Tue, 27 Sep 2005 00:46:30 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id CD2C1FB289; Tue, 27 Sep 2005 00:46:28 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 38A82FB280; Tue, 27 Sep 2005 00:46:26 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 37F2AFB282; Tue, 27 Sep 2005 00:46:25 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 9F2DEFB262 for ; Tue, 27 Sep 2005 00:46:24 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C7AE689852; Tue, 27 Sep 2005 07:46:23 +0300 (EEST) Message-ID: <4338CEAB.5010901@piuha.net> Date: Tue, 27 Sep 2005 07:46:35 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont References: <200509261528.j8QFSrtA004126@givry.rennes.enst-bretagne.fr> In-Reply-To: <200509261528.j8QFSrtA004126@givry.rennes.enst-bretagne.fr> Cc: mobike@machshav.com, Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Content-Transfer-Encoding: 7bit Francis Dupont wrote: > In your previous mail you wrote: > > The text that your provided above Francis looks like > material that could be included in the security > considerations section. Of course, we'd have to also > mention that under some conditions, the attack is > temporary. For instance, if the real node sends packets > after the attacker has left, the problem is corrected. > >=> unfortunately this is not true: the problem can be corrected >only with an explicit action (an address update to the right address). > > Right. The real node needs to do an address update. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 27 01:35:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK87U-0005K7-Bj for mobike-archive@megatron.ietf.org; Tue, 27 Sep 2005 01:35:14 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02366 for ; Tue, 27 Sep 2005 01:35:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 93923FB289; Tue, 27 Sep 2005 01:35:04 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1D908FB280; Tue, 27 Sep 2005 01:35:00 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 60C6EFB282; Tue, 27 Sep 2005 01:34:58 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 461D0FB262 for ; Tue, 27 Sep 2005 01:34:57 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 64DDF89852; Tue, 27 Sep 2005 08:34:55 +0300 (EEST) Message-ID: <4338DA0A.1090503@piuha.net> Date: Tue, 27 Sep 2005 08:35:06 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont , Pasi.Eronen@nokia.com References: <200509201232.j8KCWg7n070911@givry.rennes.enst-bretagne.fr> <43380F7D.7000406@piuha.net> In-Reply-To: <43380F7D.7000406@piuha.net> Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Content-Transfer-Encoding: 7bit Some further thoughts. Even in v4, the benefit of the no-preventation-and-no-traversal case is extremely small. Basically, its only different to the NAT preventation case if you happen to have a rare type of a NAT between. For normal NATs, the communication would fail. So I would actually like to say something like "NAT preventation SHOULD be enabled by default if NAT traversal is not enabled." I also checked with Pasi that he seems OK with this approach. I also reviewed our security considerations text, and it seems that we have sufficient text to describe what the impact of the NAT prevention payloads (or lack of thereof) is. However, I did not see sufficient text to talk about how temporary or permanent these attacks are. I'd like to suggest the following text be added between paragraphs 2 and 3 in Section 4.1: This attack can only be launched by on-path attackers that are capable of modifying either the initial IKE packets or other packets carrying NAT detection payloads (such as Dead Peer Detection messages). By modifying the outer addresses in these packets, the attackers can make the peers believe a new NAT or a changed NAT binding exists between them. The attack can continue as long as the attacker is on the path, modifying packets. If this is no longer the case, IKEv2 and MOBIKE mechanisms designed to detect NAT mapping changes will eventually recognize that the intended traffic is not getting through, and update the addresses appropriately. Does this work for everyone? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 27 05:15:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKBYl-0001iD-Iy for mobike-archive@megatron.ietf.org; Tue, 27 Sep 2005 05:15:35 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24983 for ; Tue, 27 Sep 2005 05:15:32 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 46D0CFB27F; Tue, 27 Sep 2005 05:15:31 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EB12EFB262; Tue, 27 Sep 2005 05:15:24 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0EE58FB27F; Tue, 27 Sep 2005 05:15:24 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 6BE5DFB24F for ; Tue, 27 Sep 2005 05:15:23 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A909989852; Tue, 27 Sep 2005 12:15:21 +0300 (EEST) Message-ID: <43390DB4.1010603@piuha.net> Date: Tue, 27 Sep 2005 12:15:32 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: stephane@cisco.com, Mohan Parthasarathy References: <13E3DA8B48E17D4C96D261A36A23FCD68E4BA6@xmb-rtp-208.amer.cisco.com> In-Reply-To: <13E3DA8B48E17D4C96D261A36A23FCD68E4BA6@xmb-rtp-208.amer.cisco.com> Cc: mobike@machshav.com Subject: Re: [Mobike] issue 34 proposal X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Content-Transfer-Encoding: 7bit stephane@cisco.com wrote: >Just to clarify... > >If one does detect NAT change at ESP layer, what does one do? > >Do we do a return routability check on the new address before updating >it's SADB? It would seem logical, but just want to make sure we're on >the same page. > > and Mohan wrote: >Eventually, you want to recover faster too, right ? If it is going to take a roundtrip >extra compared to IKEv2 NAT-T before you can use the address, how slower >it is compared with the explicit update ? > > I would note that the return routability text is already being performed based on policy (as agreed upon in earlier issues). So it isn't clear to me that we need to have an answer here. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 27 06:37:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKCq4-0002Kn-2j for mobike-archive@megatron.ietf.org; Tue, 27 Sep 2005 06:37:32 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28000 for ; Tue, 27 Sep 2005 06:37:29 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E78E7FB286; Tue, 27 Sep 2005 06:37:26 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 316D0FB280; Tue, 27 Sep 2005 06:37:23 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 757D7FB282; Tue, 27 Sep 2005 06:37:22 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 54679FB24A for ; Tue, 27 Sep 2005 06:37:21 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D71EE89852 for ; Tue, 27 Sep 2005 13:37:19 +0300 (EEST) Message-ID: <433920EB.8060208@piuha.net> Date: Tue, 27 Sep 2005 13:37:31 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List References: In-Reply-To: Subject: [Mobike] Conclusion on issue 34 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Content-Transfer-Encoding: 7bit Based on discussion, it appears that most people prefer the following: 1) NAT-detection payload -based NAT reboot/change detection as a complement to existing source address -based mechanisms. This mechanism would be used if MOBIKE is on, because otherwise MOBIKE probing would become harder. Detection would be done by including NAT detection payloads in dead peer detection messages. Existing source address -based detection is still allowed in limited manner: "MUST NOT do automatic update with IKEv2 packets when MOBIKE is used (breaks the probing), but you MAY do it for ESP packets." 2) Use IKE messages for the path testing that is needed in MOBIKE. I have specifically left out the conclusion about whether to do return routability after a NAT change is detected. I'm hoping its covered by the policy that we already have for return routability usage. If people disagree about this we'll open a separate issue on it. Also, it was brought up during the discussion that our charter talks about NAT traversal, requires us to not change IKEv2 NAT traversal but also requires us to document how they work together. There has been a discussion of how well the different alternative proposals follow the charter. We discussed this with Paul and concluded that its important we choose the solution that the group feels is the technically correct one. The charter requires us to document interactions, which we are doing. We also do not change anything in the regular NAT traversal behaviour, except that when both NAT traversal and MOBIKE are being used we need to handle source address changes in MOBIKE-compatible manner. We realize that any specification of the interaction that goes beyond ("they can be used completely independently" and "they can not be used together at all") is walking a fine line between complying and violating the charter. But we feel that in this case we are still reasonably within charter. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 27 13:26:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKJDP-00025J-Gp for mobike-archive@megatron.ietf.org; Tue, 27 Sep 2005 13:26:03 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26491 for ; Tue, 27 Sep 2005 13:26:00 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 84BD4FB284; Tue, 27 Sep 2005 13:25:59 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A6D53FB27D; Tue, 27 Sep 2005 13:25:54 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9F06BFB27F; Tue, 27 Sep 2005 13:25:53 -0400 (EDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by machshav.com (Postfix) with ESMTP id A3748FB24F for ; Tue, 27 Sep 2005 13:25:52 -0400 (EDT) Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 27 Sep 2005 10:25:50 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,150,1125903600"; d="scan'208"; a="11441543:sNHT25451960" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8RHPARL020717; Tue, 27 Sep 2005 13:25:46 -0400 (EDT) Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 13:25:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Sep 2005 13:25:42 -0400 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD69CF481@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Mobike] issue 34 proposal Thread-Index: AcW+hq7gza9WNjalRXamxvNdQnRsHQFAF/IQ From: "Stephane Beaulieu (stephane)" To: X-OriginalArrivalTime: 27 Sep 2005 17:25:43.0343 (UTC) FILETIME=[7D339BF0:01C5C388] Cc: Pasi.Eronen@nokia.com, Jari Arkko , mobike@machshav.com, Tero Kivinen Subject: Re: [Mobike] issue 34 proposal X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Content-Transfer-Encoding: 7bit > > In your previous mail you wrote: > > But, couldn't an attacker capture an ESP packet, change > the src ip / > port, and force us to start sending/flooding packets to an > un-suspecting > IP addr? > > => yes but by definition a NAT is out of control (if you can > control it the first thing you'll do is to remove it :-) so: OK. That's a bogus argument. NAT's exist all over the place, mostly in places where RA (and Mobike) will be done. The attack in question would be most effective when done near the Head-End. The Head-End administrator can't control whether it's peers are behind NAT or not. > - the implicit update is its own defense, i.e., either it is > not supported > and the attack doesn't work, or it is supported and the > first good packet > from the node behind the NAT will fix the address But if someone is sitting in front of the head-end, then he can muck with all the packets. Even worse, let some good ones through, and switch others that way neither peer will ever detect it (except for noticing lots of TCP retransmits). > - the pseudo-NAT can simply move the direct (i.e., not > reflected) traffic > to a third party > > At least a RR test would tell us that our 'peer' can > indeed recv packets > on the new IP. > > => not really as: > > Still has MitM issues on the RR, mind you... > > => IMHO it is better to rely on ingress filtering: > - when it is deployed, it catches the same attacks than RR > - when it is not deployed, the attackers have already too many > simpler possibilities as the real world can prove everyday... > So I think that most of RR "requirements" are only FUD. If no RR test (with NATD payloads) is done *before* switching, then consider me opposed to this solution. In fact, I'm beginning to think that ESP detection might cause more problems than it solves... Stephane. > > Thanks > > Francis.Dupont@enst-bretagne.fr > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 27 13:29:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKJH5-0002Xp-5h for mobike-archive@megatron.ietf.org; Tue, 27 Sep 2005 13:29:51 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26609 for ; Tue, 27 Sep 2005 13:29:47 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7BB9AFB283; Tue, 27 Sep 2005 13:29:46 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E852DFB27F; Tue, 27 Sep 2005 13:29:41 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5DFCDFB280; Tue, 27 Sep 2005 13:29:39 -0400 (EDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by machshav.com (Postfix) with ESMTP id 9081EFB27D for ; Tue, 27 Sep 2005 13:29:38 -0400 (EDT) Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 Sep 2005 13:29:38 -0400 X-IronPort-AV: i="3.97,150,1125892800"; d="scan'208"; a="71980299:sNHT30694556" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8RHT3RF021960; Tue, 27 Sep 2005 13:29:33 -0400 (EDT) Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 13:29:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Sep 2005 13:29:06 -0400 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD69CF483@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Mobike] issue 34 proposal Thread-Index: AcXDRBRGdQKl+S6bRmmmok0i8Q6k2gARLbzQ From: "Stephane Beaulieu (stephane)" To: "Jari Arkko" , "Mohan Parthasarathy" X-OriginalArrivalTime: 27 Sep 2005 17:29:07.0329 (UTC) FILETIME=[F6C96710:01C5C388] Cc: mobike@machshav.com Subject: Re: [Mobike] issue 34 proposal X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Content-Transfer-Encoding: 7bit > > >Just to clarify... > > > >If one does detect NAT change at ESP layer, what does one do? > > > >Do we do a return routability check on the new address > before updating > >it's SADB? It would seem logical, but just want to make > sure we're on > >the same page. > > > > > and Mohan wrote: > > >Eventually, you want to recover faster too, right ? If it is > going to > >take a roundtrip extra compared to IKEv2 NAT-T before you > can use the > >address, how slower it is compared with the explicit update ? > > > > > I would note that the return routability text is already > being performed based on policy (as agreed upon in earlier > issues). So it isn't clear to me that we need to have an answer here. > I think I missed this part of the discussion, but it seems like an appropriate thing to do. However, if a known attack is possible, we might want to add this as a SHOULD or at least document it as a security consideration. Stephane. > --Jari > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 27 13:30:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKJHx-0002lZ-4X for mobike-archive@megatron.ietf.org; Tue, 27 Sep 2005 13:30:45 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26639 for ; Tue, 27 Sep 2005 13:30:42 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 6769CFB28A; Tue, 27 Sep 2005 13:30:41 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 72526FB280; Tue, 27 Sep 2005 13:30:38 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 23CD9FB282; Tue, 27 Sep 2005 13:30:37 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 6FB91FB27D for ; Tue, 27 Sep 2005 13:30:36 -0400 (EDT) Message-ID: <042701c5c389$2a36fdb0$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jari Arkko" , "Francis Dupont" , References: <200509201232.j8KCWg7n070911@givry.rennes.enst-bretagne.fr><43380F7D.7000406@piuha.net> <4338DA0A.1090503@piuha.net> Date: Tue, 27 Sep 2005 10:30:33 -0700 MIME-Version: 1.0 Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Content-Transfer-Encoding: 7bit Yes, this sounds fine to me. jak ----- Original Message ----- From: "Jari Arkko" To: "Francis Dupont" ; Cc: Sent: Monday, September 26, 2005 10:35 PM Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? > Some further thoughts. Even in v4, the benefit > of the no-preventation-and-no-traversal case is > extremely small. Basically, its only different > to the NAT preventation case if you happen > to have a rare type of a NAT between. For > normal NATs, the communication would fail. > > So I would actually like to say something like > "NAT preventation SHOULD be enabled by default > if NAT traversal is not enabled." I also checked > with Pasi that he seems OK with this approach. > > I also reviewed our security considerations > text, and it seems that we have sufficient > text to describe what the impact of the > NAT prevention payloads (or lack of thereof) is. > However, I did not see sufficient text to > talk about how temporary or permanent these > attacks are. I'd like to suggest the following > text be added between paragraphs 2 and 3 > in Section 4.1: > > This attack can only be launched by on-path > attackers that are capable of modifying either > the initial IKE packets or other packets carrying > NAT detection payloads (such as Dead Peer Detection > messages). By modifying the outer addresses in > these packets, the attackers can make the peers > believe a new NAT or a changed NAT binding exists > between them. The attack can continue as long as > the attacker is on the path, modifying packets. If this > is no longer the case, IKEv2 and MOBIKE mechanisms > designed to detect NAT mapping changes will eventually > recognize that the intended traffic is not getting through, > and update the addresses appropriately. > > Does this work for everyone? > > --Jari > > _______________________________________________ > 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 Tue Sep 27 13:34:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKJLF-00040m-PH for mobike-archive@megatron.ietf.org; Tue, 27 Sep 2005 13:34:09 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26750 for ; Tue, 27 Sep 2005 13:34:07 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E50B0FB284; Tue, 27 Sep 2005 13:34:04 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7B9EDFB27D; Tue, 27 Sep 2005 13:34:01 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4848EFB280; Tue, 27 Sep 2005 13:33:59 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id DC7D2FB24F for ; Tue, 27 Sep 2005 13:33:57 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8RHXZp13555; Tue, 27 Sep 2005 19:33:35 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8RHXZqP008955; Tue, 27 Sep 2005 19:33:35 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509271733.j8RHXZqP008955@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko In-reply-to: Your message of Tue, 27 Sep 2005 08:35:06 +0300. <4338DA0A.1090503@piuha.net> Date: Tue, 27 Sep 2005 19:33:35 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit In your previous mail you wrote: I'd like to suggest the following text be added between paragraphs 2 and 3 in Section 4.1: This attack can only be launched by on-path attackers that are capable of modifying either the initial IKE packets or other packets carrying NAT detection payloads (such as Dead Peer Detection messages). By modifying the outer addresses in these packets, the attackers can make the peers believe a new NAT or a changed NAT binding exists between them. The attack can continue as long as the attacker is on the path, modifying packets. => it should be clear that the packets are IKE messages. In fact, we need the whole text to see if a confusion is possible, and BTW the term "message" is better than "packet"... If this is no longer the case, IKEv2 and MOBIKE mechanisms designed to detect NAT mapping changes will eventually recognize that the intended traffic is not getting through, and update the addresses appropriately. Does this work for everyone? => this works. Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 27 15:56:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKLYu-0006hZ-NL for mobike-archive@megatron.ietf.org; Tue, 27 Sep 2005 15:56:25 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06138 for ; Tue, 27 Sep 2005 15:56:21 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A92C5FB286; Tue, 27 Sep 2005 15:56:15 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 83038FB280; Tue, 27 Sep 2005 15:56:12 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7F33FFB282; Tue, 27 Sep 2005 15:56:10 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 3EF93FB27D for ; Tue, 27 Sep 2005 15:56:09 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8RJtIp22908; Tue, 27 Sep 2005 21:55:18 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8RJtIDh009934; Tue, 27 Sep 2005 21:55:18 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509271955.j8RJtIDh009934@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Stephane Beaulieu (stephane)" In-reply-to: Your message of Tue, 27 Sep 2005 13:25:42 EDT. <13E3DA8B48E17D4C96D261A36A23FCD69CF481@xmb-rtp-208.amer.cisco.com> Date: Tue, 27 Sep 2005 21:55:18 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: Pasi.Eronen@nokia.com, Jari Arkko , mobike@machshav.com, Tero Kivinen Subject: Re: [Mobike] issue 34 proposal X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit In your previous mail you wrote: If no RR test (with NATD payloads) is done *before* switching, then consider me opposed to this solution. => we are speaking about ESP so I don't understand the "with NATD payloads" (BTW with NATD payloads only the real source can put a fake address as they are protected). In fact, I'm beginning to think that ESP detection might cause more problems than it solves... => ESP detection is in IKEv2, if you believe it you should have objected during the IKEv2 last call. Regards Francis.Dupont@enst-bretagne.fr PS: BTW I believe the ESP detection is the right mechanism for the implicit update of NAT-T. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 27 16:00:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKLca-0007sr-Qb for mobike-archive@megatron.ietf.org; Tue, 27 Sep 2005 16:00:13 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07024 for ; Tue, 27 Sep 2005 16:00:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id BF081FB289; Tue, 27 Sep 2005 16:00:09 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B1716FB27D; Tue, 27 Sep 2005 16:00:06 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C769FFB282; Tue, 27 Sep 2005 16:00:05 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 84132FB23E for ; Tue, 27 Sep 2005 16:00:04 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8RJxup23263; Tue, 27 Sep 2005 21:59:56 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8RJxtJu009960; Tue, 27 Sep 2005 21:59:55 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509271959.j8RJxtJu009960@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Stephane Beaulieu (stephane)" In-reply-to: Your message of Tue, 27 Sep 2005 13:29:06 EDT. <13E3DA8B48E17D4C96D261A36A23FCD69CF483@xmb-rtp-208.amer.cisco.com> Date: Tue, 27 Sep 2005 21:59:55 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Mohan Parthasarathy , Jari Arkko Subject: Re: [Mobike] issue 34 proposal X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit In your previous mail you wrote: > I would note that the return routability text is already > being performed based on policy (as agreed upon in earlier > issues). So it isn't clear to me that we need to have an answer here. I think I missed this part of the discussion, => to summary for the explicit update (Mobike one) the default policy is to perform a RR check (equivalent of a SHOULD but clearer about the cases the RR check is not needed). There was always a consensus, the discussion was about the wording (clearer, simpler and more accurate). but it seems like an appropriate thing to do. However, if a known attack is possible, we might want to add this as a SHOULD or at least document it as a security consideration. => as Jari explained this is already in the document. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 27 16:13:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKLpT-0006hQ-G2 for mobike-archive@megatron.ietf.org; Tue, 27 Sep 2005 16:13:32 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11829 for ; Tue, 27 Sep 2005 16:13:29 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9C652FB289; Tue, 27 Sep 2005 16:13:26 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A86FBFB27D; Tue, 27 Sep 2005 16:13:21 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9C534FB280; Tue, 27 Sep 2005 16:13:20 -0400 (EDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by machshav.com (Postfix) with ESMTP id DBA18FB24F for ; Tue, 27 Sep 2005 16:13:19 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 27 Sep 2005 13:13:19 -0700 X-IronPort-AV: i="3.97,150,1125903600"; d="scan'208"; a="662279224:sNHT32586488" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8RKCl4p025752; Tue, 27 Sep 2005 13:13:15 -0700 (PDT) Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 16:12:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Sep 2005 16:12:46 -0400 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD69CF55D@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Mobike] issue 34 proposal Thread-Index: AcXDnYx9/SVs0kATRIOuh+Csbq8IkQAAC9Gw From: "Stephane Beaulieu (stephane)" To: X-OriginalArrivalTime: 27 Sep 2005 20:12:46.0927 (UTC) FILETIME=[D3B925F0:01C5C39F] Cc: Pasi.Eronen@nokia.com, Jari Arkko , mobike@machshav.com, Tero Kivinen Subject: Re: [Mobike] issue 34 proposal X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Content-Transfer-Encoding: 7bit > > In your previous mail you wrote: > > If no RR test (with NATD payloads) is done *before* switching, then > consider me opposed to this solution. > > => we are speaking about ESP so I don't understand the "with > NATD payloads" (BTW with NATD payloads only the real source > can put a fake address as they are protected). What I'm saying is that if I detect a NAT change at the ESP layer, I'd want to send an IKE packet (with NATD payloads) to the peer to make SURE he can both recv/send packets from/to that address before I start using it. Yes this adds a little extra latency (1 round trip). But this leaves no doubt that the peer is at least reachable on that address. > > In fact, I'm beginning to think that ESP detection might cause more > problems than it solves... > > => ESP detection is in IKEv2, if you believe it you should > have objected during the IKEv2 last call. I think we must be talking about different things. I see nothing in the ikev2-17 that describes how NAT decisions are made using ESP packets. All I see is text describing how to use ISAKMP NAT-D payloads to detect if a NAT box is present in the network. The draft is rather large, so I may have missed it. Can you point me to some text that describes how ESP pkts are used to detect a NAT, or a NAT mapping change? > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: BTW I believe the ESP detection is the right mechanism > for the implicit update of NAT-T. > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 27 16:40:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKMFO-0002ZO-Hi for mobike-archive@megatron.ietf.org; Tue, 27 Sep 2005 16:40:18 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19245 for ; Tue, 27 Sep 2005 16:40:16 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id DDCFEFB27D; Tue, 27 Sep 2005 16:40:14 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9185BFB280; Tue, 27 Sep 2005 16:40:11 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CD852FB282; Tue, 27 Sep 2005 16:40:09 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 3204DFB27D for ; Tue, 27 Sep 2005 16:40:08 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A60BA89852; Tue, 27 Sep 2005 23:40:06 +0300 (EEST) Message-ID: <4339AE31.3080307@piuha.net> Date: Tue, 27 Sep 2005 23:40:17 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Stephane Beaulieu (stephane)" References: <13E3DA8B48E17D4C96D261A36A23FCD69CF483@xmb-rtp-208.amer.cisco.com> In-Reply-To: <13E3DA8B48E17D4C96D261A36A23FCD69CF483@xmb-rtp-208.amer.cisco.com> Cc: Mohan Parthasarathy , mobike@machshav.com Subject: Re: [Mobike] issue 34 proposal X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Content-Transfer-Encoding: 7bit Stephane Beaulieu (stephane) wrote: >I think I missed this part of the discussion, but it seems like an >appropriate thing to do. However, if a known attack is possible, we >might want to add this as a SHOULD or at least document it as a security >consideration. > > Its on by default, I think. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 27 21:36:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKQrc-0003Pr-TV for mobike-archive@megatron.ietf.org; Tue, 27 Sep 2005 21:36:05 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05852 for ; Tue, 27 Sep 2005 21:36:02 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 17982FB284; Tue, 27 Sep 2005 21:36:00 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 98235FB27D; Tue, 27 Sep 2005 21:35:56 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0149EFB282; Tue, 27 Sep 2005 21:35:55 -0400 (EDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by machshav.com (Postfix) with SMTP id 0ABFEFB27D for ; Tue, 27 Sep 2005 21:35:54 -0400 (EDT) Received: (qmail 34762 invoked from network); 28 Sep 2005 01:35:51 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.169.160.212 with login) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 28 Sep 2005 01:35:51 -0000 Message-ID: <002901c5c3cc$f865e820$6701a8c0@adithya> From: "Mohan Parthasarathy" To: "Jari Arkko" , "Francis Dupont" , References: <200509201232.j8KCWg7n070911@givry.rennes.enst-bretagne.fr><43380F7D.7000406@piuha.net> <4338DA0A.1090503@piuha.net> Date: Tue, 27 Sep 2005 18:35:54 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Content-Transfer-Encoding: 7bit > Some further thoughts. Even in v4, the benefit > of the no-preventation-and-no-traversal case is > extremely small. Basically, its only different > to the NAT preventation case if you happen > to have a rare type of a NAT between. For > normal NATs, the communication would fail. > > So I would actually like to say something like > "NAT preventation SHOULD be enabled by default > if NAT traversal is not enabled." I also checked > with Pasi that he seems OK with this approach. > > I also reviewed our security considerations > text, and it seems that we have sufficient > text to describe what the impact of the > NAT prevention payloads (or lack of thereof) is. > However, I did not see sufficient text to > talk about how temporary or permanent these > attacks are. I'd like to suggest the following > text be added between paragraphs 2 and 3 > in Section 4.1: > > This attack can only be launched by on-path > attackers that are capable of modifying either > the initial IKE packets or other packets carrying > NAT detection payloads (such as Dead Peer Detection > messages). By modifying the outer addresses in Hmm.. with issue 34, we are also allowing updates from ESP packets.. > these packets, the attackers can make the peers > believe a new NAT or a changed NAT binding exists > between them. The attack can continue as long as > the attacker is on the path, modifying packets. If this > is no longer the case, IKEv2 and MOBIKE mechanisms > designed to detect NAT mapping changes will eventually > recognize that the intended traffic is not getting through, > and update the addresses appropriately. > > Does this work for everyone? > Looks okay to me. -mohan > --Jari > > _______________________________________________ > 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 Tue Sep 27 21:36:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKQsQ-0003c6-K2 for mobike-archive@megatron.ietf.org; Tue, 27 Sep 2005 21:36:54 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05938 for ; Tue, 27 Sep 2005 21:36:52 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 624A1FB289; Tue, 27 Sep 2005 21:36:52 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EE353FB280; Tue, 27 Sep 2005 21:36:48 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4BC71FB282; Tue, 27 Sep 2005 21:36:47 -0400 (EDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by machshav.com (Postfix) with SMTP id 4920CFB27D for ; Tue, 27 Sep 2005 21:36:46 -0400 (EDT) Received: (qmail 36217 invoked from network); 28 Sep 2005 01:36:46 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.169.160.212 with login) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 28 Sep 2005 01:36:45 -0000 Message-ID: <003301c5c3cd$18fd4290$6701a8c0@adithya> From: "Mohan Parthasarathy" To: "Jari Arkko" , "MOBIKE Mailing List" References: <433920EB.8060208@piuha.net> Date: Tue, 27 Sep 2005 18:36:49 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Subject: Re: [Mobike] Conclusion on issue 34 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Content-Transfer-Encoding: 7bit Looks okay to me. -mohan ----- Original Message ----- From: "Jari Arkko" To: "MOBIKE Mailing List" Sent: Tuesday, September 27, 2005 3:37 AM Subject: [Mobike] Conclusion on issue 34 > Based on discussion, it appears that most people prefer > the following: > > 1) NAT-detection payload -based NAT reboot/change detection > as a complement to existing source address -based > mechanisms. This mechanism would be used if MOBIKE > is on, because otherwise MOBIKE probing would become > harder. > > Detection would be done by including NAT detection > payloads in dead peer detection messages. > > Existing source address -based detection is still allowed in > limited manner: "MUST NOT do automatic update with > IKEv2 packets when MOBIKE is used (breaks the probing), > but you MAY do it for ESP packets." > > 2) Use IKE messages for the path testing that is needed > in MOBIKE. > > I have specifically left out the conclusion about whether > to do return routability after a NAT change is detected. > I'm hoping its covered by the policy that we already have > for return routability usage. If people disagree about this > we'll open a separate issue on it. > > Also, it was brought up during the discussion that our > charter talks about NAT traversal, requires us to not > change IKEv2 NAT traversal but also requires us to > document how they work together. There has been a > discussion of how well the different alternative proposals > follow the charter. We discussed this with Paul and > concluded that its important we choose the solution > that the group feels is the technically correct one. > The charter requires us to document interactions, > which we are doing. We also do not change anything > in the regular NAT traversal behaviour, except that > when both NAT traversal and MOBIKE are being > used we need to handle source address changes > in MOBIKE-compatible manner. We realize that > any specification of the interaction that goes beyond > ("they can be used completely independently" and > "they can not be used together at all") is walking > a fine line between complying and violating the > charter. But we feel that in this case we are still > reasonably within charter. > > --Jari > > _______________________________________________ > 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 Wed Sep 28 02:53:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKVoj-00048l-0Z for mobike-archive@megatron.ietf.org; Wed, 28 Sep 2005 02:53:25 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17084 for ; Wed, 28 Sep 2005 02:53:23 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 716E0FB283; Wed, 28 Sep 2005 02:53:19 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 25CFBFB262; Wed, 28 Sep 2005 02:53:15 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 39496FB280; Wed, 28 Sep 2005 02:53:11 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 914DFFB24F for ; Wed, 28 Sep 2005 02:53:09 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8S6qQr28368; Wed, 28 Sep 2005 08:52:26 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8S6qOCB012028; Wed, 28 Sep 2005 08:52:24 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509280652.j8S6qOCB012028@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Stephane Beaulieu (stephane)" In-reply-to: Your message of Tue, 27 Sep 2005 16:12:46 EDT. <13E3DA8B48E17D4C96D261A36A23FCD69CF55D@xmb-rtp-208.amer.cisco.com> Date: Wed, 28 Sep 2005 08:52:24 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: Pasi.Eronen@nokia.com, Jari Arkko , mobike@machshav.com, Tero Kivinen Subject: Re: [Mobike] issue 34 proposal X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit In your previous mail you wrote: > => we are speaking about ESP so I don't understand the "with > NATD payloads" (BTW with NATD payloads only the real source > can put a fake address as they are protected). What I'm saying is that if I detect a NAT change at the ESP layer => how NAT-T/implicit update (ESP detection is a part of it) and MOBIKE/explicit update can interfere is a closed point (which both has no interest for me and does what you like). > In fact, I'm beginning to think that ESP detection might cause more > problems than it solves... > > => ESP detection is in IKEv2, if you believe it you should > have objected during the IKEv2 last call. I think we must be talking about different things. I see nothing in the ikev2-17 that describes how NAT decisions are made using ESP packets. => it is at the end of 2.23 page 39: There are cases where a NAT box decides to remove mappings that are still alive (for example, the keepalive interval is too long, or the NAT box is rebooted). To recover in these cases, hosts that are not behind a NAT SHOULD send all packets (including retransmission packets) to the IP address and port from the last valid authenticated packet from the other end (i.e., dynamically update the address). A host behind a NAT SHOULD NOT do this because it opens a DoS attack possibility. Any authenticated IKE packet or any authenticated UDP encapsulated ESP packet can be used to detect that the IP address or the port has changed. Note that similar but probably not identical actions will likely be needed to make IKE work with Mobile IP, but such processing is not addressed by this document. All I see is text describing how to use ISAKMP NAT-D payloads to detect if a NAT box is present in the network. The draft is rather large, so I may have missed it. Can you point me to some text that describes how ESP pkts are used to detect a NAT, or a NAT mapping change? => now you have the text about NAT mapping change detection, including IKE, ESP and implicit update. And in a past message in this list you have the decision (and proposed text) about application of this in a mixed NAT-T/MOBIKE context: References: Based on discussion, it appears that most people prefer the following: 1) NAT-detection payload -based NAT reboot/change detection as a complement to existing source address -based mechanisms. This mechanism would be used if MOBIKE is on, because otherwise MOBIKE probing would become harder. Detection would be done by including NAT detection payloads in dead peer detection messages. Existing source address -based detection is still allowed in limited manner: "MUST NOT do automatic update with IKEv2 packets when MOBIKE is used (breaks the probing), but you MAY do it for ESP packets." 2) Use IKE messages for the path testing that is needed in MOBIKE. I (Jari) have specifically left out the conclusion about whether to do return routability after a NAT change is detected. I'm hoping its covered by the policy that we already have for return routability usage. If people disagree about this we'll open a separate issue on it. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Sep 28 08:42:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKbGS-0006nN-Qb for mobike-archive@megatron.ietf.org; Wed, 28 Sep 2005 08:42:25 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03301 for ; Wed, 28 Sep 2005 08:42:23 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4C9C5FB28D; Wed, 28 Sep 2005 08:42:20 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 29454FB286; Wed, 28 Sep 2005 08:42:15 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D8243FB289; Wed, 28 Sep 2005 08:42:12 -0400 (EDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by machshav.com (Postfix) with ESMTP id A207FFB27D for ; Wed, 28 Sep 2005 08:42:11 -0400 (EDT) Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 28 Sep 2005 08:42:11 -0400 X-IronPort-AV: i="3.97,154,1125892800"; d="scan'208"; a="72099678:sNHT34142410" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8SCg4Qn017494; Wed, 28 Sep 2005 08:42:08 -0400 (EDT) Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Sep 2005 08:42:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 Sep 2005 08:42:02 -0400 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD69CF66C@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Mobike] issue 34 proposal Thread-Index: AcXD+VlIQgoyCb59T5+4Ts28h03FEgAMI3jQ From: "Stephane Beaulieu (stephane)" To: X-OriginalArrivalTime: 28 Sep 2005 12:42:03.0823 (UTC) FILETIME=[0730B3F0:01C5C42A] Cc: Pasi.Eronen@nokia.com, Jari Arkko , mobike@machshav.com, Tero Kivinen Subject: Re: [Mobike] issue 34 proposal X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Content-Transfer-Encoding: 7bit I had indeed missed that text. Thanks. > -----Original Message----- > From: Francis.Dupont@enst-bretagne.fr > [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Wednesday, September 28, 2005 2:52 AM > To: Stephane Beaulieu (stephane) > Cc: mobike@machshav.com; Jari Arkko; Pasi.Eronen@nokia.com; > Tero Kivinen > Subject: Re: [Mobike] issue 34 proposal > > In your previous mail you wrote: > > > => we are speaking about ESP so I don't understand the "with > > NATD payloads" (BTW with NATD payloads only the real source > > can put a fake address as they are protected). > > What I'm saying is that if I detect a NAT change at the ESP layer > > => how NAT-T/implicit update (ESP detection is a part of it) > and MOBIKE/explicit update can interfere is a closed point > (which both has no interest for me and does what you like). > > > In fact, I'm beginning to think that ESP detection > might cause more > > problems than it solves... > > > > => ESP detection is in IKEv2, if you believe it you should > > have objected during the IKEv2 last call. > > I think we must be talking about different things. I see > nothing in the > ikev2-17 that describes how NAT decisions are made using > ESP packets. > > => it is at the end of 2.23 page 39: > > There are cases where a NAT box decides to remove mappings that > are still alive (for example, the keepalive interval is > too long, > or the NAT box is rebooted). To recover in these cases, > hosts that > are not behind a NAT SHOULD send all packets (including > retransmission packets) to the IP address and port from the last > valid authenticated packet from the other end (i.e., dynamically > update the address). A host behind a NAT SHOULD NOT do this > because it opens a DoS attack possibility. Any authenticated IKE > packet or any authenticated UDP encapsulated ESP packet can be > used to detect that the IP address or the port has changed. > > Note that similar but probably not identical actions will likely > be needed to make IKE work with Mobile IP, but such > processing is > not addressed by this document. > > All I see is text describing how to use ISAKMP NAT-D > payloads to detect > if a NAT box is present in the network. The draft is > rather large, so I > may have missed it. Can you point me to some text that > describes how > ESP pkts are used to detect a NAT, or a NAT mapping change? > > => now you have the text about NAT mapping change detection, > including IKE, ESP and implicit update. And in a past message > in this list you have the decision (and proposed text) about > application of this in a mixed NAT-T/MOBIKE context: > References: > > > Based on discussion, it appears that most people prefer > the following: > > 1) NAT-detection payload -based NAT reboot/change detection > as a complement to existing source address -based > mechanisms. This mechanism would be used if MOBIKE > is on, because otherwise MOBIKE probing would become > harder. > > Detection would be done by including NAT detection > payloads in dead peer detection messages. > > Existing source address -based detection is still allowed in > limited manner: "MUST NOT do automatic update with > IKEv2 packets when MOBIKE is used (breaks the probing), > but you MAY do it for ESP packets." > > 2) Use IKE messages for the path testing that is needed > in MOBIKE. > > I (Jari) have specifically left out the conclusion about whether > to do return routability after a NAT change is detected. > I'm hoping its covered by the policy that we already have > for return routability usage. If people disagree about this > we'll open a separate issue on it. > > Regards > > Francis.Dupont@enst-bretagne.fr > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Sep 28 11:52:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKeEJ-0005Kg-Qy for mobike-archive@megatron.ietf.org; Wed, 28 Sep 2005 11:52:24 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15902 for ; Wed, 28 Sep 2005 11:52:18 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D3460FB284; Wed, 28 Sep 2005 11:52:13 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 95680FB284; Wed, 28 Sep 2005 11:52:09 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 767BCFB289; Wed, 28 Sep 2005 11:52:07 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 2D88EFB284 for ; Wed, 28 Sep 2005 11:52:06 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7927989880; Wed, 28 Sep 2005 18:52:05 +0300 (EEST) Message-ID: <433AB99E.7030009@piuha.net> Date: Wed, 28 Sep 2005 18:41:18 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont References: <200509191506.j8JF6rl8065143@givry.rennes.enst-bretagne.fr> In-Reply-To: <200509191506.j8JF6rl8065143@givry.rennes.enst-bretagne.fr> Cc: mobike@machshav.com, Pasi.Eronen@nokia.com Subject: Re: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Content-Transfer-Encoding: 7bit Francis Dupont wrote: > I think we have a pending milestone change coming in any > case. E.g., what's the timeplan and interest for reduced > tunnel overhead and pfkey work? Should the transport doc > be in the milestones? > > I see the SCTP support as one of the use cases in the > charter, along with the main use case of roaming VPN > users. My understanding has been that we are not > required to cover everything that we need to do in > one document. > >=> so the issue is "closed" only for the current document? > > Right. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Sep 28 11:52:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKeES-0005Nf-1Q for mobike-archive@megatron.ietf.org; Wed, 28 Sep 2005 11:52:32 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15917 for ; Wed, 28 Sep 2005 11:52:28 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1D93DFB297; Wed, 28 Sep 2005 11:52:28 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F3E8DFB289; Wed, 28 Sep 2005 11:52:22 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 465D8FB28B; Wed, 28 Sep 2005 11:52:12 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 0A662FB282 for ; Wed, 28 Sep 2005 11:52:06 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id EA94E89871; Wed, 28 Sep 2005 18:52:04 +0300 (EEST) Message-ID: <433AB62C.60402@piuha.net> Date: Wed, 28 Sep 2005 18:26:36 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: In-Reply-To: Cc: mobike@machshav.com, pekkas@netcore.fi Subject: Re: [Mobike] FW: external mobike-protocol-02 review (technical) (issue 42) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: >Yes, this is something that probably deserves a slightly longer >explanation (but I don't think we should spend too much time on >it). How about this? > >1.3 MOBIKE and Network Address Translation (NAT) > > In some MOBIKE scenarios the network may contain NATs or stateful > packet filters (for brevity, the rest of this document talks simply > about NATs). The NAT Traversal feature specified in [IKEv2] allows > IKEv2 to work through NATs in many cases, and MOBIKE can leverage > this functionality: when the addresses used for IPsec SAs are > changed, MOBIKE can enable or disable IKEv2 NAT Traversal as needed. > > Nevertheless, there are some limitations. NATs usually introduce an > asymmetry in the network: packets reaching the NAT from the "inside" > are treated differently from packets coming from the "outside". This > asymmetry leads to restrictions on what MOBIKE can do. To give a > concrete example, consider a situation where both peers have only a > single address, and the initiator is behind a NAT. If the > responder's address now changes, it needs to send a packet to the > initiator using its new address. However, if the NAT is, for > instance, of the "restricted cone" type (see [STUN] for one > description of different NAT types), this is not possible: the NAT > will drop packets sent from the new address (unless the initiator has > previously sent a packet to that address -- which it cannot do until > it knows the address). > > For simplicity, MOBIKE does not attempt to handle all possible NAT- > related scenarios. Instead, MOBIKE assumes that if NATs are present, > the initiator is the party "behind" the NAT, and does not fully > support the case where the responder's addresses change. > > "Does not fully support" means that no special effort is made to > support this functionality. However, if the alternative is losing > connectivity completely, the responder can still attempt to proceed > with the change, and depending on, e.g., the exact type of NAT, it > may succeed. However, analyzing the exact circumstances when this > will or will not work is not done in this document. > > Works for me. >>==> "relatively long timeout intervals" is pretty ambiguous. >>While this may not affect the interoperability, shouldn't we be >>a bit more precise what kind of order of magnitude we're >>talking about here? Seconds? Ten seconds? 30 sec? Minutes? >>10 minutes? Hours? >> >> > >This is to some degree also a matter of local policy... but I >guess it would be useful to at least give a reasonable example. > >Tero, do you have an opinion about what would a good >recommendation be? Maybe something like > > "While no specific timeout lengths are required, it is > suggested that responders continue retransmitting IKEv2 > requests for at least five minutes before giving up." > > Ok. The key point is that the responder side should not be aggressive in this regard. >> The data associated with this notification is the SHA-1 >> hash [FIPS180-2] of the following data: >> >>==> this spec is not algorithm-agile. (I can't find the ref >>right now where this is encouraged.) In this case, maybe it >>doesn't need to be considering the impact (I don't take a >>stance on that) -- but this probably deserves at least brief >>discussion in the security considerations section. >> >> > >This part is basically copied from IKEv2 NAT detection payloads, >which also use SHA-1 (and IKEv2 spec didn't include any >discussion about this either).... > >However, here the situation might actually be slightly different, >since the security implications of NAT_DETECTION_*_IP payloads >and NO_NATS_ALLOWED are different. The simplest solution might > > Right. >be just to place the IP addresses in this payload (and mandate >comparing them with the IP header)... > > That seems simplest. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Sep 28 11:57:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKeJC-0006RL-Kv for mobike-archive@megatron.ietf.org; Wed, 28 Sep 2005 11:57:26 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16119 for ; Wed, 28 Sep 2005 11:57:23 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 92978FB289; Wed, 28 Sep 2005 11:57:21 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B4FC2FB24A; Wed, 28 Sep 2005 11:57:18 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 583D0FB27D; Wed, 28 Sep 2005 11:57:16 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 3BE3BFB249 for ; Wed, 28 Sep 2005 11:57:15 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 51B8E89870; Wed, 28 Sep 2005 18:57:14 +0300 (EEST) Message-ID: <433ABD65.7070902@piuha.net> Date: Wed, 28 Sep 2005 18:57:25 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola , Pasi.Eronen@nokia.com References: <433814D1.3080908@piuha.net> In-Reply-To: <433814D1.3080908@piuha.net> Cc: mobike@machshav.com Subject: Re: [Mobike] FW: external mobike-protocol-02 review (technical) (issue 42) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Content-Transfer-Encoding: 7bit Replying my own e-mail... >> a) some people will be (at least slightly) concerned that MOBIKE will >> reveal the internal topology of the site. This may or may not be a >> big issue (especially as probably the most IPsec sessions will go to >> at least semi-trusted nodes), but if we don't state it now, someone >> is going to invent a fancy MOBIKE "exploit" 5 years down the road. A >> sentence or two in a separate paragraph in Security Considerations >> section would probably be sufficient. > > > Agreed. >> b) as the conveyed addresses are used for address selection, there >> might be issues with that. Let's say, the responder tells it has >> addresses 20.20.20.20 and 10.0.0.2. The initiator has 10.0.0.1, and >> possibly 30.30.30.30. The initiator and responder are in different >> sites (a NAT between them). Now the initiator's address selection >> policy might get skewed if it'd prefer particular kind of addresses. >> This may be one issue where an explicit warning might be useful. > > > Yes. I'd be even happier if we were able to know > which addresses are behind a NAT, but... Thinking about this further, it seems that sending the addresses as they currently are is the least bad option here, as long as we have sufficient warnings about that. If we want to support multiple addresses for failover, we need to inform the peer. Yet it would be quite hard to test all these addresses, or pairs really, to find out which one of them have a NAT towards the other peer. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 29 13:53:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL2b6-00077f-MA for mobike-archive@megatron.ietf.org; Thu, 29 Sep 2005 13:53:32 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25092 for ; Thu, 29 Sep 2005 13:53:29 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1017AFB294; Thu, 29 Sep 2005 13:53:28 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5C4C2FB291; Thu, 29 Sep 2005 13:53:23 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3874EFB292; Thu, 29 Sep 2005 13:53:21 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 7388FFB28D for ; Thu, 29 Sep 2005 13:53:20 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A186989864 for ; Thu, 29 Sep 2005 20:53:14 +0300 (EEST) Message-ID: <433C2A15.2060908@piuha.net> Date: Thu, 29 Sep 2005 20:53:25 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Subject: [Mobike] mobike protocol revision -03 & process forward X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Content-Transfer-Encoding: 7bit Folks, Executive summary: please review the draft (URL at the end). Longer version: Pasi has produced a new version of the protocol specification that we believe addresses all issues submitted so far. At this stage the chairs believe that we are ready for Working Group Last Call on this document. We have also agreed to be a part of an experiment where RFC Editor copy editing process takes place prior to the WGLC, IETF LC and IESG review, hopefully reducing time needed after the draft has been approved, and reducing the number of editorial comments later. Here's our time plan: - Draft -03 available now - Next week the RFC editor processes the draft - Official WGLC will start when the draft-04 returns back to us (but comments are welcome even now) - WGLC will end by October 17th which leaves Pasi some time to edit the -05 before the Vancouver deadline - Assuming all uncovered issues can be solved during WGLC, which we hope, -05 will be sent to IETF LC and the IESG As you can see, we do not have too much time before the final revision is needed. So it is essential that all of us review the draft, provide comments, and participate in the discussion of how possible problems are solved in a timely manner. Now is a good time to start reading the draft! Here's the draft url: http://www.arkko.com/publications/mobike/draft-ietf-mobike-protocol-03.txt _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 29 15:50:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL4Q1-0006K1-RN for mobike-archive@megatron.ietf.org; Thu, 29 Sep 2005 15:50:13 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01604 for ; Thu, 29 Sep 2005 15:50:11 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id BC786FB28D; Thu, 29 Sep 2005 15:50:08 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2574CFB291; Thu, 29 Sep 2005 15:50:05 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 67A23FB292; Thu, 29 Sep 2005 15:50:03 -0400 (EDT) Received: from newodin.ietf.org (unknown [132.151.6.50]) by machshav.com (Postfix) with ESMTP id B5143FB28D for ; Thu, 29 Sep 2005 15:50:02 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EL4Pq-00067K-0S; Thu, 29 Sep 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 29 Sep 2005 15:50:02 -0400 Cc: mobike@machshav.com Subject: [Mobike] I-D ACTION:draft-ietf-mobike-protocol-03.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IKEv2 Mobility and Multihoming Working Group of the IETF. Title : IKEv2 Mobility and Multihoming Protocol (MOBIKE) Author(s) : P. Eronen Filename : draft-ietf-mobike-protocol-03.txt Pages : 30 Date : 2005-9-29 This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2). MOBIKE allows hosts to update the (outer) IP addresses associated with IKEv2 and IPsec Security Associations. A mobile VPN client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another. Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the currently used one stops working. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobike-protocol-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-mobike-protocol-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-mobike-protocol-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: <2005-9-29152142.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobike-protocol-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobike-protocol-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-29152142.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --NextPart-- From mobike-bounces@machshav.com Fri Sep 30 04:32:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELGJd-0002v0-6n for mobike-archive@megatron.ietf.org; Fri, 30 Sep 2005 04:32:25 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28838 for ; Fri, 30 Sep 2005 04:32:22 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3260AFB29E; Fri, 30 Sep 2005 04:32:20 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A401FFB298; Fri, 30 Sep 2005 04:32:16 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 99E83FB29B; Fri, 30 Sep 2005 04:32:13 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 01E29FB28D for ; Fri, 30 Sep 2005 04:32:13 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id EB68D89864 for ; Fri, 30 Sep 2005 11:32:06 +0300 (EEST) Message-ID: <433CF812.9030506@piuha.net> Date: Fri, 30 Sep 2005 11:32:18 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List References: <433C2A15.2060908@piuha.net> In-Reply-To: <433C2A15.2060908@piuha.net> Subject: [Mobike] WGLC length X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Content-Transfer-Encoding: 7bit The -03 is now in the I-D directories, as you may have seen from the announcements. In the meanwhile, we have been informed that the copy editing process may take some additional time due to another document already being in the same process at this time. This may set the official WGLC start time to as far as October 10th. As this leaves exactly two weeks until the I-D deadline, our proposal is that we shorten the WGLC by a few days to ensure that Pasi has time to edit the resolutions in to the document. Note that the technical content of the draft is already available, so there should still be ample time for everyone to read, comment, and discuss. If anyone thinks otherwise, let the chairs know. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike