From mobike-bounces@machshav.com Mon Aug 01 08:58:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzZsh-0004ay-PP for mobike-archive@megatron.ietf.org; Mon, 01 Aug 2005 08:58:59 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06685 for ; Mon, 1 Aug 2005 08:58:55 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id AC567FB281; Mon, 1 Aug 2005 08:58:57 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1793EFB277; Mon, 1 Aug 2005 08:58:55 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 01DF9FB27C; Mon, 1 Aug 2005 08:58:53 -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 70FD9FB262 for ; Mon, 1 Aug 2005 08:58:51 -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 j71CwEJ20291 for ; Mon, 1 Aug 2005 14: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 j71CwERj008198 for ; Mon, 1 Aug 2005 14:58:15 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200508011258.j71CwERj008198@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobike@machshav.com Date: Mon, 01 Aug 2005 14:58:14 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Subject: [Mobike] about draft-ietf-mobike-protocol-01.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 Some comments about draft-ietf-mobike-protocol-01.txt: - 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! - 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). - 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. - in 2.2 why the ADDITIONAL_*_ADDRESS are limited to IKE_AUTH? (2.4 is too far, please add a pointer to it) - 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) - 2.2 is enough to make the transport mode with mobike I-D applicable, so we should progress it? - in 2.3 the SPD entries have to be updated too or expired SAs will be renewed with wrong addresses. - in 2.3 it should be clearer that NAT_XXX notifications are mandatory. - 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... - another limitation of 2.3 is it cannot update selectively a subset of SAs: again a case only is handled! - 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. - 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). - 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 (:-). - 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). - 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). - 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. 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 Aug 03 05:01:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0F7j-00085u-SX for mobike-archive@megatron.ietf.org; Wed, 03 Aug 2005 05:01:16 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26317 for ; Wed, 3 Aug 2005 05:01:12 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id CE86CFB28A; Wed, 3 Aug 2005 05:01:12 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 64933FB282; Wed, 3 Aug 2005 05:01:12 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 713B0FB289; Wed, 3 Aug 2005 05:01:10 -0400 (EDT) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id A52E5FB27C for ; Wed, 3 Aug 2005 05:01:09 -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 j738ssKd008513 for ; Wed, 3 Aug 2005 11:54:58 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Aug 2005 12:01:07 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Aug 2005 12:01: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 Date: Wed, 3 Aug 2005 12:01:07 +0300 Message-ID: Thread-Topic: Presentation slides Thread-Index: AcWYCeKa3Kdqol43TzaV5XOlm/yYMQ== From: To: X-OriginalArrivalTime: 03 Aug 2005 09:01:07.0644 (UTC) FILETIME=[E2C24FC0:01C59809] Subject: [Mobike] Presentation slides 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 Current snapshots of slides are now available from: http://www.vpnc.org/ietf-mobike/Paris-05/ietf63_mobike_agenda.ppt http://www.vpnc.org/ietf-mobike/Paris-05/ietf63_mobike_protocol.ppt http://www.vpnc.org/ietf-mobike/Paris-05/ietf63_mobike_issues.ppt http://www.vpnc.org/ietf-mobike/Paris-05/ietf63_mobike_design.ppt Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Aug 03 08:23:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0IHC-0008Ch-48 for mobike-archive@megatron.ietf.org; Wed, 03 Aug 2005 08:23:14 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10526 for ; Wed, 3 Aug 2005 08:23:11 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id EA0A4FB28D; Wed, 3 Aug 2005 08:23:08 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id ECC24FB282; Wed, 3 Aug 2005 08:23:07 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4D403FB289; Wed, 3 Aug 2005 08:23:05 -0400 (EDT) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id 73913FB277; Wed, 3 Aug 2005 08:23:04 -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 j73CN140019047; Wed, 3 Aug 2005 15:23:03 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Aug 2005 15:22:56 +0300 Received: from bsebe101.NOE.Nokia.com ([172.19.160.235]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Aug 2005 07:22:54 -0500 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] Presentation slides Date: Wed, 3 Aug 2005 08:22:53 -0400 Message-ID: Thread-Topic: Presentation slides Thread-Index: AcWYCeKa3Kdqol43TzaV5XOlm/yYMQAG/sUg From: To: , X-OriginalArrivalTime: 03 Aug 2005 12:22:54.0202 (UTC) FILETIME=[12D475A0:01C59826] 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 The audio streaming of the MOBIKE session is not very good. Could somebody please look into it. I am trying to listen in remotely. Thanks, Atul > -----Original Message----- > From: mobike-bounces@machshav.com [mailto:mobike-bounces@machshav.com] > Sent: Wednesday, August 03, 2005 5:01 AM > To: mobike@machshav.com > Subject: [Mobike] Presentation slides >=20 >=20 > Current snapshots of slides are now available from: >=20 > http://www.vpnc.org/ietf-mobike/Paris-05/ietf63_mobike_agenda.ppt > http://www.vpnc.org/ietf-mobike/Paris-05/ietf63_mobike_protocol.ppt > http://www.vpnc.org/ietf-mobike/Paris-05/ietf63_mobike_issues.ppt > http://www.vpnc.org/ietf-mobike/Paris-05/ietf63_mobike_design.ppt >=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 Aug 04 03:27:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0a90-0003td-Ac for mobike-archive@megatron.ietf.org; Thu, 04 Aug 2005 03:27:58 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07438 for ; Thu, 4 Aug 2005 03:27:55 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4E498FB282; Thu, 4 Aug 2005 03:27:55 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1E6BEFB266; Thu, 4 Aug 2005 03:27:54 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EB47FFB27C; Thu, 4 Aug 2005 03:27:51 -0400 (EDT) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id 084D4FB262 for ; Thu, 4 Aug 2005 03:27:51 -0400 (EDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j747RlrI005930 for ; Thu, 4 Aug 2005 10:27:49 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 10:27:43 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 10:27:43 +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: Thu, 4 Aug 2005 10:27:43 +0300 Message-ID: Thread-Topic: 3GPP2 liaison statement Thread-Index: AcWYxgB4Ksp2iTahSKaGvVrejsqqjQ== From: To: X-OriginalArrivalTime: 04 Aug 2005 07:27:43.0451 (UTC) FILETIME=[00D012B0:01C598C6] Subject: [Mobike] 3GPP2 liaison statement 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 This is the liaison statement I mentioned during the WG=20 meeting yesterday: https://datatracker.ietf.org/documents/LIAISON/file160.pdf Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 04 03:39:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0aJg-0008DE-C5 for mobike-archive@megatron.ietf.org; Thu, 04 Aug 2005 03:39:00 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08432 for ; Thu, 4 Aug 2005 03:38:57 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3473BFB27D; Thu, 4 Aug 2005 03:38:58 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CDA91FB262; Thu, 4 Aug 2005 03:38:56 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 399DDFB266; Thu, 4 Aug 2005 03:38:55 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id 43D1EFB262; Thu, 4 Aug 2005 03:38: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 j747cqcC022436; Thu, 4 Aug 2005 10:38:53 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 10:38:52 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 10:38: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] Presentation slides Date: Thu, 4 Aug 2005 10:38:52 +0300 Message-ID: Thread-Topic: Presentation slides Thread-Index: AcWYCeKa3Kdqol43TzaV5XOlm/yYMQAvYLWA From: To: , X-OriginalArrivalTime: 04 Aug 2005 07:38:52.0489 (UTC) FILETIME=[8F972B90:01C598C7] 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 now uploaded the final versions of the protocol and issues presentations (I don't think there were any changes in the=20 agenda or design ones). Best regards, Pasi > -----Original Message----- > From: mobike-bounces@machshav.com [mailto:mobike-bounces@machshav.com] > Sent: Wednesday, August 03, 2005 12:01 PM > To: mobike@machshav.com > Subject: [Mobike] Presentation slides >=20 >=20 > Current snapshots of slides are now available from: >=20 > http://www.vpnc.org/ietf-mobike/Paris-05/ietf63_mobike_agenda.ppt > http://www.vpnc.org/ietf-mobike/Paris-05/ietf63_mobike_protocol.ppt > http://www.vpnc.org/ietf-mobike/Paris-05/ietf63_mobike_issues.ppt > http://www.vpnc.org/ietf-mobike/Paris-05/ietf63_mobike_design.ppt >=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 Aug 04 04:06:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0akh-0001lp-B9 for mobike-archive@megatron.ietf.org; Thu, 04 Aug 2005 04:06:55 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10215 for ; Thu, 4 Aug 2005 04:06:48 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B3E25FB266; Thu, 4 Aug 2005 04:06:49 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A4289FB262; Thu, 4 Aug 2005 04:06:48 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 24DC4FB27C; Thu, 4 Aug 2005 04:06:47 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id D3E15FB24A for ; Thu, 4 Aug 2005 04:06:45 -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 j7486fRP020425 for ; Thu, 4 Aug 2005 11:06:45 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 11:06:44 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 11:06: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] Presentation slides Date: Thu, 4 Aug 2005 11:06:44 +0300 Message-ID: Thread-Topic: Presentation slides Thread-Index: AcWYCeKa3Kdqol43TzaV5XOlm/yYMQAvYLWAAAD83UA= From: To: X-OriginalArrivalTime: 04 Aug 2005 08:06:44.0590 (UTC) FILETIME=[743D88E0:01C598CB] 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 Paul's wrap-up slide is now available, too: http://www.vpnc.org/ietf-mobike/Paris-05/ietf63_mobike_wrapup.ppt Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 04 06:02:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cYO-0006Hu-KU for mobike-archive@megatron.ietf.org; Thu, 04 Aug 2005 06:02:20 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18595 for ; Thu, 4 Aug 2005 06:02:16 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 151F7FB283; Thu, 4 Aug 2005 06:02:17 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D44D1FB262; Thu, 4 Aug 2005 06:02:14 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F3F79FB27D; Thu, 4 Aug 2005 06:02:13 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id A15EEFB24A for ; Thu, 4 Aug 2005 06:02:11 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E1D3889854; Thu, 4 Aug 2005 13:02:09 +0300 (EEST) Message-ID: <42F1E7AE.4050805@piuha.net> Date: Thu, 04 Aug 2005 13:02:22 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu, MOBIKE Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman Subject: [Mobike] MOBIKE summary 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 MOBIKE WG is working towards its goal of enabling movements and simultaneous connectivity in IKEv2-based VPNs. In May, we reached an agreement on all of our major design decisions, and in June the protocol specification came out as a WG draft. We received a number of in-depth reviews prior to IETF-63, and much of the feedback was reflected in a revised specification that come out in July. We spent most of the time in this week's meeting to discuss the technical issues that had not yet been addressed. It seemed that we have consensus on the way forward for most of the simple issues. One big issue still remains to be solved, relating to one detail around MOBIKE's interaction with NAT traversal. (We were told that this issue can affect as many as 20 lines of code, so the debate will no doubt continue on the list.) We expect the MOBIKE protocol specification to go to WGLC in September, and be sent to the IESG prior to IETF-64. The next weeks will be spent on the list to confirm the consensus from the meeting, to close the remaining issues, address some new reviews that we received and for additional review. Reviewers for this protocol are also sought from the rest of the SEC area. If you want to have an impact on the protocol, this would be a good time to read the spec. Separately, our protocol design considerations document is tracking the discussion, and will come out a little behind the protocol itself. We expect that it is done before the next IETF as well. We also have gotten our first inter-WG dependency for MOBIKE within the IETF, and received a liason statement from the 3GPP2 stating an interest in our solution. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 04 08:42:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0f3P-00086b-Oo for mobike-archive@megatron.ietf.org; Thu, 04 Aug 2005 08:42:32 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02222 for ; Thu, 4 Aug 2005 08:42:29 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id EF889FB27F; Thu, 4 Aug 2005 08:42:28 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AB0B5FB27C; Thu, 4 Aug 2005 08:42:27 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B8443FB27D; Thu, 4 Aug 2005 08:42:26 -0400 (EDT) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id E3B7BFB277 for ; Thu, 4 Aug 2005 08:42:25 -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 j74CcPgq000883 for ; Thu, 4 Aug 2005 15:38:26 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 15:42:21 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 15:42:20 +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: Thu, 4 Aug 2005 15:42:20 +0300 Message-ID: Thread-Topic: Issue 37: Move MOBIKE_SUPPORTED to IKE_AUTH Thread-Index: AcWY8fRC20nNl5+qSPeZ7+vZi4lL8A== From: To: X-OriginalArrivalTime: 04 Aug 2005 12:42:20.0864 (UTC) FILETIME=[F4A0B400:01C598F1] Subject: [Mobike] Issue 37: Move MOBIKE_SUPPORTED to IKE_AUTH 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 (This issue was brought up during the meeting.) It might be a good idea to move the MOBIKE_SUPPORTED payload from its current place (IKE_SA_INIT) to IKE_AUTH. This would allow per-user policy on whether use of MOBIKE is allowed or not, and it would help in fragmentation concerns (fragmenting IKE_SA_INIT is bad, fragmenting other messages less so). There doesn't seem to be any good reasons not do this (we don't seem to have any functionality that would need to know about MOBIKE already in IKE_SA_INIT phase). Several people supported this change in the meeting (and nobody opposed it), so unless anyone on the mailing list objects, I'll move the payload to IKE_AUTH in version -02 (in case of multiple IKE_AUTH exchanges, the messages containing the SA payloads, like most other things). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Aug 10 11:23:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2sQF-0000I0-T9 for mobike-archive@megatron.ietf.org; Wed, 10 Aug 2005 11:23:15 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05846 for ; Wed, 10 Aug 2005 11:23:12 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 82D44FB28A; Wed, 10 Aug 2005 11:23:11 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5D173FB284; Wed, 10 Aug 2005 11:23:08 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8B98EFB286; Wed, 10 Aug 2005 11:23:06 -0400 (EDT) Received: from above.proper.com (above.proper.com [208.184.76.39]) by machshav.com (Postfix) with ESMTP id 209F7FB27D for ; Wed, 10 Aug 2005 11:23:05 -0400 (EDT) Received: from [10.242.21.248] ([38.136.12.131]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7AFN2hx043518 for ; Wed, 10 Aug 2005 08:23:04 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 10 Aug 2005 08:45:50 -0400 To: mobike@machshav.com From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [Mobike] First draft of minutes from last week 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 Greetings again. Sorry for getting these to the list late; I have been travelling since Paris. --Paul Hoffman MOBIKE WG meeting Wednesday August 3, 2005, Paris Notes taken by Lakshminath Dondeti and Maureen Stillman, combined by Paul Hoffman Introductory talk Jari A: In May we resolved design issues. Pasi wrote a protocol draft according to decisions made; it was reviewed and revised version has been submitted. Related documents are here FYI: * devarapalli-mip4-mobike-connectivity -- MIPv4 approved WG (not MOBIKE) item. Discussed in 3GPP, especially in relation to 3GPP-WLAN interconnection May need liaison planning. Good to review in MOBIKE also. Paul H: we should coordinate with MIPv4 list. Pasi E: There is a discussion underway in that group. * dupont-mobike-transport Paul H: Please review, and we'll discuss within a reasonable time Paul H: It's fine to talk about non-WG documents as long as they don't block WG doc progress. There are several other drafts like the above two. Please see the agenda slides. Pasi E on MOBIKE-Protocol-01: (see the slides) MOBIKE easy issues (Pasi Eronen): 21, 25, 29 are Editorial 26 Window size and latest update counter Word "path" now used only in senses that include the route 23 : Separate payload types 30 : Protocol ID in notifications (to be in sync with the ikev2-clarifications document) 24 NAT prevention needs clarification and a better name Jari A.: Let's make some progress here by coming with some decisions and we can get those confirmed on the list. Francis D: dependency on 22 35, Version number (Skip the complexity now!) 37: Move MOBIKE supported notification from IKEv2_SA_INIT to AUTH exchange Allows per user policy about whether MOBIKE is allowed Hannes: less fragmentation risk if added to AUTH Jari A: Clarification req: Tero: Can't fragment the first packet, because can't do stateless IKEv2 exchange. Let's keep IKEv2_SA_INIT packet very small and allow the stateless feature to be continued to be supported. NAT-T may make the notification even larger. Seems like there is consensus on this. 36: Unacceptable addresses. Receiver might not know which address set was acceptable Jari A: I had different thoughts on the list, but it is clarified now and I am ok with this. Pasi: This is a corner case anyway 27: Security and path testing Sec considerations section needs text on path testing Dependent on issue 34 Consensus calls: 35, 37 (Lakshminath: add comments from Tero as text) and 36 mostly yes and no hands on oppose. All will be repeated on the list. 22: close the issue, misunderstanding (Hannes) MOBIKE issue 34 (Pasi Eronen): (see the slides!) Discussion in the room: Current protocol just does what IKEv2 NAT traversal does This is another place where we upgrade a MAY to a MUST in IKE v2 Terminals that are totally idle sending keep alives consumes energy Should we ask the BEHAVE WG anything? (Paul H says no, emphatically) Only 2 people in the room have done an implementation with this Suggestion: never time out; wait until you are under attack When added to IKEv2, it was a corner case if you care about it you implement the SHOULD if you don't care then you don't implement the SHOULD Path test is valuable independent of this issue. It is clear we need this path testing feature regardless of this issue. Relationship to Path test with approach 1 there are more of these time periods -> more need of separate exchange if you want to do NAT detection in path testing -> need separate exchange with approach 3 fewer of these time periods summary: approach 1 and 3 both work both have pros and cons Tero agreed to write the summary to the list and send them Want to see more discussion on the list; security considerations for the path test exchange Sense of how we support this corner case; do we want to drop it? We know it will happen if the NAT rebooted or change mapping for some reason Ask on the list about implentations IKEv1 or IKEv2 Next steps (Jari A) get rough consensus on technical issues fix security considerations clarify role of multihoming 3GPP2 has sent a liaison statement; we need to respond to it Design document (Hannes) mobike design 03 document update for this IETF changed lots of text and organization Difficult to follow the whole story; moved text to make it easier to understand missing pieces selecting address (issue #20) more details in the security consideration section add design rationale for some issues that arise readability - better structure for the doc -- new outline Paul H: this tracks the IKEv2 clarifications document and can get to the IESG after the protocol document (not by long) People seem to like that Way forward (Jari A and Paul H) Close all open issues on the protocol document We want to finish for real by September 15 Then have WG last call At the same time as WG last call for the protocol finish the design document Read the docs now; don't wait. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 11 14:29:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3HoB-0004O1-VX for mobike-archive@megatron.ietf.org; Thu, 11 Aug 2005 14:29:40 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18358 for ; Thu, 11 Aug 2005 14:29:36 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 8AD54FB2B1; Thu, 11 Aug 2005 14:29:29 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2A9CBFB2AC; Thu, 11 Aug 2005 14:29:21 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 54485FB2AF; Thu, 11 Aug 2005 14:29:18 -0400 (EDT) Received: from above.proper.com (above.proper.com [208.184.76.39]) by machshav.com (Postfix) with ESMTP id ADB69FB2AB for ; Thu, 11 Aug 2005 14:29:17 -0400 (EDT) Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7BITGg5000699 for ; Thu, 11 Aug 2005 11:29:17 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 11 Aug 2005 11:29:35 -0700 To: mobike@machshav.com From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Mobike] Slides from the meeting 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 A temporary pointer of the proceedings with the slides from the WG meeting last week can be found at --Paul Hoffman, Director --VPN Consortium _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Aug 15 14:12:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4jRv-0007GJ-Sx for mobike-archive@megatron.ietf.org; Mon, 15 Aug 2005 14:12:40 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17441 for ; Mon, 15 Aug 2005 14:12:38 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 80C7AFB27D; Mon, 15 Aug 2005 14:12:37 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3DD9AFB246; Mon, 15 Aug 2005 14:12:34 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 150DEFB262; Mon, 15 Aug 2005 14:12:32 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id DAA56FB23E for ; Mon, 15 Aug 2005 14:12:30 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E81F289852 for ; Mon, 15 Aug 2005 21:12:28 +0300 (EEST) Message-ID: <4300DB19.30403@piuha.net> Date: Mon, 15 Aug 2005 21:12:41 +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 Subject: [Mobike] confirming consensus on issues from Paris 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 the Paris IETF we had a set of smaller issues and one bigger issue. It seemed like we agreed on the smaller issues in the meeting, but promised to confirm this on the mailing list. This e-mail summarizes the proposals and calls for people to voice additions or objections, if any. If you agree with what we concluded in the meeting, you don't need to respond. The issues were: 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 From mobike-bounces@machshav.com Tue Aug 16 07:14:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4zOv-0002Wn-OF for mobike-archive@megatron.ietf.org; Tue, 16 Aug 2005 07:14:38 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03334 for ; Tue, 16 Aug 2005 07:14:36 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9B50CFB27F; Tue, 16 Aug 2005 07:14:33 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4001DFB246; Tue, 16 Aug 2005 07:14:28 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2AD71FB266; Tue, 16 Aug 2005 07:14:26 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 945CFFB23E for ; Tue, 16 Aug 2005 07:14:24 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id CD3BE89854 for ; Tue, 16 Aug 2005 14:14:16 +0300 (EEST) Message-ID: <4301CA95.2060208@piuha.net> Date: Tue, 16 Aug 2005 14:14:29 +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 Subject: [Mobike] issue 27 -- security for path testing 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 issue relates to the lack of security considerations text on path testing. In Paris we decided, obviously enough, that more text would be needed and that the actual text would depend on the resolution to issue 34, how path testing is actually done. In an effort to speed the process up a bit, I wrote the below text suggestions that correspond to the different outcomes of issue 34. The first text suggestion (A) is what we would use if we continue to use the path testing scheme in -01. That is, the path test messages are unprotected. The next text suggestion (B) is what we would use if we adopt Tero's path testing scheme where the test messages are regular IKEv2 Informational exchanges. Finally, there are some common text changes (C) that are needed in any case. Please comment. --Jari Change A ====== Add a new paragraph at the end of Section 4: MOBIKE also employs its own path test messages and can only provide limited protection for them. Specifically, these messages are sent outside the protection of the IKE SA and can therefore be spoofed, modified, or read. However, MOBIKE initiators do not use these messages beyond confirming that a sent message gets a response and finding out the characteristics of the path (addresses and NATs). MOBIKE responders do not use these messages at all, beyond blindly responding to them. A cookie mechanism ensures that attackers cannot send a response blindly without seeing a request first. Nevertheless, on-path attackers can intercept legitimate requests and responses, and either prevent them from reaching the destination, carrying them to the destination even across networks that would not let other packets through, or modify NAT behaviour enroute. As a result, these attacks may lead to denial-of-service. Note that denial-of-service is typically possible for on-path attackers even without the MOBIKE messages, e.g., by blocking IKE messages. Change B ====== Add a new paragraph at the end of Section 4: MOBIKE also employs its own path test messages and can only provide limited protection for them. Specifically, while these messages are protected by the IKE SA, the relevant information in these messages is mainly in the unprotected parts such as the IP header, and can therefore be spoofed, modified, or read. MOBIKE initiators do not use these messages beyond confirming that a sent message gets a response and finding out the characteristics of the path (addresses and NATs). MOBIKE responders do not use these messages at all, beyond blindly responding to them. A cookie mechanism ensures that attackers cannot send a response blindly without seeing a request first. Nevertheless, on-path attackers can intercept legitimate requests and responses, and either prevent them from reaching the destination, carrying them to the destination even across networks that would not let other packets through, or modify NAT behaviour enroute. As a result, these attacks may lead to denial-of-service. Note that denial-of-service is typically possible for on-path attackers even without the MOBIKE messages, e.g., by blocking IKE messages. Common Changes C ============= In Section 4 we have the following text: Spoofing indications related to network connectivity Attackers may also spoof various indications from lower layers and the network in an effort to confuse the peers about which addresses are or are not working. For example, attackers may spoof ICMP error messages in an effort to cause the parties to move their traffic elsewhere or even to disconnect. Attackers may also spoof information related to network attachments, router discovery, and address assignments in an effort to make the parties believe they have Internet connectivity when in reality they do not. This may cause use of non-preferred addresses or even denial- of-service. Add the following to the end of the second paragraph: Finally, attackers may spoof information related to the path test messages employed by MOBIKE itself. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Aug 16 09:04:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E517J-00022a-Tw for mobike-archive@megatron.ietf.org; Tue, 16 Aug 2005 09:04:38 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08978 for ; Tue, 16 Aug 2005 09:04:30 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id EE451FB27C; Tue, 16 Aug 2005 09:04:29 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 742DDFB246; Tue, 16 Aug 2005 09:04:27 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D69ECFB266; Tue, 16 Aug 2005 09:04:25 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 978DBFB246 for ; Tue, 16 Aug 2005 09:04:24 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 167D489852; Tue, 16 Aug 2005 16:04:23 +0300 (EEST) Message-ID: <4301E463.30405@piuha.net> Date: Tue, 16 Aug 2005 16:04:35 +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 , Tero Kivinen , Pasi Eronen Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] issue 34 -- ESP vs. IKE based NAT reboot detection 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'd like to open discussion on this issue. Please read the slides and notes from http://www3.ietf.org/proceedings/05aug/slides/mobike-2.pdf http://www.machshav.com/pipermail/mobike/2005-August/000912.html and post your thoughts on this issue. As far as I can determine, we are primarily discussing two alternatives: Alt 1: The approach in -01 which retains what IKEv2 does when NAT mappings change. I.e., there's a SHOULD in the IKEv2 spec that allows implementations to update mappings based on what they see happening for the UDP-encapsulated ESP packets. Alt 3: Tero's approach, which says not to use this feature in IKEv2 when MOBIKE is employed, and instead relies on periodic IKE probes. Based on the discussion in IETF-63, it seems that both approaches work, but the tradeoffs are mainly in the area of ease of implementation vs. pressure to decrease probing/keepalive intervals. We do know that there are some (even if few) implementations of IKEv1/v2 that employ the ESP-based check. Similarly, some other implementations aren't doing it. Note also that we need to keep in mind what the requirement level for this feature is or will be. If its not a MUST, this means that whatever bad effect there may be (implementation diffuculties or additional messaging), you do NOT have to suffer from that unless you also need to support this feature. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Aug 16 11:46:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E53eN-0006Oo-1G for mobike-archive@megatron.ietf.org; Tue, 16 Aug 2005 11:46:51 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19123 for ; Tue, 16 Aug 2005 11:46:47 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E5264FB27C; Tue, 16 Aug 2005 11:46:48 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 37D35FB246; Tue, 16 Aug 2005 11:46:47 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E35FCFB266; Tue, 16 Aug 2005 11:46:45 -0400 (EDT) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id B74FAFB23E for ; Tue, 16 Aug 2005 11:46:44 -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 j7GFkc0F006995; Tue, 16 Aug 2005 18:46:39 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Aug 2005 18:46:38 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Aug 2005 18:46: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 Date: Tue, 16 Aug 2005 18:46:39 +0300 Message-ID: Thread-Topic: issue 34 -- ESP vs. IKE based NAT reboot detection Thread-Index: AcWiYzYdHHJf+qY+Q2uSF8JDzlqn+AAFJg6Q From: To: , , X-OriginalArrivalTime: 16 Aug 2005 15:46:38.0007 (UTC) FILETIME=[B027D470:01C5A279] Subject: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection 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 Hmm... I think both alternatives 1 and 3 have good arguments for them. >From implementation point of view, alternative 1 (IKEv2 NAT-T) places implementation complexity in the peer outside NAT (typically VPN gateway), while in alternative 3 the peer behind NAT (e.g., VPN client) does most of the work. The latter would perhaps be more=20 consistent with the "initiator decides" approach (and seems "nicer"=20 in other ways, too). My only concern with it is that it could result=20 in non-insignificant increase of IKEv2 exchanges for the responder...=20 (if people who care about NAT mapping changes start lowering the=20 threshold "X" for doing DPD). On the other hand, a gateway that is worried about this increase does have ways of preventing the peer from doing unnecessary DPD. For instance, if it's currently receiving packets from the peer, but not sending anything (because it hasn't received anything from the network "behind the gateway"), it could send "dummy" (TFC padding only) ESP packets every now and then. If these reach the peer (behind NAT), it will know the gateway is still alive and NAT mapping OK, so it=20 would not do DPD unnecessarily. Specification-wise, alternative 3 would be quite simple. It looks like the main addition would be that implementations that support NAT-T can include NAT_DETECTION_* payloads in any Informational request (and if they're included in the request, the responder must also include them in the response, but no other action is necessarily taken). This allows the initiator to detect when a NAT mapping has changed, and send UPDATE_SA_ADDRESSES. (On the other hand, alternative 1 -- pointing to IKEv2 NAT-T spec -- is quite simple as well...) Best regards, Pasi > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Tuesday, August 16, 2005 4:05 PM > To: MOBIKE Mailing List; Tero Kivinen; Eronen Pasi=20 > (Nokia-NRC/Helsinki) > Subject: issue 34 -- ESP vs. IKE based NAT reboot detection >=20 >=20 > I'd like to open discussion on this issue. Please read > the slides and notes from >=20 > http://www3.ietf.org/proceedings/05aug/slides/mobike-2.pdf > http://www.machshav.com/pipermail/mobike/2005-August/000912.html >=20 > and post your thoughts on this issue. As far as I can > determine, we are primarily discussing two alternatives: >=20 > Alt 1: The approach in -01 which retains what IKEv2 does > when NAT mappings change. I.e., there's a SHOULD in the > IKEv2 spec that allows implementations to update mappings > based on what they see happening for the UDP-encapsulated > ESP packets. >=20 > Alt 3: Tero's approach, which says not to use this feature > in IKEv2 when MOBIKE is employed, and instead relies on > periodic IKE probes. >=20 > Based on the discussion in IETF-63, it seems that both > approaches work, but the tradeoffs are mainly in the > area of ease of implementation vs. pressure to decrease > probing/keepalive intervals. >=20 > We do know that there are some (even if few) implementations > of IKEv1/v2 that employ the ESP-based check. Similarly, some other > implementations aren't doing it. >=20 > Note also that we need to keep in mind what the requirement > level for this feature is or will be. If its not a MUST, this means > that whatever bad effect there may be (implementation diffuculties > or additional messaging), you do NOT have to suffer from that > unless you also need to support this feature. >=20 > --Jari >=20 >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Aug 16 23:28:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Eb5-0000qZ-8t for mobike-archive@megatron.ietf.org; Tue, 16 Aug 2005 23:28:11 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03765 for ; Tue, 16 Aug 2005 23:28:07 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B622EFB280; Tue, 16 Aug 2005 23:28:08 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 94A9FFB266; Tue, 16 Aug 2005 23:28:01 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 59A3AFB27C; Tue, 16 Aug 2005 23:28:00 -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 B6537FB246 for ; Tue, 16 Aug 2005 23:27:58 -0400 (EDT) Received: (qmail 48557 invoked from network); 17 Aug 2005 03:15:59 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.163.212.39 with login) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 17 Aug 2005 03:15:58 -0000 Message-ID: <00d501c5a2d9$fd280af0$6f01a8c0@adithya> From: "Mohan Parthasarathy" To: , , , References: Subject: Re: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection Date: Tue, 16 Aug 2005 20:15:57 -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 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, Sorry if this was discussed at the meeting. I did not understand a couple of things in this mail 1) You mention implementation complexity. I saw some reference to it in the slides if i am not mistaken. Also, Jari mentioned something in his mail. Is this general "complexity" of MOBIKE ? or something specific to this feature i.e NAT traversal ? Having implemented NAT traversal, i don't know how it can be considered complex considering the complexity of IKEv2 itself :-) So, i am missing something.. 2) Could you clarify how alt.2 increases the IKEv2 messages for the responder ? I understand that there is an explicit message to update the address. But you seem to be talking about a different thing. So, could you clarify ? thanks mohan ----- Original Message ----- From: To: ; ; Sent: Tuesday, August 16, 2005 8:46 AM Subject: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection Hmm... I think both alternatives 1 and 3 have good arguments for them. >From implementation point of view, alternative 1 (IKEv2 NAT-T) places implementation complexity in the peer outside NAT (typically VPN gateway), while in alternative 3 the peer behind NAT (e.g., VPN client) does most of the work. The latter would perhaps be more consistent with the "initiator decides" approach (and seems "nicer" in other ways, too). My only concern with it is that it could result in non-insignificant increase of IKEv2 exchanges for the responder... (if people who care about NAT mapping changes start lowering the threshold "X" for doing DPD). On the other hand, a gateway that is worried about this increase does have ways of preventing the peer from doing unnecessary DPD. For instance, if it's currently receiving packets from the peer, but not sending anything (because it hasn't received anything from the network "behind the gateway"), it could send "dummy" (TFC padding only) ESP packets every now and then. If these reach the peer (behind NAT), it will know the gateway is still alive and NAT mapping OK, so it would not do DPD unnecessarily. Specification-wise, alternative 3 would be quite simple. It looks like the main addition would be that implementations that support NAT-T can include NAT_DETECTION_* payloads in any Informational request (and if they're included in the request, the responder must also include them in the response, but no other action is necessarily taken). This allows the initiator to detect when a NAT mapping has changed, and send UPDATE_SA_ADDRESSES. (On the other hand, alternative 1 -- pointing to IKEv2 NAT-T spec -- is quite simple as well...) Best regards, Pasi > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Tuesday, August 16, 2005 4:05 PM > To: MOBIKE Mailing List; Tero Kivinen; Eronen Pasi > (Nokia-NRC/Helsinki) > Subject: issue 34 -- ESP vs. IKE based NAT reboot detection > > > I'd like to open discussion on this issue. Please read > the slides and notes from > > http://www3.ietf.org/proceedings/05aug/slides/mobike-2.pdf > http://www.machshav.com/pipermail/mobike/2005-August/000912.html > > and post your thoughts on this issue. As far as I can > determine, we are primarily discussing two alternatives: > > Alt 1: The approach in -01 which retains what IKEv2 does > when NAT mappings change. I.e., there's a SHOULD in the > IKEv2 spec that allows implementations to update mappings > based on what they see happening for the UDP-encapsulated > ESP packets. > > Alt 3: Tero's approach, which says not to use this feature > in IKEv2 when MOBIKE is employed, and instead relies on > periodic IKE probes. > > Based on the discussion in IETF-63, it seems that both > approaches work, but the tradeoffs are mainly in the > area of ease of implementation vs. pressure to decrease > probing/keepalive intervals. > > We do know that there are some (even if few) implementations > of IKEv1/v2 that employ the ESP-based check. Similarly, some other > implementations aren't doing it. > > Note also that we need to keep in mind what the requirement > level for this feature is or will be. If its not a MUST, this means > that whatever bad effect there may be (implementation diffuculties > or additional messaging), you do NOT have to suffer from that > unless you also need to support this feature. > > --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 Aug 17 01:03:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5G4o-00015D-Ib for mobike-archive@megatron.ietf.org; Wed, 17 Aug 2005 01:03:01 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08063 for ; Wed, 17 Aug 2005 01:02:56 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C7BA0FB280; Wed, 17 Aug 2005 01:02:55 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E9CACFB27D; Wed, 17 Aug 2005 01:02:53 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EC562FB27F; Wed, 17 Aug 2005 01:02:51 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 4B697FB246 for ; Wed, 17 Aug 2005 01:02:51 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7166689852; Wed, 17 Aug 2005 08:02:49 +0300 (EEST) Message-ID: <4302C505.4020703@piuha.net> Date: Wed, 17 Aug 2005 08:03:01 +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] RE: issue 34 -- ESP vs. IKE based NAT reboot detection References: <00d501c5a2d9$fd280af0$6f01a8c0@adithya> In-Reply-To: <00d501c5a2d9$fd280af0$6f01a8c0@adithya> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Pasi.Eronen@nokia.com, kivinen@iki.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 Mohan Parthasarathy wrote: >Pasi, > >Sorry if this was discussed at the meeting. I did not understand a couple of things in this mail > >1) You mention implementation complexity. I saw some reference to it in the slides if i am not > mistaken. Also, Jari mentioned something in his mail. Is this general "complexity" of MOBIKE ? > or something specific to this feature i.e NAT traversal ? Having implemented NAT traversal, > i don't know how it can be considered complex considering the complexity of IKEv2 itself :-) > So, i am missing something.. > > I guess the main complexity that people were worried about is that the *ipsec* part needs to detect a changed address and tell this to the IKE part. This may involve a PFKEY extension, among other things, and may be hard on a hardware that does IPsec but does not have this address detection function. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Aug 17 19:23:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5XFu-0007Y7-P0 for mobike-archive@megatron.ietf.org; Wed, 17 Aug 2005 19:23:35 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11653 for ; Wed, 17 Aug 2005 19:23:30 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C4C18FB282; Wed, 17 Aug 2005 19:23:31 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 75B5BFB27F; Wed, 17 Aug 2005 19:23:30 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 6AC0BFB280; Wed, 17 Aug 2005 19:23:29 -0400 (EDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by machshav.com (Postfix) with ESMTP id C91ACFB27D for ; Wed, 17 Aug 2005 19:23:28 -0400 (EDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j7HNNMHT017672; Wed, 17 Aug 2005 16:23:23 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7HNNMUj018894; Wed, 17 Aug 2005 19:23:22 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7HNNLPj020621; Wed, 17 Aug 2005 19:23:21 -0400 (EDT) Subject: Re: [Mobike] issue 34 -- ESP vs. IKE based NAT reboot detection From: Bill Sommerfeld To: Jari Arkko In-Reply-To: <4301E463.30405@piuha.net> References: <4301E463.30405@piuha.net> Content-Type: text/plain Message-Id: <1124321001.17138.226.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Wed, 17 Aug 2005 19:23:21 -0400 Content-Transfer-Encoding: 7bit Cc: Pasi Eronen , MOBIKE Mailing List , 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 On Tue, 2005-08-16 at 09:04, Jari Arkko wrote: > Alt 1: The approach in -01 which retains what IKEv2 does > when NAT mappings change. I.e., there's a SHOULD in the > IKEv2 spec that allows implementations to update mappings > based on what they see happening for the UDP-encapsulated > ESP packets. > > Alt 3: Tero's approach, which says not to use this feature > in IKEv2 when MOBIKE is employed, and instead relies on > periodic IKE probes. Assume you're implementing both IKEv2 NAT traversal as well as mobike, with mobike use being optional. Either alternative presumably needs a notification from ESP to key management that NAT-level "motion" has been detected, but alternative 3 also seems to require a "mode bit" in ESP indicating when you should let ESP handle the address updates and when it should ignore them. I'd rather avoid that complexity. - Bill _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 18 02:51:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5eFf-0003GU-A6 for mobike-archive@megatron.ietf.org; Thu, 18 Aug 2005 02:51:47 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14958 for ; Thu, 18 Aug 2005 02:51:45 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3BB7EFB282; Thu, 18 Aug 2005 02:51:44 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 46872FB27F; Thu, 18 Aug 2005 02:51:43 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 94D4CFB280; Thu, 18 Aug 2005 02:51:41 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id DF361FB27D for ; Thu, 18 Aug 2005 02:51:40 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2597689852; Thu, 18 Aug 2005 09:51:39 +0300 (EEST) Message-ID: <43043007.4050104@piuha.net> Date: Thu, 18 Aug 2005 09:51:51 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Subject: Re: [Mobike] issue 34 -- ESP vs. IKE based NAT reboot detection References: <4301E463.30405@piuha.net> <1124321001.17138.226.camel@thunk> In-Reply-To: <1124321001.17138.226.camel@thunk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pasi Eronen , MOBIKE Mailing List , 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 Bill Sommerfeld wrote: >Assume you're implementing both IKEv2 NAT traversal as well as mobike, >with mobike use being optional. > > A likely case. >Either alternative presumably needs a notification from ESP to key >management that NAT-level "motion" has been detected, but alternative 3 >also seems to require a "mode bit" in ESP indicating when you should let >ESP handle the address updates and when it should ignore them. > > Yes. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 18 21:35:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5vmh-0008LN-Sc for mobike-archive@megatron.ietf.org; Thu, 18 Aug 2005 21:35:06 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21512 for ; Thu, 18 Aug 2005 21:35:01 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3D3BBFB280; Thu, 18 Aug 2005 21:35:01 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5FD33FB280; Thu, 18 Aug 2005 21:34:58 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 56E7AFB282; Thu, 18 Aug 2005 21:34:56 -0400 (EDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by machshav.com (Postfix) with SMTP id 69969FB27F for ; Thu, 18 Aug 2005 21:34:55 -0400 (EDT) Received: (qmail 49815 invoked from network); 19 Aug 2005 01:34:54 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.59.125 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 19 Aug 2005 01:34:54 -0000 Message-ID: <005201c5a45e$331ee130$6701a8c0@adithya> From: "Mohan Parthasarathy" To: "Jari Arkko" References: <00d501c5a2d9$fd280af0$6f01a8c0@adithya> <4302C505.4020703@piuha.net> Subject: Re: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection Date: Thu, 18 Aug 2005 18:34: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: mobike@machshav.com, Pasi.Eronen@nokia.com, kivinen@iki.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 > >Sorry if this was discussed at the meeting. I did not understand a couple of things in this mail > > > >1) You mention implementation complexity. I saw some reference to it in the slides if i am not > > mistaken. Also, Jari mentioned something in his mail. Is this general "complexity" of MOBIKE ? > > or something specific to this feature i.e NAT traversal ? Having implemented NAT traversal, > > i don't know how it can be considered complex considering the complexity of IKEv2 itself :-) > > So, i am missing something.. > > > > > I guess the main complexity that people were worried about > is that the *ipsec* part needs to detect a changed address > and tell this to the IKE part. This may involve a PFKEY extension, > among other things, > Linux (2.6) uses netlink sockets for this purpose. The hook is there and the event does not get generated from IPsec to IKE. But it is trivial to implement. So, if some one wants to cook up a PF_KEY extension, they can do so and it should not be a problem. If someone feels that this functionality is needed, i don't think this is hard to implement. Perhaps, the real reason is nobody needs it and hence it does not seem to be there. So, i don't agree that this is complex. > and may be hard on a hardware that > does IPsec but does not have this address detection function. > Ok. Again, i am not sure whether the reason it does not exist in hardware today is because there is a lack of need for it or it is difficult to do it in hardware ? As VPN gateway most likely will use hardware acceleration and as this feature does not seem to be present in the hardware, would it not make sense to use alt.3 ? Note that we can't help with the current IKEv2 NAT traversal. At least there is some *reason* (complexity, no hardware support, security etc.) why it does not exist today. Perhaps, we can make this work with MOBIKE if we don't rely on the IKEv2 NAT traversal mechanism. -mohan > --Jari > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 18 21:38:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5vqM-0000d7-Sx for mobike-archive@megatron.ietf.org; Thu, 18 Aug 2005 21:38:51 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21693 for ; Thu, 18 Aug 2005 21:38:47 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B7046FB28B; Thu, 18 Aug 2005 21:38:48 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E0539FB285; Thu, 18 Aug 2005 21:38:42 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9F019FB286; Thu, 18 Aug 2005 21:38:41 -0400 (EDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by machshav.com (Postfix) with SMTP id 8C6F5FB284 for ; Thu, 18 Aug 2005 21:38:40 -0400 (EDT) Received: (qmail 54825 invoked from network); 19 Aug 2005 01:38:40 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.59.125 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 19 Aug 2005 01:38:39 -0000 Message-ID: <005801c5a45e$b978ccf0$6701a8c0@adithya> From: "Mohan Parthasarathy" To: "Bill Sommerfeld" , "Jari Arkko" References: <4301E463.30405@piuha.net> <1124321001.17138.226.camel@thunk> Subject: Re: [Mobike] issue 34 -- ESP vs. IKE based NAT reboot detection Date: Thu, 18 Aug 2005 18:38:38 -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 Mailing List , Pasi Eronen , 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 > On Tue, 2005-08-16 at 09:04, Jari Arkko wrote: > > Alt 1: The approach in -01 which retains what IKEv2 does > > when NAT mappings change. I.e., there's a SHOULD in the > > IKEv2 spec that allows implementations to update mappings > > based on what they see happening for the UDP-encapsulated > > ESP packets. > > > > Alt 3: Tero's approach, which says not to use this feature > > in IKEv2 when MOBIKE is employed, and instead relies on > > periodic IKE probes. > > Assume you're implementing both IKEv2 NAT traversal as well as mobike, > with mobike use being optional. > > Either alternative presumably needs a notification from ESP to key > management that NAT-level "motion" has been detected, but alternative 3. > Why does alternative 3 require this notification ? > also seems to require a "mode bit" in ESP indicating when you should let > ESP handle the address updates and when it should ignore them. > > I'd rather avoid that complexity. > Is this not a per-SA bit ? If MOBIKE is used and the bit indicates such, then don't update the SA and don't send the trigger to IKE if you use alt.3. If NAT traversal is used and MOBIKE is not used, then update and send trigger. Why is it complex ? I am missing something. thanks mohan > - Bill > > > _______________________________________________ > 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 Aug 23 06:39:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7WBR-0002QL-AK for mobike-archive@megatron.ietf.org; Tue, 23 Aug 2005 06:39:09 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25459 for ; Tue, 23 Aug 2005 06:39:06 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 02CD3FB27F; Tue, 23 Aug 2005 06:39:07 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9C69EFB266; Tue, 23 Aug 2005 06:39:04 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C36C4FB277; Tue, 23 Aug 2005 06:39:01 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 8452CFB249 for ; Tue, 23 Aug 2005 06:39:00 -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 j7NAcZrO006882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Aug 2005 13:38:35 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j7NAcYBx007614; Tue, 23 Aug 2005 13:38:34 +0300 (EEST) Resent-From: kivinen@iki.fi X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f Resent-Message-ID: <17162.64681.443868.724533@fireball.kivinen.iki.fi> Resent-Date: Tue, 23 Aug 2005 13:38:33 +0300 Resent-To: MOBIKE Mailing List Message-ID: <17157.44459.248416.210930@fireball.kivinen.iki.fi> In-Reply-To: <4300DB19.30403@piuha.net> References: <4300DB19.30403@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 From: Tero Kivinen To: Jari Arkko Subject: [Mobike] confirming consensus on issues from Paris Date: Fri, 19 Aug 2005 13:00:11 +0300 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Edit-Time: 0 min X-Total-Time: 0 min 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 Jari Arkko writes: > 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. Those names are not very good, but as I cannot think any better... > 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. The issue 37 will solve this problem, so we can close that if issue 37 decides to move notifications to IKE_AUTH message. > 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. Now when I have had some more time to think about this, I think Pasi's solution is the best. My original proposal (include the addresses in the notify) might have some issues with NATs, so I think the Pasi's solution is better. > 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. Moving the notification solves the issue 35, so I think we should move the notifications. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Aug 23 06:39:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7WBc-0002Ws-TL for mobike-archive@megatron.ietf.org; Tue, 23 Aug 2005 06:39:21 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25462 for ; Tue, 23 Aug 2005 06:39:18 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3FCAAFB290; Tue, 23 Aug 2005 06:39:19 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 02C21FB28A; Tue, 23 Aug 2005 06:39:15 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CA94AFB289; Tue, 23 Aug 2005 06:39:10 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id E916EFB249 for ; Tue, 23 Aug 2005 06:39:06 -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 j7NAcj8B007812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Aug 2005 13:38:45 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j7NAcjJR000734; Tue, 23 Aug 2005 13:38:45 +0300 (EEST) Resent-From: kivinen@iki.fi X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f Resent-Message-ID: <17162.64692.135124.544984@fireball.kivinen.iki.fi> Resent-Date: Tue, 23 Aug 2005 13:38:44 +0300 Resent-To: MOBIKE Mailing List Message-ID: <17157.45611.204562.768292@fireball.kivinen.iki.fi> In-Reply-To: <4301CA95.2060208@piuha.net> References: <4301CA95.2060208@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 From: Tero Kivinen To: Jari Arkko Subject: [Mobike] issue 27 -- security for path testing Date: Fri, 19 Aug 2005 13:19:23 +0300 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Edit-Time: 0 min X-Total-Time: 0 min 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 Jari Arkko writes: > Change A > ====== > > Add a new paragraph at the end of Section 4: > > MOBIKE also employs its own path test messages > and can only provide limited protection for them. Specifically, > these messages are sent outside the protection of the IKE > SA and can therefore be spoofed, modified, or read. However, > MOBIKE initiators do not use these messages beyond confirming > that a sent message gets a response and finding out the > characteristics of the path (addresses and NATs). MOBIKE > responders do not use these messages at all, beyond > blindly responding to them. > > A cookie mechanism ensures that attackers cannot send a response > blindly without seeing a request first. Nevertheless, on-path > attackers can intercept legitimate requests and responses, > and either prevent them from reaching the destination, > carrying them to the destination even across networks that > would not let other packets through, or modify NAT behaviour > enroute. As a result, these attacks may lead to denial-of-service. > Note that denial-of-service is typically possible for on-path > attackers even without the MOBIKE messages, e.g., by blocking > IKE messages. I do not know if the is belongs to here, but the those path test messages might also be filtered out by statefull content inspection devices (firewalls, intrusion detection / prevention systems etc), as they are not part of any existing IKE SA, and some devices might consider source IKE SPI being 0 as an attack. I do know that old NAT boxes used to do IKE SA session tracking based on the IKE SPIs and they did the demultiplexing of the incoming packets based on the IKE SPIs instead of ports. This shouldn't be problem here as we are using port 4500 instead of port 500, and NATs should not do that on port 4500. I am just wondering if there is any boxes that filter IKE packets in that kind of statefull way. The paragraph above also requires some text about replay attacks, i.e. stating that each cookie used MUST be unique, and each cookie has only certain time window and after that it is forgotten, and if packet having that cookie is later received it must not be accepted. If we use the path testing inside IKE, then there is message id's taking care of the replays, thus cookies does not need to be unique, they simply need to be non-guessable. Also in general each cookie is tied to the specific address pair it was sent to. I.e. if same cookie is used for multiple addresses pairs, then malious host B can fake an response back from the address where it actually didn't see the message. This is mostly for B as there we do need to retransmit the packet to other addresses if we do not get reply back (and in which case we should restart path testing), but also for C as this must be taken care of in both cases. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Aug 23 06:39:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7WBo-0002Zf-51 for mobike-archive@megatron.ietf.org; Tue, 23 Aug 2005 06:39:32 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25471 for ; Tue, 23 Aug 2005 06:39:28 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 26570FB28F; Tue, 23 Aug 2005 06:39:30 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CB3E6FB28D; Tue, 23 Aug 2005 06:39:26 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 53A17FB28B; Tue, 23 Aug 2005 06:39:24 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 71A51FB266 for ; Tue, 23 Aug 2005 06:39:20 -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 j7NAcwtB007840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Aug 2005 13:38:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j7NAcw2N001239; Tue, 23 Aug 2005 13:38:58 +0300 (EEST) Resent-From: kivinen@iki.fi X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f Resent-Message-ID: <17162.64704.909355.242266@fireball.kivinen.iki.fi> Resent-Date: Tue, 23 Aug 2005 13:38:56 +0300 Resent-To: MOBIKE Mailing List Message-ID: <17157.46194.868402.255877@fireball.kivinen.iki.fi> In-Reply-To: <1124321001.17138.226.camel@thunk> References: <4301E463.30405@piuha.net> <1124321001.17138.226.camel@thunk> X-Mailer: VM 7.17 under Emacs 21.4.1 From: Tero Kivinen To: Bill Sommerfeld Subject: Re: [Mobike] issue 34 -- ESP vs. IKE based NAT reboot detection Date: Fri, 19 Aug 2005 13:29:06 +0300 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Edit-Time: 0 min X-Total-Time: 0 min Cc: MOBIKE Mailing List , Pasi Eronen , 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 Bill Sommerfeld writes: > Either alternative presumably needs a notification from ESP to key > management that NAT-level "motion" has been detected, but alternative 3 > also seems to require a "mode bit" in ESP indicating when you should let > ESP handle the address updates and when it should ignore them. Not in the ESP, as the ESP is not the one who is going to make the change anyways. When the ESP notifies the addresses are changed it need to notify about that to the IKE, and at least in our case the IKE (usermode policymanager) would be doing that kind of decisions when to change and how to change, i.e. it would be then sending notification back to the ESP to ask it to modify the outer addresses. In case mobike, the usermode policymanager would not send those notifications, and with normal IKEv2 NAT-T it could send those (depending on the policy). If the NAT-T updating is supported, then the change needs to be done in both ESP and IKE SAs regardless which one of those detect the change (and depending on the policy). I am pretty much sure that there are people who want to disable that, or do it only partially (i.e. only update port, but not address etc) and all this depends on policy. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Aug 23 06:40:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7WCK-0002c9-DU for mobike-archive@megatron.ietf.org; Tue, 23 Aug 2005 06:40:04 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25498 for ; Tue, 23 Aug 2005 06:40:01 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 34508FB299; Tue, 23 Aug 2005 06:40:03 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AE8FFFB28E; Tue, 23 Aug 2005 06:39:57 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D1E5CFB292; Tue, 23 Aug 2005 06:39:55 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 470EEFB28E for ; Tue, 23 Aug 2005 06:39:35 -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 j7NAd8QC015270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Aug 2005 13:39:08 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j7NAd8XQ004195; Tue, 23 Aug 2005 13:39:08 +0300 (EEST) Resent-From: kivinen@iki.fi X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f Resent-Message-ID: <17162.64714.862231.851953@fireball.kivinen.iki.fi> Resent-Date: Tue, 23 Aug 2005 13:39:06 +0300 Resent-To: MOBIKE Mailing List Message-ID: <17157.47348.409165.539403@fireball.kivinen.iki.fi> In-Reply-To: <005201c5a45e$331ee130$6701a8c0@adithya> References: <00d501c5a2d9$fd280af0$6f01a8c0@adithya> <4302C505.4020703@piuha.net> <005201c5a45e$331ee130$6701a8c0@adithya> X-Mailer: VM 7.17 under Emacs 21.4.1 From: Tero Kivinen To: "Mohan Parthasarathy" Subject: Re: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection Date: Fri, 19 Aug 2005 13:48:20 +0300 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Edit-Time: 0 min X-Total-Time: 0 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: > Ok. Again, i am not sure whether the reason it does not exist in > hardware today is because there is a lack of need for it or it is > difficult to do it in hardware ? Mostly because it has not been needed before this. And we are now talking about the IPsec hardware, not just basic crypto hardware. There is two issues there. Firstly you need to be able to do the actual update of the outer tunnel address. I think none of the hardware drivers support APIs for doing that, and I am not sure if any of the actual hardware support that. You can probably do it by reading information from old SA, removing the old SA and install new SA, with new outer address, but with same SPI, keys, window and sequence number. The problem there is that hardware might not give ability to read the window and sequence number from inside the chip. That feature is needed for mobike anyways, so we need to find solution for that (might require new hardware, but hopefully hardware driver updating is enough (depending on the hardware limitations)). The second case is to get the notifications from the hardware when the outer IP-numbers do not match the ones configured to the SA. This is case that is only needed for the NAT-T dynamic updates. I am doubtful that any current hardware supports that, and I haven't really found out suitable workaround to be able to emulate that on hardware. It might require software check for each packet, which might destroy the hardware speedups... > As VPN gateway most likely will use hardware acceleration and as > this feature does not seem to be present in the hardware, would it > not make sense to use alt.3 ? Thats why I am saying alternate 3 is better, as it requires less changes or updates to the hardware. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Aug 24 12:34:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7yCM-0006sR-GU for mobike-archive@megatron.ietf.org; Wed, 24 Aug 2005 12:34:02 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03108 for ; Wed, 24 Aug 2005 12:33:54 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 60A50FB284; Wed, 24 Aug 2005 12:33:55 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CE3BFFB277; Wed, 24 Aug 2005 12:33:53 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7C303FB27D; Wed, 24 Aug 2005 12:33:52 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 9E293FB246 for ; Wed, 24 Aug 2005 12:33:51 -0400 (EDT) Message-ID: <024301c5a8c9$9b670500$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "MOBIKE Mailing List" Date: Wed, 24 Aug 2005 09:33:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit Subject: [Mobike] Dormant Mode? 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 I'd like to raise a possible issue here, namely whether or not Mobike should attempt to support dormant mode hosts. I say that it's a "possible" issue because, in general, most IETF protocols don't do a very good job supporting dormant mode, and it would be entirely consistent to say that Mobike doesn't either. But I think the point should at least be raised. Section 2.4 of draft-ietf-ipsec-ikev2-17.txt (IKEv2 spec) has some guidance about connection timers, but there is nothing specific about recommended values for timeouts or retransmissions, since, as the document correctly notes, this will vary depending on circumstance. Since some mobile hosts can actually spend more time in dormant mode than active, for power saving purposes, there's a possibility that the IKE SAs will need to be regenerated from scratch every time the mobile host comes out of dormant mode, if the timeouts are set too short. In addition, if there are any stateful middleboxes (proxies, firewalls), the state on them could expire prematurely, causing a request incoming through the VPN tunnel gateway to be rejected even though the VPN tunnel gateway itself didn't time out the SA. The basic issue I think that needs addressing is: should Mobike attempt in some way to address dormant mode, since, like address changes, it is a characteristic of mobile hosts? Thoughts? jak _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Aug 24 13:13:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7yor-0004SU-Kt for mobike-archive@megatron.ietf.org; Wed, 24 Aug 2005 13:13:45 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06222 for ; Wed, 24 Aug 2005 13:13:42 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1DFBEFB27F; Wed, 24 Aug 2005 13:13:44 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C85A8FB262; Wed, 24 Aug 2005 13:13:41 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 41C93FB27D; Wed, 24 Aug 2005 13:13:40 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 28BCFFB246 for ; Wed, 24 Aug 2005 13:13:39 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5DB3C89852; Wed, 24 Aug 2005 20:13:37 +0300 (EEST) Message-ID: <430CAACC.8070701@piuha.net> Date: Wed, 24 Aug 2005 20:13:48 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mobike] Dormant Mode? References: <024301c5a8c9$9b670500$196115ac@dcml.docomolabsusa.com> In-Reply-To: <024301c5a8c9$9b670500$196115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=Windows-1252; 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 Good question. I think we made a decision earlier on that we will not support what we called "zero address set" mode, where the client notifies the other end that its temporarily unreachable. I'd rather not reopen that discussion. However, this is not the same as providing a protocol that is suitable even to peers going dormant. For instance, it might be an idea to provide specification guidance or even some informational data over the protocol about the characteristics of the peer at the other end. This could also be done as an orthogonal function to the base MOBIKE protocol exchange. (Also, we'd probably want to stay away from re-introducing lifetimes that were removed when going from IKEv1 to IKEv2.) --Jari James Kempf wrote: > So I'd like to raise a possible issue here, namely whether or not > Mobike should attempt to support dormant mode hosts. I say that it's a > "possible" issue because, in general, most IETF protocols don't do a > very good job supporting dormant mode, and it would be entirely > consistent to say that Mobike doesn't either. But I think the point > should at least be raised. > > Section 2.4 of draft-ietf-ipsec-ikev2-17.txt (IKEv2 spec) has some > guidance about connection timers, but there is nothing specific about > recommended values for timeouts or retransmissions, since, as the > document correctly notes, this will vary depending on circumstance. > Since some mobile hosts can actually spend more time in dormant mode > than active, for power saving purposes, there's a possibility that the > IKE SAs will need to be regenerated from scratch every time the mobile > host comes out of dormant mode, if the timeouts are set too short. In > addition, if there are any stateful middleboxes (proxies, firewalls), > the state on them could expire prematurely, causing a request incoming > through the VPN tunnel gateway to be rejected even though the VPN > tunnel gateway itself didn't time out the SA. > > The basic issue I think that needs addressing is: should Mobike > attempt in some way to address dormant mode, since, like address > changes, it is a characteristic of mobile hosts? > > Thoughts? > > jak > > _______________________________________________ > 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 Aug 24 13:17:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ysi-0005yY-Fc for mobike-archive@megatron.ietf.org; Wed, 24 Aug 2005 13:17:44 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06393 for ; Wed, 24 Aug 2005 13:17:40 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7217FFB281; Wed, 24 Aug 2005 13:17:42 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 43E60FB262; Wed, 24 Aug 2005 13:17:41 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8A280FB27D; Wed, 24 Aug 2005 13:17:39 -0400 (EDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by machshav.com (Postfix) with ESMTP id 00429FB246 for ; Wed, 24 Aug 2005 13:17:38 -0400 (EDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j7OHHa2B022388; Wed, 24 Aug 2005 10:17:36 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7OHHZWB020194; Wed, 24 Aug 2005 13:17:35 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7OHHYfE009490; Wed, 24 Aug 2005 13:17:34 -0400 (EDT) Subject: Re: [Mobike] Dormant Mode? From: Bill Sommerfeld To: James Kempf In-Reply-To: <024301c5a8c9$9b670500$196115ac@dcml.docomolabsusa.com> References: <024301c5a8c9$9b670500$196115ac@dcml.docomolabsusa.com> Content-Type: text/plain Message-Id: <1124903854.7308.51.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Wed, 24 Aug 2005 13:17:34 -0400 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 On Wed, 2005-08-24 at 12:33, James Kempf wrote: > So I'd like to raise a possible issue here, namely whether or not Mobike > should attempt to support dormant mode hosts. I say that it's a "possible" > issue because, in general, most IETF protocols don't do a very good job > supporting dormant mode, and it would be entirely consistent to say that > Mobike doesn't either. But I think the point should at least be raised. What, specifically, do you mean by "dormant"? (I hope we get a generic definition which covers both the "phone" space and the "laptop" space, which appear to do power management very differently...) This could be conceptually similar to/related to the "no active addresses" mode we discussed early in the life of the WG. I liked it but it didn't get much traction at the time for reasons I didn't fully understand. - Bill _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Aug 24 13:29:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7z4A-0000ds-RO for mobike-archive@megatron.ietf.org; Wed, 24 Aug 2005 13:29:34 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06865 for ; Wed, 24 Aug 2005 13:29:30 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 55C1DFB289; Wed, 24 Aug 2005 13:29:32 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 88BC2FB277; Wed, 24 Aug 2005 13:29:28 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 12B5AFB27D; Wed, 24 Aug 2005 13:29:27 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 8EBAFFB262 for ; Wed, 24 Aug 2005 13:29:25 -0400 (EDT) Message-ID: <028601c5a8d1$5e2ff680$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Bill Sommerfeld" References: <024301c5a8c9$9b670500$196115ac@dcml.docomolabsusa.com> <1124903854.7308.51.camel@thunk> Subject: Re: [Mobike] Dormant Mode? Date: Wed, 24 Aug 2005 10:29:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original 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 > What, specifically, do you mean by "dormant"? (I hope we get a generic > definition which covers both the "phone" space and the "laptop" space, > which appear to do power management very differently...) > I think for purposes of Mobike, dormant mode could be defined as the mobile host will not be originating any packets for some period of time, including responses to IKEv2 probes, in order to preserve power but is still reachable at one of the addresses should any packets be incoming. Gratiutious packets should therefore be avoided. > This could be conceptually similar to/related to the "no active > addresses" mode we discussed early in the life of the WG. I liked it > but it didn't get much traction at the time for reasons I didn't fully > understand. > No, I don't think "no active addresses" would properly characterize it. The host is still prepared to take incoming packets at one of the addresses its got (like for example an incoming phone call). A deeper mode might be "no active addresses", in which the host either is turned off for the night, or isn't prepared to take any incoming packets, for even more power saving. I think this behavior spans phones and laptops, the difference between the two is what happens to packets that come while the mobile host is in dormant mode. With laptops (802.11), the AP buffers them then delivers them when the laptop periodically wakes up and polls. With phones, the RNC gets on the paging channel and pages the mobile, then delivers the packets when the mobile wakes up and re-connects. jak _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Aug 24 13:40:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zES-0004Q0-N2 for mobike-archive@megatron.ietf.org; Wed, 24 Aug 2005 13:40:16 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07352 for ; Wed, 24 Aug 2005 13:40:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 58023FB281; Wed, 24 Aug 2005 13:40:10 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 93F95FB277; Wed, 24 Aug 2005 13:40:08 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AB056FB27D; Wed, 24 Aug 2005 13:40:06 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 96589FB262 for ; Wed, 24 Aug 2005 13:40:05 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7995589852; Wed, 24 Aug 2005 20:40:04 +0300 (EEST) Message-ID: <430CB0FF.3040508@piuha.net> Date: Wed, 24 Aug 2005 20:40:15 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mobike] Dormant Mode? References: <024301c5a8c9$9b670500$196115ac@dcml.docomolabsusa.com> <1124903854.7308.51.camel@thunk> <028601c5a8d1$5e2ff680$196115ac@dcml.docomolabsusa.com> In-Reply-To: <028601c5a8d1$5e2ff680$196115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Bill Sommerfeld , 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 James Kempf wrote: > No, I don't think "no active addresses" would properly characterize > it. The host is still prepared to take incoming packets at one of the > addresses its got (like for example an incoming phone call). > > A deeper mode might be "no active addresses", in which the host either > is turned off for the night, or isn't prepared to take any incoming > packets, for even more power saving. > > I think this behavior spans phones and laptops, the difference between > the two is what happens to packets that come while the mobile host is > in dormant mode. With laptops (802.11), the AP buffers them then > delivers them when the laptop periodically wakes up and polls. With > phones, the RNC gets on the paging channel and pages the mobile, then > delivers the packets when the mobile wakes up and re-connects. Or informs the device on a signaling channel, forcing the device to wake up. In any case, its useful to avoid extra packets over wireless. NAT traversal and its keepalives are btw probably a big contributor here. Some of us have talked about adaptive keepalive behaviours, but I'm not sure yet if that is technically possible. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Aug 24 15:00:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80Tx-0005l6-Mk for mobike-archive@megatron.ietf.org; Wed, 24 Aug 2005 15: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 PAA11505 for ; Wed, 24 Aug 2005 15:00:14 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7BCA3FB281; Wed, 24 Aug 2005 15:00:11 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D7088FB27D; Wed, 24 Aug 2005 15:00:09 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 824CDFB27F; Wed, 24 Aug 2005 15:00:07 -0400 (EDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by machshav.com (Postfix) with ESMTP id 84579FB277 for ; Wed, 24 Aug 2005 15:00:06 -0400 (EDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j7OIxx2B005613; Wed, 24 Aug 2005 11:59:59 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7OIxxUj000992; Wed, 24 Aug 2005 14:59:59 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7OIxwEk009827; Wed, 24 Aug 2005 14:59:59 -0400 (EDT) Subject: Re: [Mobike] Dormant Mode? From: Bill Sommerfeld To: James Kempf In-Reply-To: <028601c5a8d1$5e2ff680$196115ac@dcml.docomolabsusa.com> References: <024301c5a8c9$9b670500$196115ac@dcml.docomolabsusa.com> <1124903854.7308.51.camel@thunk> <028601c5a8d1$5e2ff680$196115ac@dcml.docomolabsusa.com> Content-Type: text/plain Message-Id: <1124909998.7308.175.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Wed, 24 Aug 2005 14:59:58 -0400 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 On Wed, 2005-08-24 at 13:29, James Kempf wrote: > I think for purposes of Mobike, dormant mode could be defined as the mobile > host will not be originating any packets for some period of time, including > responses to IKEv2 probes, in order to preserve power but is still reachable > at one of the addresses should any packets be incoming. Gratiutious packets > should therefore be avoided. my (somewhat dated, and admittedly limited) experience with demand-dial ppp connections leads me to believe that the definition of "gratuitous" is often highly user-specific and/or application-specific; if we go down this path, will we end up with nodes exchanging specially-marked selector sets describing the equivalent of the pppd "active-filter"? > A deeper mode might be "no active addresses", in which the host either is > turned off for the night, or isn't prepared to take any incoming packets, > for even more power saving. ok, that's what I thought you meant by "dormant" earlier. In any event, if we create an operating mode in which NAT keepalives are no longer sent, then that will, IMHO, be more-or-less equivalent to a no-address-mode scheme --- if you suspend NAT keepalives for longer than the NAT's idle-session-destruction timer, you'll essentially lose incoming connectivity to the side which is behind that NAT it reasserts its presence. - Bill _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Aug 24 15:09:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80cQ-0000Y2-D5 for mobike-archive@megatron.ietf.org; Wed, 24 Aug 2005 15:09:02 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12406 for ; Wed, 24 Aug 2005 15:08:59 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 70AB0FB289; Wed, 24 Aug 2005 15:08:59 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 84CB0FB27D; Wed, 24 Aug 2005 15:08:57 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C1D46FB27F; Wed, 24 Aug 2005 15:08:56 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 1CC6CFB277 for ; Wed, 24 Aug 2005 15:08:56 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B71E189852; Wed, 24 Aug 2005 22:08:54 +0300 (EEST) Message-ID: <430CC5D2.6040101@piuha.net> Date: Wed, 24 Aug 2005 22:09:06 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Subject: Re: [Mobike] Dormant Mode? References: <024301c5a8c9$9b670500$196115ac@dcml.docomolabsusa.com> <1124903854.7308.51.camel@thunk> <028601c5a8d1$5e2ff680$196115ac@dcml.docomolabsusa.com> <1124909998.7308.175.camel@thunk> In-Reply-To: <1124909998.7308.175.camel@thunk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: James Kempf , 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 Bill Sommerfeld wrote: >In any event, if we create an operating mode in which NAT keepalives are >no longer sent, then that will, IMHO, be more-or-less equivalent to a >no-address-mode scheme --- if you suspend NAT keepalives for longer than >the NAT's idle-session-destruction timer, you'll essentially lose >incoming connectivity to the side which is behind that NAT it reasserts >its presence. > > I'd prefer not to do this. But there may be a way to do this without losing connectivity. Say, you open up another UDP-level "connection" through the same pair of addresses, and start increasing keepalive on that connection; when you see a port/address change you record the last working keepalive interval and use half of that as your regular IKE keepalive. This scheme has a number of drawbacks, including the assumption that NAT keepalive periods are static and that it would have to be rerun every time you move. Perhaps some of the other communities that have a need for NAT traversal capability have found better solutions. Anyone? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 25 06:03:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8EZu-0007Fy-FZ for mobike-archive@megatron.ietf.org; Thu, 25 Aug 2005 06:03:23 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10328 for ; Thu, 25 Aug 2005 06:03:18 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1A527FB285; Thu, 25 Aug 2005 06:03:19 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 59E02FB27D; Thu, 25 Aug 2005 06:03:18 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 53005FB27F; Thu, 25 Aug 2005 06:03:17 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 9B67FFB277 for ; Thu, 25 Aug 2005 06:03:16 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id F358289852; Thu, 25 Aug 2005 13:03:15 +0300 (EEST) Message-ID: <430D976F.5060508@piuha.net> Date: Thu, 25 Aug 2005 13:03:27 +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: <00d501c5a2d9$fd280af0$6f01a8c0@adithya> <4302C505.4020703@piuha.net> <005201c5a45e$331ee130$6701a8c0@adithya> <17157.47348.409165.539403@fireball.kivinen.iki.fi> In-Reply-To: <17157.47348.409165.539403@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Tero Kivinen wrote: >Thats why I am saying alternate 3 is better, as it requires less >changes or updates to the hardware. > > 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. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 25 08:53:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8HEU-0006nf-NN for mobike-archive@megatron.ietf.org; Thu, 25 Aug 2005 08:53:26 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15986 for ; Thu, 25 Aug 2005 08:53:24 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 897B3FB284; Thu, 25 Aug 2005 08:53:24 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 67D3AFB27D; Thu, 25 Aug 2005 08:53:22 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 84A31FB27F; Thu, 25 Aug 2005 08:53:20 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id D3A74FB277 for ; Thu, 25 Aug 2005 08:53:18 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 39E9C89852; Thu, 25 Aug 2005 15:53:17 +0300 (EEST) Message-ID: <430DBF48.8010207@piuha.net> Date: Thu, 25 Aug 2005 15:53:28 +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 27 -- security for path testing References: <4301CA95.2060208@piuha.net> <17157.45611.204562.768292@fireball.kivinen.iki.fi> In-Reply-To: <17157.45611.204562.768292@fireball.kivinen.iki.fi> 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 Tero Kivinen wrote: >Jari Arkko writes: > > >>Change A >>====== >> >>Add a new paragraph at the end of Section 4: >> >> MOBIKE also employs its own path test messages >> and can only provide limited protection for them. Specifically, >> these messages are sent outside the protection of the IKE >> SA and can therefore be spoofed, modified, or read. However, >> MOBIKE initiators do not use these messages beyond confirming >> that a sent message gets a response and finding out the >> characteristics of the path (addresses and NATs). MOBIKE >> responders do not use these messages at all, beyond >> blindly responding to them. >> >> A cookie mechanism ensures that attackers cannot send a response >> blindly without seeing a request first. Nevertheless, on-path >> attackers can intercept legitimate requests and responses, >> and either prevent them from reaching the destination, >> carrying them to the destination even across networks that >> would not let other packets through, or modify NAT behaviour >> enroute. As a result, these attacks may lead to denial-of-service. >> Note that denial-of-service is typically possible for on-path >> attackers even without the MOBIKE messages, e.g., by blocking >> IKE messages. >> >> > >I do not know if the is belongs to here, but the those path test >messages might also be filtered out by statefull content inspection >devices (firewalls, intrusion detection / prevention systems etc), as >they are not part of any existing IKE SA, and some devices might >consider source IKE SPI being 0 as an attack. > > This is certainly something that we should document. Thanks for bringing it up! >I do know that old NAT boxes used to do IKE SA session tracking based >on the IKE SPIs and they did the demultiplexing of the incoming >packets based on the IKE SPIs instead of ports. This shouldn't be >problem here as we are using port 4500 instead of port 500, and NATs >should not do that on port 4500. > >I am just wondering if there is any boxes that filter IKE packets in >that kind of statefull way. > >The paragraph above also requires some text about replay attacks, i.e. >stating that each cookie used MUST be unique, and each cookie has only >certain time window and after that it is forgotten, and if packet >having that cookie is later received it must not be accepted. If we >use the path testing inside IKE, then there is message id's taking >care of the replays, thus cookies does not need to be unique, they >simply need to be non-guessable. > > Yes. Uniqueness is handled in Section 3.5 already, I think. For the rest we need new text. >Also in general each cookie is tied to the specific address pair it >was sent to. I.e. if same cookie is used for multiple addresses pairs, >then malious host B can fake an response back from the address where >it actually didn't see the message. This is mostly for B as there we >do need to retransmit the packet to other addresses if we do not get >reply back (and in which case we should restart path testing), but >also for C as this must be taken care of in both cases. > > Right. Thanks. Here's an updated text: Change A ====== Add a new paragraph at the end of Section 4: MOBIKE also employs its own path test messages and can only provide limited protection for them. Specifically, these messages are sent outside the protection of the IKE SA and can therefore be spoofed, modified, or read. However, MOBIKE initiators do not use these messages beyond confirming that a sent message gets a response and finding out the characteristics of the path (addresses and NATs). MOBIKE responders do not use these messages at all, beyond blindly responding to them. A cookie mechanism ensures that attackers cannot send a response blindly without seeing a request first. Nevertheless, on-path attackers can intercept legitimate requests and responses, and either prevent them from reaching the destination, carrying them to the destination even across networks that would not let other packets through, or modify NAT behaviour enroute. As a result, these attacks may lead to denial-of-service. Note that denial-of-service is typically possible for on-path attackers even without the MOBIKE messages, e.g., by blocking IKE messages. Given that the path test messages use cookie values of zero for both ends, its possible that firewalls that inspect IKE packets may filter out packets with the sender's SPI set to zero. Sections 2.5 and 3.5 provide a mechanism which ensures that old path test messages can not be replayed, and that responses can not be blindly switched to appear to come from a different address. Add to 2.5 COOKIE2 notification payload: The use of COOKIE2 is necessary to ensure that the peer cannot generate the correct response without seeing the request. The sender of the PATH_TEST exchange MUST include a COOKIE2 notification payload. The data in this payload MUST be randomly chosen as described in Section 3.5, for each new packet that is sent. The recipient MUST copy the payload as-is to the response. When processing the response, the original sender MUST verify that the value is the same one as sent, within a reasonable time window to avoid replaying old values. If the values do not match, the response MUST be silently ignored. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 25 14:30:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8MUC-0006Vc-Qm for mobike-archive@megatron.ietf.org; Thu, 25 Aug 2005 14:30:01 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06006 for ; Thu, 25 Aug 2005 14:29:58 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 8B0E9FB285; Thu, 25 Aug 2005 14:29:57 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 50F78FB27D; Thu, 25 Aug 2005 14:29:56 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B7BE7FB27F; Thu, 25 Aug 2005 14:29:54 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id F337CFB277 for ; Thu, 25 Aug 2005 14:29:53 -0400 (EDT) Message-ID: <050f01c5a9a2$fbb97a80$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jari Arkko" , "Bill Sommerfeld" References: <024301c5a8c9$9b670500$196115ac@dcml.docomolabsusa.com> <1124903854.7308.51.camel@thunk> <028601c5a8d1$5e2ff680$196115ac@dcml.docomolabsusa.com> <1124909998.7308.175.camel@thunk> <430CC5D2.6040101@piuha.net> Subject: Re: [Mobike] Dormant Mode? Date: Thu, 25 Aug 2005 11:29:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response 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 Jari, > I'd prefer not to do this. But there may be a way to do > this without losing connectivity. Say, you open up another > UDP-level "connection" through the same pair of addresses, > and start increasing keepalive on that connection; when you > see a port/address change you record the last working keepalive > interval and use half of that as your regular IKE keepalive. > This scheme has a number of drawbacks, including the > assumption that NAT keepalive periods are static and that > it would have to be rerun every time you move. Perhaps > some of the other communities that have a need for NAT > traversal capability have found better solutions. Anyone? > This sounds like an acceptable way to estimate the NAT timeout, but I think it should probably be incorporated into STUN or something like that. It would be far better if the host could just ask the NAT what its timeout is, but we're not there yet. It won't solve the problem of dormant mode hosts, though. If the keepalive originates at the VPN gateway, it will wake the host up. It has to somehow originate on the host side. jak _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 25 14:36:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8MaY-00015N-4D for mobike-archive@megatron.ietf.org; Thu, 25 Aug 2005 14:36:34 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06479 for ; Thu, 25 Aug 2005 14:36:31 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C9EB2FB289; Thu, 25 Aug 2005 14:36:31 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 83629FB27F; Thu, 25 Aug 2005 14:36:27 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8AD3CFB284; Thu, 25 Aug 2005 14:36:25 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id CBB98FB27D for ; Thu, 25 Aug 2005 14:36:24 -0400 (EDT) Message-ID: <051701c5a9a3$e4c66da0$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Bill Sommerfeld" References: <024301c5a8c9$9b670500$196115ac@dcml.docomolabsusa.com> <1124903854.7308.51.camel@thunk> <028601c5a8d1$5e2ff680$196115ac@dcml.docomolabsusa.com> <1124909998.7308.175.camel@thunk> Subject: Re: [Mobike] Dormant Mode? Date: Thu, 25 Aug 2005 11:36:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original 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 > my (somewhat dated, and admittedly limited) experience with demand-dial > ppp connections leads me to believe that the definition of "gratuitous" > is often highly user-specific and/or application-specific; if we go down > this path, will we end up with nodes exchanging specially-marked > selector sets describing the equivalent of the pppd "active-filter"? > Well, some kind of filter is a possibility, but I don't think it is necessary. The basic requirement, for any kind of Mobike support, is that the VPN gateway SA timeout is extended, on host request when it is about to go into dormant mode, so that the host isn't getting frequent keepalives. > In any event, if we create an operating mode in which NAT keepalives are > no longer sent, then that will, IMHO, be more-or-less equivalent to a > no-address-mode scheme --- if you suspend NAT keepalives for longer than > the NAT's idle-session-destruction timer, you'll essentially lose > incoming connectivity to the side which is behind that NAT it reasserts > its presence. > I don't see any way to fix the problem with NAT keepalives from the VPN side, because any keepalive sent to an address owned by the host will get delivered, thus waking it up, which is what you want to avoid. But I think it could help in a nonNAT situation. jak _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 25 15:19:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8NGJ-0006gF-21 for mobike-archive@megatron.ietf.org; Thu, 25 Aug 2005 15:19:43 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09684 for ; Thu, 25 Aug 2005 15:19:35 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id AF713FB289; Thu, 25 Aug 2005 15:19:35 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 878FDFB284; Thu, 25 Aug 2005 15:19:33 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DD85AFB285; Thu, 25 Aug 2005 15:19:31 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 47A4BFB240 for ; Thu, 25 Aug 2005 15:19:31 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 740AE89852; Thu, 25 Aug 2005 22:17:26 +0300 (EEST) Message-ID: <430E193F.10702@piuha.net> Date: Thu, 25 Aug 2005 22:17:19 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mobike] Dormant Mode? References: <024301c5a8c9$9b670500$196115ac@dcml.docomolabsusa.com> <1124903854.7308.51.camel@thunk> <028601c5a8d1$5e2ff680$196115ac@dcml.docomolabsusa.com> <1124909998.7308.175.camel@thunk> <430CC5D2.6040101@piuha.net> <050f01c5a9a2$fbb97a80$196115ac@dcml.docomolabsusa.com> In-Reply-To: <050f01c5a9a2$fbb97a80$196115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bill Sommerfeld , 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 James Kempf wrote: > > This sounds like an acceptable way to estimate the NAT timeout, but I > think it should probably be incorporated into STUN or something like > that. Probably. > It would be far better if the host could just ask the NAT what its > timeout is, but we're not there yet. Yes. > It won't solve the problem of dormant mode hosts, though. If the > keepalive originates at the VPN gateway, it will wake the host up. It > has to somehow originate on the host side. Ah, but surely any improvement in the keepalive processing should ensure that both peers employ the same timeouts. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 25 16:23:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8OGV-0005m0-2e for mobike-archive@megatron.ietf.org; Thu, 25 Aug 2005 16:23:59 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16730 for ; Thu, 25 Aug 2005 16:23:55 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 68BEAFB28B; Thu, 25 Aug 2005 16:23:55 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 87822FB289; Thu, 25 Aug 2005 16:23:54 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B28DEFB28A; Thu, 25 Aug 2005 16:23:52 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id EDECBFB285 for ; Thu, 25 Aug 2005 16:23:51 -0400 (EDT) Message-ID: <054e01c5a9b2$e78b8340$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jari Arkko" References: <024301c5a8c9$9b670500$196115ac@dcml.docomolabsusa.com> <1124903854.7308.51.camel@thunk> <028601c5a8d1$5e2ff680$196115ac@dcml.docomolabsusa.com> <1124909998.7308.175.camel@thunk> <430CC5D2.6040101@piuha.net> <050f01c5a9a2$fbb97a80$196115ac@dcml.docomolabsusa.com> <430E193F.10702@piuha.net> Subject: Re: [Mobike] Dormant Mode? Date: Thu, 25 Aug 2005 13:23:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Cc: Bill Sommerfeld , 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 >> It won't solve the problem of dormant mode hosts, though. If the >> keepalive originates at the VPN gateway, it will wake the host up. It has >> to somehow originate on the host side. > > Ah, but surely any improvement in the keepalive processing should ensure > that both peers employ the same timeouts. > Right. If they both sync with the NAT timeout, then it doesn't matter. I guess the real problem is that the host can't influence the NAT timeout. If it's set too short, then the host will have to wake up - or get woken up - to keep the NAT and SA state hot. Sigh. I suppose at this point one must throw up one's hands and say "its up to the network operator to configure their NAT timeouts so that dormant mode hosts don't need to wake up excessively". jak _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Aug 29 06:30:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9gum-00006d-Lb for mobike-archive@megatron.ietf.org; Mon, 29 Aug 2005 06:30:58 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28828 for ; Mon, 29 Aug 2005 06:30:53 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4BD46FB27F; Mon, 29 Aug 2005 06:30:53 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 43076FB249; Mon, 29 Aug 2005 06:30:48 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 30E8DFB262; Mon, 29 Aug 2005 06:30:47 -0400 (EDT) Received: from inchng01.tcs.com (InChnG01.tcs.com [203.101.69.158]) by machshav.com (Postfix) with ESMTP id D8F6AFB246 for ; Mon, 29 Aug 2005 06:30:42 -0400 (EDT) Received: from ([172.20.83.59]) by inchng01.tcs.com with InterScan Messaging Security Suite; Mon, 29 Aug 2005 12:04:50 +0530 Importance: High To: mobike@machshav.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: arun1.s@tcs.com Date: Mon, 29 Aug 2005 12:04:08 +0530 X-MIMETrack: Serialize by Router on InChnM03/TCS(Release 6.53HF361 | February 23, 2005) at08/29/2005 12:04:09, Serialize complete at 08/29/2005 12:04:09 X-imss-version: 2.030 X-imss-result: Passed X-imss-scores: Clean:74.36730 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:4 C:3 M:3 S:3 R:3 (1.0000 1.0000) Subject: [Mobike] Need info 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: , Content-Type: multipart/mixed; boundary="===============0596534544==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com This is a multipart message in MIME format. --===============0596534544== Content-Type: multipart/alternative; boundary="=_alternative 0024FEF66525706C_=" This is a multipart message in MIME format. --=_alternative 0024FEF66525706C_= Content-Type: text/plain; charset="US-ASCII" Hi all, I am currently working on MobileIP.We have successfully done the HA and MN.Now we are into the IPSec implementation phase.I will very much thankful if someone can explain or tell where i can get resouce for the initial message exchange.I went through the RFC 2401..but its bit dry..I will be thankful if some one can explain what happens once i got the data which need to be sent through the tunnel.What will be my first message.I can understand for OUTBOUND we maintain a SA but again is the initial data sent is also encrypted.If so do we use Digital signatures for it.Hope someone out there could clear my doubt and give a better picture. Thanks in advance... With Thanks and Regards Arun Srinivasan Tata Consultancy Services Limited Mailto: arun1.s@tcs.com Website: http://www.tcs.com Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you --=_alternative 0024FEF66525706C_= Content-Type: text/html; charset="US-ASCII"
Hi all,

       I am currently working on MobileIP.We have successfully done the HA and MN.Now we are into the IPSec implementation phase.I will very much thankful if someone can explain or tell where i can get resouce for the initial message exchange.I went through the RFC 2401..but its bit dry..I will be thankful if some one can explain what happens once i got the data which need to be sent through the tunnel.What will be my first message.I can understand for OUTBOUND we maintain a SA but again is the initial data sent is also encrypted.If so do we use Digital signatures for it.Hope someone out there could clear my doubt and give a better picture.

Thanks in advance...

With Thanks and Regards
Arun Srinivasan
Tata Consultancy Services Limited
Mailto: arun1.s@tcs.com
Website: http://www.tcs.com
Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
--=_alternative 0024FEF66525706C_=-- --===============0596534544== 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 --===============0596534544==-- From mobike-bounces@machshav.com Mon Aug 29 08:39:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9ivO-0000tl-N3 for mobike-archive@megatron.ietf.org; Mon, 29 Aug 2005 08:39:42 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05339 for ; Mon, 29 Aug 2005 08:39:40 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 47CFBFB27F; Mon, 29 Aug 2005 08:39:37 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A7070FB249; Mon, 29 Aug 2005 08:39:34 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 38F46FB262; Mon, 29 Aug 2005 08:39:33 -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 79BBEFB246 for ; Mon, 29 Aug 2005 08:39:32 -0400 (EDT) Received: from [192.168.0.2] (unknown [61.196.102.211]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 6FC8D4C803 for ; Mon, 29 Aug 2005 21:39:14 +0900 (JST) Date: Mon, 29 Aug 2005 21:39:11 +0900 From: Shinta Sugimoto To: mobike@machshav.com Message-Id: <20050829181308.5057.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] Subject: [Mobike] comments on draft-ike-mobike-design-03.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 Content-Transfer-Encoding: 7bit Hello, I read draft-ike-mobike-design-03.txt and had a few comments/questions as below: Technical Comments: - Section 4, fourth paragraph, it says "Using this API, the MOBIKE daemon can create entries in the Security Association (SAD) and Security Policy Databases (SPD)." I believe "this API" refers to PF_KEY which is initially designed as an interface to SAD. So, the draft should be accurate in this respect, IMHO. - (In Section 5.1) Is my understanding correct that the three alternatives presented here could be exclusively used to indicate support for MOBIKE ? Or use of "critical" flag in the payload header is encouraged in every attempt of sending MOBIKE specific messages ? - Section 5.8 (Scope of SA changes), I think this is very important issue. Separate management of IKE SA and IPsec SA in terms of address update allows us more flexible and (potentially) user-friendly operation although there will be more complexity and overhead to do so. Editorial Comments: - Section 3.1, second paragraph, s/statufu/stateful/ - Page 19, first bullet, last sentence, s/it/is/ - Section 5.6, page 20, second bullet, s/in order provide/in order to provide/ - Section 5.6, 3rd paragraph, first sentence, s/an IP addressed/an IP address/ - Section 5.6, 3rd paragraph, s/weaker guarantees then/weaker guarantees than/ - Section 5.6, 5th paragraph (page 21), s/material.A protection/material. A protection/ - Page 22, second bullet, first sentence, unnecessary "()" appears. - Section 5.9, 2nd sentence, s/the it/it/ Regards, Shinta _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Aug 29 09:08:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9jNF-0005rx-CH for mobike-archive@megatron.ietf.org; Mon, 29 Aug 2005 09:08:32 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06776 for ; Mon, 29 Aug 2005 09:08:26 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D109BFB27C; Mon, 29 Aug 2005 09:08:22 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 44CE3FB249; Mon, 29 Aug 2005 09:08:20 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 44516FB262; Mon, 29 Aug 2005 09:08:18 -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 C18BCFB246 for ; Mon, 29 Aug 2005 09:08:16 -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 j7TD82311135; Mon, 29 Aug 2005 15:08: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 j7TD82go051029; Mon, 29 Aug 2005 15:08:02 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200508291308.j7TD82go051029@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Shinta Sugimoto Subject: Re: [Mobike] comments on draft-ike-mobike-design-03.txt In-reply-to: Your message of Mon, 29 Aug 2005 21:39:11 +0900. <20050829181308.5057.SHINTA@sfc.wide.ad.jp> Date: Mon, 29 Aug 2005 15:08:02 +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 read draft-ike-mobike-design-03.txt and had a few comments/questions as below: Technical Comments: - Section 4, fourth paragraph, it says "Using this API, the MOBIKE daemon can create entries in the Security Association (SAD) and Security Policy Databases (SPD)." I believe "this API" refers to PF_KEY which is initially designed as an interface to SAD. So, the draft should be accurate in this respect, IMHO. => PF_KEY can't offically be used to manage the SPD so IMHO the current wording should be kept. - Section 5.8 (Scope of SA changes), I think this is very important issue. Separate management of IKE SA and IPsec SA in terms of address update allows us more flexible and (potentially) user-friendly operation although there will be more complexity and overhead to do so. => I agree on both: it is an important issue and the current decision is bad. 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 Aug 30 08:40:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA5PI-0003Cg-6c for mobike-archive@megatron.ietf.org; Tue, 30 Aug 2005 08:40:05 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09941 for ; Tue, 30 Aug 2005 08:40:01 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B55C3FB27C; Tue, 30 Aug 2005 08:39:44 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4347EFB246; Tue, 30 Aug 2005 08:39:42 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8D1D8FB277; Tue, 30 Aug 2005 08:39:40 -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 975F0FB240 for ; Tue, 30 Aug 2005 08:39:36 -0400 (EDT) Received: from [192.168.0.2] (unknown [61.196.102.211]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 9F92E4CC11 for ; Tue, 30 Aug 2005 21:39:29 +0900 (JST) Date: Tue, 30 Aug 2005 21:39:26 +0900 From: Shinta Sugimoto To: mobike@machshav.com Message-Id: <20050830100732.505B.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] Subject: [Mobike] comments on draft-ietf-mobike-protocol-01.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 Content-Transfer-Encoding: 7bit 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 ? 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? 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 ? - Section 2.7 (NAT prevention), I also felt that better naming is needed for NAT_PREVENTED. Taking look at issue #24, I tend to agree that NAT_PREVENTED should be replaced with something like NAT_PREVENTION_FAILURE from which one can easily understand that it's an erroneous state (or failure case). Editorial Comments: - 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. - Section 2.4 (Updating additional addresses), the first sentence says "both the initiator and responder can send a list of additional addresses (in addition to the one used for IKE_SA_INIT/IKE_AUTH exchange) to the initiator in the IKE_AUTH exchange." It seems to me that the sentence is a bit paradoxical. IMHO, the phrase "to the initiator" can be eliminated. Regards, Shinta _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Aug 30 08:49:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA5Ym-0005W8-3t for mobike-archive@megatron.ietf.org; Tue, 30 Aug 2005 08:49:52 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10323 for ; Tue, 30 Aug 2005 08:49:50 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9EC54FB283; Tue, 30 Aug 2005 08:49:49 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CE729FB277; Tue, 30 Aug 2005 08:49:45 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2A8C2FB27C; Tue, 30 Aug 2005 08:49:44 -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 06B3DFB23C for ; Tue, 30 Aug 2005 08:49:40 -0400 (EDT) Received: from [192.168.0.2] (unknown [61.196.102.211]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 7E5464C5CE; Tue, 30 Aug 2005 21:49:38 +0900 (JST) Date: Tue, 30 Aug 2005 21:49:35 +0900 From: Shinta Sugimoto To: Francis Dupont Subject: Re: [Mobike] comments on draft-ike-mobike-design-03.txt In-Reply-To: <200508291308.j7TD82go051029@givry.rennes.enst-bretagne.fr> References: <20050829181308.5057.SHINTA@sfc.wide.ad.jp> <200508291308.j7TD82go051029@givry.rennes.enst-bretagne.fr> Message-Id: <20050830213934.5060.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 On Mon, 29 Aug 2005 15:08:02 +0200 Francis Dupont wrote: > In your previous mail you wrote: > > I read draft-ike-mobike-design-03.txt and had a few comments/questions > as below: > > Technical Comments: > > - Section 4, fourth paragraph, it says "Using this API, the MOBIKE > daemon can create entries in the Security Association (SAD) and > Security Policy Databases (SPD)." I believe "this API" refers to > PF_KEY which is initially designed as an interface to SAD. So, the > draft should be accurate in this respect, IMHO. > > => PF_KEY can't offically be used to manage the SPD so IMHO the > current wording should be kept. That's the point that I wanted to make. The current texts could be read in a way that both SADB and SPD can be accessed by the API (PF_KEY). Figure 3 shows an example protocol interaction between a pair of MOBIKE peers. MOBIKE interacts with the IPsec engine using the PF_KEY API [RFC2367]. Using this API, the MOBIKE daemon can create entries in the Security Association (SAD) and Security Policy Databases (SPD). So just thought that it would be bettter to say: Figure 3 shows an example protocol interaction between a pair of MOBIKE peers. MOBIKE interacts with the IPsec engine using certain API. PF_KEY [RFC2367] can be used by the MOBIKE daemon to access the Security Association Database (SAD). Regards, Shinta > > - Section 5.8 (Scope of SA changes), I think this is very important > issue. Separate management of IKE SA and IPsec SA in terms of address > update allows us more flexible and (potentially) user-friendly > operation although there will be more complexity and overhead to > do so. > > => I agree on both: it is an important issue and the current decision is bad. > > 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 Aug 30 10:23:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA71o-0003R6-3k for mobike-archive@megatron.ietf.org; Tue, 30 Aug 2005 10:23:56 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15927 for ; Tue, 30 Aug 2005 10:23:52 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 56F5FFB27D; Tue, 30 Aug 2005 10:23:53 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C2971FB262; Tue, 30 Aug 2005 10:23:52 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7EA92FB277; Tue, 30 Aug 2005 10:23:51 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id 99FA7FB246 for ; Tue, 30 Aug 2005 10:23:50 -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 j7UENnrD013333; Tue, 30 Aug 2005 17:23:49 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Aug 2005 17:23:49 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Aug 2005 17:23:48 +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 36: unacceptable addresses (was: confirming consensus on issues from Paris) Date: Tue, 30 Aug 2005 17:23:48 +0300 Message-ID: Thread-Topic: [Mobike] confirming consensus on issues from Paris Thread-Index: AcWhxROzKcFwxjcHSR6GKFxxqlsZTwLqHcww From: To: , X-OriginalArrivalTime: 30 Aug 2005 14:23:48.0648 (UTC) FILETIME=[6FF85280:01C5AD6E] 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: > 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=20 response, starts again from the first step (and ignores=20 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.) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Aug 31 07:36:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAQtP-0003X5-B1 for mobike-archive@megatron.ietf.org; Wed, 31 Aug 2005 07:36:35 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14983 for ; Wed, 31 Aug 2005 07:36:32 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1B529FB282; Wed, 31 Aug 2005 07:36:22 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 16A45FB27C; Wed, 31 Aug 2005 07:36:21 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9A422FB27D; Wed, 31 Aug 2005 07:36:19 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id B4659FB277 for ; Wed, 31 Aug 2005 07:36:18 -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 j7VBa3ud005257; Wed, 31 Aug 2005 14:36:10 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Aug 2005 14:36:10 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Aug 2005 14:36:09 +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 38: editorial comments (was: comments on draft-ietf-mobike-protocol-01.txt) Date: Wed, 31 Aug 2005 14:36:09 +0300 Message-ID: Thread-Topic: [Mobike] comments on draft-ietf-mobike-protocol-01.txt Thread-Index: AcWtYDP8UkkUA5vcQsqq7+L4bxzFgAAveQ/Q From: To: , X-OriginalArrivalTime: 31 Aug 2005 11:36:09.0777 (UTC) FILETIME=[2ED42A10:01C5AE20] 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 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=20 while we're doing e.g. rekeying or dead peer detection. > - Section 2.4 (Updating additional addresses), the first > sentence says "both the initiator and responder can send a > list of additional addresses (in addition to the one used for > IKE_SA_INIT/IKE_AUTH exchange) to the initiator in the > IKE_AUTH exchange." It seems to me that the sentence is a bit > paradoxical. IMHO, the phrase "to the initiator" can be > eliminated. Yes, you're right. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Aug 31 07:45:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAR1h-0005hd-SN for mobike-archive@megatron.ietf.org; Wed, 31 Aug 2005 07:45:09 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15432 for ; Wed, 31 Aug 2005 07:45:08 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B3984FB284; Wed, 31 Aug 2005 07:45:01 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 344A9FB281; Wed, 31 Aug 2005 07:45:00 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9EDE6FB282; Wed, 31 Aug 2005 07:44:58 -0400 (EDT) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id B0ED0FB27C for ; Wed, 31 Aug 2005 07:44:57 -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 j7VBhnwY004654 for ; Wed, 31 Aug 2005 14:43:54 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Aug 2005 14:44:57 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Aug 2005 14:44: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 Subject: RE: [Mobike] issue 34 -- ESP vs. IKE based NAT reboot detection Date: Wed, 31 Aug 2005 14:44:55 +0300 Message-ID: Thread-Topic: [Mobike] issue 34 -- ESP vs. IKE based NAT reboot detection Thread-Index: AcWnz9pgu/ZYEDkVT0+QeOO4/BoW8QGUH0DQ From: To: X-OriginalArrivalTime: 31 Aug 2005 11:44:55.0741 (UTC) FILETIME=[6853E6D0:01C5AE21] 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 Kivinen writes: >=20 > Bill Sommerfeld writes: > > Either alternative presumably needs a notification from ESP to=20 > > key management that NAT-level "motion" has been detected, but=20 > > alternative 3 also seems to require a "mode bit" in ESP=20 > > indicating when you should let ESP handle the address updates=20 > > and when it should ignore them. >=20 > Not in the ESP, as the ESP is not the one who is going to make the > change anyways. When the ESP notifies the addresses are changed it > need to notify about that to the IKE, and at least in our case the > IKE (usermode policymanager) would be doing that kind of decisions > when to change and how to change, i.e. it would be then sending > notification back to the ESP to ask it to modify the outer > addresses. The specs don't really say (and even should not say) how this should be implemented. Either the ESP module updates the IPsec SAs (and just notifies the IKE module so that IKE_SA gets updated as well),=20 or the ESP module could just notify the IKE module, which would=20 then update both IPsec and IKE SAs. Linux/OpenSWAN uses the latter option, and so does your implementation, it seems... but concievably, some implementation=20 could use the former. But I'm beginning to think that perhaps your proposal (3) would have some advantages; at least there would not be two different sources (ESP and MOBIKE) asking for changes in the addresses... Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Aug 31 09:07:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EASJr-0006iQ-Fm for mobike-archive@megatron.ietf.org; Wed, 31 Aug 2005 09:07:59 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19586 for ; Wed, 31 Aug 2005 09:07:56 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 83370FB281; Wed, 31 Aug 2005 09:07:55 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1BDEFFB27C; Wed, 31 Aug 2005 09:07:54 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 6A7F8FB27D; Wed, 31 Aug 2005 09:07:53 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id DA115FB27C for ; Wed, 31 Aug 2005 09:06:37 -0400 (EDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j7VD6C9W032512; Wed, 31 Aug 2005 16:06:33 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Aug 2005 16:06:32 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Aug 2005 16:06:31 +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 39 (was: comments on draft-ietf-mobike-protocol-01.txt) Date: Wed, 31 Aug 2005 16:06:31 +0300 Message-ID: Thread-Topic: [Mobike] comments on draft-ietf-mobike-protocol-01.txt Thread-Index: AcWtYDP8UkkUA5vcQsqq7+L4bxzFgAAzDODA From: To: , X-OriginalArrivalTime: 31 Aug 2005 13:06:31.0919 (UTC) FILETIME=[CEAD5FF0:01C5AE2C] 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 Shinta Sugimoto writes: >=20 > Hello, >=20 > I read draft-ietf-mobike-protocol-01.txt and had following > comments/questions. >=20 > Technical Comments/Questions: >=20 > - 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?=20 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). > 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...) > 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.) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Aug 31 21:10:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAdb8-00030u-Ie for mobike-archive@megatron.ietf.org; Wed, 31 Aug 2005 21:10:35 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00317 for ; Wed, 31 Aug 2005 21:10:30 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C6C41FB27D; Wed, 31 Aug 2005 21:10:29 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BA846FB23E; Wed, 31 Aug 2005 21:10:27 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7760CFB246; Wed, 31 Aug 2005 21:10:26 -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 AFBBAFB23E for ; Wed, 31 Aug 2005 21:09:07 -0400 (EDT) Received: (qmail 94406 invoked from network); 1 Sep 2005 01:09:07 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.169.161.66 with login) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 1 Sep 2005 01:09:06 -0000 Message-ID: <005701c5ae91$c36d5360$7401a8c0@adithya> From: "Mohan Parthasarathy" To: "Jari Arkko" , "Tero Kivinen" 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> Subject: Re: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection Date: Wed, 31 Aug 2005 18:09:11 -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, 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: > > >Thats why I am saying alternate 3 is better, as it requires less > >changes or updates to the hardware. > > > > > 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 ? -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