From mailman-bounces@machshav.com Sun Aug 1 01:01:48 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07750 for ; Sun, 1 Aug 2004 01:01:48 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1CF71FB4DE; Sun, 1 Aug 2004 01:01:48 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B2798FB4FF for ; Sun, 1 Aug 2004 01:01:16 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: machshav.com mailing list memberships reminder From: mailman-owner@machshav.com To: mobike-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sun, 01 Aug 2004 05:00:08 +0000 Precedence: bulk X-BeenThere: mailman@machshav.com X-Mailman-Version: 2.1.4 List-Id: mailman.machshav.com X-List-Administrivia: yes Sender: mailman-bounces@machshav.com Errors-To: mailman-bounces@machshav.com Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your machshav.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@machshav.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@machshav.com. Thanks! Passwords for mobike-archive@lists.ietf.org: List Password // URL ---- -------- mobike@machshav.com behoef https://www.machshav.com/mailman/options.cgi/mobike/mobike-archive%40lists.ietf.org From mobike-bounces@machshav.com Sun Aug 1 05:21:47 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05061 for ; Sun, 1 Aug 2004 05:21:47 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 77C53FB4DD; Sun, 1 Aug 2004 05:21:43 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1F7F4FB4D8; Sun, 1 Aug 2004 05:21:40 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2C6F0FB4D8; Sun, 1 Aug 2004 05:21:38 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 41E37FB44D for ; Sun, 1 Aug 2004 05:21:37 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 2D7FD89846; Sun, 1 Aug 2004 12:21:33 +0300 (EEST) Message-ID: <410CA159.5050307@piuha.net> Date: Sun, 01 Aug 2004 10:52:57 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi Eronen , MOBIKE Mailing List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] Comments on draft-eronen-mobike-mopo-00.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net 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, I liked your draft! I think your approach of having a set of separate features - independently usable even in a non-mobile situation - is a good one. I also liked the NAT prevention feature a lot! The path testing approach you have is also good, I think. A couple of comments: o Section 1.2. If I am not mistaken, one of the features that you are also not doing is the movement of IPsec SAs one by one. You move them all at once, right? o Section 7.3: I'm not sure I understand exactly what "when the window size allows" implies. Can we get into an eternal wait if there's something else going on at the same time as we move? o Section 8.1: Couldn't you condense the first two bullets by saying that if the responder is not behind a NAT and is non-mobile, then the initiator can be multihomed, mobile and behind any type of a NAT? If this is the case, then I believe there's sufficient functionality. o We need more details to what happens when you receive a NAT_PREVENTION payload and there has been an address change in transit. Editorial: o Section 6: s/not addresses/not all addresses/ --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Aug 1 16:36:50 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23322 for ; Sun, 1 Aug 2004 16:36:49 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D0C8DFB4D9; Sun, 1 Aug 2004 16:36:49 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6B536FB44D; Sun, 1 Aug 2004 16:36:49 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5ADDEFB4D8; Sun, 1 Aug 2004 16:36:47 -0400 (EDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by machshav.com (Postfix) with ESMTP id B7586FB44D for ; Sun, 1 Aug 2004 16:36:46 -0400 (EDT) Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i71Kabe09492; Sun, 1 Aug 2004 16:36:37 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PPX39CD8; Sun, 1 Aug 2004 16:36:36 -0400 Received: from [47.140.52.241] (artpt5tr.us.nortel.com [47.140.52.241]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PSKYPWKF; Sun, 1 Aug 2004 16:36:36 -0400 Message-ID: <410D5451.40702@nortelnetworks.com> Date: Sun, 01 Aug 2004 16:36:33 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net Subject: Re: [Mobike] Comments on draft-eronen-mobike-mopo-00.txt References: <410CA159.5050307@piuha.net> In-Reply-To: <410CA159.5050307@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , Pasi Eronen X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 wrote: > > Pasi, > > I liked your draft! I think your approach of having > a set of separate features - independently usable even > in a non-mobile situation - is a good one. I also liked > the NAT prevention feature a lot! The path testing > approach you have is also good, I think. > > A couple of comments: > > o Section 1.2. If I am not mistaken, one of the features > that you are also not doing is the movement of IPsec > SAs one by one. You move them all at once, right? > > o Section 7.3: I'm not sure I understand exactly > what "when the window size allows" implies. Can we > get into an eternal wait if there's something else > going on at the same time as we move? > This may be stating the obvious, but, for instance, if there is an outstanding rekey message for which a response has not been received, and if the peer moves, an RR request could not be sent, right? (assuming window size =1, but we can construct a scenario for window size > 1). So, "RR required for any further operation" policy would/might not quite work. (I need to double check the rekeying rules). Delayed RR would work however, because the rekey process could be completed before verifying RR (the rekey reply message would have to be accepted whether it comes from the old or the new address). cheers, Lakshminath > o Section 8.1: Couldn't you condense the first two bullets > by saying that if the responder is not behind a NAT > and is non-mobile, then the initiator can be multihomed, > mobile and behind any type of a NAT? If this is the case, > then I believe there's sufficient functionality. > > o We need more details to what happens when you receive > a NAT_PREVENTION payload and there has been an address > change in transit. > > Editorial: > > o Section 6: s/not addresses/not all addresses/ > > --Jari > > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Aug 3 00:38:35 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00451 for ; Tue, 3 Aug 2004 00:38:34 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id BA023FB4DA; Tue, 3 Aug 2004 00:38:34 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 06CD3FB4D7; Tue, 3 Aug 2004 00:38:34 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F30A7FB4D9; Tue, 3 Aug 2004 00:38:31 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id EF988FB44D for ; Tue, 3 Aug 2004 00:38:30 -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 i734cPi01232 for ; Tue, 3 Aug 2004 06:38:25 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i734cPSj005073 for ; Tue, 3 Aug 2004 06:38:25 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200408030438.i734cPSj005073@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobike@machshav.com Date: Tue, 03 Aug 2004 06:38:25 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Subject: [Mobike] SG-SG using the SCTP model of multi-homing X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 This is a concrete example of a SG-SG setup using what I called the SCTP model of multi-homing (one control connection, multiple streams using different paths). My telecom engineer school has two main sites B and C with three networks between them: - a Gbits/s research network (we'd like to use it for everything but we may not :-) - a dedicated 4 Mbits/s ATM link used for PABX interconnection and videoconferences but available for general IP traffic between the two sites too - a 16Mbits/s (don't laugh) attachment of each site to the NREN (National Research and Education Network), itself connected to the Internet. Imagine we'd like to protect all 3 paths with an IKEv2 Security Gateway box per site, I'd like to setup an IKE SA using the Gbits/s network, an IPsec SA pair for research traffic throught it, a second IPsec SA pair for general traffic throught the dedicated ATM and be able to downgrade up to the Internet path in case of problems. The easiest way to provide this is to use the part of SAs update feature. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 5 20:15:01 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28448 for ; Thu, 5 Aug 2004 20:15:01 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id F4206FB4DD; Thu, 5 Aug 2004 20:15:01 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 80B66FB4D9; Thu, 5 Aug 2004 20:15:01 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3AB08FB4DA; Thu, 5 Aug 2004 20:14:59 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id 38B3CFB4D7 for ; Thu, 5 Aug 2004 20:14:58 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i760Eu618869 for ; Fri, 6 Aug 2004 03:14:56 +0300 (EET DST) X-Scanned: Fri, 6 Aug 2004 03:13:06 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i760D6uE018175 for ; Fri, 6 Aug 2004 03:13:06 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00XdOzlt; Fri, 06 Aug 2004 03:13:04 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i760D2n11060 for ; Fri, 6 Aug 2004 03:13:02 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 6 Aug 2004 03:13:02 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Aug 2004 03:13:02 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3B95@esebe023.ntc.nokia.com> Thread-Topic: Closing some less controversial issues Thread-Index: AcR7SiKL7Rq+3oL5S2KswjhUVjAZVw== From: To: X-OriginalArrivalTime: 06 Aug 2004 00:13:02.0603 (UTC) FILETIME=[23773DB0:01C47B4A] Subject: [Mobike] Closing some less controversial issues X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 think we should close some of the less controversial=20 issues on the issues list. These have been discussed on the=20 mailing list and meetings, and I think we have a rough consensus on them.=20 If you disagree, please tell so within a week or so. Issue 2: "Is simultaneous movement of both parties supported?" "No; both parties can be mobile, but simultaneous=20 movement is not supported." Issue 9: "Does MOBIKE require RFC2401bis?" "IKEv2 requires RFC2401bis, and MOBIKE requires IKEv2." Issue 7: "Do we support tunnel mode only, or tunnel mode first and transport later, or both by same document?" "First document will consider only tunnel mode." Issue 13: "Does switching from IPv4 to IPv6 or vice versa work? Presumably only for tunnel mode?"=20 "Changing from IPv4 to IPv6 or vice versa should work=20 for tunnel mode at least." Cheers, Pasi (as issues list maintainer) _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 5 20:20:56 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28624 for ; Thu, 5 Aug 2004 20:20:55 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id CBEFEFB4DC; Thu, 5 Aug 2004 20:20:56 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6E442FB4DA; Thu, 5 Aug 2004 20:20:56 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3C0C2FB4DB; Thu, 5 Aug 2004 20:20:55 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by machshav.com (Postfix) with ESMTP id A808EFB4D7 for ; Thu, 5 Aug 2004 20:20:54 -0400 (EDT) Received: from [128.9.176.224] (c2-vpn07.isi.edu [128.9.176.224]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i760KSJ25088; Thu, 5 Aug 2004 17:20:29 -0700 (PDT) Message-ID: <4112CECD.7030207@isi.edu> Date: Thu, 05 Aug 2004 17:20:29 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Closing some less controversial issues References: <052E0C61B69C3741AFA5FE88ACC775A6010C3B95@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C3B95@esebe023.ntc.nokia.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0676933875==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0676933875== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig676651CCD5BAB9A65651EF55" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig676651CCD5BAB9A65651EF55 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > I think we should close some of the less controversial > issues on the issues list. These have been discussed on the > mailing list and meetings, and I think we have a rough > consensus on them. > > If you disagree, please tell so within a week or so. > > Issue 2: "Is simultaneous movement of both parties supported?" > > "No; both parties can be mobile, but simultaneous > movement is not supported." What mechanism will be used to ensure that only one end moves at a time? If you cannot ensure it, what happens _when_ it happens? > Issue 9: "Does MOBIKE require RFC2401bis?" > > "IKEv2 requires RFC2401bis, and MOBIKE requires IKEv2." > > Issue 7: "Do we support tunnel mode only, or tunnel mode first and > transport later, or both by same document?" > > "First document will consider only tunnel mode." IMO, it would be more useful to support transport mode than tunnel mode. (reasons in draft-touch-ipsec-vpn) > Issue 13: "Does switching from IPv4 to IPv6 or vice versa work? > Presumably only for tunnel mode?" > > "Changing from IPv4 to IPv6 or vice versa should work > for tunnel mode at least." > > Cheers, > Pasi (as issues list maintainer) > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike --------------enig676651CCD5BAB9A65651EF55 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD4DBQFBEs7OE5f5cImnZrsRAuqUAJwM+qOU1XIgkDmuocVVtKP8l4VFFACY8GsE ZlOWVileoP7f+ZCjg12flg== =inlK -----END PGP SIGNATURE----- --------------enig676651CCD5BAB9A65651EF55-- --===============0676933875== 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 --===============0676933875==-- From mobike-bounces@machshav.com Thu Aug 5 20:29:11 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28955 for ; Thu, 5 Aug 2004 20:29:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 67F7DFB4DF; Thu, 5 Aug 2004 20:29:11 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E5DC6FB4DB; Thu, 5 Aug 2004 20:29:10 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 82848FB4DC; Thu, 5 Aug 2004 20:29:09 -0400 (EDT) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 79AFDFB4DA for ; Thu, 5 Aug 2004 20:29:08 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i760T6Yu017878 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 6 Aug 2004 03:29:06 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i760T67A017875; Fri, 6 Aug 2004 03:29:06 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16658.53458.99247.766352@fireball.kivinen.iki.fi> Date: Fri, 6 Aug 2004 03:29:06 +0300 From: Tero Kivinen To: Subject: [Mobike] Closing some less controversial issues In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C3B95@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A6010C3B95@esebe023.ntc.nokia.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > Issue 2: "Is simultaneous movement of both parties supported?" > > "No; both parties can be mobile, but simultaneous > movement is not supported." > > Issue 9: "Does MOBIKE require RFC2401bis?" > > "IKEv2 requires RFC2401bis, and MOBIKE requires IKEv2." > > Issue 7: "Do we support tunnel mode only, or tunnel mode first and > transport later, or both by same document?" > > "First document will consider only tunnel mode." > > Issue 13: "Does switching from IPv4 to IPv6 or vice versa work? > Presumably only for tunnel mode?" > > "Changing from IPv4 to IPv6 or vice versa should work > for tunnel mode at least." I agree to closing all these issues. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 5 22:45:22 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05791 for ; Thu, 5 Aug 2004 22:45:21 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 21550FB4DE; Thu, 5 Aug 2004 22:45:23 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C2303FB4DB; Thu, 5 Aug 2004 22:45:22 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 10AE0FB4DC; Thu, 5 Aug 2004 22:45:21 -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 14F2FFB4DA for ; Thu, 5 Aug 2004 22:45:20 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i762jF819103; Fri, 6 Aug 2004 04:45:15 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i762jESj015728; Fri, 6 Aug 2004 04:45:14 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200408060245.i762jESj015728@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Closing some less controversial issues In-reply-to: Your message of Fri, 06 Aug 2004 03:13:02 +0300. <052E0C61B69C3741AFA5FE88ACC775A6010C3B95@esebe023.ntc.nokia.com> Date: Fri, 06 Aug 2004 04:45:14 +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.4 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: Issue 7: "Do we support tunnel mode only, or tunnel mode first and transport later, or both by same document?" "First document will consider only tunnel mode." => note that I plan to write a short document which explains both why transport mode is out of scope and how transport mode can take advantage of mobike (peer address list to be accurate). => please close them. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 5 22:52:47 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06599 for ; Thu, 5 Aug 2004 22:52:47 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1F880FB4DF; Thu, 5 Aug 2004 22:52:49 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 663DEFB4DC; Thu, 5 Aug 2004 22:52:48 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B8DB4FB4DE; Thu, 5 Aug 2004 22:52:46 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id AB947FB4DA for ; Thu, 5 Aug 2004 22:52:45 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i762qc819491; Fri, 6 Aug 2004 04:52:38 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i762qcSj015772; Fri, 6 Aug 2004 04:52:38 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200408060252.i762qcSj015772@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Joe Touch Subject: Re: [Mobike] Closing some less controversial issues In-reply-to: Your message of Thu, 05 Aug 2004 17:20:29 PDT. <4112CECD.7030207@isi.edu> Date: Fri, 06 Aug 2004 04:52:38 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: > Issue 2: "Is simultaneous movement of both parties supported?" > > "No; both parties can be mobile, but simultaneous > movement is not supported." What mechanism will be used to ensure that only one end moves at a time? => none. If you cannot ensure it, what happens _when_ it happens? => message exchange failure, timeout and full reset of everything. > Issue 7: "Do we support tunnel mode only, or tunnel mode first and > transport later, or both by same document?" > > "First document will consider only tunnel mode." IMO, it would be more useful to support transport mode than tunnel mode. (reasons in draft-touch-ipsec-vpn) => I understand your reasons but transport mode of tunnels is a bit special and should be handled by specifics mechanisms... Can we talk about this later and/or off-line? Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 5 22:59:24 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06927 for ; Thu, 5 Aug 2004 22:59:23 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C7B2FFB4DE; Thu, 5 Aug 2004 22:59:25 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7D8A6FB4D9; Thu, 5 Aug 2004 22:59:25 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CFE29FB4DA; Thu, 5 Aug 2004 22:59:23 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by machshav.com (Postfix) with ESMTP id 3B50AFB4D7 for ; Thu, 5 Aug 2004 22:59:23 -0400 (EDT) Received: from [130.129.131.133] (opene-130-129-131-133.ietf60.ietf.org [130.129.131.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i762w4J00268; Thu, 5 Aug 2004 19:58:04 -0700 (PDT) Message-ID: <4112F3B9.4040006@isi.edu> Date: Thu, 05 Aug 2004 19:58:01 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] Closing some less controversial issues References: <200408060252.i762qcSj015772@givry.rennes.enst-bretagne.fr> In-Reply-To: <200408060252.i762qcSj015772@givry.rennes.enst-bretagne.fr> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0215160611==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0215160611== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig82E27A775D8727DA3C19240E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig82E27A775D8727DA3C19240E Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Francis Dupont wrote: > In your previous mail you wrote: > > > Issue 2: "Is simultaneous movement of both parties supported?" > > > > "No; both parties can be mobile, but simultaneous > > movement is not supported." > > What mechanism will be used to ensure that only one end moves at a time? > > => none. > > If you cannot ensure it, what happens _when_ it happens? > > => message exchange failure, timeout and full reset of everything. Thanks. My apologies for jumping in without a huge amount of context, and thanks for the answer. So long as it's handled, not defined-away ;-) > > Issue 7: "Do we support tunnel mode only, or tunnel mode first and > > transport later, or both by same document?" > > > > "First document will consider only tunnel mode." > > IMO, it would be more useful to support transport mode than tunnel mode. > (reasons in draft-touch-ipsec-vpn) > > => I understand your reasons but transport mode of tunnels is a bit > special and should be handled by specifics mechanisms... > Can we talk about this later and/or off-line? Sure. Again, just concerned about the statement, and glad it's handled already. > Regards > > Francis.Dupont@enst-bretagne.fr --------------enig82E27A775D8727DA3C19240E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBEvO5E5f5cImnZrsRAqpUAKCDxEgyDVSTvLL2nX1pS67gJSIMNQCgnkoq iDyUHJmv1XgjRIts4MKRdcs= =ny4+ -----END PGP SIGNATURE----- --------------enig82E27A775D8727DA3C19240E-- --===============0215160611== 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 --===============0215160611==-- From mobike-bounces@machshav.com Thu Aug 5 23:25:31 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08412 for ; Thu, 5 Aug 2004 23:25:30 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5E3F1FB4DF; Thu, 5 Aug 2004 23:25:32 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 150EAFB4DB; Thu, 5 Aug 2004 23:25:32 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 716B5FB4DE; Thu, 5 Aug 2004 23:25:30 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id 7964CFB4DA for ; Thu, 5 Aug 2004 23:25:29 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i763PRB08329 for ; Fri, 6 Aug 2004 06:25:27 +0300 (EET DST) X-Scanned: Fri, 6 Aug 2004 06:21:40 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i763Leg7010735 for ; Fri, 6 Aug 2004 06:21:40 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00Ut1gKv; Fri, 06 Aug 2004 06:21:38 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i763Lcu05476 for ; Fri, 6 Aug 2004 06:21:38 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 6 Aug 2004 06:21:37 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Aug 2004 06:21:37 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3B96@esebe023.ntc.nokia.com> Thread-Topic: Slides available Thread-Index: AcR7ZHv7gVq7adO2Qm2qbaUd1ibNSQ== From: To: X-OriginalArrivalTime: 06 Aug 2004 03:21:37.0934 (UTC) FILETIME=[7BEDBAE0:01C47B64] Subject: [Mobike] Slides available X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 Slides from the WG meeting on Monday are now on-line at . Minutes are not=20 there yet (but hopefully will be some time next week). Regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Aug 6 02:03:33 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23388 for ; Fri, 6 Aug 2004 02:03:33 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D287DFB4DD; Fri, 6 Aug 2004 02:03:32 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2F579FB4DA; Fri, 6 Aug 2004 02:03:32 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2AD92FB4DB; Fri, 6 Aug 2004 02:03:31 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 7F5ADFB4D7 for ; Fri, 6 Aug 2004 02:03:30 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 606BC89844; Fri, 6 Aug 2004 09:03:27 +0300 (EEST) Message-ID: <41131F22.9060104@piuha.net> Date: Fri, 06 Aug 2004 09:03:14 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Closing some less controversial issues References: <052E0C61B69C3741AFA5FE88ACC775A6010C3B95@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C3B95@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Francis Dupont , mobike@machshav.com, touch@ISI.EDU X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net 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 agree with closing these issues. Joe: I believe transport mode is useful too, but I'd like to make us do the tunnel mode first, as it fits our primary scenario, the VPN roadwarrior case. Francis: Yes, it would be very good if you could come up with the the document that you mentioned. --Jari Pasi.Eronen@nokia.com wrote: > I think we should close some of the less controversial > issues on the issues list. These have been discussed on the > mailing list and meetings, and I think we have a rough > consensus on them. > > If you disagree, please tell so within a week or so. > > Issue 2: "Is simultaneous movement of both parties supported?" > > "No; both parties can be mobile, but simultaneous > movement is not supported." > > Issue 9: "Does MOBIKE require RFC2401bis?" > > "IKEv2 requires RFC2401bis, and MOBIKE requires IKEv2." > > Issue 7: "Do we support tunnel mode only, or tunnel mode first and > transport later, or both by same document?" > > "First document will consider only tunnel mode." > > Issue 13: "Does switching from IPv4 to IPv6 or vice versa work? > Presumably only for tunnel mode?" > > "Changing from IPv4 to IPv6 or vice versa should work > for tunnel mode at least." > > Cheers, > Pasi (as issues list maintainer) > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Aug 6 12:30:57 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08287 for ; Fri, 6 Aug 2004 12:30:56 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id DE48DFB4E0; Fri, 6 Aug 2004 12:30:55 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 70BECFB4DB; Fri, 6 Aug 2004 12:30:55 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 08E4FFB4DF; Fri, 6 Aug 2004 12:30:54 -0400 (EDT) Received: from smtp810.mail.sc5.yahoo.com (smtp810.mail.sc5.yahoo.com [66.163.170.80]) by machshav.com (Postfix) with SMTP id 3E945FB4D7 for ; Fri, 6 Aug 2004 12:30:50 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.163.215.163 with login) by smtp810.mail.sc5.yahoo.com with SMTP; 6 Aug 2004 16:30:49 -0000 Message-ID: <00c201c47bd2$be62ef80$6501a8c0@adithya> From: "Mohan Parthasarathy" To: , References: <052E0C61B69C3741AFA5FE88ACC775A6010C3B95@esebe023.ntc.nokia.com> Subject: Re: [Mobike] Closing some less controversial issues Date: Fri, 6 Aug 2004 09:30: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 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 agree to close all this. But i don't understand your conclusion on Issue 9. I am assuming the answer is yes. -mohan ----- Original Message ----- From: To: Sent: Thursday, August 05, 2004 5:13 PM Subject: [Mobike] Closing some less controversial issues I think we should close some of the less controversial issues on the issues list. These have been discussed on the mailing list and meetings, and I think we have a rough consensus on them. If you disagree, please tell so within a week or so. Issue 2: "Is simultaneous movement of both parties supported?" "No; both parties can be mobile, but simultaneous movement is not supported." Issue 9: "Does MOBIKE require RFC2401bis?" "IKEv2 requires RFC2401bis, and MOBIKE requires IKEv2." Issue 7: "Do we support tunnel mode only, or tunnel mode first and transport later, or both by same document?" "First document will consider only tunnel mode." Issue 13: "Does switching from IPv4 to IPv6 or vice versa work? Presumably only for tunnel mode?" "Changing from IPv4 to IPv6 or vice versa should work for tunnel mode at least." Cheers, Pasi (as issues list maintainer) _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Aug 6 12:43:59 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09138 for ; Fri, 6 Aug 2004 12:43:59 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 34A6CFB4E2; Fri, 6 Aug 2004 12:44:01 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8929BFB4DF; Fri, 6 Aug 2004 12:44:00 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BA106FB4E0; Fri, 6 Aug 2004 12:43:59 -0400 (EDT) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by machshav.com (Postfix) with ESMTP id 6422FFB4DB for ; Fri, 6 Aug 2004 12:43:59 -0400 (EDT) Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i76Giqxl020708 for ; Fri, 6 Aug 2004 09:44:52 -0700 (MST) Received: from il27exm03.cig.mot.com (il27exm03.cig.mot.com [10.17.193.4]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i76GhvUI023513 for ; Fri, 6 Aug 2004 11:43:57 -0500 Received: by il27exm03.cig.mot.com with Internet Mail Service (5.5.2657.72) id ; Fri, 6 Aug 2004 11:43:57 -0500 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'mobike@machshav.com'" Date: Fri, 6 Aug 2004 11:43:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Mobike] unsubscribing from mobike list X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 Either the link provided does not work, or I am not accepting the CA properly, although I did accept the certificates, in any case I do not want to go through any installation for any reason. https://www.machshav.com/mailman/options/mobike/madjid.nakhjiri%40motorola.com At any rate could you get me unsubscribed? Thanks, Madjid _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Aug 8 04:16:45 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06717 for ; Sun, 8 Aug 2004 04:16:44 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 2CDF6FB451; Sun, 8 Aug 2004 04:16:44 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2F393FB455; Sun, 8 Aug 2004 04:16:43 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 40F1AFB456; Sun, 8 Aug 2004 04:16:39 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id BC599FB451 for ; Sun, 8 Aug 2004 04:16:36 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 225C689836; Sun, 8 Aug 2004 11:16:12 +0300 (EEST) Message-ID: <4115E13D.5010502@piuha.net> Date: Sun, 08 Aug 2004 11:15:57 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy Subject: Re: [Mobike] Closing some less controversial issues References: <052E0C61B69C3741AFA5FE88ACC775A6010C3B95@esebe023.ntc.nokia.com> <00c201c47bd2$be62ef80$6501a8c0@adithya> In-Reply-To: <00c201c47bd2$be62ef80$6501a8c0@adithya> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net 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 answer is yes. Pasi meant that since IKEv2 requires RFC 2401bis and MOBIKE requires IKEv2, then MOBIKE has to assume RFC 2401bis also... --Jari Mohan Parthasarathy wrote: > I agree to close all this. But i don't understand your conclusion on Issue 9. > I am assuming the answer is yes. > ----- Original Message ----- > Issue 9: "Does MOBIKE require RFC2401bis?" > > "IKEv2 requires RFC2401bis, and MOBIKE requires IKEv2." _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Aug 10 09:34:45 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25728 for ; Tue, 10 Aug 2004 09:34:44 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D7CC7FB4D6; Tue, 10 Aug 2004 09:34:45 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AFC72FB44D; Tue, 10 Aug 2004 09:34:44 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 79346FB458; Tue, 10 Aug 2004 09:34:42 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by machshav.com (Postfix) with ESMTP id 71CD2FB44C for ; Tue, 10 Aug 2004 09:34:41 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7ADYdj28766 for ; Tue, 10 Aug 2004 16:34:39 +0300 (EET DST) X-Scanned: Tue, 10 Aug 2004 16:31:26 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i7ADVQnL019279 for ; Tue, 10 Aug 2004 16:31:26 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00H4nM9z; Tue, 10 Aug 2004 16:31:26 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7ADVPn09013 for ; Tue, 10 Aug 2004 16:31:25 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 Aug 2004 16:31:23 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 Aug 2004 16:31:23 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 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, 10 Aug 2004 16:31:21 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3BA3@esebe023.ntc.nokia.com> Thread-Topic: Preliminary minutes available Thread-Index: AcR+3lLiGZIl35uCQ1qVjJf37yJF7Q== From: To: X-OriginalArrivalTime: 10 Aug 2004 13:31:24.0072 (UTC) FILETIME=[549E5A80:01C47EDE] Subject: [Mobike] Preliminary minutes available X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 combined notes taken by Wassim Haddad, Hannes Tschofenig, Tero Kivinen, and Gabriel Montenegro (big thanks!) http://www.vpnc.org/ietf-mobike/SanDiego-04/ietf60_mobike_minutes.html Please check and correct as appropriate: many of us were=20 either quite tired (especially at the end), or were talking=20 a lot, or both (I confess to the last one :-) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 12 09:05:28 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29462 for ; Thu, 12 Aug 2004 09:05:26 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E9A17FB45B; Thu, 12 Aug 2004 09:05:25 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C5886FB452; Thu, 12 Aug 2004 09:05:24 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9DEA6FB458; Thu, 12 Aug 2004 09:05:22 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id 21E73FB44C for ; Thu, 12 Aug 2004 09:05:21 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7CD5HB24048 for ; Thu, 12 Aug 2004 16:05:18 +0300 (EET DST) X-Scanned: Thu, 12 Aug 2004 16:01:32 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i7CD1WU9005691 for ; Thu, 12 Aug 2004 16:01:32 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 009jiSmr; Thu, 12 Aug 2004 16:01:31 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7CD1In20509 for ; Thu, 12 Aug 2004 16:01:18 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 12 Aug 2004 16:01:11 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 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, 12 Aug 2004 16:01:12 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3BAA@esebe023.ntc.nokia.com> Thread-Topic: New issue 16: No packets from other end? Thread-Index: AcSAbHFToUbUJBTZTGqhmrz4TpAjxg== From: To: X-OriginalArrivalTime: 12 Aug 2004 13:01:12.0016 (UTC) FILETIME=[71600D00:01C4806C] Subject: [Mobike] New issue 16: No packets from other end? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 created a new issue in the issue list: "Can the protocol recover from situations where the only=20 sign of problems is lack of packets from the other end?" (http://www.vpnc.org/ietf-mobike/issues.html) Many people at the WG meeting expressed opinions that this=20 should be handled somehow (in addition to handling e.g.=20 link-down triggers from layer 2, or something similar). So far, I do not remember anyone saying that the protocol does not need to handle this situation. But comments are welcome. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 12 10:29:29 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05335 for ; Thu, 12 Aug 2004 10:29:29 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 2C82DFB4D6; Thu, 12 Aug 2004 10:29:29 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9AD54FB44C; Thu, 12 Aug 2004 10:29:27 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E1C0FFB458; Thu, 12 Aug 2004 10:29:25 -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 B658DFB44C for ; Thu, 12 Aug 2004 10:29:24 -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 i7CETAq13788 for ; Thu, 12 Aug 2004 16:29:10 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i7CETASj065311 for ; Thu, 12 Aug 2004 16:29:10 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200408121429.i7CETASj065311@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobike@machshav.com Date: Thu, 12 Aug 2004 16:29:10 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Subject: [Mobike] transport mode and Mobike X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com I've just submitted a draft about transport mode and Mobike. It should be available soon... As it is in xml it should be easy to modify by anybody (i.e., I can go on holidays now :-). My purpose is to make it a WG item and to publish it asap as a BCP. There should be no blocking normative references even the document doesn't make real sense without IKEv2 and RFC2401bis. Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 12 10:43:38 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06174 for ; Thu, 12 Aug 2004 10:43:37 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 0D3DFFB4D6; Thu, 12 Aug 2004 10:43:39 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 53012FB452; Thu, 12 Aug 2004 10:43:37 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E9A6AFB458; Thu, 12 Aug 2004 10:43:35 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 74586FB44C for ; Thu, 12 Aug 2004 10:43:34 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i7CEhOq17512; Thu, 12 Aug 2004 16:43:24 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i7CEhNSj065447; Thu, 12 Aug 2004 16:43:24 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200408121443.i7CEhNSj065447@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] New issue 16: No packets from other end? In-reply-to: Your message of Thu, 12 Aug 2004 16:01:12 +0300. <052E0C61B69C3741AFA5FE88ACC775A6010C3BAA@esebe023.ntc.nokia.com> Date: Thu, 12 Aug 2004 16:43:23 +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.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: I've created a new issue in the issue list: "Can the protocol recover from situations where the only sign of problems is lack of packets from the other end?" (http://www.vpnc.org/ietf-mobike/issues.html) => note that this issue applies only if we decide that the protocol should handle everything by itself, i.e., there is no generic control of the mobile/multi-homed environment (what should be likely the case for a not-dedicated-to-IPsec box). Regards Francis.Dupont@enst-bretagne.fr PS: the action related to issue 7 is done. IMHO we can stop here the possible interactions between Mobike and transport mode but we'll talk about that when my draft will be available in repositories, i.e., tomorrow or next week? PPS: IMHO it is not a good idea to put everything into mobike tools: we should not re-invent all the movement detection and multi-homing handling. For example SCTP tried and even failed to specify a complete peer dead detection. We should only specify what kind of events or conditions should be reported to the generic control ("lack of packets from the other end" is a good example) and what kind of actions should be proposed to the generic control (tear-down, update, addition of a new peer address, etc), but not the control itself! _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Aug 12 23:36:17 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28756 for ; Thu, 12 Aug 2004 23:36:17 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4F592FB458; Thu, 12 Aug 2004 23:36:18 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9946CFB452; Thu, 12 Aug 2004 23:36:17 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AFFB9FB453; Thu, 12 Aug 2004 23:36:15 -0400 (EDT) Received: from smtp814.mail.sc5.yahoo.com (smtp814.mail.sc5.yahoo.com [66.163.170.84]) by machshav.com (Postfix) with SMTP id 2EA83FB44C for ; Thu, 12 Aug 2004 23:36:15 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.58.101 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 13 Aug 2004 03:36:11 -0000 Message-ID: <005501c480e6$af5b5bd0$6401a8c0@adithya> From: "Mohan Parthasarathy" To: , References: <052E0C61B69C3741AFA5FE88ACC775A6010C3BAA@esebe023.ntc.nokia.com> Subject: Re: [Mobike] New issue 16: No packets from other end? Date: Thu, 12 Aug 2004 20:36:12 -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.4 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 Are we assuming that triggers for these are going to come from outside of mobike or mobike itself will detect such things ? -mohan ----- Original Message ----- From: To: Sent: Thursday, August 12, 2004 6:01 AM Subject: [Mobike] New issue 16: No packets from other end? I've created a new issue in the issue list: "Can the protocol recover from situations where the only sign of problems is lack of packets from the other end?" (http://www.vpnc.org/ietf-mobike/issues.html) Many people at the WG meeting expressed opinions that this should be handled somehow (in addition to handling e.g. link-down triggers from layer 2, or something similar). So far, I do not remember anyone saying that the protocol does not need to handle this situation. But comments are welcome. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Aug 13 01:38:44 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05529 for ; Fri, 13 Aug 2004 01:38:43 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id DD126FB458; Fri, 13 Aug 2004 01:38:43 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BC724FB452; Fri, 13 Aug 2004 01:38:42 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B51CAFB453; Fri, 13 Aug 2004 01:38:40 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id C68C6FB44C for ; Fri, 13 Aug 2004 01:38:39 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 4D55089836; Fri, 13 Aug 2004 08:38:36 +0300 (EEST) Message-ID: <411C53C9.8070007@piuha.net> Date: Fri, 13 Aug 2004 08:38:17 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy Subject: Re: [Mobike] New issue 16: No packets from other end? References: <052E0C61B69C3741AFA5FE88ACC775A6010C3BAA@esebe023.ntc.nokia.com> <005501c480e6$af5b5bd0$6401a8c0@adithya> In-Reply-To: <005501c480e6$af5b5bd0$6401a8c0@adithya> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net 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 Triggering something known locally (interface down etc) needs an external trigger. Lack of packets could be triggered either by external triggers or MOBIKE/IKEv2 itself. I personally prefer the latter, because there would be less reliance on APIs and other protocol layers. --Jari Mohan Parthasarathy wrote: > Are we assuming that triggers for these are going to come from outside of mobike or > mobike itself will detect such things ? > > -mohan > > ----- Original Message ----- > From: > To: > Sent: Thursday, August 12, 2004 6:01 AM > Subject: [Mobike] New issue 16: No packets from other end? > > > I've created a new issue in the issue list: > > "Can the protocol recover from situations where the only > sign of problems is lack of packets from the other end?" > > (http://www.vpnc.org/ietf-mobike/issues.html) > > Many people at the WG meeting expressed opinions that this > should be handled somehow (in addition to handling e.g. > link-down triggers from layer 2, or something similar). > > So far, I do not remember anyone saying that the protocol > does not need to handle this situation. But comments > are welcome. > > Best regards, > Pasi > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Aug 13 04:25:47 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27184 for ; Fri, 13 Aug 2004 04:25:47 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 41AB4FB458; Fri, 13 Aug 2004 04:25:48 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 83138FB44F; Fri, 13 Aug 2004 04:25:47 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 587D0FB452; Fri, 13 Aug 2004 04:25:46 -0400 (EDT) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 99254FB44C for ; Fri, 13 Aug 2004 04:25:44 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i7D8PgYu005382 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 13 Aug 2004 11:25:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i7D8PdqJ005379; Fri, 13 Aug 2004 11:25:39 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16668.31491.219608.28156@fireball.kivinen.iki.fi> Date: Fri, 13 Aug 2004 11:25:39 +0300 From: Tero Kivinen To: jari.arkko@piuha.net Subject: Re: [Mobike] New issue 16: No packets from other end? In-Reply-To: <411C53C9.8070007@piuha.net> References: <052E0C61B69C3741AFA5FE88ACC775A6010C3BAA@esebe023.ntc.nokia.com> <005501c480e6$af5b5bd0$6401a8c0@adithya> <411C53C9.8070007@piuha.net> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 0 min X-Total-Time: 0 min Cc: Pasi.Eronen@nokia.com, Mohan Parthasarathy , mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: > Triggering something known locally (interface down etc) > needs an external trigger. Lack of packets could be triggered > either by external triggers or MOBIKE/IKEv2 itself. I > personally prefer the latter, because there would be > less reliance on APIs and other protocol layers. Modify that MOBIKE/IKEv2 to include also IPsec then I agree... The most common way to get the information is to notice that there is no ESP packets coming in.... -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Aug 13 05:21:38 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29752 for ; Fri, 13 Aug 2004 05:21:37 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4615AFB458; Fri, 13 Aug 2004 05:21:38 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 04626FB44F; Fri, 13 Aug 2004 05:21:36 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D6A87FB452; Fri, 13 Aug 2004 05:21:34 -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 9AB85FB44C for ; Fri, 13 Aug 2004 05:21:33 -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 i7D9LSi18724; Fri, 13 Aug 2004 11:21:28 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i7D9LSSj069003; Fri, 13 Aug 2004 11:21:28 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200408130921.i7D9LSSj069003@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen Subject: Re: [Mobike] New issue 16: No packets from other end? In-reply-to: Your message of Fri, 13 Aug 2004 11:25:39 +0300. <16668.31491.219608.28156@fireball.kivinen.iki.fi> Date: Fri, 13 Aug 2004 11:21:28 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.com, Mohan Parthasarathy , jari.arkko@piuha.net X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: Jari Arkko writes: > Triggering something known locally (interface down etc) > needs an external trigger. Lack of packets could be triggered > either by external triggers or MOBIKE/IKEv2 itself. I > personally prefer the latter, because there would be > less reliance on APIs and other protocol layers. Modify that MOBIKE/IKEv2 to include also IPsec then I agree... The most common way to get the information is to notice that there is no ESP packets coming in.... => IMHO this is a dangerous path to follow because it shall give a monster for the MOBIKE/IKEv2 tool. I understand you are more interested by MOBIKE SGs than by more generic mobile/multi-homed boxes where MOBIKE is only a small part of the whole thing but please don't specialize MOBIKE as some are always trying to specialize IPsec to VPNs. 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 Fri Aug 13 06:09:43 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02670 for ; Fri, 13 Aug 2004 06:09:42 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 756E9FB459; Fri, 13 Aug 2004 06:09:42 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9AABBFB44F; Fri, 13 Aug 2004 06:09:41 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 55202FB452; Fri, 13 Aug 2004 06:09:40 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id 48431FB44C for ; Fri, 13 Aug 2004 06:09:39 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7DA9aB22938; Fri, 13 Aug 2004 13:09:36 +0300 (EET DST) X-Scanned: Fri, 13 Aug 2004 13:07:30 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i7DA7UVu020513; Fri, 13 Aug 2004 13:07:30 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00nlUHMo; Fri, 13 Aug 2004 13:07:29 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7DA7Kn15797; Fri, 13 Aug 2004 13:07:20 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 13 Aug 2004 13:07:16 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 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] New issue 16: No packets from other end? Date: Fri, 13 Aug 2004 13:07:16 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3BBB@esebe023.ntc.nokia.com> Thread-Topic: [Mobike] New issue 16: No packets from other end? Thread-Index: AcSBD29K6WcO32HtTtiykHWUO6PROwADV66g From: To: , X-OriginalArrivalTime: 13 Aug 2004 10:07:16.0871 (UTC) FILETIME=[4FF50970:01C4811D] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 wrote: >=20 > Jari Arkko writes: > > Triggering something known locally (interface down etc) > > needs an external trigger. Lack of packets could be triggered > > either by external triggers or MOBIKE/IKEv2 itself. I > > personally prefer the latter, because there would be > > less reliance on APIs and other protocol layers. >=20 > Modify that MOBIKE/IKEv2 to include also IPsec then I agree... The > most common way to get the information is to notice that there is no > ESP packets coming in.... Do you mean that lack of ESP packets would trigger an IKEv2 informational request and lack of response to that would trigger=20 MOBIKE to change paths, or that lack of ESP packets would directly trigger MOBIKE to change paths? Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Aug 13 06:16:13 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03179 for ; Fri, 13 Aug 2004 06:16:13 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A73D2FB4D7; Fri, 13 Aug 2004 06:16:13 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DDC5CFB44F; Fri, 13 Aug 2004 06:16:09 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 12BD9FB452; Fri, 13 Aug 2004 06:16:09 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 3D0A8FB44C for ; Fri, 13 Aug 2004 06:16:08 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 9F55289810; Fri, 13 Aug 2004 13:16:06 +0300 (EEST) Message-ID: <411C94D4.20605@piuha.net> Date: Fri, 13 Aug 2004 13:15:48 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] New issue 16: No packets from other end? References: <200408130921.i7D9LSSj069003@givry.rennes.enst-bretagne.fr> In-Reply-To: <200408130921.i7D9LSSj069003@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Francis Dupont wrote: > In your previous mail you wrote: > > Jari Arkko writes: > > Triggering something known locally (interface down etc) > > needs an external trigger. Lack of packets could be triggered > > either by external triggers or MOBIKE/IKEv2 itself. I > > personally prefer the latter, because there would be > > less reliance on APIs and other protocol layers. > > Modify that MOBIKE/IKEv2 to include also IPsec then I agree... The > most common way to get the information is to notice that there is no > ESP packets coming in.... > > => IMHO this is a dangerous path to follow because it shall give > a monster for the MOBIKE/IKEv2 tool. I understand you are more interested > by MOBIKE SGs than by more generic mobile/multi-homed boxes where > MOBIKE is only a small part of the whole thing but please don't > specialize MOBIKE as some are always trying to specialize IPsec to VPNs. This is a good point. One way to look at this is to talk about what observations must be supported by a MOBIKE implementation and what observations are optional. For instance, local knowledge could still be allowed even if MOBIKE/IKEv2/IPsec was mandated to deliver observations about problems. Or are you suggesting that local knowledge would be mandatory and 'lack of packets' optional? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Aug 13 06:16:51 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03228 for ; Fri, 13 Aug 2004 06:16:51 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E1EF6FB4D7; Fri, 13 Aug 2004 06:16:52 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C8B2FFB44F; Fri, 13 Aug 2004 06:16:51 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A2FD3FB452; Fri, 13 Aug 2004 06:16:50 -0400 (EDT) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 6DC61FB44C for ; Fri, 13 Aug 2004 06:16:49 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i7DAGgYu006575 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 13 Aug 2004 13:16:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i7DAGgRA006572; Fri, 13 Aug 2004 13:16:42 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16668.38154.92287.211330@fireball.kivinen.iki.fi> Date: Fri, 13 Aug 2004 13:16:42 +0300 From: Tero Kivinen To: Francis Dupont Subject: Re: [Mobike] New issue 16: No packets from other end? In-Reply-To: <200408130921.i7D9LSSj069003@givry.rennes.enst-bretagne.fr> References: <16668.31491.219608.28156@fireball.kivinen.iki.fi> <200408130921.i7D9LSSj069003@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: Pasi.Eronen@nokia.com, jari.arkko@piuha.net, Mohan Parthasarathy , mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Francis Dupont writes: > => IMHO this is a dangerous path to follow because it shall give > a monster for the MOBIKE/IKEv2 tool. I understand you are more interested > by MOBIKE SGs than by more generic mobile/multi-homed boxes where > MOBIKE is only a small part of the whole thing but please don't > specialize MOBIKE as some are always trying to specialize IPsec to VPNs. The MOBIKE/IKEv2 will be used along with IPsec, I do not even consider and option that we would create MOBIKE to be used without IPsec. Most of the IPsec implementations already check out the flow if ESP packets, and can start actions if they are missing for too long (for example IKEv1 you used that for crash recovery and dead peer detection). Why we cannot allow that same mechanism to be used in the MOBIKE? I don't think we want to mandate that thing, but we do want to say that MOBIKE implementations are allowed to consider the connection to be up if there is ESP packets coming from the other end. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Aug 13 06:22:24 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03781 for ; Fri, 13 Aug 2004 06:22:23 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7A86AFB459; Fri, 13 Aug 2004 06:22:25 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 90289FB44F; Fri, 13 Aug 2004 06:22:24 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D17E5FB452; Fri, 13 Aug 2004 06:22:22 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id B21ABFB44C for ; Fri, 13 Aug 2004 06:22:21 -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 i7DAM4D26538; Fri, 13 Aug 2004 12:22:05 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i7DAM4Sj069331; Fri, 13 Aug 2004 12:22:04 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200408131022.i7DAM4Sj069331@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] New issue 16: No packets from other end? In-reply-to: Your message of Fri, 13 Aug 2004 13:07:16 +0300. <052E0C61B69C3741AFA5FE88ACC775A6010C3BBB@esebe023.ntc.nokia.com> Date: Fri, 13 Aug 2004 12:22:04 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, kivinen@iki.fi X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: Do you mean that lack of ESP packets would trigger an IKEv2 informational request and lack of response to that would trigger MOBIKE to change paths, or that lack of ESP packets would directly trigger MOBIKE to change paths? => this is exactly the kind of questions we should avoid: the lack of ESP packets should be reported (not by MOBIKE but by IPsec itself) to the control which can ask to MOBIKE to trigger an IKEv2 informational request or to change paths. The control mechanism can be inside or outside the MOBIKE tool but should NOT be defined by MOBIKE. As a Mobile IPv6 implementor I can say that handoff detection is not so easy and I definitively don't want to get it in my IKE daemon code or in MOBIKE specs. Just ask Jari... 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 Fri Aug 13 07:03:14 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06072 for ; Fri, 13 Aug 2004 07:03:13 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id BF239FB453; Fri, 13 Aug 2004 07:03:15 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 96DF9FB44F; Fri, 13 Aug 2004 07:03:14 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D5D07FB452; Fri, 13 Aug 2004 07:03:13 -0400 (EDT) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 8FA98FB44C for ; Fri, 13 Aug 2004 07:03:12 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i7DB3AYu007098 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 13 Aug 2004 14:03:10 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i7DB39eJ007095; Fri, 13 Aug 2004 14:03:09 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16668.40941.449270.46458@fireball.kivinen.iki.fi> Date: Fri, 13 Aug 2004 14:03:09 +0300 From: Tero Kivinen To: Subject: RE: [Mobike] New issue 16: No packets from other end? In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C3BBB@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A6010C3BBB@esebe023.ntc.nokia.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > Do you mean that lack of ESP packets would trigger an IKEv2 > informational request and lack of response to that would trigger > MOBIKE to change paths, or that lack of ESP packets > would directly trigger MOBIKE to change paths? The first. I.e. we need to still do the dead peer detection to verify if it just so that the other end is simply silent. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Aug 13 07:14:26 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06570 for ; Fri, 13 Aug 2004 07:14:26 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7CE9BFB458; Fri, 13 Aug 2004 07:14:26 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 00D6CFB44C; Fri, 13 Aug 2004 07:14:26 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1C757FB452; Fri, 13 Aug 2004 07:14:24 -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 E8187FB44C for ; Fri, 13 Aug 2004 07:14:22 -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 i7DBEED30606; Fri, 13 Aug 2004 13:14: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.12.3/8.12.3) with ESMTP id i7DBEESj069487; Fri, 13 Aug 2004 13:14:14 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200408131114.i7DBEESj069487@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] New issue 16: No packets from other end? In-reply-to: Your message of Fri, 13 Aug 2004 13:15:48 +0300. <411C94D4.20605@piuha.net> Date: Fri, 13 Aug 2004 13:14:14 +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.4 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: > => IMHO this is a dangerous path to follow because it shall give > a monster for the MOBIKE/IKEv2 tool. I understand you are more interested > by MOBIKE SGs than by more generic mobile/multi-homed boxes where > MOBIKE is only a small part of the whole thing but please don't > specialize MOBIKE as some are always trying to specialize IPsec to VPNs. This is a good point. One way to look at this is to talk about what observations must be supported by a MOBIKE implementation and what observations are optional. For instance, local knowledge => I don't know what you call "local knowledge". could still be allowed even if MOBIKE/IKEv2/IPsec was => MOBIKE should not specify anything about IPsec itself, i.e., it should be a hint in the design document only. mandated to deliver observations about problems. Or are you suggesting that local knowledge would be mandatory and 'lack of packets' optional? 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 Fri Aug 13 07:18:59 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06742 for ; Fri, 13 Aug 2004 07:18:58 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B0F20FB453; Fri, 13 Aug 2004 07:18:58 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BDE34FB44F; Fri, 13 Aug 2004 07:18:57 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7F8B1FB452; Fri, 13 Aug 2004 07:18:56 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 28D06FB44C for ; Fri, 13 Aug 2004 07:18:55 -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 i7DBIjD30989; Fri, 13 Aug 2004 13:18:45 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i7DBIjSj069524; Fri, 13 Aug 2004 13:18:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200408131118.i7DBIjSj069524@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen Subject: Re: [Mobike] New issue 16: No packets from other end? In-reply-to: Your message of Fri, 13 Aug 2004 13:16:42 +0300. <16668.38154.92287.211330@fireball.kivinen.iki.fi> Date: Fri, 13 Aug 2004 13:18:45 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: Pasi.Eronen@nokia.com, jari.arkko@piuha.net, Mohan Parthasarathy , mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: Francis Dupont writes: > => IMHO this is a dangerous path to follow because it shall give > a monster for the MOBIKE/IKEv2 tool. I understand you are more interested > by MOBIKE SGs than by more generic mobile/multi-homed boxes where > MOBIKE is only a small part of the whole thing but please don't > specialize MOBIKE as some are always trying to specialize IPsec to VPNs. The MOBIKE/IKEv2 will be used along with IPsec, I do not even consider and option that we would create MOBIKE to be used without IPsec. Most of the IPsec implementations already check out the flow if ESP packets, and can start actions if they are missing for too long (for example IKEv1 you used that for crash recovery and dead peer detection). Why we cannot allow that same mechanism to be used in the MOBIKE? I don't think we want to mandate that thing, but we do want to say that MOBIKE implementations are allowed to consider the connection to be up if there is ESP packets coming from the other end. => I believe you missed my point: I have no concern about the mechanism itself but I have a concern about where it is implemented and as a side effect how it is specified. 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 Fri Aug 13 10:43:01 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19821 for ; Fri, 13 Aug 2004 10:43:00 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 896CAFB458; Fri, 13 Aug 2004 10:42:56 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4B902FB44F; Fri, 13 Aug 2004 10:42:52 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 03790FB452; Fri, 13 Aug 2004 10:42:50 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id E16B2FB44C for ; Fri, 13 Aug 2004 10:42:48 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7DEglB17961 for ; Fri, 13 Aug 2004 17:42:47 +0300 (EET DST) X-Scanned: Fri, 13 Aug 2004 17:41:17 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i7DEfHMG013316 for ; Fri, 13 Aug 2004 17:41:17 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00G6Ov7y; Fri, 13 Aug 2004 17:41:15 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7DEfDn27750 for ; Fri, 13 Aug 2004 17:41:13 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 13 Aug 2004 09:39:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] New issue 16: No packets from other end? Date: Fri, 13 Aug 2004 10:39:43 -0400 Message-ID: Thread-Topic: New issue 16: No packets from other end? Thread-Index: AcSAbHFToUbUJBTZTGqhmrz4TpAjxgA1RhFA From: To: , X-OriginalArrivalTime: 13 Aug 2004 14:39:45.0364 (UTC) FILETIME=[606B1940:01C48143] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 needed some clarifications from MOBIKE veterans, before expressing=20 an opinion: What is the "other end" here? The mobile host? or the multihoming SGW? Who initiates the MOBIKE protocol? I would guess: (1) a mobile host after the move, needs to notify the remote SGW of its new address. (2) a multihoming SGW, upon detecting that one of its interfaces (which was used to contact the mobile host) is down and it needs=20 to notify the mobile host of its new interface address to be used. Are there any other scenarios of how MOBIKE can be initiated? When would we use the information that there is "lack of packets from the other = end", to initiate the MOBIKE protocol? Thanks, Atul > -----Original Message----- > From: mobike-bounces@machshav.com=20 > [mailto:mobike-bounces@machshav.com]On > Behalf Of ext=20 > Sent: Thursday, August 12, 2004 9:01 AM > To: mobike@machshav.com > Subject: [Mobike] New issue 16: No packets from other end? >=20 >=20 > I've created a new issue in the issue list: >=20 > "Can the protocol recover from situations where the only=20 > sign of problems is lack of packets from the other end?" >=20 > (http://www.vpnc.org/ietf-mobike/issues.html) >=20 > Many people at the WG meeting expressed opinions that this=20 > should be handled somehow (in addition to handling e.g.=20 > link-down triggers from layer 2, or something similar). >=20 > So far, I do not remember anyone saying that the protocol > does not need to handle this situation. But comments > are welcome. >=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 Fri Aug 13 16:31:31 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16299 for ; Fri, 13 Aug 2004 16:31:30 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A0748FB459; Fri, 13 Aug 2004 16:31:31 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2D259FB452; Fri, 13 Aug 2004 16:31:31 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9DF35FB453; Fri, 13 Aug 2004 16:31:29 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by machshav.com (Postfix) with ESMTP id DDFADFB44C for ; Fri, 13 Aug 2004 16:31:28 -0400 (EDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i7DKUtm01275; Fri, 13 Aug 2004 13:30:55 -0700 X-mProtect: <200408132030> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDJU8wY; Fri, 13 Aug 2004 13:30:54 PDT Message-ID: <411D2703.2050502@iprg.nokia.com> Date: Fri, 13 Aug 2004 13:39:31 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040430 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Mobike] New issue 16: No packets from other end? References: <052E0C61B69C3741AFA5FE88ACC775A6010C3BBB@esebe023.ntc.nokia.com> <16668.40941.449270.46458@fireball.kivinen.iki.fi> In-Reply-To: <16668.40941.449270.46458@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit what is "lack of ESP packets"? for how long do you wait? isnt this dependent on the application? do you want to trigger an IKEv2 informational request everytime the application "pauses"? MOBIKE shouldnt decide. I agree with Francis, that the "lack of ESP packets" should be handled elsewhere in the stack (and not in MOBIKE). Vijay Tero Kivinen wrote: > Pasi.Eronen@nokia.com writes: > >>Do you mean that lack of ESP packets would trigger an IKEv2 >>informational request and lack of response to that would trigger >>MOBIKE to change paths, or that lack of ESP packets >>would directly trigger MOBIKE to change paths? > > > The first. I.e. we need to still do the dead peer detection to verify > if it just so that the other end is simply silent. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Aug 15 10:39:41 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00480 for ; Sun, 15 Aug 2004 10:39:41 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 6EDADFB455; Sun, 15 Aug 2004 10:39:42 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2A914FB451; Sun, 15 Aug 2004 10:39:41 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0B50FFB452; Sun, 15 Aug 2004 10:39:40 -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 CFF2DFB44C for ; Sun, 15 Aug 2004 10:39:38 -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 i7FEdW216347; Sun, 15 Aug 2004 16:39:32 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i7FEdWSj077946; Sun, 15 Aug 2004 16:39:32 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200408151439.i7FEdWSj077946@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Preliminary minutes available In-reply-to: Your message of Tue, 10 Aug 2004 16:31:21 +0300. <052E0C61B69C3741AFA5FE88ACC775A6010C3BA3@esebe023.ntc.nokia.com> Date: Sun, 15 Aug 2004 16:39:32 +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.4 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: => near the end, at "Scope of SA changes" Francis: RFC 3554 (IPsec for SCTP) is very unclear about multiple addresses in SPD entries. => s/SPD/SADB/ (to be more accurate the issue is about multiple simultaneous outer addresses of tunnel mode IPsec SAs in the outgoing code: - RFC 2041bis and IKEv2 supports multiple simultaneous addresses in traffic selectors - successive outer addresses of tunnel mode IPsec SAs are the core goal of Mobike - transport mode IPsec SAs are out of the immediate scope of Mobike - cf some message exchanges with Steve Kent, multiple simultaneous out addresses of tunnel mode IPsec SAs in the incomming code are not an issue and are handled by RFC 2041bis.) Thanks Francis.Dupont@enst-bretagne.fr PS: BTW I sent just after the session a mail explaining what I call the SCTP model of multi-homing. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Aug 15 14:25:18 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11676 for ; Sun, 15 Aug 2004 14:25:17 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 70740FB455; Sun, 15 Aug 2004 14:25:18 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C2944FB451; Sun, 15 Aug 2004 14:25:17 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 53F2CFB452; Sun, 15 Aug 2004 14:25:16 -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 F0200FB44C for ; Sun, 15 Aug 2004 14:25:14 -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 i7FIP0232020; Sun, 15 Aug 2004 20:25:01 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i7FIP0Sj080247; Sun, 15 Aug 2004 20:25:00 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200408151825.i7FIP0Sj080247@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Atul.Sharma@nokia.com Subject: Re: [Mobike] New issue 16: No packets from other end? In-reply-to: Your message of Fri, 13 Aug 2004 10:39:43 EDT. Date: Sun, 15 Aug 2004 20:25:00 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 needed some clarifications from MOBIKE veterans, before expressing an opinion: What is the "other end" here? => you are at one side, the other end is the other. The mobile host? or the multihoming SGW? => you are narrowing the scope of MOBIKE without good reasons. MOBIKE supports one or both ends mobile and/or multi-homed. Who initiates the MOBIKE protocol? I would guess: (1) a mobile host after the move, needs to notify the remote SGW of its new address. (2) a multihoming SGW, upon detecting that one of its interfaces (which was used to contact the mobile host) is down and it needs to notify the mobile host of its new interface address to be used. Are there any other scenarios of how MOBIKE can be initiated? => many, for instance two multi-homed hosts, two multi-homed SGWs, a mobile SGW, a multi-homed host, etc. When would we use the information that there is "lack of packets from the other end", to initiate the MOBIKE protocol? => IMHO this is not in the scope of the MOBIKE protocol so I can't give an answer. But if this end knows alternate peer addresses of the other end, obviously to try them seems a good idea... Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Aug 15 20:18:12 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28185 for ; Sun, 15 Aug 2004 20:18:12 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id F3010FB457; Sun, 15 Aug 2004 20:18:11 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 363B9FB451; Sun, 15 Aug 2004 20:18:09 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 00DE9FB452; Sun, 15 Aug 2004 20:18:07 -0400 (EDT) Received: from smtp811.mail.sc5.yahoo.com (smtp811.mail.sc5.yahoo.com [66.163.170.81]) by machshav.com (Postfix) with SMTP id 50AD3FB44C for ; Sun, 15 Aug 2004 20:18:07 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.57.54 with login) by smtp811.mail.sc5.yahoo.com with SMTP; 16 Aug 2004 00:18:04 -0000 Message-ID: <00c501c48326$7f8ab850$6401a8c0@adithya> From: "Mohan Parthasarathy" To: References: <052E0C61B69C3741AFA5FE88ACC775A6010C3BAA@esebe023.ntc.nokia.com> <005501c480e6$af5b5bd0$6401a8c0@adithya> <411C53C9.8070007@piuha.net> Subject: Re: [Mobike] New issue 16: No packets from other end? Date: Sun, 15 Aug 2004 17:18:03 -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.4 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 > > Triggering something known locally (interface down etc) > needs an external trigger. Lack of packets could be triggered > either by external triggers or MOBIKE/IKEv2 itself. I > personally prefer the latter, because there would be > less reliance on APIs and other protocol layers. > There are already other working groups like DNA, multi6 etc. that would come up with mechanisms to detect link changes, path changes etc. MOBIKE could just use that. But your concern is how will MOBIKE interface with other modules to learn the information ? i.e., if there is no mechanism to learn about link up/link down in the system or MIP4/MIP6 is not implemented in the node, what should MOBIKE do ? Also, what does it mean if there are other mechanisms, should MOBIKE use that or invent something new or take into consideration both ? It would be simpler if we just document what sort of triggers ( a few examples) are needed for MOBIKE to work. Whether it is implemented as part of MOBIKE or outside of MOBIKE is an implementation detail. I guess this is what Francis is getting at. If so, i agree. -mohan > --Jari > > Mohan Parthasarathy wrote: > > Are we assuming that triggers for these are going to come from outside of mobike or > > mobike itself will detect such things ? > > > > -mohan > > > > ----- Original Message ----- > > From: > > To: > > Sent: Thursday, August 12, 2004 6:01 AM > > Subject: [Mobike] New issue 16: No packets from other end? > > > > > > I've created a new issue in the issue list: > > > > "Can the protocol recover from situations where the only > > sign of problems is lack of packets from the other end?" > > > > (http://www.vpnc.org/ietf-mobike/issues.html) > > > > Many people at the WG meeting expressed opinions that this > > should be handled somehow (in addition to handling e.g. > > link-down triggers from layer 2, or something similar). > > > > So far, I do not remember anyone saying that the protocol > > does not need to handle this situation. But comments > > are welcome. > > > > Best regards, > > Pasi > > _______________________________________________ > > Mobike mailing list > > Mobike@machshav.com > > https://www.machshav.com/mailman/listinfo.cgi/mobike > > _______________________________________________ > > Mobike mailing list > > Mobike@machshav.com > > https://www.machshav.com/mailman/listinfo.cgi/mobike > > > > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Aug 16 07:27:28 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27226 for ; Mon, 16 Aug 2004 07:27:28 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 0F296FB44C; Mon, 16 Aug 2004 07:27:27 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 006F2FB44D; Mon, 16 Aug 2004 07:27:25 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5F96DFB452; Mon, 16 Aug 2004 07:27:22 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by machshav.com (Postfix) with ESMTP id 07E7BFB44C for ; Mon, 16 Aug 2004 07:27:21 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7GBRG321265 for ; Mon, 16 Aug 2004 14:27:16 +0300 (EET DST) X-Scanned: Mon, 16 Aug 2004 14:26:14 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7GBQEMM031719 for ; Mon, 16 Aug 2004 14:26:14 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00UXhVj7; Mon, 16 Aug 2004 14:24:39 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7GBOYu22450 for ; Mon, 16 Aug 2004 14:24:34 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 16 Aug 2004 14:24:35 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 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] New issue 16: No packets from other end? Date: Mon, 16 Aug 2004 14:24:34 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C164@esebe023.ntc.nokia.com> Thread-Topic: [Mobike] New issue 16: No packets from other end? Thread-Index: AcSBdIHs6reGUqm0TQGPn/7bJWTe0wCC/eOw From: To: , X-OriginalArrivalTime: 16 Aug 2004 11:24:35.0123 (UTC) FILETIME=[9BCF6030:01C48383] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Hi Vijay, IKEv2 already triggers an informational exchange if=20 there's no incoming ESP traffic for some time (how long you wait is not specified). We're not changing that part, I hope. The main issue for MOBIKE is what to do if we don't receive a reply=20 to the informational request (even after some number=20 of retransmissions). If we don't do anything, the SAs will be closed. In my=20 opinion, that's not acceptable. The lack of replies=20 should trigger changing to some other addresses (if a=20 working path is available). We don't need to specify exactly how this works, and as Francis pointed out, there are many complex issues in e.g. handoff=20 decisions that we don't want to put in MOBIKE specs. What we IMHO do need to specify are the parts required for=20 interoperability, like what is sent/received to/from the other=20 node, and some parts of how those messages are processed.=20 I think this should be specified in the MOBIKE spec; that is, we should not assume that there is some other unspecified protocol=20 (in addition to IKEv2 and ESP/AH) running between the parties. Best regards, Pasi > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: Friday, August 13, 2004 11:40 PM > To: Tero Kivinen > Cc: Eronen Pasi (Nokia-NRC/Helsinki); mobike@machshav.com > Subject: Re: [Mobike] New issue 16: No packets from other end? >=20 > what is "lack of ESP packets"? for how long do you wait? > isnt this dependent on the application? >=20 > do you want to trigger an IKEv2 informational request everytime > the application "pauses"? >=20 > MOBIKE shouldnt decide. I agree with Francis, that the "lack > of ESP packets" should be handled elsewhere in the stack (and > not in MOBIKE). >=20 > Vijay >=20 > Tero Kivinen wrote: > > Pasi.Eronen@nokia.com writes: > >=20 > >>Do you mean that lack of ESP packets would trigger an IKEv2 > >>informational request and lack of response to that would trigger=20 > >>MOBIKE to change paths, or that lack of ESP packets > >>would directly trigger MOBIKE to change paths? > >=20 > >=20 > > The first. I.e. we need to still do the dead peer detection=20 > > to verify if it just so that the other end is simply silent.=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Aug 16 07:42:57 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27903 for ; Mon, 16 Aug 2004 07:42:57 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7FD9EFB44D; Mon, 16 Aug 2004 07:42:56 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 69580FB452; Mon, 16 Aug 2004 07:42:54 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9D04FFB453; Mon, 16 Aug 2004 07:42:52 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id DC2D0FB44D for ; Mon, 16 Aug 2004 07:42:50 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7GBgnB28993 for ; Mon, 16 Aug 2004 14:42:49 +0300 (EET DST) X-Scanned: Mon, 16 Aug 2004 14:39:26 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i7GBdQns000701 for ; Mon, 16 Aug 2004 14:39:26 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00zyd0Iv; Mon, 16 Aug 2004 14:39:23 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7GBdLn14382 for ; Mon, 16 Aug 2004 14:39:21 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 16 Aug 2004 14:38:17 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 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] New issue 16: No packets from other end? Date: Mon, 16 Aug 2004 14:38:14 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C165@esebe023.ntc.nokia.com> Thread-Topic: New issue 16: No packets from other end? Thread-Index: AcSAbHFToUbUJBTZTGqhmrz4TpAjxgA1RhFAAJCTLqA= From: To: , X-OriginalArrivalTime: 16 Aug 2004 11:38:17.0372 (UTC) FILETIME=[85E89DC0:01C48385] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Hi Atul, The other end could be a mobile host or SGW, depending=20 on your point of view. The issue is what to do if we have not received a "link=20 down" signal from layer 2 (or somewhere), but we don't=20 get any responses (to IKEv2 requests) from the other end=20 either. In this situation, should we just close the=20 connection, or "somehow" trigger MOBIKE to change to=20 some other address(es)?=20 (Some details of the "somehow" part will be beyond=20 the scope of the MOBIKE specification, but probably =20 something needs to be said to ensure interoperability.) Best regards, Pasi > -----Original Message----- > From: Atul.Sharma@nokia.com > Sent: Friday, August 13, 2004 5:40 PM > To: Eronen Pasi (Nokia-NRC/Helsinki); mobike@machshav.com > Subject: RE: [Mobike] New issue 16: No packets from other end? >=20 > I needed some clarifications from MOBIKE veterans, before=20 > expressing an opinion: >=20 > What is the "other end" here? The mobile host? or the=20 > multihoming SGW? >=20 > Who initiates the MOBIKE protocol? I would guess: > (1) a mobile host after the move, needs to notify the=20 > remote SGW of its new address. > (2) a multihoming SGW, upon detecting that one of its=20 > interfaces (which was used to contact the mobile host) > is down and it needs to notify the mobile host of its > new interface address to be used. >=20 > Are there any other scenarios of how MOBIKE can be initiated?=20 > When would we use the information that there is "lack of packets=20 > from the other end", to initiate the MOBIKE protocol? >=20 > Thanks, > Atul >=20 > > -----Original Message----- > > From: mobike-bounces@machshav.com=20 > > [mailto:mobike-bounces@machshav.com]On > > Behalf Of ext=20 > > Sent: Thursday, August 12, 2004 9:01 AM > > To: mobike@machshav.com > > Subject: [Mobike] New issue 16: No packets from other end? > >=20 > >=20 > > I've created a new issue in the issue list: > >=20 > > "Can the protocol recover from situations where the only=20 > > sign of problems is lack of packets from the other end?" > >=20 > > (http://www.vpnc.org/ietf-mobike/issues.html) > >=20 > > Many people at the WG meeting expressed opinions that this=20 > > should be handled somehow (in addition to handling e.g.=20 > > link-down triggers from layer 2, or something similar). > >=20 > > So far, I do not remember anyone saying that the protocol > > does not need to handle this situation. But comments > > are welcome. > >=20 > > Best regards, > > Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Aug 16 08:37:58 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00845 for ; Mon, 16 Aug 2004 08:37:57 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id BC674FB4D5; Mon, 16 Aug 2004 08:37:57 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9C8ABFB453; Mon, 16 Aug 2004 08:37:55 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7B291FB455; Mon, 16 Aug 2004 08:37:53 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id 50704FB452 for ; Mon, 16 Aug 2004 08:37:52 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7GCbov29696 for ; Mon, 16 Aug 2004 15:37:50 +0300 (EET DST) X-Scanned: Mon, 16 Aug 2004 15:33:30 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7GCXUI4019973 for ; Mon, 16 Aug 2004 15:33:30 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 001XazXN; Mon, 16 Aug 2004 15:33:29 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7GCXRn12567 for ; Mon, 16 Aug 2004 15:33:27 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 16 Aug 2004 07:33:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] New issue 16: No packets from other end? Date: Mon, 16 Aug 2004 08:33:18 -0400 Message-ID: Thread-Topic: New issue 16: No packets from other end? Thread-Index: AcSAbHFToUbUJBTZTGqhmrz4TpAjxgA1RhFAAJCTLqAAAhtxEA== From: To: , X-OriginalArrivalTime: 16 Aug 2004 12:33:21.0044 (UTC) FILETIME=[370CF540:01C4838D] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 Passi, ....for the explanation. I think in that case you are trying to solve network failure recovery inside the MOBIKE protocol. I think Francis and someone else on the list commented such functionality should probably be outside the MOBIKE protocol specification. MOBIKE's mandate, in my opinion, is to notify the "other end" of the change in address or plurality of addresses due to=20 mobility or multihoming using IKE mechanism (information=20 exchange). Trying to solve a general problem within MOBIKE, may complicate MOBIKE protocol unnecessarily. Network failure recovery (without notifications) should be solved elsewhere IMHO. Best, Atul > -----Original Message----- > From: Eronen Pasi (Nokia-NRC/Helsinki)=20 > Sent: Monday, August 16, 2004 7:38 AM > To: Sharma Atul (Nokia-ES/Boston); mobike@machshav.com > Subject: RE: [Mobike] New issue 16: No packets from other end? >=20 >=20 >=20 > Hi Atul, >=20 > The other end could be a mobile host or SGW, depending=20 > on your point of view. >=20 > The issue is what to do if we have not received a "link=20 > down" signal from layer 2 (or somewhere), but we don't=20 > get any responses (to IKEv2 requests) from the other end=20 > either. In this situation, should we just close the=20 > connection, or "somehow" trigger MOBIKE to change to=20 > some other address(es)?=20 >=20 > (Some details of the "somehow" part will be beyond=20 > the scope of the MOBIKE specification, but probably =20 > something needs to be said to ensure interoperability.) >=20 > Best regards, > Pasi >=20 > > -----Original Message----- > > From: Atul.Sharma@nokia.com > > Sent: Friday, August 13, 2004 5:40 PM > > To: Eronen Pasi (Nokia-NRC/Helsinki); mobike@machshav.com > > Subject: RE: [Mobike] New issue 16: No packets from other end? > >=20 > > I needed some clarifications from MOBIKE veterans, before=20 > > expressing an opinion: > >=20 > > What is the "other end" here? The mobile host? or the=20 > > multihoming SGW? > >=20 > > Who initiates the MOBIKE protocol? I would guess: > > (1) a mobile host after the move, needs to notify the=20 > > remote SGW of its new address. > > (2) a multihoming SGW, upon detecting that one of its=20 > > interfaces (which was used to contact the mobile host) > > is down and it needs to notify the mobile host of its > > new interface address to be used. > >=20 > > Are there any other scenarios of how MOBIKE can be initiated?=20 > > When would we use the information that there is "lack of packets=20 > > from the other end", to initiate the MOBIKE protocol? > >=20 > > Thanks, > > Atul > >=20 > > > -----Original Message----- > > > From: mobike-bounces@machshav.com=20 > > > [mailto:mobike-bounces@machshav.com]On > > > Behalf Of ext=20 > > > Sent: Thursday, August 12, 2004 9:01 AM > > > To: mobike@machshav.com > > > Subject: [Mobike] New issue 16: No packets from other end? > > >=20 > > >=20 > > > I've created a new issue in the issue list: > > >=20 > > > "Can the protocol recover from situations where the only=20 > > > sign of problems is lack of packets from the other end?" > > >=20 > > > (http://www.vpnc.org/ietf-mobike/issues.html) > > >=20 > > > Many people at the WG meeting expressed opinions that this=20 > > > should be handled somehow (in addition to handling e.g.=20 > > > link-down triggers from layer 2, or something similar). > > >=20 > > > So far, I do not remember anyone saying that the protocol > > > does not need to handle this situation. But comments > > > are welcome. > > >=20 > > > Best regards, > > > Pasi >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Aug 16 08:53:26 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01558 for ; Mon, 16 Aug 2004 08:53:25 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 41611FB45B; Mon, 16 Aug 2004 08:53:26 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3870AFB453; Mon, 16 Aug 2004 08:53:25 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0501EFB455; Mon, 16 Aug 2004 08:53:24 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id CE47BFB452 for ; Mon, 16 Aug 2004 08:53:22 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7GCr4v20428; Mon, 16 Aug 2004 15:53:04 +0300 (EET DST) X-Scanned: Mon, 16 Aug 2004 15:50:51 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7GCoptQ011956; Mon, 16 Aug 2004 15:50:51 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00xqlHob; Mon, 16 Aug 2004 15:50:49 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7GCogn29697; Mon, 16 Aug 2004 15:50:42 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 16 Aug 2004 07:50:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] New issue 16: No packets from other end? Date: Mon, 16 Aug 2004 08:50:35 -0400 Message-ID: Thread-Topic: [Mobike] New issue 16: No packets from other end? Thread-Index: AcSC9UzYgfCL34FCRma68y4xmiB4IAAmHG/A From: To: X-OriginalArrivalTime: 16 Aug 2004 12:50:38.0715 (UTC) FILETIME=[A18CFCB0:01C4838F] Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 Francis, ....for the answers. It does clarify the questions raised in the original mail. I had some follow up comments/doubts, though: Plurality of addresses can be communicated statically, but change of address(es) need to be communicated dynamically, unless the change is to a predetermined address(es) only. In the dynamic scenario, a mobile host detecting a move or a multihomed SGW detecting a network interface failure shall notify the other end of the change. Are there any other "dynamic" scenarios? In the static or predetermined case, the end aware of the change is required to notify the change to the other end? Or it is not mandatory and the other end will try different prior known addresses? We have to be clear in specifying what is a MUST and what is an option, to guarantee interoperability. Do we have that already in the protocol? Best, Atul > -----Original Message----- > From: Francis.Dupont@enst-bretagne.fr > [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Sunday, August 15, 2004 2:25 PM > To: Sharma Atul (Nokia-ES/Boston) > Cc: Eronen Pasi (Nokia-NRC/Helsinki); mobike@machshav.com > Subject: Re: [Mobike] New issue 16: No packets from other end?=20 >=20 >=20 > In your previous mail you wrote: >=20 > I needed some clarifications from MOBIKE veterans, before=20 > expressing=20 > an opinion: > =20 > What is the "other end" here? >=20 > =3D> you are at one side, the other end is the other. >=20 > The mobile host? or the multihoming SGW? >=20 > =3D> you are narrowing the scope of MOBIKE without good reasons. > MOBIKE supports one or both ends mobile and/or multi-homed. > =20 > Who initiates the MOBIKE protocol? I would guess: > (1) a mobile host after the move, needs to notify the=20 > remote SGW of > its new address. > (2) a multihoming SGW, upon detecting that one of its interfaces > (which was used to contact the mobile host) is down=20 > and it needs=20 > to notify the mobile host of its new interface=20 > address to be used. > =20 > Are there any other scenarios of how MOBIKE can be initiated? >=20 > =3D> many, for instance two multi-homed hosts, two multi-homed SGWs, > a mobile SGW, a multi-homed host, etc. >=20 > When would > we use the information that there is "lack of packets from=20 > the other end", > to initiate the MOBIKE protocol? > =20 > =3D> IMHO this is not in the scope of the MOBIKE protocol so I=20 > can't give > an answer. But if this end knows alternate peer addresses of=20 > the other end, > obviously to try them seems a good idea... >=20 > Regards >=20 > Francis.Dupont@enst-bretagne.fr >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Aug 16 09:52:53 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04434 for ; Mon, 16 Aug 2004 09:52:52 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id AB911FB458; Mon, 16 Aug 2004 09:52:52 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F0962FB452; Mon, 16 Aug 2004 09:52:49 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BAD6EFB453; Mon, 16 Aug 2004 09:52:48 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id 7F8FCFB451 for ; Mon, 16 Aug 2004 09:52:47 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7GDqjB27768 for ; Mon, 16 Aug 2004 16:52:45 +0300 (EET DST) X-Scanned: Mon, 16 Aug 2004 16:50:24 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7GDoOjW029754 for ; Mon, 16 Aug 2004 16:50:24 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00YPfrLU; Mon, 16 Aug 2004 16:50:21 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7GDoLu09529 for ; Mon, 16 Aug 2004 16:50:21 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 16 Aug 2004 16:41:53 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 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] New issue 16: No packets from other end? Date: Mon, 16 Aug 2004 16:41:53 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C167@esebe023.ntc.nokia.com> Thread-Topic: New issue 16: No packets from other end? Thread-Index: AcSAbHFToUbUJBTZTGqhmrz4TpAjxgA1RhFAAJCTLqAAAhtxEAABqaVw From: To: , X-OriginalArrivalTime: 16 Aug 2004 13:41:53.0985 (UTC) FILETIME=[CA8DF310:01C48396] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Hi Atul, My impression was that the main reason we are adding=20 multihoming support to IKEv2 is to recover from failures=20 (since load balancing is explicitly beyond the scope).=20 I think that restricting ourselves to those network failures=20 where we get an explicit "link down" signal will seriously=20 limit the usefulness of the protocol's multihoming features. (For instance, the multihoming features of SCTP don't have that kind of restriction.) Best regards, Pasi > -----Original Message----- > From: atul.sharma@nokia.com > Sent: Monday, August 16, 2004 3:33 PM > To: Eronen Pasi (Nokia-NRC/Helsinki); mobike@machshav.com > Subject: RE: [Mobike] New issue 16: No packets from other end? >=20 >=20 > Thanks Passi, >=20 > ....for the explanation. I think in that case you are trying > to solve network failure recovery inside the MOBIKE protocol. >=20 > I think Francis and someone else on the list commented such > functionality should probably be outside the MOBIKE protocol > specification. >=20 > MOBIKE's mandate, in my opinion, is to notify the "other end" > of the change in address or plurality of addresses due to=20 > mobility or multihoming using IKE mechanism (information=20 > exchange). Trying to solve a general problem within MOBIKE, > may complicate MOBIKE protocol unnecessarily. Network failure > recovery (without notifications) should be solved elsewhere > IMHO. >=20 > Best, > Atul >=20 > > -----Original Message----- > > From: Eronen Pasi (Nokia-NRC/Helsinki)=20 > > Sent: Monday, August 16, 2004 7:38 AM > > To: Sharma Atul (Nokia-ES/Boston); mobike@machshav.com > > Subject: RE: [Mobike] New issue 16: No packets from other end? > >=20 > >=20 > >=20 > > Hi Atul, > >=20 > > The other end could be a mobile host or SGW, depending=20 > > on your point of view. > >=20 > > The issue is what to do if we have not received a "link=20 > > down" signal from layer 2 (or somewhere), but we don't=20 > > get any responses (to IKEv2 requests) from the other end=20 > > either. In this situation, should we just close the=20 > > connection, or "somehow" trigger MOBIKE to change to=20 > > some other address(es)?=20 > >=20 > > (Some details of the "somehow" part will be beyond=20 > > the scope of the MOBIKE specification, but probably =20 > > something needs to be said to ensure interoperability.) > >=20 > > Best regards, > > Pasi > >=20 > > > -----Original Message----- > > > From: Atul.Sharma@nokia.com > > > Sent: Friday, August 13, 2004 5:40 PM > > > To: Eronen Pasi (Nokia-NRC/Helsinki); mobike@machshav.com > > > Subject: RE: [Mobike] New issue 16: No packets from other end? > > >=20 > > > I needed some clarifications from MOBIKE veterans, before=20 > > > expressing an opinion: > > >=20 > > > What is the "other end" here? The mobile host? or the=20 > > > multihoming SGW? > > >=20 > > > Who initiates the MOBIKE protocol? I would guess: > > > (1) a mobile host after the move, needs to notify the=20 > > > remote SGW of its new address. > > > (2) a multihoming SGW, upon detecting that one of its=20 > > > interfaces (which was used to contact the mobile host) > > > is down and it needs to notify the mobile host of its > > > new interface address to be used. > > >=20 > > > Are there any other scenarios of how MOBIKE can be initiated?=20 > > > When would we use the information that there is "lack of packets=20 > > > from the other end", to initiate the MOBIKE protocol? > > >=20 > > > Thanks, > > > Atul > > >=20 > > > > -----Original Message----- > > > > From: mobike-bounces@machshav.com=20 > > > > [mailto:mobike-bounces@machshav.com]On > > > > Behalf Of ext=20 > > > > Sent: Thursday, August 12, 2004 9:01 AM > > > > To: mobike@machshav.com > > > > Subject: [Mobike] New issue 16: No packets from other end? > > > >=20 > > > >=20 > > > > I've created a new issue in the issue list: > > > >=20 > > > > "Can the protocol recover from situations where the only=20 > > > > sign of problems is lack of packets from the other end?" > > > >=20 > > > > (http://www.vpnc.org/ietf-mobike/issues.html) > > > >=20 > > > > Many people at the WG meeting expressed opinions that this=20 > > > > should be handled somehow (in addition to handling e.g.=20 > > > > link-down triggers from layer 2, or something similar). > > > >=20 > > > > So far, I do not remember anyone saying that the protocol > > > > does not need to handle this situation. But comments > > > > are welcome. > > > >=20 > > > > Best regards, > > > > Pasi > >=20 > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Aug 16 11:46:59 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12124 for ; Mon, 16 Aug 2004 11:46:58 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 78E74FB459; Mon, 16 Aug 2004 11:46:59 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9E54EFB452; Mon, 16 Aug 2004 11:46:56 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B714FFB453; Mon, 16 Aug 2004 11:46:54 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by machshav.com (Postfix) with ESMTP id 6DEF6FB451 for ; Mon, 16 Aug 2004 11:46:53 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7GFkoj09499 for ; Mon, 16 Aug 2004 18:46:51 +0300 (EET DST) X-Scanned: Mon, 16 Aug 2004 18:44:32 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7GFiW3m018649 for ; Mon, 16 Aug 2004 18:44:32 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 007EwlOp; Mon, 16 Aug 2004 18:39:01 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7GFPOu09134 for ; Mon, 16 Aug 2004 18:25:24 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 16 Aug 2004 10:23:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] New issue 16: No packets from other end? Date: Mon, 16 Aug 2004 11:23:04 -0400 Message-ID: Thread-Topic: New issue 16: No packets from other end? Thread-Index: AcSAbHFToUbUJBTZTGqhmrz4TpAjxgA1RhFAAJCTLqAAAhtxEAABqaVwAAPmf8A= From: To: , X-OriginalArrivalTime: 16 Aug 2004 15:23:10.0763 (UTC) FILETIME=[F098AFB0:01C483A4] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Hi Pasi, Situations where traffic being sent expects a response from the other end in a reasonable time, can give some indication of network/path failures, though not an=20 absolute indication. But just saying that "No packets=20 from the other end in some amount of time" is an indicative of network/path failure may not be a correct statement. We will have to explicitly say, that if certain part of the protocol, say an IKE message does not get response in a certain amount of time, we initiate change of address.=20 Another possibility could be the keepalives, which shall be needed for the NAT case anyway, could be used as an indication of network/path failures. Lack of keepalive could be a trigger for MOBIKE change of address notification. I agree we should try to recover from as many failures/changes as possible without making the protocol unreasonably complex. I think use of keepalives, which are needed anyway, for this purpose should not make the protocol any more complex than it already is. >From the title of the issue, it seemed we are trying to proactively solve network failure recovery. I think we are in agreement. This sounds reasonable to me. I=20 guess, then we will have to understand Francis' objection to=20 such failure recovery. Best, Atul > -----Original Message----- > From: Eronen Pasi (Nokia-NRC/Helsinki)=20 > Sent: Monday, August 16, 2004 9:42 AM > To: Sharma Atul (Nokia-ES/Boston); mobike@machshav.com > Subject: RE: [Mobike] New issue 16: No packets from other end? >=20 >=20 > Hi Atul, >=20 > My impression was that the main reason we are adding=20 > multihoming support to IKEv2 is to recover from failures=20 > (since load balancing is explicitly beyond the scope).=20 >=20 > I think that restricting ourselves to those network failures=20 > where we get an explicit "link down" signal will seriously=20 > limit the usefulness of the protocol's multihoming features. > (For instance, the multihoming features of SCTP don't > have that kind of restriction.) >=20 > Best regards, > Pasi >=20 > > -----Original Message----- > > From: atul.sharma@nokia.com > > Sent: Monday, August 16, 2004 3:33 PM > > To: Eronen Pasi (Nokia-NRC/Helsinki); mobike@machshav.com > > Subject: RE: [Mobike] New issue 16: No packets from other end? > >=20 > >=20 > > Thanks Passi, > >=20 > > ....for the explanation. I think in that case you are trying > > to solve network failure recovery inside the MOBIKE protocol. > >=20 > > I think Francis and someone else on the list commented such > > functionality should probably be outside the MOBIKE protocol > > specification. > >=20 > > MOBIKE's mandate, in my opinion, is to notify the "other end" > > of the change in address or plurality of addresses due to=20 > > mobility or multihoming using IKE mechanism (information=20 > > exchange). Trying to solve a general problem within MOBIKE, > > may complicate MOBIKE protocol unnecessarily. Network failure > > recovery (without notifications) should be solved elsewhere > > IMHO. > >=20 > > Best, > > Atul > >=20 > > > -----Original Message----- > > > From: Eronen Pasi (Nokia-NRC/Helsinki)=20 > > > Sent: Monday, August 16, 2004 7:38 AM > > > To: Sharma Atul (Nokia-ES/Boston); mobike@machshav.com > > > Subject: RE: [Mobike] New issue 16: No packets from other end? > > >=20 > > >=20 > > >=20 > > > Hi Atul, > > >=20 > > > The other end could be a mobile host or SGW, depending=20 > > > on your point of view. > > >=20 > > > The issue is what to do if we have not received a "link=20 > > > down" signal from layer 2 (or somewhere), but we don't=20 > > > get any responses (to IKEv2 requests) from the other end=20 > > > either. In this situation, should we just close the=20 > > > connection, or "somehow" trigger MOBIKE to change to=20 > > > some other address(es)?=20 > > >=20 > > > (Some details of the "somehow" part will be beyond=20 > > > the scope of the MOBIKE specification, but probably =20 > > > something needs to be said to ensure interoperability.) > > >=20 > > > Best regards, > > > Pasi > > >=20 > > > > -----Original Message----- > > > > From: Atul.Sharma@nokia.com > > > > Sent: Friday, August 13, 2004 5:40 PM > > > > To: Eronen Pasi (Nokia-NRC/Helsinki); mobike@machshav.com > > > > Subject: RE: [Mobike] New issue 16: No packets from other end? > > > >=20 > > > > I needed some clarifications from MOBIKE veterans, before=20 > > > > expressing an opinion: > > > >=20 > > > > What is the "other end" here? The mobile host? or the=20 > > > > multihoming SGW? > > > >=20 > > > > Who initiates the MOBIKE protocol? I would guess: > > > > (1) a mobile host after the move, needs to notify the=20 > > > > remote SGW of its new address. > > > > (2) a multihoming SGW, upon detecting that one of its=20 > > > > interfaces (which was used to contact the mobile host) > > > > is down and it needs to notify the mobile host of its > > > > new interface address to be used. > > > >=20 > > > > Are there any other scenarios of how MOBIKE can be initiated?=20 > > > > When would we use the information that there is "lack=20 > of packets=20 > > > > from the other end", to initiate the MOBIKE protocol? > > > >=20 > > > > Thanks, > > > > Atul > > > >=20 > > > > > -----Original Message----- > > > > > From: mobike-bounces@machshav.com=20 > > > > > [mailto:mobike-bounces@machshav.com]On > > > > > Behalf Of ext=20 > > > > > Sent: Thursday, August 12, 2004 9:01 AM > > > > > To: mobike@machshav.com > > > > > Subject: [Mobike] New issue 16: No packets from other end? > > > > >=20 > > > > >=20 > > > > > I've created a new issue in the issue list: > > > > >=20 > > > > > "Can the protocol recover from situations where the only=20 > > > > > sign of problems is lack of packets from the other end?" > > > > >=20 > > > > > (http://www.vpnc.org/ietf-mobike/issues.html) > > > > >=20 > > > > > Many people at the WG meeting expressed opinions that this=20 > > > > > should be handled somehow (in addition to handling e.g.=20 > > > > > link-down triggers from layer 2, or something similar). > > > > >=20 > > > > > So far, I do not remember anyone saying that the protocol > > > > > does not need to handle this situation. But comments > > > > > are welcome. > > > > >=20 > > > > > Best regards, > > > > > Pasi > > >=20 > > _______________________________________________ > > Mobike mailing list > > Mobike@machshav.com > > https://www.machshav.com/mailman/listinfo.cgi/mobike > >=20 >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Aug 16 19:22:15 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21217 for ; Mon, 16 Aug 2004 19:22:15 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id F327DFB455; Mon, 16 Aug 2004 19:22:16 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8A252FB452; Mon, 16 Aug 2004 19:22:15 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CE200FB453; Mon, 16 Aug 2004 19:22:13 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by machshav.com (Postfix) with ESMTP id EA155FB451 for ; Mon, 16 Aug 2004 19:22:12 -0400 (EDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i7GNLgA10976; Mon, 16 Aug 2004 16:21:42 -0700 X-mProtect: <200408162321> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJqggDi; Mon, 16 Aug 2004 16:21:41 PDT Message-ID: <41214396.4010803@iprg.nokia.com> Date: Mon, 16 Aug 2004 16:30:30 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040430 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] New issue 16: No packets from other end? References: <052E0C61B69C3741AFA5FE88ACC775A60227C164@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A60227C164@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit hi Pasi, Pasi.Eronen@nokia.com wrote: > Hi Vijay, > > IKEv2 already triggers an informational exchange if > there's no incoming ESP traffic for some time (how long > you wait is not specified). you are right. I mixed it up. > We're not changing that part, I hope. The main issue > for MOBIKE is what to do if we don't receive a reply > to the informational request (even after some number > of retransmissions). > > If we don't do anything, the SAs will be closed. In my > opinion, that's not acceptable. The lack of replies > should trigger changing to some other addresses (if a > working path is available). I am not sure how you can do that. what if the application prefers "failing" to using an expensive link? for example, lets assume my mobile device has a low bandwidth GPRS link (address IP1 on that link) and a high bandwidth WLAN link (address IP2 on that link). I have set it up so that my email is downloaded only when I connect to my Enterprise through a VPN connection when I have the WLAN link. if the WLAN link is not available, I dont want the email client to download email. lets assume I am in the middle of downloading email. I lose WLAN coverage. with your proposal, the MOBIKE protocol switches to using IP1. I dont want that. > We don't need to specify exactly how this works, and as Francis > pointed out, there are many complex issues in e.g. handoff > decisions that we don't want to put in MOBIKE specs. > > What we IMHO do need to specify are the parts required for > interoperability, like what is sent/received to/from the other > node, and some parts of how those messages are processed. > I think this should be specified in the MOBIKE spec; that is, we > should not assume that there is some other unspecified protocol > (in addition to IKEv2 and ESP/AH) running between the parties. IMHO, I prefer "something in the Mobile Node" telling MOBIKE, "switch to using this address with this VPN GW". then a MOBIKE update should be sent. this is the model I had in my mind. for "something in the Mobile Node" I had assumed DNA, MIP6, Multi6, new address configuration, default router change, etc... Vijay _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Aug 16 23:20:26 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03453 for ; Mon, 16 Aug 2004 23:20:25 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E0CF7FB4D6; Mon, 16 Aug 2004 23:20:26 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 720FFFB452; Mon, 16 Aug 2004 23:20:25 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BA9BEFB456; Mon, 16 Aug 2004 23:20:23 -0400 (EDT) Received: from smtp814.mail.sc5.yahoo.com (smtp814.mail.sc5.yahoo.com [66.163.170.84]) by machshav.com (Postfix) with SMTP id 2EC99FB451 for ; Mon, 16 Aug 2004 23:20:23 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@67.123.80.184 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 17 Aug 2004 03:20:22 -0000 Message-ID: <005201c48409$207977a0$6401a8c0@adithya> From: "Mohan Parthasarathy" To: "Vijay Devarapalli" , References: <052E0C61B69C3741AFA5FE88ACC775A60227C164@esebe023.ntc.nokia.com> <41214396.4010803@iprg.nokia.com> Subject: Re: [Mobike] New issue 16: No packets from other end? Date: Mon, 16 Aug 2004 20:20:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 > > for example, lets assume my mobile device has a low bandwidth > GPRS link (address IP1 on that link) and a high bandwidth WLAN > link (address IP2 on that link). I have set it up so that my > email is downloaded only when I connect to my Enterprise > through a VPN connection when I have the WLAN link. if the > WLAN link is not available, I dont want the email client to > download email. lets assume I am in the middle of downloading > email. I lose WLAN coverage. with your proposal, the MOBIKE > protocol switches to using IP1. I dont want that. > > > We don't need to specify exactly how this works, and as Francis > > pointed out, there are many complex issues in e.g. handoff > > decisions that we don't want to put in MOBIKE specs. > > > > What we IMHO do need to specify are the parts required for > > interoperability, like what is sent/received to/from the other > > node, and some parts of how those messages are processed. > > I think this should be specified in the MOBIKE spec; that is, we > > should not assume that there is some other unspecified protocol > > (in addition to IKEv2 and ESP/AH) running between the parties. > > IMHO, I prefer "something in the Mobile Node" telling MOBIKE, > "switch to using this address with this VPN GW". then a MOBIKE > update should be sent. this is the model I had in my mind. > But we don't want to restrict MOBIKE to do it this way. This means we should keep MOBIKE flexible enough to use any external trigger it wants. > for "something in the Mobile Node" I had assumed DNA, MIP6, > Multi6, new address configuration, default router change, etc... > Agreed. -mohan > Vijay > _______________________________________________ > 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 17 02:54:49 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25988 for ; Tue, 17 Aug 2004 02:54:48 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id EC10BFB4D8; Tue, 17 Aug 2004 02:54:48 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D73DAFB452; Tue, 17 Aug 2004 02:54:47 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5D54DFB453; Tue, 17 Aug 2004 02:54:46 -0400 (EDT) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 28F92FB451 for ; Tue, 17 Aug 2004 02:54:45 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i7H6sgYu029721 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 17 Aug 2004 09:54:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i7H6sfEp029718; Tue, 17 Aug 2004 09:54:41 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16673.43953.30691.731812@fireball.kivinen.iki.fi> Date: Tue, 17 Aug 2004 09:54:41 +0300 From: Tero Kivinen To: Subject: RE: [Mobike] New issue 16: No packets from other end? In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 Atul.Sharma@nokia.com writes: > I agree we should try to recover from as many failures/changes > as possible without making the protocol unreasonably complex. I > think use of keepalives, which are needed anyway, for this purpose > should not make the protocol any more complex than it already is. Note, that NAT-T keepalives are not authenticated, and MUST NOT be used to any other purpose than to keep the NAT mapping up. They MUST NOT be used to give any indication whether the other end is up or not. The sender of the keepalives, can stop sending them at any time, if it detects that NAT does not need them, or it can put the TTL low enough so that they never reach the final IKE destination, but do go through the NAT. And the sender do not send keepalives if it has sent any ESP packets lately to the other end, i.e the ESP packets also acts as keepalives, the specific keepalive packets are only used if there is no other traffic going through. -- 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 17 09:41:39 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14904 for ; Tue, 17 Aug 2004 09:41:39 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1115BFB459; Tue, 17 Aug 2004 09:41:38 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0D335FB451; Tue, 17 Aug 2004 09:41:35 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 92D77FB452; Tue, 17 Aug 2004 09:41:32 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by machshav.com (Postfix) with ESMTP id 87AF6FB44C for ; Tue, 17 Aug 2004 09:41:31 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7HDfSj08330 for ; Tue, 17 Aug 2004 16:41:28 +0300 (EET DST) X-Scanned: Tue, 17 Aug 2004 16:38:31 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7HDcVJw010459 for ; Tue, 17 Aug 2004 16:38:31 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00t8iXg8; Tue, 17 Aug 2004 16:38:30 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7HDcUu28091 for ; Tue, 17 Aug 2004 16:38:30 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 17 Aug 2004 08:38:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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, 17 Aug 2004 09:38:27 -0400 Message-ID: Thread-Topic: 3rd Party Bombing Thread-Index: AcSEXOE8NtzQpU6HRweMRodiVeCagwAAjfDQ From: To: X-OriginalArrivalTime: 17 Aug 2004 13:38:28.0524 (UTC) FILETIME=[7A80D6C0:01C4845F] Subject: [Mobike] 3rd Party Bombing X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 > Looking at the minutes, I know this issue was raised by Francis Dupont = at IETF-59. > Then at IETF-60, which I attended, this issue was discussed under the = MOBIKE > design. But unfortunately, the 3rd Party Bombing Protection issue did = not seem to=20 > make it to the issue list. >=20 > I want to educate myself on this issue. I know the basic problem. But = I do not have > full grasp of all the protection levels, and what and how they achieve = this. The current > design draft though mentions the problem, does not talk in this = protection level terms. >=20 > My private request on this has not been replied yet. Is there someone = who can initiate > openly a discussion on the different protection levels and what they = aim to achieve? >=20 > Could we also make this an issue in the issue list? There is stuff on = RR there, but the > different protection levels and issues with them are not discussed. >=20 > Thanks, > Atul >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Aug 18 05:01:55 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19316 for ; Wed, 18 Aug 2004 05:01:54 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id CA280FB456; Wed, 18 Aug 2004 05:01:54 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1BD1EFB453; Wed, 18 Aug 2004 05:01:52 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 21D95FB452; Wed, 18 Aug 2004 05:01:49 -0400 (EDT) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 20CBAFB44C for ; Wed, 18 Aug 2004 05:01:47 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i7I91bYu015456 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 18 Aug 2004 12:01:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i7I91Zbq015453; Wed, 18 Aug 2004 12:01:35 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16675.6895.150592.856009@fireball.kivinen.iki.fi> Date: Wed, 18 Aug 2004 12:01:35 +0300 From: Tero Kivinen To: Subject: [Mobike] 3rd Party Bombing In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 2 min Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 Atul.Sharma@nokia.com writes: > > I want to educate myself on this issue. I know the basic problem. > > But I do not have full grasp of all the protection levels, and > > what and how they achieve this. The current design draft though > > mentions the problem, does not talk in this protection level > > terms. The reason that the protection levels are not mentioned in the design draft, was that I created the terms while making the slides for the IETF. I plan to update the design draft and put more about that stuff there too. > > My private request on this has not been replied yet. Is there > > someone who can initiate openly a discussion on the different > > protection levels and what they aim to achieve? Your request is still waiting in my mailbox, I haven't had time to respond to it (my likely respond will be to update the draft and sent that to you, so it takes some time). -- 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 24 11:03:48 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12721 for ; Tue, 24 Aug 2004 11:03:47 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7C0E7FB4D7; Tue, 24 Aug 2004 11:03:48 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E89B1FB44D; Tue, 24 Aug 2004 11:03:46 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7724AFB455; Tue, 24 Aug 2004 11:03:45 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by machshav.com (Postfix) with ESMTP id 1B281FB44C for ; Tue, 24 Aug 2004 11:03:44 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7OF3fT11099 for ; Tue, 24 Aug 2004 18:03:41 +0300 (EET DST) X-Scanned: Tue, 24 Aug 2004 18:01:29 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7OF1TiJ022551 for ; Tue, 24 Aug 2004 18:01:29 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 004TbtkE; Tue, 24 Aug 2004 18:01:28 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7OF1Mn21279 for ; Tue, 24 Aug 2004 18:01:22 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 24 Aug 2004 18:01:22 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 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] New issue 16: No packets from other end? Date: Tue, 24 Aug 2004 18:01:21 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C18C@esebe023.ntc.nokia.com> Thread-Topic: [Mobike] New issue 16: No packets from other end? Thread-Index: AcSD59vrtnciGozmSZeW22R5SWoixwF/Disw From: To: X-OriginalArrivalTime: 24 Aug 2004 15:01:22.0428 (UTC) FILETIME=[38129BC0:01C489EB] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Hi Vijay (and sorry for a long delay in replying), > I am not sure how you can do that. what if the application > prefers "failing" to using an expensive link? >=20 > for example, lets assume my mobile device has a low bandwidth > GPRS link (address IP1 on that link) and a high bandwidth WLAN > link (address IP2 on that link). I have set it up so that my > email is downloaded only when I connect to my Enterprise > through a VPN connection when I have the WLAN link. if the > WLAN link is not available, I dont want the email client to > download email. lets assume I am in the middle of downloading > email. I lose WLAN coverage. with your proposal, the MOBIKE > protocol switches to using IP1. I dont want that. I agree, certainly we should have enough flexibility in the specs to handle both cases here (switching to another path and failing), depending on local policies. > > We don't need to specify exactly how this works, and as Francis > > pointed out, there are many complex issues in e.g. handoff=20 > > decisions that we don't want to put in MOBIKE specs. > >=20 > > What we IMHO do need to specify are the parts required for=20 > > interoperability, like what is sent/received to/from the other=20 > > node, and some parts of how those messages are processed.=20 > > I think this should be specified in the MOBIKE spec; that is, we > > should not assume that there is some other unspecified protocol=20 > > (in addition to IKEv2 and ESP/AH) running between the parties. >=20 > IMHO, I prefer "something in the Mobile Node" telling MOBIKE, > "switch to using this address with this VPN GW". then a MOBIKE > update should be sent. this is the model I had in my mind. >=20 > for "something in the Mobile Node" I had assumed DNA, MIP6, > Multi6, new address configuration, default router change, etc... Those are the things Jari called "local knowledge":=20 something in the mobile node knows what should be done ("switch to this address"), based on information that's "local" in the sense that it's not a result of an end-to-end protocol between the IKEv2 nodes. I don't think there's any disagreement about handling those:=20 we just assume that there's "something" in the mobile node=20 that triggers appropriate MOBIKE messages to be sent. But issue 16 is more about what to do if we know there=20 is a problem (=3D=3Dwe don't receive any replies to our IKE=20 requests, even after retransmissions), but we don't know=20 what address change would correct the situation (because the "local knowlege" is either not reliable enough, or the failure is in the "middle" where local knowledge does not reach). Here the options seem to be: (1) fail, (2) send some=20 IKEv2 message(s), either new ones or the one we were=20 retransmitting, along some other path, and use information about their delivery to help deciding what should be done, or (3) send some non-IKEv2 message(s) along=20 some other path. Now, option 1 would be the right choice only if we=20 assume that the "local knowledge" is reliable enough,=20 and we do not care about non-local failures. (Is this the choice you prefer?) Option 3 means we don't have interoperability unless the nodes also agree what that non-IKEv2 end-to-end (between IKEv2 peers) protocol is.=20 So my opinion is strongly something like option 2: if=20 we don't receive replies to our IKEv2 request(s), try=20 sending them along some other path (unless the current=20 path is the only one acceptable to us, of course). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Aug 24 11:14:11 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13647 for ; Tue, 24 Aug 2004 11:14:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 36937FB4D9; Tue, 24 Aug 2004 11:14:12 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A5F1BFB455; Tue, 24 Aug 2004 11:14:11 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7AB51FB457; Tue, 24 Aug 2004 11:14:09 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id 6F2E4FB44C for ; Tue, 24 Aug 2004 11:14:08 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7OFE7N18857 for ; Tue, 24 Aug 2004 18:14:07 +0300 (EET DST) X-Scanned: Tue, 24 Aug 2004 18:11:06 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7OFB67c027065 for ; Tue, 24 Aug 2004 18:11:06 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00Yvjmvt; Tue, 24 Aug 2004 18:11:04 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7OFAxu21428 for ; Tue, 24 Aug 2004 18:10:59 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 24 Aug 2004 18:10:58 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 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, 24 Aug 2004 18:10:58 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3C0E@esebe023.ntc.nokia.com> Thread-Topic: New issue 17: Full connectivity Thread-Index: AcSJ7JCVexVDXPZbSYWDfRIkxPvBjA== From: To: X-OriginalArrivalTime: 24 Aug 2004 15:10:58.0973 (UTC) FILETIME=[8FB864D0:01C489EC] Subject: [Mobike] New issue 17: Full connectivity X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Hi, Based on talks at San Diego, I've created a new issue on the issue tracker: "If both parties have several addresses, do we assume=20 that all pairs have connectivity between them?" There was discussion about this in mid-April (one example=20 mentioned was two SGWs connected via two different private=20 networks), and most people thought we should not assume this. Assuming this would also seem to largely rule out IPv4/v6 mobility. If we decide _not_ to make this assumption, then we have cases=20 where we have to change both parties's addresses in SAs=20 at the same time. It also seems the protocol will require some kind of address lists, so something like SMOBIKE won't work (unless we assume=20 one party knows several addresses for the other party via some=20 other means than address lists sent within the protocol). Any comments? Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Aug 24 11:32:25 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15079 for ; Tue, 24 Aug 2004 11:32:24 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7D48EFB4DA; Tue, 24 Aug 2004 11:32:26 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B3B17FB455; Tue, 24 Aug 2004 11:32:25 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0402DFB4D5; Tue, 24 Aug 2004 11:32:24 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by machshav.com (Postfix) with ESMTP id EA1CBFB44D for ; Tue, 24 Aug 2004 11:32:22 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7OFWL109621 for ; Tue, 24 Aug 2004 18:32:21 +0300 (EET DST) X-Scanned: Tue, 24 Aug 2004 18:30:08 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7OFU8iv014817 for ; Tue, 24 Aug 2004 18:30:08 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 009fN3vi; Tue, 24 Aug 2004 18:30:06 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7OFU4n15141 for ; Tue, 24 Aug 2004 18:30:04 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 24 Aug 2004 18:30:03 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 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, 24 Aug 2004 18:30:03 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3C10@esebe023.ntc.nokia.com> Thread-Topic: New issue 18: Threat discussion Thread-Index: AcSJ7zrp+ll6ZMdeRvOy1D8v0YYq7w== From: To: X-OriginalArrivalTime: 24 Aug 2004 15:30:03.0878 (UTC) FILETIME=[3A230860:01C489EF] Subject: [Mobike] New issue 18: Threat discussion X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 At the San Diego meeting I promised to create a new issue about the various threats the protocol should consider. So far, we have at least the following (notation: the IKE peers are A and B; C is an innocent victim). 1) Unauthenticated attacker directs the traffic stream from B to a third party C, with the intent flooding C with unwanted traffic. 2) Authenticated peer A directs the traffic stream from B to a third party C, with the intent of flooding C with unwanted traffic. 3) Unauthenticated attacker directs the traffic stream from B to somewhere (perhaps to the attacker or /dev/null),=20 with the intent of preventing the legitimate peers from=20 communicating. 4) Unauthenticated attacker causes the IKE_SA to be closed by modifying just one or two IKE packets (if attacker can modify all packets, he can of course DoS). Do we have any other threats, assuming we don't need to=20 repeat those where MOBIKE doesn't change anything in normal IKEv2? Should we add some discussion about these=20 to the design document and/or protocol proposals? (BTW, a comment about terminology: Francis has quite consistently called case 1 "transient pseudo-NAT attack"=20 and case 2 "third party bombing". I (and several others)=20 have sometimes called both 1 and 2 third party bombing.) Cheers, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Aug 24 11:57:24 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17128 for ; Tue, 24 Aug 2004 11:57:23 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 63BB4FB4DE; Tue, 24 Aug 2004 11:57:25 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 53AD9FB4D5; Tue, 24 Aug 2004 11:57:24 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0C57BFB4DB; Tue, 24 Aug 2004 11:57:23 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 10363FB44D for ; Tue, 24 Aug 2004 11:57:22 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 3301589874; Tue, 24 Aug 2004 18:57:20 +0300 (EEST) Message-ID: <412B6544.4090202@piuha.net> Date: Tue, 24 Aug 2004 18:56:52 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] New issue 17: Full connectivity References: <052E0C61B69C3741AFA5FE88ACC775A6010C3C0E@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C3C0E@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > Hi, > > Based on talks at San Diego, I've created a new issue > on the issue tracker: > > "If both parties have several addresses, do we assume > that all pairs have connectivity between them?" > > There was discussion about this in mid-April (one example > mentioned was two SGWs connected via two different private > networks), and most people thought we should not assume this. > > Assuming this would also seem to largely rule out IPv4/v6 > mobility. > > If we decide _not_ to make this assumption, then we have cases > where we have to change both parties's addresses in SAs > at the same time. > > It also seems the protocol will require some kind of address > lists, so something like SMOBIKE won't work (unless we assume > one party knows several addresses for the other party via some > other means than address lists sent within the protocol). I think the two SGW example is a pretty convincing one, so I'd rather not assume full connectivity. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Aug 24 12:01:12 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17374 for ; Tue, 24 Aug 2004 12:01:11 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 99761FB4E2; Tue, 24 Aug 2004 12:01:13 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B61C8FB4D5; Tue, 24 Aug 2004 12:01:10 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 93D9DFB4DF; Tue, 24 Aug 2004 12:01:09 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 97A8FFB44D for ; Tue, 24 Aug 2004 12:01:08 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id B9D3089874; Tue, 24 Aug 2004 19:01:07 +0300 (EEST) Message-ID: <412B6628.3090900@piuha.net> Date: Tue, 24 Aug 2004 19:00:40 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] New issue 16: No packets from other end? References: <052E0C61B69C3741AFA5FE88ACC775A60227C18C@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A60227C18C@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit This is a good summary, thanks Pasi. I would add that in some cases we have also option 4: wait until the local knowledge gets a chance to be updated. For instance, even standard (not RFC 3775 or DNA WG-enhanced) IPv6 neighbor discovery will eventually detect a movement, even if this can be slow. This also makes a feature interaction possible where MOBIKE decides to do something (e.g., move to GPRS) while in fact we were still in the DNA process and were going to tell MOBIKE to do something else (e.g., move to this new local LAN link). But I personally would also like option 2, as long as we also assume basic local link movement detection from a non-MOBIKE mechanism. Seems like most people want to rely on some sort of standard movement detection process outside MOBIKE (= the local knowledge). Question: how are we going to specify this, just as an assumption that its outside the MOBIKE protocol, or as a hard requirement to do ? It seems that the former is the only option, given that movement detection is somewhat of a moving target (no pun intended). IPv4 and IPv6 have different capabilities, several enhancements are being worked in different places (MIP6/DHCP/DNA WGs), etc. --Jari > Those are the things Jari called "local knowledge": > something in the mobile node knows what should be done > ("switch to this address"), based on information > that's "local" in the sense that it's not a result > of an end-to-end protocol between the IKEv2 nodes. > > I don't think there's any disagreement about handling those: > we just assume that there's "something" in the mobile node > that triggers appropriate MOBIKE messages to be sent. > > But issue 16 is more about what to do if we know there > is a problem (==we don't receive any replies to our IKE > requests, even after retransmissions), but we don't know > what address change would correct the situation (because > the "local knowlege" is either not reliable enough, > or the failure is in the "middle" where local knowledge > does not reach). > > Here the options seem to be: (1) fail, (2) send some > IKEv2 message(s), either new ones or the one we were > retransmitting, along some other path, and use information > about their delivery to help deciding what should > be done, or (3) send some non-IKEv2 message(s) along > some other path. > > Now, option 1 would be the right choice only if we > assume that the "local knowledge" is reliable enough, > and we do not care about non-local failures. (Is this > the choice you prefer?) > > Option 3 means we don't have interoperability unless the > nodes also agree what that non-IKEv2 end-to-end (between > IKEv2 peers) protocol is. > > So my opinion is strongly something like option 2: if > we don't receive replies to our IKEv2 request(s), try > sending them along some other path (unless the current > path is the only one acceptable to us, of course). > > Best regards, > Pasi > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Aug 30 11:03:31 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00356 for ; Mon, 30 Aug 2004 11:03:30 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E2039FB4DC; Mon, 30 Aug 2004 11:03:31 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B98A1FB456; Mon, 30 Aug 2004 11:03:30 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 88FC4FB4DB; Mon, 30 Aug 2004 11:03:28 -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 6D6E5FB453 for ; Mon, 30 Aug 2004 11:03:27 -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 i7UF3IM08599; Mon, 30 Aug 2004 17:03:18 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i7UF3ISj041642; Mon, 30 Aug 2004 17:03:18 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200408301503.i7UF3ISj041642@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] New issue 17: Full connectivity In-reply-to: Your message of Tue, 24 Aug 2004 18:10:58 +0300. <052E0C61B69C3741AFA5FE88ACC775A6010C3C0E@esebe023.ntc.nokia.com> Date: Mon, 30 Aug 2004 17:03:18 +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.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: "If both parties have several addresses, do we assume that all pairs have connectivity between them?" => obviously no so not only we need address lists but we need some kind of loose address pairing. BTW the question is not new and was proposed when I tried to find a good usage case for the loose address pairing my proposal provides... Thanks Francis.Dupont@enst-bretagne.fr PS: obviously = just consider a mix of IPv4 and IPv6 addresses for both peers. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Aug 30 11:07:59 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00604 for ; Mon, 30 Aug 2004 11:07:58 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 91D1CFB4E1; Mon, 30 Aug 2004 11:07:59 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8AEBFFB4DC; Mon, 30 Aug 2004 11:07:58 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EFDA0FB4DD; Mon, 30 Aug 2004 11:07:56 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id D75C6FB4DB for ; Mon, 30 Aug 2004 11:07:55 -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 i7UF7aM09175; Mon, 30 Aug 2004 17:07:36 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i7UF7ZSj041677; Mon, 30 Aug 2004 17:07:36 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200408301507.i7UF7ZSj041677@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] New issue 16: No packets from other end? In-reply-to: Your message of Tue, 24 Aug 2004 19:00:40 +0300. <412B6628.3090900@piuha.net> Date: Mon, 30 Aug 2004 17:07:35 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: Seems like most people want to rely on some sort of standard movement detection process outside MOBIKE (= the local knowledge). => = what I called "generic mobility/multi-homing control". Question: how are we going to specify this, just as an assumption that its outside the MOBIKE protocol, or as a hard requirement to do ? => clearly outside. It seems that the former is the only option, given that movement detection is somewhat of a moving target (no pun intended). IPv4 and IPv6 have different capabilities, several enhancements are being worked in different places (MIP6/DHCP/DNA WGs), etc. => we should also consider multi-homing which is not so easy... At least for mobility we have some practice (:-)! Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Aug 30 11:21:57 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01371 for ; Mon, 30 Aug 2004 11:21:56 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id CB760FB4E2; Mon, 30 Aug 2004 11:21:57 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 69ABAFB4DC; Mon, 30 Aug 2004 11:21:56 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 80E8FFB4DD; Mon, 30 Aug 2004 11:21:55 -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 42F8EFB4DB for ; Mon, 30 Aug 2004 11:21:54 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i7UFLkM10990; Mon, 30 Aug 2004 17:21:46 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i7UFLlSj041744; Mon, 30 Aug 2004 17:21:47 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200408301521.i7UFLlSj041744@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] New issue 18: Threat discussion In-reply-to: Your message of Tue, 24 Aug 2004 18:30:03 +0300. <052E0C61B69C3741AFA5FE88ACC775A6010C3C10@esebe023.ntc.nokia.com> Date: Mon, 30 Aug 2004 17:21:47 +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.4 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: So far, we have at least the following (notation: the IKE peers are A and B; C is an innocent victim). => I disagree a bit about the presentation: the level of authentication is very important too. With other words, we shall have to give to the return routability procedure(s) a trust level. 1) Unauthenticated attacker directs the traffic stream from B to a third party C, with the intent flooding C with unwanted traffic. 2) Authenticated peer A directs the traffic stream from B to a third party C, with the intent of flooding C with unwanted traffic. 3) Unauthenticated attacker directs the traffic stream from B to somewhere (perhaps to the attacker or /dev/null), with the intent of preventing the legitimate peers from communicating. => 1 and 3 should be merged? 4) Unauthenticated attacker causes the IKE_SA to be closed by modifying just one or two IKE packets (if attacker can modify all packets, he can of course DoS). Do we have any other threats, assuming we don't need to repeat those where MOBIKE doesn't change anything in normal IKEv2? Should we add some discussion about these to the design document and/or protocol proposals? (BTW, a comment about terminology: Francis has quite consistently called case 1 "transient pseudo-NAT attack" and case 2 "third party bombing". I (and several others) have sometimes called both 1 and 2 third party bombing.) => if you have read my draft about case 1 you know why I has considered cases 1/3 as very different of case 2. BTW the attack and the defense are very bound to NAT traversal capability, when the case 2 is essentialy a question of trust in the peer (this is why the level of trust is so critical), and the name comes from MIPv6 security discussion (Erik or Jari?). Thanks Francis.Dupont@enst-bretagne.fr PS: draft-dupont-transient-pseudonat-04.txt (any comment and/or improvement are wellcome) _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike