From mailman-bounces@machshav.com Sun May 1 01:03:25 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26219 for ; Sun, 1 May 2005 01:03:24 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 46C04FB2AD; Sun, 1 May 2005 01:03:24 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 48253FB393 for ; Sun, 1 May 2005 01:01:22 -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 May 2005 05:00:07 +0000 Precedence: bulk X-BeenThere: mailman@machshav.com X-Mailman-Version: 2.1.5 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 Fri May 6 10:03:05 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17514 for ; Fri, 6 May 2005 10:03:04 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A9319FB292; Fri, 6 May 2005 10:03:03 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 442C1FB28D; Fri, 6 May 2005 10:03:01 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 10426FB28E; Fri, 6 May 2005 10:03:00 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 6EC88FB289 for ; Fri, 6 May 2005 10:02:59 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5387989879; Fri, 6 May 2005 17:02:55 +0300 (EEST) Message-ID: <427B7915.4040804@piuha.net> Date: Fri, 06 May 2005 17:03:01 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] issues 18, 15, 6 -- return routability References: <200504050822.j358Mcvj093590@givry.rennes.enst-bretagne.fr> In-Reply-To: <200504050822.j358Mcvj093590@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Hi Francis, > - If the specific IP address can be found in the peer's certificate, > you can skip the test > >=> I maintain my proposal to change this into "if the specific IP address >is already authorized, you can skip the test". >This is more general (as there can be other ways to authorized an address) >and more accurate (so it should answer Vijay's concern). > > Agreed. I think we can close this issue now. (At first when I saw this I thought there might be an issue with regards to having clear implementation requirements. I.e. what is the minimum that an implementation has to do. But then I realized that the way that we are apparently going to write this is that the additional authorization mechanisms are optional, i.e. the minimum you have to do is to always do the test. It doesn't matter if you support certificates or xmlconf admin interface or look at the moon's phase...) --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri May 6 10:03:30 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17572 for ; Fri, 6 May 2005 10:03:29 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E44C6FB29D; Fri, 6 May 2005 10:03:30 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EC5ADFB299; Fri, 6 May 2005 10:03:28 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 513BDFB29B; Fri, 6 May 2005 10:03:27 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 9E53BFB28E for ; Fri, 6 May 2005 10:03:26 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D0BD089879; Fri, 6 May 2005 17:03:25 +0300 (EEST) Message-ID: <427B7933.8090608@piuha.net> Date: Fri, 06 May 2005 17:03:31 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mobike] issues 18, 15, 6 -- return routability References: <424AB3D9.60008@piuha.net><200504050822.j358Mcvj093590@givry.rennes.enst-bretagne.fr> <16978.23469.695763.696396@fireball.kivinen.iki.fi> <030201c539f8$91082570$0f6115ac@dcml.docomolabsusa.com> In-Reply-To: <030201c539f8$91082570$0f6115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Francis Dupont , Tero Kivinen X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit James Kempf wrote: >How about CGA? > > CGA helps most with the ownership problem, but we don't have that issue here since we have shared key material between the peers, using that will suffice to show we are talking to the right node. However, CGA doesn't go all the way towards ensuring that the peer at the other end is trusted and doesn't redirect his streams somewhere else. It helps a little, however, since its hard to spoof someone else's address; but you can still spoof and bomb a victim network. Combined with some credit-based monitoring against flooding attacks you could probably get a very good solution with CGA. But I'm hoping we can do without it this WG, we are basically just doing a simple RR test, guided by some policy of when that is necessasary. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon May 9 07:26:48 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00322 for ; Mon, 9 May 2005 07:26:47 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5BDA9FB282; Mon, 9 May 2005 07:26:46 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0FA32FB27D; Mon, 9 May 2005 07:26:45 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 56DDBFB280; Mon, 9 May 2005 07:26:43 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 42E45FB266 for ; Mon, 9 May 2005 07:26:42 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 664EF89863; Mon, 9 May 2005 14:26:40 +0300 (EEST) Message-ID: <427F48F6.6020104@piuha.net> Date: Mon, 09 May 2005 14:26:46 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Mobike] issue 11 -- window size References: <424AB7FF.3080408@piuha.net> <16977.7603.98381.2831@fireball.kivinen.iki.fi> <42513836.1040308@piuha.net> <16978.17701.446055.840859@fireball.kivinen.iki.fi> <003001c53a41$570d93c0$6501a8c0@adithya> <16981.2434.30434.819709@fireball.kivinen.iki.fi> <001c01c53bc8$1e23d550$6501a8c0@adithya> <16982.13787.382550.756541@fireball.kivinen.iki.fi> <018f01c53c97$1d23a250$6501a8c0@adithya> <16983.58047.278167.446495@fireball.kivinen.iki.fi> In-Reply-To: <16983.58047.278167.446495@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mohan Parthasarathy , MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Hello folks, We have had a lively discussion about this on the list. We started by listing a couple of alternatives including doing certain MOBIKE messages outside the window, and requiring larger than 1 window sizes. Tero brought up his proposal (see [1] and clarifications e.g. in [2]) which can work under window size 1 while still fitting within the regular IKEv2 message processing. Some discussion was held on exactly how this can be integrated to NAT traversal and potential future extensions. My sense was that there were at least some persons who felt that Tero's approach is good enough. I think Mohan was the only one who had question marks about this, e.g., why pick it over others and how well it works with NATs. How do others who have not voiced an opinion yet feel? Are there serious issues with Tero's proposal? If not, we could just do what Tero proposed. --Jari [1] http://www.machshav.com/pipermail/mobike/2005-April/000730.html [2] http://www.machshav.com/pipermail/mobike/2005-April/000752.html _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon May 9 10:19:05 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17699 for ; Mon, 9 May 2005 10:19:04 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id EE4E8FB280; Mon, 9 May 2005 10:19:04 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 42AB9FB27D; Mon, 9 May 2005 10:19:03 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7C735FB27F; Mon, 9 May 2005 10:19:01 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id 03674FB27C for ; Mon, 9 May 2005 10:19:00 -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 j49EIpM03160 for ; Mon, 9 May 2005 17:18:55 +0300 (EET DST) X-Scanned: Mon, 9 May 2005 17:14:49 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j49EEnms032087 for ; Mon, 9 May 2005 17:14:49 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00aSnhzC; Mon, 09 May 2005 17:14:47 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 j49EEkM09146 for ; Mon, 9 May 2005 17:14:46 +0300 (EET DST) Received: from esebh006.NOE.Nokia.com ([172.21.138.88]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 9 May 2005 17:14:35 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 9 May 2005 17:14:17 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 May 2005 17:14:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issue 11 -- window size Date: Mon, 9 May 2005 17:14:10 +0300 Message-ID: Thread-Topic: [Mobike] issue 11 -- window size Thread-Index: AcVUimSK/wzCEQmnQk2XJN0m2RUekwADwAxQ From: To: X-OriginalArrivalTime: 09 May 2005 14:14:11.0132 (UTC) FILETIME=[5F109FC0:01C554A1] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Hello, Repeating myself from IETF62, Tero's proposal (using the latest IKEv2 request as a path test message) works perfectly if the responder never uses the addresses from the IP header for anything else except transmitting the reply. All the cases where the IP header is used for something else require some=20 kind of special handling, and this complicates things. One example that I mentioned to Tero in Minneapolis... - Current path (A1,B1) stops working, and the peers switch=20 to (A2,B2). A is behind a NAT in both cases. - After a while (A2,B2) still works (and continues working), but the peers really prefer (A1,B1) because it's faster/cheaper/ whatever. So, A sends the last request using addresses (A1,B1)=20 to see if it has become operational again. - Suppose that direction A1->B1 works, but B1->A1 does not (e.g. because of a malfunctioning middlebox or something; the cause does not really matter). B receives the packet, and if it hasn't seen it yet, processes it, sends reply, and (if it implements the NAT-T "SHOULD" from IKEv2) moves all traffic to=20 path (A1,B1). Which does not work. - In MOPO-IKE, path test is a separate message primarily because then it cannot interfere with anything else. Here,=20 host A would not receive B's reply to the PATH_TEST=20 message, and traffic would stay on path (A2,B2) which=20 is working fine. Of course, there are several ways how this particular problem could be fixed. (Or we could define this as a feature rather than a problem :-) IMHO going through all these special cases and ensuring that they're handled correctly is more work (and more complexity in the spec) than a separate path test message. But perhaps the difference in complexity is not that big, so if people are really interested in working on those special cases, we could go that route, too... Best regards, Pasi > -----Original Message----- > From: Jari Arkko > Sent: Monday, May 09, 2005 2:27 PM > To: Tero Kivinen > Cc: Mohan Parthasarathy; MOBIKE Mailing List > Subject: Re: [Mobike] issue 11 -- window size >=20 >=20 > Hello folks, >=20 > We have had a lively discussion about this on the list. > We started by listing a couple of alternatives including > doing certain MOBIKE messages outside the window, > and requiring larger than 1 window sizes. Tero brought up > his proposal (see [1] and clarifications e.g. in [2]) which > can work under window size 1 while still fitting within > the regular IKEv2 message processing. Some discussion > was held on exactly how this can be integrated to NAT > traversal and potential future extensions. >=20 > My sense was that there were at least some persons who > felt that Tero's approach is good enough. I think Mohan > was the only one who had question marks > about this, e.g., why pick it over others and how well it > works with NATs. How do others who have not voiced > an opinion yet feel? Are there serious issues with Tero's > proposal? If not, we could just do what Tero proposed. >=20 > --Jari >=20 > [1] http://www.machshav.com/pipermail/mobike/2005-April/000730.html > [2] http://www.machshav.com/pipermail/mobike/2005-April/000752.html >=20 >=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 May 9 10:31:19 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19250 for ; Mon, 9 May 2005 10:31:19 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B3233FB283; Mon, 9 May 2005 10:31:19 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8AE31FB27F; Mon, 9 May 2005 10:31:18 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A053AFB282; Mon, 9 May 2005 10:31:16 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id 87E03FB27D for ; Mon, 9 May 2005 10:31:15 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j49EVDI20418 for ; Mon, 9 May 2005 17:31:13 +0300 (EET DST) X-Scanned: Mon, 9 May 2005 17:30:01 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j49EU1QR008652 for ; Mon, 9 May 2005 17:30:01 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 004Zm8Vp; Mon, 09 May 2005 17:30:00 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 j49ETwM23683 for ; Mon, 9 May 2005 17:29:58 +0300 (EET DST) Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 9 May 2005 17:29:23 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 May 2005 17:29:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issues 18, 15, 6 -- return routability Date: Mon, 9 May 2005 17:29:22 +0300 Message-ID: Thread-Topic: [Mobike] issues 18, 15, 6 -- return routability Thread-Index: AcVSRLb7KiNUGG+2TxSMiHBxlT/DWACXe4aw From: To: X-OriginalArrivalTime: 09 May 2005 14:29:23.0028 (UTC) FILETIME=[7E98E940:01C554A3] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Hi, I think we came to agreement on when we can skip the test=20 completely (by default, do the check; fancier authorization is possible but does not have to be standardized). But what about the before/after moving the traffic part? (My suggestion would be that this does not have to be=20 standardized either. Implementations could even decide it=20 on the fly based on some fancy criteria such as credit-based=20 things or something.) Best regards, Pasi > -----Original Message----- > From: Jari Arkko > Sent: Friday, May 06, 2005 5:03 PM > To: Francis Dupont > Cc: mobike@machshav.com > Subject: Re: [Mobike] issues 18, 15, 6 -- return routability >=20 >=20 > Hi Francis, >=20 > > - If the specific IP address can be found in the peer's=20 > > certificate, you can skip the test > > =20 > > =3D> I maintain my proposal to change this into "if the=20 > > specific IP address is already authorized, you can skip=20 > > the test".This is more general (as there can be other ways=20 > > to authorized an address) and more accurate (so it should=20 > > answer Vijay's concern). > > Agreed. I think we can close this issue now. >=20 > (At first when I saw this I thought there might be an issue > with regards to having clear implementation requirements. > I.e. what is the minimum that an implementation has to do. > But then I realized that the way that we are apparently going > to write this is that the additional authorization mechanisms > are optional, i.e. the minimum you have to do is to always > do the test. It doesn't matter if you support certificates or > xmlconf admin interface or look at the moon's phase...) >=20 > --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue May 10 01:04:14 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19217 for ; Tue, 10 May 2005 01:04:13 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 6A9DDFB286; Tue, 10 May 2005 01:04:11 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C9195FB27C; Tue, 10 May 2005 01:04:05 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CED61FB27D; Tue, 10 May 2005 01:04:04 -0400 (EDT) Received: from smtp801.mail.sc5.yahoo.com (smtp801.mail.sc5.yahoo.com [66.163.168.180]) by machshav.com (Postfix) with SMTP id BC99CFB277 for ; Tue, 10 May 2005 01:04:03 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.163.212.130 with login) by smtp801.mail.sc5.yahoo.com with SMTP; 10 May 2005 05:04:00 -0000 Message-ID: <001101c5551d$b08cb0b0$6501a8c0@adithya> From: "Mohan Parthasarathy" To: , "MOBIKE Mailing List" References: <00ee01c5550e$89114280$6501a8c0@adithya> Subject: Re: [Mobike] issue 11 -- window size Date: Mon, 9 May 2005 22:04:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > > Repeating myself from IETF62, Tero's proposal (using the latest > IKEv2 request as a path test message) works perfectly if the > responder never uses the addresses from the IP header for > anything else except transmitting the reply. All the cases > where the IP header is used for something else require some > kind of special handling, and this complicates things. > In my understanding, the new addresses is just used only for the reply but i can see how it interacts badly with IKEv2 NAT-T. > One example that I mentioned to Tero in Minneapolis... > > - Current path (A1,B1) stops working, and the peers switch > to (A2,B2). A is behind a NAT in both cases. > > - After a while (A2,B2) still works (and continues working), but > the peers really prefer (A1,B1) because it's faster/cheaper/ > whatever. So, A sends the last request using addresses (A1,B1) > to see if it has become operational again. > > - Suppose that direction A1->B1 works, but B1->A1 does not > (e.g. because of a malfunctioning middlebox or something; the > cause does not really matter). B receives the packet, and if > it hasn't seen it yet, processes it, sends reply, and (if it > implements the NAT-T "SHOULD" from IKEv2) moves all traffic to > path (A1,B1). Which does not work. > > - In MOPO-IKE, path test is a separate message primarily > because then it cannot interfere with anything else. Here, > host A would not receive B's reply to the PATH_TEST > message, and traffic would stay on path (A2,B2) which > is working fine. > If the window size is 1, you have to retransmit the last message with a new address (discovered through PATH_TEST message in your case). If "A" retransmits the message with new address (A1, B1), why does'nt B move all traffic to path (A1, B1) ? How is this prevented in MOPO-IKE ? -mohan > Of course, there are several ways how this particular problem > could be fixed. (Or we could define this as a feature rather > than a problem :-) > > IMHO going through all these special cases and ensuring that > they're handled correctly is more work (and more complexity in > the spec) than a separate path test message. But perhaps the > difference in complexity is not that big, so if people are > really interested in working on those special cases, we could > go that route, too... > > Best regards, > Pasi > > > -----Original Message----- > > From: Jari Arkko > > Sent: Monday, May 09, 2005 2:27 PM > > To: Tero Kivinen > > Cc: Mohan Parthasarathy; MOBIKE Mailing List > > Subject: Re: [Mobike] issue 11 -- window size > > > > > > Hello folks, > > > > We have had a lively discussion about this on the list. > > We started by listing a couple of alternatives including > > doing certain MOBIKE messages outside the window, > > and requiring larger than 1 window sizes. Tero brought up > > his proposal (see [1] and clarifications e.g. in [2]) which > > can work under window size 1 while still fitting within > > the regular IKEv2 message processing. Some discussion > > was held on exactly how this can be integrated to NAT > > traversal and potential future extensions. > > > > My sense was that there were at least some persons who > > felt that Tero's approach is good enough. I think Mohan > > was the only one who had question marks > > about this, e.g., why pick it over others and how well it > > works with NATs. How do others who have not voiced > > an opinion yet feel? Are there serious issues with Tero's > > proposal? If not, we could just do what Tero proposed. > > > > --Jari > > > > [1] http://www.machshav.com/pipermail/mobike/2005-April/000730.html > > [2] http://www.machshav.com/pipermail/mobike/2005-April/000752.html > > > > > > _______________________________________________ > > Mobike mailing list > > Mobike@machshav.com > > https://www.machshav.com/mailman/listinfo.cgi/mobike > > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue May 10 02:58:37 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21468 for ; Tue, 10 May 2005 02:58:36 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 8C326FB27F; Tue, 10 May 2005 02:58:36 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 159A8FB27C; Tue, 10 May 2005 02:58:35 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 855FCFB27D; Tue, 10 May 2005 02:58:33 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id 481CCFB249 for ; Tue, 10 May 2005 02:58:31 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j4A6wTI23339; Tue, 10 May 2005 09:58:29 +0300 (EET DST) X-Scanned: Tue, 10 May 2005 09:56:19 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j4A6uJKK021235; Tue, 10 May 2005 09:56:19 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00rlLRqD; Tue, 10 May 2005 09:56:18 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 j4A6u7M29203; Tue, 10 May 2005 09:56:07 +0300 (EET DST) Received: from esebh107.NOE.Nokia.com ([172.21.143.143]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 May 2005 09:55:55 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 09:55:53 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 09:55:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issue 11 -- window size Date: Tue, 10 May 2005 09:55:52 +0300 Message-ID: Thread-Topic: [Mobike] issue 11 -- window size Thread-Index: AcVVHfIlsmdJqoPtQyS7dJNbNYELAwADY0Fw From: To: , X-OriginalArrivalTime: 10 May 2005 06:55:53.0449 (UTC) FILETIME=[4ED66590:01C5552D] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Mohan Parthasarathy wrote: > > - In MOPO-IKE, path test is a separate message primarily > > because then it cannot interfere with anything else. Here,=20 > > host A would not receive B's reply to the PATH_TEST=20 > > message, and traffic would stay on path (A2,B2) which=20 > > is working fine. > > If the window size is 1, you have to retransmit the last message=20 > with a new address (discovered through PATH_TEST message in your=20 > case). If "A" retransmits the message with new address (A1, B1),=20 > why does'nt B move all traffic to path (A1, B1) ? How is this=20 > prevented in MOPO-IKE ? In the example I gave the current path (A2,B2) was working all the time, so there's no need to retransmit the last message over (A1,B1). But if (A2,B2) stops working, and we discover that (A3,B3) works, then MOPO-IKE retransmits any outstanding requests using (A3,B3). If NAT-T was enabled, this can cause the responder to move all traffic=20 to (A3,B3).... but in this case it's not a problem, because that's what we wanted to do anyway!=20 (I did consider this interaction of NAT-T and MOPO-IKE when making=20 MOPO-IKE draft version -02, although there's no explicit text about it.=20 In other words, MOPO-IKE does not require changing NAT-T behavior=20 in this situation: when the host "outside NAT" receives a valid=20 authenticated packet, it can update the address+port as usual.) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue May 10 04:03:01 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26032 for ; Tue, 10 May 2005 04:03:01 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 96500FB27F; Tue, 10 May 2005 04:03:01 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D7DBDFB277; Tue, 10 May 2005 04:03:00 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 74E96FB27C; Tue, 10 May 2005 04:02:59 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 3C3D5FB266 for ; Tue, 10 May 2005 04:02:58 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id CDA8D89863; Tue, 10 May 2005 11:02:56 +0300 (EEST) Message-ID: <42806AB8.1070007@piuha.net> Date: Tue, 10 May 2005 11:03:04 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] issue 11 -- window size References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Hi Pasi, >- Current path (A1,B1) stops working, and the peers switch > to (A2,B2). A is behind a NAT in both cases. > >- After a while (A2,B2) still works (and continues working), but > the peers really prefer (A1,B1) because it's faster/cheaper/ > whatever. So, A sends the last request using addresses (A1,B1) > to see if it has become operational again. > >- Suppose that direction A1->B1 works, but B1->A1 does not > (e.g. because of a malfunctioning middlebox or something; the > cause does not really matter). B receives the packet, and if > it hasn't seen it yet, processes it, sends reply, and (if it > implements the NAT-T "SHOULD" from IKEv2) moves all traffic to > path (A1,B1). Which does not work. > > OK, I see the problem now. It looks like there are sevaral subtasks in what we are trying to do: (i) test (ii) commit to particular set of addresses (iii) manage unidirectional connectivity (#19) Tero's model, as I understand it, appears to combine both (i) and (ii) as well as disallow unidirectional connectivity. In a sense his model is less flexible, but at the same time simpler. A good tradeoff? Lets think about it. Anyway, presumably you could modify Tero's proposal to separate (i) and (ii). The drawback in that is that if there's a change in connectivity between initiating (ii) and completing it, you have no possibility to send a test message -- only a commit message. This is because the model requires sequenced delivery of all messages. But what exactly is the problem that results from this? Presumably you wanted to commit to a particular set of addresses. So the only reason why you might want to start testing is that you don't get a response. If you have just one alternative left, then there's no issue -- switch to it, with commit, if you can. But if there are multiple alternatives, then you might wish to test which one to choose. Question: could you do this by ordering the retransmissions of the commit message in a proper way? (Or am I now in the area of trying to fix the special cases that you Pasi were worried about?) --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue May 10 05:12:42 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00847 for ; Tue, 10 May 2005 05:12:41 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 12C4BFB27D; Tue, 10 May 2005 05:12:42 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A17C2FB266; Tue, 10 May 2005 05:12:38 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 510F0FB277; Tue, 10 May 2005 05:12:36 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 420C1FB266 for ; Tue, 10 May 2005 05:12:34 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j4A9CURn027473 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 10 May 2005 12:12:31 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j4A9CUOn027470; Tue, 10 May 2005 12:12:30 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17024.31485.363865.154285@fireball.kivinen.iki.fi> Date: Tue, 10 May 2005 12:12:29 +0300 From: Tero Kivinen To: Subject: RE: [Mobike] issue 11 -- window size In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 20 min X-Total-Time: 59 min Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > - Current path (A1,B1) stops working, and the peers switch > to (A2,B2). A is behind a NAT in both cases. > > - After a while (A2,B2) still works (and continues working), but > the peers really prefer (A1,B1) because it's faster/cheaper/ > whatever. So, A sends the last request using addresses (A1,B1) > to see if it has become operational again. > > - Suppose that direction A1->B1 works, but B1->A1 does not > (e.g. because of a malfunctioning middlebox or something; the > cause does not really matter). B receives the packet, and if > it hasn't seen it yet, processes it, sends reply, and (if it > implements the NAT-T "SHOULD" from IKEv2) moves all traffic to > path (A1,B1). Which does not work. Yes, IKEv2 NAT-T does not support unidirectional paths. That does not mean that our MOBIKE protocol needs to do that. On the other hand, I am not sure we want to support unidirectional paths. I had a feeling we already somewhere decided that we do require two-way connection between working addresses, i.e. we are not supposed to support such thing. The MOBIKE protocol can simply use path test and actual changes as a separate message, there is no reason to do the changes based on the other packets. On the other hand other packets can be used as a path test message, as it does answer to the question "does this path work?" > - In MOPO-IKE, path test is a separate message primarily > because then it cannot interfere with anything else. Here, > host A would not receive B's reply to the PATH_TEST > message, and traffic would stay on path (A2,B2) which > is working fine. If MOBIKE protocol uses separate N(MOVE TRAFFIC) then that thing can only happen for very short time, and it will be fixed immediately after that. I.e. if we detect that A1<->B1 path works in both ways and we want to move to it, and we send N(MOVE TRAFFIC). If the path A1<->B1 now breaks so that A cannot get reply back, but B has already moved traffic, then A will notice that it cannot get replies back so it starts trying other addresses, and when it finds a working path the traffic is then moved to that (either implicitly by B updating the IPsec SAs for each address A tries, or explicitly by B ignoring retransmissions of N(MOVE TRAFFIC) with different address, and A noticing after exchange, that traffic got moved to wrong address, and redoing the N(MOVE TRAFFIC)). Same thing can happen in MOPO-IKE if the path happens to break between path test and traffic move operations. > Of course, there are several ways how this particular problem > could be fixed. (Or we could define this as a feature rather > than a problem :-) Yes, and as we are not talking about the actual protocol, we simply need to agree here that those things can be solved. We are trying to decide the higher level option, and if you find some fundamental problem, which cannot be solved at all then we want to hear it now... > IMHO going through all these special cases and ensuring that > they're handled correctly is more work (and more complexity in > the spec) than a separate path test message. But perhaps the > difference in complexity is not that big, so if people are > really interested in working on those special cases, we could > go that route, too... Most of the same special cases needs to be handled regardless weather the path test is separate or not. We need to solve the thing what to do for the ongoing exchange when the path breaks during it. We cannot modify the packet anymore, and we must deliver it to the end, meaning that we need to modify the outer header of that packet anyway, thus same problems. I haven't read the MOPO draft for a while, so I do not remember how those issues were solved there. Perhaps I need to reread it now and see how things are done there... -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue May 10 06:47:38 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11562 for ; Tue, 10 May 2005 06:47:38 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 75D12FB27D; Tue, 10 May 2005 06:47:39 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A7083FB266; Tue, 10 May 2005 06:47:37 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5CDE6FB277; Tue, 10 May 2005 06:47:36 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by machshav.com (Postfix) with ESMTP id 0B946FB262 for ; Tue, 10 May 2005 06:47:35 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j4AAlS828753; Tue, 10 May 2005 13:47:28 +0300 (EET DST) X-Scanned: Tue, 10 May 2005 13:44:39 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j4AAidAv001643; Tue, 10 May 2005 13:44:39 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00frtlZ7; Tue, 10 May 2005 13:44:38 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j4AAiFM10787; Tue, 10 May 2005 13:44:16 +0300 (EET DST) Received: from esebh107.NOE.Nokia.com ([172.21.143.143]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 May 2005 13:44:14 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 13:44:10 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 13:44:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issue 11 -- window size Date: Tue, 10 May 2005 13:44:10 +0300 Message-ID: Thread-Topic: [Mobike] issue 11 -- window size Thread-Index: AcVVQKtiJMMSDp1PRZmig9B7WLHq0QACzclw From: To: X-OriginalArrivalTime: 10 May 2005 10:44:09.0614 (UTC) FILETIME=[326352E0:01C5554D] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: > > - Suppose that direction A1->B1 works, but B1->A1 does not > > (e.g. because of a malfunctioning middlebox or something;=20 > > the cause does not really matter). B receives the packet,=20 > > and if it hasn't seen it yet, processes it, sends reply,=20 > > and (if it implements the NAT-T "SHOULD" from IKEv2) moves=20 > > all traffic to path (A1,B1). Which does not work. >=20 > Yes, IKEv2 NAT-T does not support unidirectional paths. That=20 > does not mean that our MOBIKE protocol needs to do that. >=20 > On the other hand, I am not sure we want to support unidirectional > paths. I had a feeling we already somewhere decided that we do > require two-way connection between working addresses, i.e. we are > not supposed to support such thing. Yes, I also think we should not support unidirectional paths, but there are two quite different ways we can do that: 1) treat unidirectional paths the same way as totally=20 dead paths: don't use them 2) assume that unidirectional paths never occur, and=20 possibly fail in weird ways if they do IMHO we should do the first. > The MOBIKE protocol can simply use path test and actual changes=20 > as a separate message, there is no reason to do the changes based=20 > on the other packets. On the other hand other packets can be used=20 > as a path test message, as it does answer to the question "does=20 > this path work?" Not unless we change NAT-T a bit, because currently it can treat=20 any authenticated packet as a change (rather than just test).=20 MOPO-IKE's approach, using a separate PATH_TEST message that is neither part of any IKE_SA nor authenticated solves works with=20 current NAT-T behavior. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue May 10 07:08:09 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13205 for ; Tue, 10 May 2005 07:08:07 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B939DFB27C; Tue, 10 May 2005 07:08:09 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 62769FB266; Tue, 10 May 2005 07:08:07 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 433E2FB277; Tue, 10 May 2005 07:08:05 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id DAE8AFB262 for ; Tue, 10 May 2005 07:07:58 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j4AB7tTq028882 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 10 May 2005 14:07:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j4AB7rwN028877; Tue, 10 May 2005 14:07:53 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17024.38409.529578.205540@fireball.kivinen.iki.fi> Date: Tue, 10 May 2005 14:07:53 +0300 From: Tero Kivinen To: Subject: RE: [Mobike] issue 11 -- window size In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: mohanp@sbcglobal.net, mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > Mohan Parthasarathy wrote: > > > > - In MOPO-IKE, path test is a separate message primarily > > > because then it cannot interfere with anything else. Here, > > > host A would not receive B's reply to the PATH_TEST > > > message, and traffic would stay on path (A2,B2) which > > > is working fine. > > > > If the window size is 1, you have to retransmit the last message > > with a new address (discovered through PATH_TEST message in your > > case). If "A" retransmits the message with new address (A1, B1), > > why does'nt B move all traffic to path (A1, B1) ? How is this > > prevented in MOPO-IKE ? > > In the example I gave the current path (A2,B2) was working all the > time, so there's no need to retransmit the last message over (A1,B1). > > But if (A2,B2) stops working, and we discover that (A3,B3) works, > then MOPO-IKE retransmits any outstanding requests using (A3,B3). > If NAT-T was enabled, this can cause the responder to move all traffic > to (A3,B3).... but in this case it's not a problem, because that's > what we wanted to do anyway! Same happens in my proposal too. When the A does not get answer back from the (A2,B2) of its update message, it starts path testing, and finally finds the (A3, B3) that works, and uses that. Now depending on the protocol the B has already moved traffic to (A3, B3), or A manually does that after noticing the situation. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue May 10 07:29:49 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15510 for ; Tue, 10 May 2005 07:29:49 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 6BEE9FB282; Tue, 10 May 2005 07:29:47 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D95DAFB266; Tue, 10 May 2005 07:29:41 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BC9C7FB277; Tue, 10 May 2005 07:29:40 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id A93B9FB24A for ; Tue, 10 May 2005 07:29:38 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j4ABTasa029161 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 10 May 2005 14:29:37 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j4ABTZKR029158; Tue, 10 May 2005 14:29:35 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17024.39710.963089.294194@fireball.kivinen.iki.fi> Date: Tue, 10 May 2005 14:29:34 +0300 From: Tero Kivinen To: Jari Arkko Subject: Re: [Mobike] issue 11 -- window size In-Reply-To: <42806AB8.1070007@piuha.net> References: <42806AB8.1070007@piuha.net> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 13 min X-Total-Time: 16 min Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari Arkko writes: > OK, I see the problem now. It looks like there are > sevaral subtasks in what we are trying to do: > > (i) test > (ii) commit to particular set of addresses > (iii) manage unidirectional connectivity (#19) > > Tero's model, as I understand it, appears to combine > both (i) and (ii) as well as disallow unidirectional > connectivity. In a sense his model is less flexible, but > at the same time simpler. A good tradeoff? Lets think > about it. The protocol in my model can be defined either to combine (i) and (ii) or do them as separate steps. i think it might be better to do them in separate steps. On the other hand in my proposal all (ii) commit messages are also always (i) test messages too, but not other way around. (iii) I do not think we should try to work around with unidirectional connectivity. > Anyway, presumably you could modify Tero's proposal > to separate (i) and (ii). The drawback in that is that > if there's a change in connectivity between initiating > (ii) and completing it, you have no possibility to send a > test message -- only a commit message. This is because > the model requires sequenced delivery of all messages. But as each (ii) is also (i) message, the result of that will be that you have done new test and have a new address pair that works, so you can initiate (ii) again immediately and move traffic there. In the mean time the traffic might be going to some other non-working address, but that it was most likely going to non-working address already before, as that is the reason why we started (ii), so no difference there. > But what exactly is the problem that results from this? > Presumably you wanted to commit to a particular > set of addresses. So the only reason why you might > want to start testing is that you don't get a response. > If you have just one alternative left, then there's no > issue -- switch to it, with commit, if you can. But if there > are multiple alternatives, then you might wish to test > which one to choose. In my proposal you can test it with empty information exchange (i.e. DPD). That will return new working pair of address. I had separate N(MOVE TRAFFIC) notify which was used to move traffic. But as N(MOVE TRAFFIC) is normal IKEv2 packet then it also acts as test packet. > Question: could you do this by ordering the retransmissions of the > commit message in a proper way? (Or am I now in the area of trying > to fix the special cases that you Pasi were worried about?) The protocol could periodicly or every time it notices change do path test with all paths with normal DPD style packet. That would not do any change in the MOBIKE state yet. When the working best path is found then the protocol could move traffic to new address pair by N(MOVE TRAFFIC) notify. For IKEv2 NAT-T interaction you have also couple of options. Easiest is simply say that NAT-T works as defined in the IKEv2, but the SHOULD for implicit update is MUST, and if initiator detects that N(MOVE TRAFFIC) did't go through with selected pair, and it needs to rever to test path method, then it needs to do N(MOVE TRAFFIC) again with new working path. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue May 10 07:43:37 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17172 for ; Tue, 10 May 2005 07:43:37 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 59158FB27F; Tue, 10 May 2005 07:43:37 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D7674FB266; Tue, 10 May 2005 07:43:35 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2A058FB277; Tue, 10 May 2005 07:43:35 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 3C413FB262 for ; Tue, 10 May 2005 07:43:33 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j4ABhVLE029348 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 10 May 2005 14:43:31 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j4ABhUI1029345; Tue, 10 May 2005 14:43:30 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17024.40546.208682.812288@fireball.kivinen.iki.fi> Date: Tue, 10 May 2005 14:43:30 +0300 From: Tero Kivinen To: Subject: RE: [Mobike] issue 11 -- window size In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 13 min X-Total-Time: 12 min Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > Yes, I also think we should not support unidirectional paths, > but there are two quite different ways we can do that: > > 1) treat unidirectional paths the same way as totally > dead paths: don't use them > 2) assume that unidirectional paths never occur, and > possibly fail in weird ways if they do > > IMHO we should do the first. I agree in that. My proposal works fine even if there is unidirectional path, it will not simply use them. During the path test it might try to use them, but after the path test is finished it either has found working bi-directional path or the connection has been broken down. > > The MOBIKE protocol can simply use path test and actual changes > > as a separate message, there is no reason to do the changes based > > on the other packets. On the other hand other packets can be used > > as a path test message, as it does answer to the question "does > > this path work?" > > Not unless we change NAT-T a bit, because currently it can treat > any authenticated packet as a change (rather than just test). > MOPO-IKE's approach, using a separate PATH_TEST message that is > neither part of any IKE_SA nor authenticated solves works with > current NAT-T behavior. There is no need to change NAT-T unless we want to. The initiator can detect the situation and it can fix it by sending one more packet with proper source and destination address. The IKEv2 does not clarify if retransmissions of the previous packets are considered as valid authenticated packets, and if the IP-addresses needs to be updated for each of those, or only for the first. Regardless what implementations do on that, we can simply fix the situation by sending new N(MOVE TRAFFIC) exchange with proper address pair. Exactly same thing happens if the path happens to break when MOPO-IKE is sending the address update packet, and path happens to break in the middle of that exchange. On the other hand we do want to modify NAT-T a bit, at lest say that the dynamically updating addresses is MUST, so we might want to clarify this issue also. Yes, I agree that doing probing of previously non-working addresses, which now have unidirectional connection, can cause the connection to loose packets in case there is NAT between both connections we are trying to use. So I suggest we do not try to do probing on that case, but simply start finding the working path only after we know there is problem with current path. As the path information is going to expire very quickly anyways, I am not sure how much probing different paths while the current path still works is going to help. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue May 10 08:31:39 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21190 for ; Tue, 10 May 2005 08:31:38 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5DF56FB27D; Tue, 10 May 2005 08:31:38 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 63ABEFB262; Tue, 10 May 2005 08:31:36 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 49E1EFB277; Tue, 10 May 2005 08:31:34 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by machshav.com (Postfix) with ESMTP id 47565FB262 for ; Tue, 10 May 2005 08:31:33 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j4ACVT806359; Tue, 10 May 2005 15:31:29 +0300 (EET DST) X-Scanned: Tue, 10 May 2005 15:28:46 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j4ACSk0r025884; Tue, 10 May 2005 15:28:46 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00Rwq1n8; Tue, 10 May 2005 15:28:45 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 j4ACSju20248; Tue, 10 May 2005 15:28:45 +0300 (EET DST) Received: from esebh107.NOE.Nokia.com ([172.21.143.143]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 May 2005 15:11:19 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 15:11:19 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 15:11:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issue 11 -- window size Date: Tue, 10 May 2005 15:11:20 +0300 Message-ID: Thread-Topic: [Mobike] issue 11 -- window size Thread-Index: AcVVVcPcdyTe3ge7Qaem4MNKddUrVgAAa1xw From: To: X-OriginalArrivalTime: 10 May 2005 12:11:18.0716 (UTC) FILETIME=[5F2CF7C0:01C55559] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Tero Kivinen writes: > Yes, I agree that doing probing of previously non-working=20 > addresses, which now have unidirectional connection, can cause=20 > the connection to loose packets in case there is NAT between both=20 > connections we are trying to use. So I suggest we do not try to do=20 > probing on that case, but simply start finding the working path only=20 > after we know there is problem with current path. I think it is useful to allow path testing even when the current path is working, and the protocol should support doing this=20 without disrupting ongoing communication (which does not seem to be possible in your proposal). (E.g., suppose we have two interfaces, one very fast and cheap,=20 second one very slow and expensive. If the first one has a temporary=20 problem, and we switch to the second one, we want to switch back=20 when possible even if the second interface keeps on working forever.) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue May 10 21:24:42 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10886 for ; Tue, 10 May 2005 21:24:41 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 622C6FB27F; Tue, 10 May 2005 21:24:41 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 09551FB24A; Tue, 10 May 2005 21:24:39 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 10B1BFB262; Tue, 10 May 2005 21:24:37 -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 517D9FB249 for ; Tue, 10 May 2005 21:24:36 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.163.215.90 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 11 May 2005 01:24:35 -0000 Message-ID: <06b501c555c8$3219d0e0$6501a8c0@adithya> From: "Mohan Parthasarathy" To: References: <06a501c555c5$e39b6f20$6501a8c0@adithya> Subject: Re: [Mobike] issue 11 -- window size Date: Tue, 10 May 2005 18:24:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: MOBIKE Mailing List , Tero Kivinen X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > > Tero Kivinen writes: > > > Yes, I agree that doing probing of previously non-working > > addresses, which now have unidirectional connection, can cause > > the connection to loose packets in case there is NAT between both > > connections we are trying to use. So I suggest we do not try to do > > probing on that case, but simply start finding the working path only > > after we know there is problem with current path. > > I think it is useful to allow path testing even when the current > path is working, and the protocol should support doing this > without disrupting ongoing communication (which does not seem > to be possible in your proposal). > Yes, this is a useful feature that MOBIKE should provide. > (E.g., suppose we have two interfaces, one very fast and cheap, > second one very slow and expensive. If the first one has a temporary > problem, and we switch to the second one, we want to switch back > when possible even if the second interface keeps on working forever.) > I am wondering when the switch will happen. If we assume that the switch will not happen when the IPsec connection is actively used (e.g. streaming services), then Tero's proposal would still be okay because temporarily changing to a non-workable address will not affect much. But i don't understand why having a separate PATH_TEST message is such a big deal. I don't see additional complexity. So, what is the issue with having a separate PATH_TEST message ? Jari said it is simpler. I am not sure i understood that. -mohan > 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 Wed May 11 05:21:06 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16050 for ; Wed, 11 May 2005 05:21:04 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 52A72FB27F; Wed, 11 May 2005 05:21:05 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4E567FB262; Wed, 11 May 2005 05:21:04 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5C52CFB266; Wed, 11 May 2005 05:21:02 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id ED37DFB249 for ; Wed, 11 May 2005 05:21:00 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j4B9KuX8001476 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 11 May 2005 12:20:57 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j4B9KtAx001471; Wed, 11 May 2005 12:20:55 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17025.52854.874280.214582@fireball.kivinen.iki.fi> Date: Wed, 11 May 2005 12:20:54 +0300 From: Tero Kivinen To: Subject: RE: [Mobike] issue 11 -- window size In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 2 min Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > I think it is useful to allow path testing even when the current > path is working, and the protocol should support doing this > without disrupting ongoing communication (which does not seem > to be possible in your proposal). It is possible, the protocol just needs to be written so it supports it. If you want to get it working with IKEv2 NAT-T you need to add modify the NAT-T behavior when using MOBIKE little more (You need to modify the NAT-T behavior in all cases) > (E.g., suppose we have two interfaces, one very fast and cheap, > second one very slow and expensive. If the first one has a temporary > problem, and we switch to the second one, we want to switch back > when possible even if the second interface keeps on working forever.) Then you simply say that only N(MOVE TRAFFIC) is the only method of updating the addresses. I.e. disable dynamic updating of IKEv2 NAT-T (it is already allowed as dynamic update is SHOULD not MUST). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed May 11 13:15:52 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25023 for ; Wed, 11 May 2005 13:15:49 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D5F5FFB27C; Wed, 11 May 2005 13:15:50 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F1349FB262; Wed, 11 May 2005 13:15:48 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0713AFB266; Wed, 11 May 2005 13:15:48 -0400 (EDT) Received: from web80604.mail.yahoo.com (web80604.mail.yahoo.com [66.218.79.93]) by machshav.com (Postfix) with SMTP id 0E925FB246 for ; Wed, 11 May 2005 13:15:47 -0400 (EDT) Message-ID: <20050511171546.93784.qmail@web80604.mail.yahoo.com> Received: from [206.132.194.2] by web80604.mail.yahoo.com via HTTP; Wed, 11 May 2005 10:15:46 PDT Date: Wed, 11 May 2005 10:15:46 -0700 (PDT) From: Mohan Parthasarathy Subject: RE: [Mobike] issue 11 -- window size To: Tero Kivinen , Pasi.Eronen@nokia.com In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com --- Tero Kivinen wrote: > Pasi.Eronen@nokia.com writes: > > I think it is useful to allow path testing even > when the current > > path is working, and the protocol should support > doing this > > without disrupting ongoing communication (which > does not seem > > to be possible in your proposal). > > It is possible, the protocol just needs to be > written so it supports > it. If you want to get it working with IKEv2 NAT-T > you need to add > modify the NAT-T behavior when using MOBIKE little > more (You need to > modify the NAT-T behavior in all cases) > > > (E.g., suppose we have two interfaces, one very > fast and cheap, > > second one very slow and expensive. If the first > one has a temporary > > problem, and we switch to the second one, we want > to switch back > > when possible even if the second interface keeps > on working forever.) > > Then you simply say that only N(MOVE TRAFFIC) is the > only method of > updating the addresses. I.e. disable dynamic > updating of IKEv2 NAT-T > (it is already allowed as dynamic update is SHOULD > not MUST). I agree that this is one possibility i.e if the peer has indicated MOBIKE support, then disable NAT-T like updates. Expect that the peer will explicitly update the addresses. To some extent, this is needed even when PATH_TEST message is a separate message i.e when the PATH_TEST is processed, you don't update the addresses of the SAs yet. Somehow this looks cleaner to me :-) If there are several paths and some of them contains NAT, i am assuming that Tero's proposal can detect them (inspite of the constraint that the retransmitted message cannot be modified). If this is getting into too much detail, i will wait :-) -mohan > -- > kivinen@safenet-inc.com > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu May 12 03:54:27 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02715 for ; Thu, 12 May 2005 03:54:26 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 2D594FB283; Thu, 12 May 2005 03:54:27 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BCC32FB27C; Thu, 12 May 2005 03:54:25 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E20E4FB27F; Thu, 12 May 2005 03:54:24 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id BF0A7FB266 for ; Thu, 12 May 2005 03:54:23 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j4C7sJY6016447 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 12 May 2005 10:54:19 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j4C7sCma016444; Thu, 12 May 2005 10:54:12 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17027.2980.182276.169823@fireball.kivinen.iki.fi> Date: Thu, 12 May 2005 10:54:12 +0300 From: Tero Kivinen To: Mohan Parthasarathy Subject: RE: [Mobike] issue 11 -- window size In-Reply-To: <20050511171546.93784.qmail@web80604.mail.yahoo.com> References: <20050511171546.93784.qmail@web80604.mail.yahoo.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 2 min Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Mohan Parthasarathy writes: > If there are several paths and some of them contains > NAT, i am assuming that Tero's proposal can detect > them (inspite of the constraint that the retransmitted > message cannot be modified). If this is getting into > too much detail, i will wait :-) Yes, the initiator can detect NAT, as the responder will not try any other addresses, i.e. it always replies back to the address where addresess are reversed. This simply requires that we want to have option to turn NAT-T on / off as a separate notify, as requested by initiator after detecting NAT (and after consulting policy etc). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu May 12 04:16:59 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03926 for ; Thu, 12 May 2005 04:16:58 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C0297FB283; Thu, 12 May 2005 04:16:58 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 72B38FB27F; Thu, 12 May 2005 04:16:56 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 382AEFB280; Thu, 12 May 2005 04:16:54 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 2B43AFB27C for ; Thu, 12 May 2005 04:16:53 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 538E789879; Thu, 12 May 2005 11:16:51 +0300 (EEST) Message-ID: <428310FC.6000807@piuha.net> Date: Thu, 12 May 2005 11:17:00 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Mobike] issue 11 -- window size References: <20050511171546.93784.qmail@web80604.mail.yahoo.com> <17027.2980.182276.169823@fireball.kivinen.iki.fi> In-Reply-To: <17027.2980.182276.169823@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pasi.Eronen@nokia.com, Mohan Parthasarathy , mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Tero Kivinen wrote: >Mohan Parthasarathy writes: > > >>If there are several paths and some of them contains >>NAT, i am assuming that Tero's proposal can detect >>them (inspite of the constraint that the retransmitted >>message cannot be modified). If this is getting into >>too much detail, i will wait :-) >> >> > >Yes, the initiator can detect NAT, as the responder will not try any >other addresses, i.e. it always replies back to the address where >addresess are reversed. > >This simply requires that we want to have option to turn NAT-T on / >off as a separate notify, as requested by initiator after detecting >NAT (and after consulting policy etc). > > Ok. And doing this separately works, because the IKEv2 messages will always go through NATs and because the peer responds back to the same address/port combination, right? Its only the ESP traffic for which the specific NAT support needs to be turned on. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu May 12 05:03:22 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07311 for ; Thu, 12 May 2005 05:03:21 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 11724FB28A; Thu, 12 May 2005 05:03:21 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BABF9FB27C; Thu, 12 May 2005 05:03:16 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 42C71FB27F; Thu, 12 May 2005 05:03:15 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id D11A5FB266 for ; Thu, 12 May 2005 05:03:11 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j4C93867017225 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 12 May 2005 12:03:09 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j4C937XU017222; Thu, 12 May 2005 12:03:08 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17027.7115.840294.72154@fireball.kivinen.iki.fi> Date: Thu, 12 May 2005 12:03:07 +0300 From: Tero Kivinen To: Jari Arkko Subject: Re: [Mobike] issue 11 -- window size In-Reply-To: <428310FC.6000807@piuha.net> References: <20050511171546.93784.qmail@web80604.mail.yahoo.com> <17027.2980.182276.169823@fireball.kivinen.iki.fi> <428310FC.6000807@piuha.net> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 1 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.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari Arkko writes: > Ok. And doing this separately works, because the IKEv2 > messages will always go through NATs and because the > peer responds back to the same address/port combination, > right? Its only the ESP traffic for which the specific NAT > support needs to be turned on. Yes. I.e. ESP traffic that is moved to the path that has NAT, needs to be UDP-encapsulated. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu May 12 06:31:23 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12320 for ; Thu, 12 May 2005 06:31:22 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A8763FB28A; Thu, 12 May 2005 06:31:23 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CAE18FB27F; Thu, 12 May 2005 06:31:21 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 94F40FB280; Thu, 12 May 2005 06:31:19 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id D10DDFB27C for ; Thu, 12 May 2005 06:31:17 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5689389879; Thu, 12 May 2005 13:31:14 +0300 (EEST) Message-ID: <4283307B.1070305@piuha.net> Date: Thu, 12 May 2005 13:31:23 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] issues 18, 15, 6 -- return routability References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: >I think we came to agreement on when we can skip the test >completely (by default, do the check; fancier authorization >is possible but does not have to be standardized). But what > > Yes. >about the before/after moving the traffic part? > > There was a proposal in [1] with some support from [2] and [3], a related other question in [4], no opposition, but not a whole lot of discussion. But maybe this is in fact enough. Unless you see a significant technical issue, perhaps we should stick with the proposal, which was "do it before (if done at all)". [1] http://www.machshav.com/pipermail/mobike/2005-March/000692.html [2] http://www.machshav.com/pipermail/mobike/2005-March/000706.html [3] http://www.machshav.com/pipermail/mobike/2005-March/000708.html [4] http://www.machshav.com/pipermail/mobike/2005-March/000694.html --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri May 13 03:52:13 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18119 for ; Fri, 13 May 2005 03:52:12 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 511F1FB277; Fri, 13 May 2005 03:52:13 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A0E19FB249; Fri, 13 May 2005 03:52:12 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B9D50FB262; Fri, 13 May 2005 03:52:11 -0400 (EDT) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id E209CFB246 for ; Fri, 13 May 2005 03:52:10 -0400 (EDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4D7naB0023524 for ; Fri, 13 May 2005 10:49:44 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 May 2005 10:51:57 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 May 2005 10:51:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issue 11 -- window size Date: Fri, 13 May 2005 10:51:57 +0300 Message-ID: Thread-Topic: [Mobike] issue 11 -- window size Thread-Index: AcVWCwYOQXPhx2hUQtGEx7CHPyZMvABhUa5w From: To: X-OriginalArrivalTime: 13 May 2005 07:51:57.0795 (UTC) FILETIME=[A3621B30:01C55790] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Tero Kivinen writes: > It is possible, the protocol just needs to be written so it > supports it. If you want to get it working with IKEv2 NAT-T > you need to add modify the NAT-T behavior when using MOBIKE > little more (You need to modify the NAT-T behavior in all > cases) > >=20 > Then you simply say that only N(MOVE TRAFFIC) is the only > method of updating the addresses. I.e. disable dynamic > updating of IKEv2 NAT-T (it is already allowed as dynamic > update is SHOULD not MUST). Ok, reading this and your previous messages, I think I finally understood what you meant.. Yes, it seems that this can be made to work (but IMHO it's much more complicated than a separate path test message). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri May 13 04:14:08 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19353 for ; Fri, 13 May 2005 04:14:07 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 67F16FB27D; Fri, 13 May 2005 04:14:08 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6BF68FB262; Fri, 13 May 2005 04:14:07 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8AB98FB266; Fri, 13 May 2005 04:14:05 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id E9110FB249 for ; Fri, 13 May 2005 04:14:04 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9E32189879; Fri, 13 May 2005 11:14:03 +0300 (EEST) Message-ID: <428461D5.7080006@piuha.net> Date: Fri, 13 May 2005 11:14:13 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] issue 11 -- window size References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: >Ok, reading this and your previous messages, I think I finally >understood what you meant.. Yes, it seems that this can be made >to work (but IMHO it's much more complicated than a separate >path test message). > > Good, so we have two window=1 alternatives. The problem that we have, however, is that we've only got one that is described in a very detailed manner, i.e. what you Pasi have in MOPO. But I talked to Tero and he promised to write up a more detailed proposal about this at some point. So I would suggest that we conclude this issue, for now -- the discussion seems to converge on some window=1 alternative, as far as I can see. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri May 13 04:24:05 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19898 for ; Fri, 13 May 2005 04:24:05 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 766E6FB280; Fri, 13 May 2005 04:24:06 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C2571FB262; Fri, 13 May 2005 04:24:03 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 36F28FB266; Fri, 13 May 2005 04:24:00 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 92BE0FB249 for ; Fri, 13 May 2005 04:23:59 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id DD5B689879; Fri, 13 May 2005 11:23:58 +0300 (EEST) Message-ID: <42846428.4010005@piuha.net> Date: Fri, 13 May 2005 11:24:08 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] issues 18, 15, 6 -- return routability References: <4283307B.1070305@piuha.net> In-Reply-To: <4283307B.1070305@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Here's a more detailed text proposal: "By default, return routability test is done before moving the traffic. However, [as decided in issue 18] these tests are optional. Nodes MAY also perform these tests upon their own initiative at other times." This seems to cover the opinion of the folks expressed earlier on the list, as well as your comments. Ok? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri May 13 05:20:42 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23606 for ; Fri, 13 May 2005 05:20:41 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id BA4F7FB27C; Fri, 13 May 2005 05:20:41 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6B3B4FB249; Fri, 13 May 2005 05:20:39 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8F25AFB262; Fri, 13 May 2005 05:20:38 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 0604CFB246 for ; Fri, 13 May 2005 05:20:38 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6C3B689879 for ; Fri, 13 May 2005 12:20:36 +0300 (EEST) Message-ID: <4284716E.2080404@piuha.net> Date: Fri, 13 May 2005 12:20:46 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] issue 19 -- same addresses for both directions? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit It looks to me that the decision on issue 20 (who decides) is the main determining factor issue 19 as well. If issue 20 resolution is that the initiator decides, then it more or less follows that we have same addresses in both directions. We can imagine different addresses even in this case, but it does not appear to be very useful or necessary. On the other hand, if we decide in 20 that the decisions are independent, then it may in fact be very hard to ensure that the two directions use the same addresses. As a result, allowing different addresses would make more sense in this scenario. My conclusion is that we should focus on trying to solve issue 20 first. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri May 13 05:23:36 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24531 for ; Fri, 13 May 2005 05:23:35 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 64728FB280; Fri, 13 May 2005 05:23:37 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A47BBFB249; Fri, 13 May 2005 05:23:32 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C5389FB262; Fri, 13 May 2005 05:23:30 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 398C2FB246 for ; Fri, 13 May 2005 05:23:30 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8E22189879 for ; Fri, 13 May 2005 12:23:29 +0300 (EEST) Message-ID: <4284721B.70806@piuha.net> Date: Fri, 13 May 2005 12:23:39 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] issue 1 - indirect indicators X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit It seems to me that our understanding of this problem has develop a lot since we originally wrote issue 1. We now have a better understanding of what other components there are in a system and how Mobike interacts with them; we are debating which entity makes decisions (20), we have decided what to do when the sign of trouble is a lack of packets (16), we have decided what kind of connectivity assumptions we make (17), and we are working through how the appearance of NATs on a new path affects MOBIKE (3). In conclusion it seems that we are already covering the details in several other issues. Therefore issue 1 will be closed as a duplicate. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri May 13 06:04:31 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28926 for ; Fri, 13 May 2005 06:04:31 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 408C0FB277; Fri, 13 May 2005 06:04:33 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 690FDFB249; Fri, 13 May 2005 06:04:32 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AB9BAFB262; Fri, 13 May 2005 06:04:31 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 8B89CFB246 for ; Fri, 13 May 2005 06:04:30 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D9C7089879 for ; Fri, 13 May 2005 13:04:29 +0300 (EEST) Message-ID: <42847BB7.4050100@piuha.net> Date: Fri, 13 May 2005 13:04:39 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] issue 3 - nats X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Some personal thoughts on solutions for this issue: We have consensus that MOBIKE and NAT-T need to work together. It seems like the core of the remaining issue is "what exactly does this mean" and "what can we achieve, given protocol and other limitations". One way to approch these questions is to try to break down the problem in smaller pieces. For instance, I believe the following questions have been asked at one point or another during the discussion: Scenarios that we can support (a) Can we move behind a NAT? (b) Can we move out from a NAT? (c) To which extent do we support the case that party outside the NAT moves? (d) If we are behind a NAT, can peer have multiple addresses? (e) If we are behind a NAT on one interface, can another interface work without NAT/NAT-T? (f) Can the responder be behind a NAT? New functionality (g) Do we need NAT prevention? (h) Do we want to disable UDP encapsulation when moving outside from behind a NAT? Implementation (i) Send keepalives on current or on all paths? (j) How do we detect NATs? Conformance requirements (k) Is NAT-T support still optional within MOBIKE? Does this cover everything, or do we have additional questions? Here are also some tentative answers to the questions: (a) Can we move behind a NAT? [Yes. But requires NAT-D payloads in the address change message, as discussed under issue 11.] (b) Can we move out from a NAT? [Yes. Does not require much. But see item h.] (c) To which extent do we support the case that party outside the NAT moves? [No. This one is really hard. We will make our life much simpler by saying no here. Outsider may not be able to initiate anything inside. The only exception is covered under item f.] (d) If we are behind a NAT, can peer have multiple addresses? [Yes. Contrary to mobility, multihoming is possible quite easily. Detailed protocol design has some further details that need to be developed later, e.g., is there a need to do keepalives on all address pairs? Tentatively, the answer to that is no.] (e) If we are behind a NAT on one interface, can another interface work without NAT/NAT-T? [Yes.] (f) Can the responder be behind a NAT? [Yes, but in a very limited scenario, when the NAT is a static NAT and not a NAPT.] (g) Do we need NAT prevention? [Yes.] (h) Do we want to disable UDP encapsulation when moving outside from behind a NAT? [Yes.] (i) Send keepalives on current or on all paths? [To be decided later.] (j) How do we detect NATs? [Using NAT-T functionality.] (k) Is NAT-T support still optional within MOBIKE? [Yes. You should be able to use MOBIKE in plain v6 environments, for instance.] --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri May 13 06:26:18 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01338 for ; Fri, 13 May 2005 06:26:17 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5A0E3FB277; Fri, 13 May 2005 06:26:19 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 50FD2FB249; Fri, 13 May 2005 06:26:13 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E446FFB262; Fri, 13 May 2005 06:26:11 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 9BBF2FB246 for ; Fri, 13 May 2005 06:26:10 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j4DAQ7Aa002323 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 13 May 2005 13:26:08 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j4DAQ33i002314; Fri, 13 May 2005 13:26:03 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17028.32954.849644.866018@fireball.kivinen.iki.fi> Date: Fri, 13 May 2005 13:26:02 +0300 From: Tero Kivinen To: Jari Arkko Subject: [Mobike] issue 3 - nats In-Reply-To: <42847BB7.4050100@piuha.net> References: <42847BB7.4050100@piuha.net> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 2 min Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari Arkko writes: > (a) Can we move behind a NAT? > [Yes. But requires NAT-D payloads in the address change > message, as discussed under issue 11.] > (b) Can we move out from a NAT? > [Yes. Does not require much. But see item h.] > (c) To which extent do we support the case that > party outside the NAT moves? > [No. This one is really hard. We will make our life much > simpler by saying no here. Outsider may not be able to > initiate anything inside. The only exception is covered under > item f.] > (d) If we are behind a NAT, can peer have multiple > addresses? > [Yes. Contrary to mobility, multihoming is possible > quite easily. Detailed protocol design has some further > details that need to be developed later, e.g., is there > a need to do keepalives on all address pairs? Tentatively, > the answer to that is no.] > (e) If we are behind a NAT on one interface, can > another interface work without NAT/NAT-T? > [Yes.] > (f) Can the responder be behind a NAT? > [Yes, but in a very limited scenario, when the NAT is > a static NAT and not a NAPT.] > (g) Do we need NAT prevention? > [Yes.] > (h) Do we want to disable UDP encapsulation when moving outside > from behind a NAT? > [Yes.] I agree on your suggestion for answers for those questions above. > (i) Send keepalives on current or on all paths? > [To be decided later.] Yes, that depends quite a lot about protocol, but if it ends up to be initiator decide style protocol, then the answer will most likely be no. If it is going to be so that both ends can decide which pair of addresses to use, then we must also send keepalives on all paths. So this is related to issue 20. > (j) How do we detect NATs? > [Using NAT-T functionality.] > (k) Is NAT-T support still optional within MOBIKE? > [Yes. You should be able to use MOBIKE in plain v6 environments, > for instance.] Agree on those again. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri May 13 06:28:03 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01517 for ; Fri, 13 May 2005 06:28:02 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 2E521FB282; Fri, 13 May 2005 06:28:04 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id ED8E8FB262; Fri, 13 May 2005 06:28:00 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8A7EAFB266; Fri, 13 May 2005 06:27:59 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 5A4D2FB246 for ; Fri, 13 May 2005 06:27:58 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j4DARu4E002336 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 13 May 2005 13:27:57 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j4DARsq5002333; Fri, 13 May 2005 13:27:54 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17028.33066.92978.705548@fireball.kivinen.iki.fi> Date: Fri, 13 May 2005 13:27:54 +0300 From: Tero Kivinen To: Jari Arkko Subject: Re: [Mobike] issues 18, 15, 6 -- return routability In-Reply-To: <42846428.4010005@piuha.net> References: <4283307B.1070305@piuha.net> <42846428.4010005@piuha.net> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari Arkko writes: > Here's a more detailed text proposal: "By default, > return routability test is done before moving the > traffic. However, [as decided in issue 18] these tests > are optional. Nodes MAY also perform these tests upon > their own initiative at other times." That text looks good for me. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri May 13 06:56:19 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03470 for ; Fri, 13 May 2005 06:56:18 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 2E188FB266; Fri, 13 May 2005 06:56:21 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0D953FB249; Fri, 13 May 2005 06:56:19 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0A685FB262; Fri, 13 May 2005 06:56:17 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 79DF4FB246 for ; Fri, 13 May 2005 06:56:16 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 488A189879; Fri, 13 May 2005 13:56:15 +0300 (EEST) Message-ID: <428487D8.3090401@piuha.net> Date: Fri, 13 May 2005 13:56:24 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Mobike] issue 3 - nats References: <42847BB7.4050100@piuha.net> <17028.32954.849644.866018@fireball.kivinen.iki.fi> In-Reply-To: <17028.32954.849644.866018@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Tero Kivinen wrote: >> (i) Send keepalives on current or on all paths? >> [To be decided later.] >> >> > >Yes, that depends quite a lot about protocol, but if it ends up to be >initiator decide style protocol, then the answer will most likely be >no. If it is going to be so that both ends can decide which pair of >addresses to use, then we must also send keepalives on all paths. So >this is related to issue 20. > > Yes, that makes sense. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri May 13 17:26:20 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12328 for ; Fri, 13 May 2005 17:26:19 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id BE90BFB286; Fri, 13 May 2005 17:26:18 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EE1E9FB266; Fri, 13 May 2005 17:26:15 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1406CFB27D; Fri, 13 May 2005 17:26:14 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by machshav.com (Postfix) with ESMTP id 7DC19FB262 for ; Fri, 13 May 2005 17:26:13 -0400 (EDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4DKt8n27830; Fri, 13 May 2005 13:55:08 -0700 X-mProtect: <200505132055> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdDd1KLo; Fri, 13 May 2005 13:55:07 PDT Message-ID: <42851B63.6010404@iprg.nokia.com> Date: Fri, 13 May 2005 14:25:55 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mobike] issues 18, 15, 6 -- return routability References: <4283307B.1070305@piuha.net> <42846428.4010005@piuha.net> In-Reply-To: <42846428.4010005@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Here's a more detailed text proposal: "By default, > return routability test is done before moving the > traffic. However, [as decided in issue 18] these tests > are optional. Nodes MAY also perform these tests upon > their own initiative at other times." > > This seems to cover the opinion of the folks expressed > earlier on the list, as well as your comments. Ok? shouldnt the return routability test be highly encouraged, though? the above text tells me that return routability tests are completely optional. the responder can do the test if it wants to. or is there some other text in some other document which says this? sorry I havent been following the discussion. Vijay _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun May 15 14:19:10 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17810 for ; Sun, 15 May 2005 14:19:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 584D5FB293; Sun, 15 May 2005 14:19:10 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AC862FB290; Sun, 15 May 2005 14:19:07 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B250BFB292; Sun, 15 May 2005 14:19:05 -0400 (EDT) Received: from smtp805.mail.sc5.yahoo.com (smtp805.mail.sc5.yahoo.com [66.163.168.184]) by machshav.com (Postfix) with SMTP id DFF0CFB28B for ; Sun, 15 May 2005 14:19:04 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.169.161.39 with login) by smtp805.mail.sc5.yahoo.com with SMTP; 15 May 2005 18:19:02 -0000 Message-ID: <00d001c5597a$91a6d840$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Jari Arkko" , "MOBIKE Mailing List" References: <42847BB7.4050100@piuha.net> Subject: Re: [Mobike] issue 3 - nats Date: Sun, 15 May 2005 11:19:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari, Agreed. -mohan > Does this cover everything, or do we have additional questions? > Here are also some tentative answers to the questions: > > (a) Can we move behind a NAT? > [Yes. But requires NAT-D payloads in the address change > message, as discussed under issue 11.] > (b) Can we move out from a NAT? > [Yes. Does not require much. But see item h.] > (c) To which extent do we support the case that > party outside the NAT moves? > [No. This one is really hard. We will make our life much > simpler by saying no here. Outsider may not be able to > initiate anything inside. The only exception is covered under > item f.] > (d) If we are behind a NAT, can peer have multiple > addresses? > [Yes. Contrary to mobility, multihoming is possible > quite easily. Detailed protocol design has some further > details that need to be developed later, e.g., is there > a need to do keepalives on all address pairs? Tentatively, > the answer to that is no.] > (e) If we are behind a NAT on one interface, can > another interface work without NAT/NAT-T? > [Yes.] > (f) Can the responder be behind a NAT? > [Yes, but in a very limited scenario, when the NAT is > a static NAT and not a NAPT.] > (g) Do we need NAT prevention? > [Yes.] > (h) Do we want to disable UDP encapsulation when moving outside > from behind a NAT? > [Yes.] > (i) Send keepalives on current or on all paths? > [To be decided later.] > (j) How do we detect NATs? > [Using NAT-T functionality.] > (k) Is NAT-T support still optional within MOBIKE? > [Yes. You should be able to use MOBIKE in plain v6 environments, > for instance.] > > --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 Mon May 16 06:12:31 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19678 for ; Mon, 16 May 2005 06:12:30 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A76D2FB29F; Mon, 16 May 2005 06:12:30 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 71173FB299; Mon, 16 May 2005 06:12:26 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4BE94FB29B; Mon, 16 May 2005 06:12:25 -0400 (EDT) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id 5652DFB297 for ; Mon, 16 May 2005 06:12:23 -0400 (EDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4GAAbtF014955; Mon, 16 May 2005 13:10:40 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 May 2005 13:12:14 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 May 2005 13:12:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issues 18, 15, 6 -- return routability Date: Mon, 16 May 2005 13:12:13 +0300 Message-ID: Thread-Topic: [Mobike] issues 18, 15, 6 -- return routability Thread-Index: AcVXlUB6NvnhcPgnRsCDiJTkVJkfPACaj1Gw From: To: X-OriginalArrivalTime: 16 May 2005 10:12:13.0998 (UTC) FILETIME=[BB1204E0:01C559FF] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Looks good to me (sensible default value + allows doing other things if needed). Best regards, Pasi > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Friday, May 13, 2005 11:24 AM > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: mobike@machshav.com > Subject: Re: [Mobike] issues 18, 15, 6 -- return routability >=20 >=20 >=20 > Here's a more detailed text proposal: "By default, > return routability test is done before moving the > traffic. However, [as decided in issue 18] these tests > are optional. Nodes MAY also perform these tests upon > their own initiative at other times." >=20 > This seems to cover the opinion of the folks expressed > earlier on the list, as well as your comments. Ok? >=20 > --Jari >=20 >=20 >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon May 16 06:30:12 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21276 for ; Mon, 16 May 2005 06:30:11 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 93F9BFB2A0; Mon, 16 May 2005 06:30:13 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3E130FB299; Mon, 16 May 2005 06:30:10 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4C657FB29B; Mon, 16 May 2005 06:30:08 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id 51B63FB297 for ; Mon, 16 May 2005 06:30:07 -0400 (EDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4GAU3Fa019247; Mon, 16 May 2005 13:30:06 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 May 2005 13:29:58 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 May 2005 13:29:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issue 3 - nats Date: Mon, 16 May 2005 13:29:57 +0300 Message-ID: Thread-Topic: [Mobike] issue 3 - nats Thread-Index: AcVXo6WOavpq9N0iQPiL+gtYuf+gogCXhulQ From: To: , X-OriginalArrivalTime: 16 May 2005 10:29:58.0305 (UTC) FILETIME=[35726110:01C55A02] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable I agree with your proposals. As some people have expressed=20 that they have no interest in NAT-T, I think it's important=20 to also have (k): if you implement NAT-T, MOBIKE works with=20 that, but implementing MOBIKE does not force you to do NAT-T if you don't want. Best regards, Pasi > -----Original Message----- > From: Jari Arkko > Sent: Friday, May 13, 2005 1:05 PM > To: MOBIKE Mailing List > Subject: [Mobike] issue 3 - nats > > > Here are also some tentative answers to the questions: >=20 > (a) Can we move behind a NAT? > [Yes. But requires NAT-D payloads in the address change > message, as discussed under issue 11.] > (b) Can we move out from a NAT? > [Yes. Does not require much. But see item h.] > (c) To which extent do we support the case that > party outside the NAT moves? > [No. This one is really hard. We will make our life much > simpler by saying no here. Outsider may not be able to > initiate anything inside. The only exception is covered under > item f.] > (d) If we are behind a NAT, can peer have multiple > addresses? > [Yes. Contrary to mobility, multihoming is possible > quite easily. Detailed protocol design has some further > details that need to be developed later, e.g., is there > a need to do keepalives on all address pairs? Tentatively, > the answer to that is no.] > (e) If we are behind a NAT on one interface, can =20 > another interface work without NAT/NAT-T? > [Yes.] > (f) Can the responder be behind a NAT? =20 > [Yes, but in a very limited scenario, when the NAT is > a static NAT and not a NAPT.] > (g) Do we need NAT prevention? > [Yes.] > (h) Do we want to disable UDP encapsulation when moving outside > from behind a NAT? > [Yes.] > (i) Send keepalives on current or on all paths? > [To be decided later.] > (j) How do we detect NATs? > [Using NAT-T functionality.] > (k) Is NAT-T support still optional within MOBIKE? > [Yes. You should be able to use MOBIKE in plain v6=20 > environments, for instance.] >=20 > --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed May 18 07:40:15 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08439 for ; Wed, 18 May 2005 07:40:13 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 15B7BFB2A6; Wed, 18 May 2005 07:40:12 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8B60AFB29F; Wed, 18 May 2005 07:40:09 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 39FCCFB2A1; Wed, 18 May 2005 07:40:08 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 9278DFB299 for ; Wed, 18 May 2005 07:40:07 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A4D5489869; Wed, 18 May 2005 14:40:05 +0300 (EEST) Message-ID: <428B29A0.4080305@piuha.net> Date: Wed, 18 May 2005 14:40:16 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mobike] issues 18, 15, 6 -- return routability References: <4283307B.1070305@piuha.net> <42846428.4010005@piuha.net> <42851B63.6010404@iprg.nokia.com> In-Reply-To: <42851B63.6010404@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit I agree. But I think issue 18 covers this already; the text below is just for discussing when to do it. (Issue 18 result was that its by default done but there MAY be some fancier authorization mechanism or configuration that enables skipping it.) --Jari Vijay Devarapalli wrote: > Jari Arkko wrote: > >> >> Here's a more detailed text proposal: "By default, >> return routability test is done before moving the >> traffic. However, [as decided in issue 18] these tests >> are optional. Nodes MAY also perform these tests upon >> their own initiative at other times." >> >> This seems to cover the opinion of the folks expressed >> earlier on the list, as well as your comments. Ok? > > > shouldnt the return routability test be highly encouraged, > though? the above text tells me that return routability > tests are completely optional. the responder can do the > test if it wants to. > > or is there some other text in some other document which > says this? sorry I havent been following the discussion. > > Vijay > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed May 18 08:11:56 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11189 for ; Wed, 18 May 2005 08:11:55 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E9198FB2A1; Wed, 18 May 2005 08:11:55 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C05F9FB27F; Wed, 18 May 2005 08:11:54 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 84B88FB280; Wed, 18 May 2005 08:11:53 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id CFA06FB27C for ; Wed, 18 May 2005 08:11:52 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2F31D89869 for ; Wed, 18 May 2005 15:11:52 +0300 (EEST) Message-ID: <428B3112.9020808@piuha.net> Date: Wed, 18 May 2005 15:12:02 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] straw poll on issue 20 (selection ipsec sa addresses and who decides) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Folks, At IETF-62 and on the list we discussed this issue that relates to what (outer) addresses are selected for the IPsec SAs, and who decides these addresses, the initiator, both peers, etc. This is a central question for the design of the mobike protocol, as it is hard to design further details without knowing the what we decide here. For this reason I'd like us to do a straw poll on what alternative people feel most comfortable with. The alternatives are discussed in http://www.vpnc.org/ietf-mobike/issue20.txt in more detail, but essentially its a question of the following choice: Option 1: "MOBIKE just informs the peer of our addresses; how they get used is a matter of local policy beyond our scope." Option 2: "Use the preferred/primary address" Option 3: "Initiator decides" Option 4: "Use the preferred/primary address if possible" Option 5: "Peers decide the source addresses independently" (There are potential other variants of design but these seem to be the main ones, or at least the current concrete proposals for the MOBIKE protocol are covered above.) Please make your opinion, along with its justifications, known by May 25th. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed May 18 13:14:04 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14146 for ; Wed, 18 May 2005 13:14:02 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5BCF0FB297; Wed, 18 May 2005 13:14:02 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B8377FB297; Wed, 18 May 2005 13:14:01 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A1B8EFB297; Wed, 18 May 2005 13:13:59 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 009DEFB28B for ; Wed, 18 May 2005 13:13:59 -0400 (EDT) Message-ID: <014f01c55bcd$26394d40$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jari Arkko" , "MOBIKE Mailing List" References: <428B3112.9020808@piuha.net> Subject: Re: [Mobike] straw poll on issue 20 (selection ipsec sa addresses andwho decides) Date: Wed, 18 May 2005 10:15:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit I prefer option 3. jak ----- Original Message ----- From: "Jari Arkko" To: "MOBIKE Mailing List" Sent: Wednesday, May 18, 2005 5:12 AM Subject: [Mobike] straw poll on issue 20 (selection ipsec sa addresses andwho decides) > > Folks, > > At IETF-62 and on the list we discussed this issue > that relates to what (outer) addresses are selected for the IPsec > SAs, and who decides these addresses, the initiator, both peers, > etc. > > This is a central question for the design of the mobike protocol, > as it is hard to design further details without knowing the > what we decide here. For this reason I'd like us to do a straw poll > on what alternative people feel most comfortable with. The > alternatives are discussed in > > http://www.vpnc.org/ietf-mobike/issue20.txt > > in more detail, but essentially its a question of > the following choice: > > Option 1: "MOBIKE just informs the peer of our addresses; how > they get used is a matter of local policy beyond our scope." > > Option 2: "Use the preferred/primary address" > > Option 3: "Initiator decides" > > Option 4: "Use the preferred/primary address if possible" > > Option 5: "Peers decide the source addresses independently" > > (There are potential other variants of design but these > seem to be the main ones, or at least the current concrete > proposals for the MOBIKE protocol are covered above.) > > Please make your opinion, along with its justifications, > known by May 25th. > > --Jari > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu May 19 02:01:32 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04604 for ; Thu, 19 May 2005 02:01:30 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D95E8FB290; Thu, 19 May 2005 02:01:29 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AC514FB281; Thu, 19 May 2005 02:01:25 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7EE06FB282; Thu, 19 May 2005 02:01:23 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id A7D75FB280 for ; Thu, 19 May 2005 02:01:22 -0400 (EDT) Received: from esebh106.NOE.Nokia.com ([172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4J61KXe010650; Thu, 19 May 2005 09:01:21 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 May 2005 09:01:20 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 May 2005 09:01:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] straw poll on issue 20 (selection ipsec sa addresses andwho decides) Date: Thu, 19 May 2005 09:01:20 +0300 Message-ID: Thread-Topic: [Mobike] straw poll on issue 20 (selection ipsec sa addresses andwho decides) Thread-Index: AcVbovj7NtarQYJKQBGoa/Y5+cpv3gAk9f+A From: To: , X-OriginalArrivalTime: 19 May 2005 06:01:19.0874 (UTC) FILETIME=[2D5A3E20:01C55C38] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Jari Arkko wrote: > > Please make your opinion, along with its justifications, > known by May 25th. Option 3, "Initiator decides". Reasons: - Simple. Very simple in the mobile client connected to=20 stationary gateway case. - Makes it easy to get the same address pair for both directions. This is important for two different reasons. First, it simplifies things if the network contains stateful firewalls or NATs. Second, it's straightforward to implement typical mobility cases, e.g.=20 laptop can move both upstream and downstream traffic from GPRS=20 to WLAN or vice versa, even if both interfaces work. - It does not prevent us from doing the non-mobile multihoming cases=20 either, e.g. gateway-to-gateway. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu May 19 04:06:50 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03030 for ; Thu, 19 May 2005 04:06:50 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 43451FB284; Thu, 19 May 2005 04:06:50 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B48E6FB281; Thu, 19 May 2005 04:06:48 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A7C05FB282; Thu, 19 May 2005 04:06:46 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 8306AFB280 for ; Thu, 19 May 2005 04:06:45 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j4J86gRL025984 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 May 2005 11:06:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j4J86fPU025981; Thu, 19 May 2005 11:06:41 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17036.18705.263702.509317@fireball.kivinen.iki.fi> Date: Thu, 19 May 2005 11:06:41 +0300 From: Tero Kivinen To: Jari Arkko Subject: [Mobike] straw poll on issue 20 (selection ipsec sa addresses and who decides) In-Reply-To: <428B3112.9020808@piuha.net> References: <428B3112.9020808@piuha.net> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari Arkko writes: > Option 3: "Initiator decides" As we need to support NATs and supporting NAT quite often means that either the design goes complicated or the host behind NAT (initiator) decides which addresses to use. So I vote for the this option. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu May 19 09:36:06 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04955 for ; Thu, 19 May 2005 09:36:04 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 90DC4FB289; Thu, 19 May 2005 09:36:03 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 69428FB281; Thu, 19 May 2005 09:36:01 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 56FD8FB282; Thu, 19 May 2005 09:36:00 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id B69DAFB280 for ; Thu, 19 May 2005 09:35:59 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A89CA89869 for ; Thu, 19 May 2005 16:35:53 +0300 (EEST) Message-ID: <428C9646.9060109@piuha.net> Date: Thu, 19 May 2005 16:36:06 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List References: <200505181944.PAA29522@ietf.org> In-Reply-To: <200505181944.PAA29522@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] FW: I-D ACTION:draft-dupont-ikev2-addrmgmt-07.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Address Management for IKE version 2 > Author(s) : F. Dupont > Filename : draft-dupont-ikev2-addrmgmt-07.txt > Pages : 16 > Date : 2005-5-18 > >The current IKEv2 proposal lacks an address management feature. As > it is compatible with the NAT traversal capability, this document > specifies a complete address management with support for multi-homing > and mobility, and fulfill mobike IETF working group goals 1, 2, 3, 4, > and 6. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-dupont-ikev2-addrmgmt-07.txt > > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu May 19 17:52:57 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04908 for ; Thu, 19 May 2005 17:52:56 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A74A3FB284; Thu, 19 May 2005 17:52:57 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 429FDFB27F; Thu, 19 May 2005 17:52:54 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 74E58FB280; Thu, 19 May 2005 17:52:52 -0400 (EDT) Received: from smtp809.mail.sc5.yahoo.com (smtp809.mail.sc5.yahoo.com [66.163.168.188]) by machshav.com (Postfix) with SMTP id B6998FB27C for ; Thu, 19 May 2005 17:52:51 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.59.81 with login) by smtp809.mail.sc5.yahoo.com with SMTP; 19 May 2005 21:52:46 -0000 Message-ID: <001701c55cbd$17720590$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Jari Arkko" , "MOBIKE Mailing List" References: <428B3112.9020808@piuha.net> Subject: Re: [Mobike] straw poll on issue 20 (selection ipsec sa addresses andwho decides) Date: Thu, 19 May 2005 14:52:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > > Option 1: "MOBIKE just informs the peer of our addresses; how > they get used is a matter of local policy beyond our scope." > > Option 2: "Use the preferred/primary address" > > Option 3: "Initiator decides" > I am assuming that this means that the initiator tests for bidirectional reachability and then tells the peer about the working address. One main reason why this seems favorable is because it works well with NATs and Firewalls. It does not mean that it does not work when they are not there. But may not work ideally e.g. two SGs connected and only one of them can decide. So, why build a protocol with this limitation ? Does providing an option for either one of them to choose or both of them to choose complicate the protocol (perhaps there could be the ping-pong effect of each one changing back and forth if both of them can choose) ? For example, the initiator says that it wants to be the deciding factor. The responder knows that the initiator is not behind a NAT (by looking at NAT-D payloads), then it might be okay for the responder to choose also, right ? So, the responder can also choose to be the deciding factor in this case. Though i *like* this option, it might make sense to provide some flexibility for this option. -mohan > Option 4: "Use the preferred/primary address if possible" > > Option 5: "Peers decide the source addresses independently" > > (There are potential other variants of design but these > seem to be the main ones, or at least the current concrete > proposals for the MOBIKE protocol are covered above.) > > Please make your opinion, along with its justifications, > known by May 25th. > > --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 Fri May 20 00:20:57 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11111 for ; Fri, 20 May 2005 00:20:55 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 67B8FFB286; Fri, 20 May 2005 00:20:56 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 804AFFB281; Fri, 20 May 2005 00:20:51 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 77593FB282; Fri, 20 May 2005 00:20:49 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 647B1FB27F for ; Fri, 20 May 2005 00:20:48 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 388AA89869; Fri, 20 May 2005 07:20:46 +0300 (EEST) Message-ID: <428D65AA.2090607@piuha.net> Date: Fri, 20 May 2005 07:20:58 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy Subject: Re: [Mobike] straw poll on issue 20 (selection ipsec sa addresses andwho decides) References: <428B3112.9020808@piuha.net> <001701c55cbd$17720590$6501a8c0@adithya> In-Reply-To: <001701c55cbd$17720590$6501a8c0@adithya> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Hi Mohan, >I am assuming that this means that the initiator tests for bidirectional >reachability and then tells the peer about the working address. >One main reason why this seems favorable is because it works well >with NATs and Firewalls. It does not mean that it does not work when >they are not there. But may not work ideally e.g. two SGs connected >and only one of them can decide. So, why build a protocol with >this limitation ? Does providing an option for either one of them to >choose or both of them to choose complicate the protocol (perhaps >there could be the ping-pong effect of each one changing back and >forth if both of them can choose) ? For example, the initiator says that >it wants to be the deciding factor. The responder knows that the initiator >is not behind a NAT (by looking at NAT-D payloads), then it might be >okay for the responder to choose also, right ? So, the responder can also >choose to be the deciding factor in this case. > > I'm not sure if this is what you were looking for, but the peers do have some ability to select who decides, simply by choosing who is the initiator... and if you don't like the initial arrangement, you could presumably take the current connection down and re-initiate yourself. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue May 24 11:50:44 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13042 for ; Tue, 24 May 2005 11:50:43 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 31548FB28A; Tue, 24 May 2005 11:50:44 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7313EFB285; Tue, 24 May 2005 11:50:43 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9B8F1FB286; Tue, 24 May 2005 11:50:41 -0400 (EDT) Received: from above.proper.com (above.proper.com [208.184.76.39]) by machshav.com (Postfix) with ESMTP id 25C85FB283 for ; Tue, 24 May 2005 11:50:41 -0400 (EDT) Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OFoc5j004554 for ; Tue, 24 May 2005 08:50:40 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <428B3112.9020808@piuha.net> References: <428B3112.9020808@piuha.net> Date: Tue, 24 May 2005 08:50:38 -0700 To: MOBIKE Mailing List From: Paul Hoffman Subject: Re: [Mobike] straw poll on issue 20 (selection ipsec sa addresses and who decides) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com At 3:12 PM +0300 5/18/05, Jari Arkko wrote: >Folks, > >At IETF-62 and on the list we discussed this issue >that relates to what (outer) addresses are selected for the IPsec >SAs, and who decides these addresses, the initiator, both peers, >etc. > >This is a central question for the design of the mobike protocol, >as it is hard to design further details without knowing the >what we decide here. I hope everyone in the WG noted that sentence. We are able to go ahead with the little input we have gotten so far, but it would be much better if we hear from many more people. > For this reason I'd like us to do a straw poll >on what alternative people feel most comfortable with. The >alternatives are discussed in > > http://www.vpnc.org/ietf-mobike/issue20.txt > >in more detail, but essentially its a question of >the following choice: > > Option 1: "MOBIKE just informs the peer of our addresses; how > they get used is a matter of local policy beyond our scope." > > Option 2: "Use the preferred/primary address" > > Option 3: "Initiator decides" > > Option 4: "Use the preferred/primary address if possible" > > Option 5: "Peers decide the source addresses independently" > >(There are potential other variants of design but these >seem to be the main ones, or at least the current concrete >proposals for the MOBIKE protocol are covered above.) > >Please make your opinion, along with its justifications, >known by May 25th. That would be tomorrow, at least in my geographic location. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue May 24 13:16:10 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19708 for ; Tue, 24 May 2005 13:16:08 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 388E2FB28B; Tue, 24 May 2005 13:16:08 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A504DFB285; Tue, 24 May 2005 13:16:05 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B79C1FB286; Tue, 24 May 2005 13:16:03 -0400 (EDT) Received: from sundance.cse.ucsc.edu (sundance.cse.ucsc.edu [128.114.48.62]) by machshav.com (Postfix) with SMTP id 10782FB277 for ; Tue, 24 May 2005 13:16:03 -0400 (EDT) Received: from localhost (geoff@localhost) by sundance.cse.ucsc.edu (8.6.10/8.6.12) with ESMTP id KAA12435; Tue, 24 May 2005 10:15:53 -0700 Date: Tue, 24 May 2005 10:15:53 -0700 (PDT) From: Geoffrey Huang To: Jari Arkko Subject: Re: [Mobike] straw poll on issue 20 (selection ipsec sa addresses and who decides) In-Reply-To: <428B3112.9020808@piuha.net> Message-ID: References: <428B3112.9020808@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com I prefer option 3 for its simplicity. Also, it seems to me that the mobile client-to-gateway scenario is such a compelling use case for Mobike, it makes it natural for the initiator to decide. -g On Wed, 18 May 2005, Jari Arkko wrote: > > Folks, > > At IETF-62 and on the list we discussed this issue > that relates to what (outer) addresses are selected for the IPsec > SAs, and who decides these addresses, the initiator, both peers, > etc. > > This is a central question for the design of the mobike protocol, > as it is hard to design further details without knowing the > what we decide here. For this reason I'd like us to do a straw poll > on what alternative people feel most comfortable with. The > alternatives are discussed in > > http://www.vpnc.org/ietf-mobike/issue20.txt > > in more detail, but essentially its a question of > the following choice: > > Option 1: "MOBIKE just informs the peer of our addresses; how > they get used is a matter of local policy beyond our scope." > > Option 2: "Use the preferred/primary address" > > Option 3: "Initiator decides" > > Option 4: "Use the preferred/primary address if possible" > > Option 5: "Peers decide the source addresses independently" > > (There are potential other variants of design but these > seem to be the main ones, or at least the current concrete > proposals for the MOBIKE protocol are covered above.) > > Please make your opinion, along with its justifications, > known by May 25th. > > --Jari > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed May 25 20:58:21 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17795 for ; Wed, 25 May 2005 20:58:20 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 54A02FB28E; Wed, 25 May 2005 20:58:20 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6FCABFB28A; Wed, 25 May 2005 20:58:19 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CF1D2FB28B; Wed, 25 May 2005 20:58:17 -0400 (EDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by machshav.com (Postfix) with ESMTP id 421CEFB284 for ; Wed, 25 May 2005 20:58:17 -0400 (EDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j4Q0wGME029550; Wed, 25 May 2005 17:58:16 -0700 (PDT) Received: from 192.9.61.12 (punchin-sommerfeld.SFBay.Sun.COM [192.9.61.12]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j4Q0wFPu002854; Wed, 25 May 2005 17:58:15 -0700 (PDT) Subject: Re: [Mobike] straw poll on issue 20 (selection ipsec sa addresses and who decides) From: Bill Sommerfeld To: Paul Hoffman In-Reply-To: References: <428B3112.9020808@piuha.net> Content-Type: text/plain Message-Id: <1117067925.35810.10.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.311 Date: Wed, 25 May 2005 17:57:31 -0700 Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit On Tue, 2005-05-24 at 08:50, Paul Hoffman wrote: > > Option 3: "Initiator decides" This seems to be the best choice to me. Though I think we haven't yet precisely nailed down what we mean by "initiator". - Bill _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed May 25 23:58:34 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02208 for ; Wed, 25 May 2005 23:58:33 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 178B6FB28F; Wed, 25 May 2005 23:58:34 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 26B65FB28A; Wed, 25 May 2005 23:58:33 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id ED0EFFB28B; Wed, 25 May 2005 23:58:30 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 83464FB284 for ; Wed, 25 May 2005 23:58:30 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 646E489832; Thu, 26 May 2005 06:58:28 +0300 (EEST) Message-ID: <42954974.9020606@piuha.net> Date: Thu, 26 May 2005 06:58:44 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Subject: Re: [Mobike] straw poll on issue 20 (selection ipsec sa addresses and who decides) References: <428B3112.9020808@piuha.net> <1117067925.35810.10.camel@unknown.hamachi.org> In-Reply-To: <1117067925.35810.10.camel@unknown.hamachi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , Paul Hoffman X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: >This seems to be the best choice to me. > > Yes, I like it too. >Though I think we haven't yet precisely nailed down what we mean by >"initiator". > > My understanding was that we are talking about the original initiator of the IKEv2 connection, not the initiator of a particular exchange later on. But I could be mistaken. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu May 26 07:11:03 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19810 for ; Thu, 26 May 2005 07:11:01 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5567CFB28F; Thu, 26 May 2005 07:11:00 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6CB8FFB282; Thu, 26 May 2005 07:10:59 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3A2EFFB284; Thu, 26 May 2005 07:10:58 -0400 (EDT) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id 58EC7FB27C for ; Thu, 26 May 2005 07:10:57 -0400 (EDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4QB7wab004764 for ; Thu, 26 May 2005 14:07:58 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 May 2005 14:10:53 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 May 2005 14:10:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] straw poll on issue 20 (selection ipsec sa addressesand who decides) Date: Thu, 26 May 2005 14:10:53 +0300 Message-ID: Thread-Topic: [Mobike] straw poll on issue 20 (selection ipsec sa addressesand who decides) Thread-Index: AcVhp1JL70yL9oodT26ur9EBtyioyQAO5L8A From: To: X-OriginalArrivalTime: 26 May 2005 11:10:53.0323 (UTC) FILETIME=[94E1E5B0:01C561E3] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Yes, what was meant is the party who initiated the IKEv2=20 connection (and not e.g. exchange initiator).=20 And we have to write the definition so that this party=20 stays the same even after rekeying the IKE_SA. (Unlike the "original initiator" in IKEv2, which is not defined anywhere in the document -- Paul's current proposal on=20 the ipsec list is that rekeying the IKE_SA can change who is the "original initiator"). Best regards, Pasi > -----Original Message----- > From: Jari Arkko > Sent: Thursday, May 26, 2005 6:59 AM > To: Bill Sommerfeld > Cc: MOBIKE Mailing List; Paul Hoffman > Subject: Re: [Mobike] straw poll on issue 20 (selection ipsec sa > addressesand who decides) >=20 >=20 > Bill Sommerfeld wrote: >=20 > >This seems to be the best choice to me. > > =20 > > > Yes, I like it too. >=20 > >Though I think we haven't yet precisely nailed down what we=20 > >mean by "initiator". =20 > > =20 > > > My understanding was that we are talking about the > original initiator of the IKEv2 connection, not the initiator > of a particular exchange later on. But I could be mistaken. >=20 > --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu May 26 22:13:11 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04111 for ; Thu, 26 May 2005 22:13:09 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1CF6EFB28E; Thu, 26 May 2005 22:13:08 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8F608FB284; Thu, 26 May 2005 22:13:07 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CA2EAFB28B; Thu, 26 May 2005 22:13:05 -0400 (EDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by machshav.com (Postfix) with ESMTP id 4542DFB282 for ; Thu, 26 May 2005 22:13:05 -0400 (EDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j4R2D3GJ023480; Thu, 26 May 2005 19:13:04 -0700 (PDT) Received: from 129.146.109.238 (d-mpk17-109-238.SFBay.Sun.COM [129.146.109.238]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j4R2D3Pu010049; Thu, 26 May 2005 19:13:03 -0700 (PDT) Subject: Re: [Mobike] straw poll on issue 20 (selection ipsec sa addresses and who decides) From: Bill Sommerfeld To: Jari Arkko In-Reply-To: <42954974.9020606@piuha.net> References: <428B3112.9020808@piuha.net> <1117067925.35810.10.camel@unknown.hamachi.org> <42954974.9020606@piuha.net> Content-Type: text/plain; charset=ASCII Message-Id: <1117159937.36160.702.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.311 Date: Thu, 26 May 2005 19:12:18 -0700 Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , Paul Hoffman X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit On Wed, 2005-05-25 at 20:58, Jari Arkko wrote: > >Though I think we haven't yet precisely nailed down what we mean by > >"initiator". > My understanding was that we are talking about the > original initiator of the IKEv2 connection, not the initiator > of a particular exchange later on. But I could be mistaken. so, the way I see it is that choosing the "one side in control" model is the central part of resolving issue 20. after we have implementation experience we may discover that certain uses for mobike (sg-sg or other peer-to-peer uses) may require a different way to pick which end is in control and we can add that later... but only if absolutely necessary. - Bill _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri May 27 11:33:28 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21327 for ; Fri, 27 May 2005 11:33:28 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id ABAA7FB293; Fri, 27 May 2005 11:33:28 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E1E59FB28F; Fri, 27 May 2005 11:33:27 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9D2EBFB28E; Fri, 27 May 2005 11:33:25 -0400 (EDT) Received: from above.proper.com (above.proper.com [208.184.76.39]) by machshav.com (Postfix) with ESMTP id 232FBFB27C for ; Fri, 27 May 2005 11:33:25 -0400 (EDT) Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RFXLIO079731 for ; Fri, 27 May 2005 08:33:22 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <428B3112.9020808@piuha.net> Date: Fri, 27 May 2005 08:33:19 -0700 To: MOBIKE Mailing List From: Paul Hoffman Subject: Closing: Re: [Mobike] straw poll on issue 20 (selection ipsec sa addresses and who decides) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com It's pretty clear that there is consensus on Option 3: "Initiator decides". --Paul Hoffman, Director --VPN Consortium _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun May 29 10:28:53 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19491 for ; Sun, 29 May 2005 10:28:52 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 99AD0FB27F; Sun, 29 May 2005 10:28:51 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DE75BFB266; Sun, 29 May 2005 10:28:49 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3D87EFB27D; Sun, 29 May 2005 10:28:48 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 97DFBFB262 for ; Sun, 29 May 2005 10:28:47 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A0FB58982E for ; Sun, 29 May 2005 17:28:45 +0300 (EEST) Message-ID: <4299D1AD.6000004@piuha.net> Date: Sun, 29 May 2005 17:29:01 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Subject: Re: [Mobike] issue 19 -- same addresses for both directions? References: <4284716E.2080404@piuha.net> In-Reply-To: <4284716E.2080404@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit I wrote earlier tha the decision on issue 20 (who decides) also has a big impact on issue 19. If we had decided in 20 that the decisions are independent, then it might in fact have been very hard to ensure that the two directions use the same addresses. As a result, allowing different addresses would make more sense in this scenario. But we ended up with "initiator decides". Therefore the deciding entity knows enough about the situation to be able to use the same address pairs in both directions. Of course, this does not necessarily have to be done. We could develop a protocol that provides independent addresses, yet would be controlled by the initiator. (Probably with some cost in terms of complexity. And I'm not quite sure how to deal with NATs and keepalives in that kind of a scenario.) How do you folks feel about this? Please post your comments by Friday, June 3rd. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun May 29 10:38:06 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20010 for ; Sun, 29 May 2005 10:38:05 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 757EDFB280; Sun, 29 May 2005 10:38:04 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CA760FB262; Sun, 29 May 2005 10:38:02 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5AF99FB266; Sun, 29 May 2005 10:38:01 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id C6A48FB24A for ; Sun, 29 May 2005 10:38:00 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0D7928982E; Sun, 29 May 2005 17:38:00 +0300 (EEST) Message-ID: <4299D3D7.1020309@piuha.net> Date: Sun, 29 May 2005 17:38:15 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mobike@machshav.com, Vijay Devarapalli Subject: Re: [Mobike] issues 18, 15, 6 -- return routability References: <4283307B.1070305@piuha.net> <42846428.4010005@piuha.net> In-Reply-To: <42846428.4010005@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit We are now closing issue 6 with the following text: > Here's a more detailed text proposal: "By default, > return routability test is done before moving the > traffic. However, [as decided in issue 18] these tests > are optional. Nodes MAY also perform these tests upon > their own initiative at other times." (Vijay, I'm hoping that my answer to your question was satisfactory. Let us know otherwise.) --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun May 29 10:38:18 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20051 for ; Sun, 29 May 2005 10:38:16 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id DA243FB297; Sun, 29 May 2005 10:38:17 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 001C5FB266; Sun, 29 May 2005 10:38:13 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1CF44FB281; Sun, 29 May 2005 10:38:12 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id EAD54FB262 for ; Sun, 29 May 2005 10:38:10 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 45B3E8982E for ; Sun, 29 May 2005 17:38:10 +0300 (EEST) Message-ID: <4299D3E1.70508@piuha.net> Date: Sun, 29 May 2005 17:38:25 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Subject: Re: [Mobike] issue 3 - nats References: <42847BB7.4050100@piuha.net> <17028.32954.849644.866018@fireball.kivinen.iki.fi> In-Reply-To: <17028.32954.849644.866018@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit I believe we have now converged on this issue as well. Tero posted a comment on the keepalive part, which changed the original proposal a bit, however. Note that this is still at a fairly high level. It seems likely that we will hit more detailed issues in actual protocol work. But it may be hard to do further discussion of this part of the issue unless we have a concrete proposal and see those detailed issues in front of us. So my suggestion is that we move on and deal with those issues separately if and when they arise. Resolution: (a) Can we move behind a NAT? [Yes. But requires NAT-D payloads in the address change message, as discussed under issue 11.] (b) Can we move out from a NAT? [Yes. But see item h.] (c) To which extent do we support the case that party outside the NAT moves? [No. Outsider may not be able to initiate anything inside. The only exception is covered under item f.] (d) If we are behind a NAT, can peer have multiple addresses? [Yes.] (e) If we are behind a NAT on one interface, can another interface work without NAT/NAT-T? [Yes.] (f) Can the responder be behind a NAT? [Yes, but in a very limited scenario, when the NAT is a static NAT and not a NAPT.] (g) Do we need NAT prevention? [Yes.] (h) Do we want to disable UDP encapsulation when moving outside from behind a NAT? [Yes.] (i) Send keepalives on current or on all paths? [Just the current one, as the "initiator decides" solution that we have picked in issue 20 makes this the logical choice here.] (j) How do we detect NATs? [Using NAT-T functionality.] (k) Is NAT-T support still optional within MOBIKE? [Yes. You should be able to use MOBIKE in plain v6 environments, for instance.] --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun May 29 10:45:56 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20302 for ; Sun, 29 May 2005 10:45:54 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 90CCEFB284; Sun, 29 May 2005 10:45:55 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 357D2FB27D; Sun, 29 May 2005 10:45:54 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 91127FB281; Sun, 29 May 2005 10:45:52 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id E82B8FB27C for ; Sun, 29 May 2005 10:45:51 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 359CB8988A; Sun, 29 May 2005 17:45:51 +0300 (EEST) Message-ID: <4299D5AE.7070503@piuha.net> Date: Sun, 29 May 2005 17:46:06 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List References: <428B3112.9020808@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pasi Eronen , Paul Hoffman Subject: [Mobike] issue status X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit The issue list has five pending issues, some of which are now being closed. This e-mail attempts to summarize the status of those five issues: 3 (nat) -- My suggestion is that we close this issue at the level of detail we have now, and open new issues during protocol work, if necessary. See http://www.machshav.com/pipermail/mobike/2005-May/000807.html 6 (rr) -- closed. See http://www.machshav.com/pipermail/mobike/2005-May/000806.html 11 (window) -- closed, but here too we may open new issues when we see two alternative proposals here, now just one proposal available. See also http://www.machshav.com/pipermail/mobike/2005-May/000778.html 19 (same addresses in both directions) -- pending, discussion to end by Friday. See http://www.machshav.com/pipermail/mobike/2005-May/000805.html 20 (who decides) -- closed http://www.machshav.com/pipermail/mobike/2005-May/000804.html --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun May 29 11:47:50 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23032 for ; Sun, 29 May 2005 11:47:49 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id EDE43FB291; Sun, 29 May 2005 11:47:48 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 054C4FB27C; Sun, 29 May 2005 11:47:45 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 69796FB27D; Sun, 29 May 2005 11:47:43 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 3BE07FB266 for ; Sun, 29 May 2005 11:47:42 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C483A8988A; Sun, 29 May 2005 18:47:40 +0300 (EEST) Message-ID: <4299E42C.6090705@piuha.net> Date: Sun, 29 May 2005 18:47:56 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List References: <428B3112.9020808@piuha.net> <4299D5AE.7070503@piuha.net> In-Reply-To: <4299D5AE.7070503@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman Subject: [Mobike] protocol work X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Folks, It looks like we are coming nearer to concluding our design issues. Great! I'm sending this e-mail just to let you know that Paul and I are discussing the next steps. Hannes is already updating the design draft. But we also need to start actual protocol work -- not just in order to finally complete our work, but also because we believe that the remaining details are hard to discuss without seeing a concrete protocol in front of us, designed in the manner that the WG wanted. We've had a number of individual drafts be published and improved while the design discussion was going on. Our intention is to get a WG draft out in its -00 form in June. The idea is not to "pick a winner" among the individual drafts, but rather to choose an editor and have him or her write a protocol draft according to guidance from the WG and using the design that we agreed on. The protocol will be called MOBIKE, and will most likely inherit quite a bit from individual proposals (with appropriate acknowledgements for contributions, of course). We've already got some volunteer editors, but additional volunteers are very welcome -- please contact either Paul or myself off the list. After the WG protocol draft is out we can start reviewing it and looking at whether there are new problems or design issues that we should worry about. If all goes well, in Paris we will spend most of our time polishing final details of the design draft and discussing what needs to change in the protocol draft in its next revision. I'm actually quite hopeful in terms of not finding too many major issues in the protocol, now that we have spent quite a lot of time and energy on thinking about the design. So WG last call might not be that far away. But this requirements effort from everyone to talk about the issues, review the initial draft, and so on. --Jari P.S. Please comment on the remaining issues (and in time). We'd like to see more people participate the discussion. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon May 30 12:56:26 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27363 for ; Mon, 30 May 2005 12:56:25 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 0EF0BFB282; Mon, 30 May 2005 12:56:25 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EAB81FB27C; Mon, 30 May 2005 12:56:22 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 42F68FB27F; Mon, 30 May 2005 12:56:22 -0400 (EDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by machshav.com (Postfix) with ESMTP id 94C5EFB24A for ; Mon, 30 May 2005 12:56:21 -0400 (EDT) Received: from [192.168.10.200] (69-12-138-157.dsl.static.sonic.net [69.12.138.157]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j4UGuKru007038; Mon, 30 May 2005 09:56:20 -0700 Message-ID: <429B451E.9080600@soe.ucsc.edu> Date: Mon, 30 May 2005 09:53:50 -0700 From: Geoffrey Huang User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050408) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mobike] issue 19 -- same addresses for both directions? References: <4284716E.2080404@piuha.net> <4299D1AD.6000004@piuha.net> In-Reply-To: <4299D1AD.6000004@piuha.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Hi Jari, Comments inline. Jari Arkko wrote: > > I wrote earlier tha the decision on issue 20 (who decides) > also has a big impact on issue 19. If we had decided in 20 > that the decisions are independent, then it might in fact > have been very hard to ensure that the two directions > use the same addresses. As a result, allowing different > addresses would make more sense in this scenario. > > But we ended up with "initiator decides". Therefore the > deciding entity knows enough about the situation to be > able to use the same address pairs in both directions. This makes sense to me - it's the logical progression from what was decided for Issue 20. > Of course, this does not necessarily have to be done. > We could develop a protocol that provides independent > addresses, yet would be controlled by the initiator. > (Probably with some cost in terms of complexity. > And I'm not quite sure how to deal with NATs and > keepalives in that kind of a scenario.) I can't imagine why this would be useful. In which scenarios wouldn't we want the initiator to decide which address pairs to use in both directions? -g > How do you folks feel about this? Please post your > comments by Friday, June 3rd. > > --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 May 31 21:28:43 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16171 for ; Tue, 31 May 2005 21:28:43 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 51796FB282; Tue, 31 May 2005 21:28:43 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A93E2FB277; Tue, 31 May 2005 21:28:41 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 28588FB280; Tue, 31 May 2005 21:28:40 -0400 (EDT) Received: from smtp827.mail.sc5.yahoo.com (smtp827.mail.sc5.yahoo.com [66.163.171.14]) by machshav.com (Postfix) with SMTP id 69CC8FB246 for ; Tue, 31 May 2005 21:28:39 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.169.162.49 with login) by smtp827.mail.sc5.yahoo.com with SMTP; 1 Jun 2005 01:28:38 -0000 Message-ID: <019e01c56649$3ddbd4f0$6601a8c0@adithya> From: "Mohan Parthasarathy" To: "Jari Arkko" , "MOBIKE Mailing List" References: <4284716E.2080404@piuha.net> <4299D1AD.6000004@piuha.net> Subject: Re: [Mobike] issue 19 -- same addresses for both directions? Date: Tue, 31 May 2005 18:28:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > > I wrote earlier tha the decision on issue 20 (who decides) > also has a big impact on issue 19. If we had decided in 20 > that the decisions are independent, then it might in fact > have been very hard to ensure that the two directions > use the same addresses. As a result, allowing different > addresses would make more sense in this scenario. > > But we ended up with "initiator decides". Therefore the > deciding entity knows enough about the situation to be > able to use the same address pairs in both directions. > > Of course, this does not necessarily have to be done. > We could develop a protocol that provides independent > addresses, yet would be controlled by the initiator. > (Probably with some cost in terms of complexity. > And I'm not quite sure how to deal with NATs and > keepalives in that kind of a scenario.) > Hmm.. we chose the "initiator decides" option because it works well with NAT. So, i am not sure i understand the issue here. Here, the initiator finds two sets of addresses (one for upstream and one for downstream traffic) and updates the peer providing information about which address pair to be used for downlink and which address to be used for up link. I would assume that it is the initiator's responsibility for sending keep alives. So, what is the issue here with NATs ? If the initiator is multi-homed and connected simultaneously to more than one access (e.g. UMTS and WLAN) at the same time, there might be some usefulness in having different paths for upstream and downstream traffic though i don't know really what it is :-) -mohan > How do you folks feel about this? Please post your > comments by Friday, June 3rd. > > --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