From mailman-bounces@machshav.com Mon Nov 1 00:02:03 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07366 for ; Mon, 1 Nov 2004 00:02:03 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 1704CFB293; Mon, 1 Nov 2004 05:02:05 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 28E9CFB2C8 for ; Mon, 1 Nov 2004 05:01:06 +0000 (UTC) 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: Mon, 01 Nov 2004 05:00:12 +0000 Precedence: bulk X-BeenThere: mailman@machshav.com X-Mailman-Version: 2.1.4 List-Id: mailman.machshav.com X-List-Administrivia: yes Sender: mailman-bounces@machshav.com Errors-To: mailman-bounces@machshav.com Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your machshav.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@machshav.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@machshav.com. Thanks! Passwords for mobike-archive@lists.ietf.org: List Password // URL ---- -------- mobike@machshav.com behoef https://www.machshav.com/mailman/options.cgi/mobike/mobike-archive%40lists.ietf.org From mobike-bounces@machshav.com Mon Nov 1 00:03:37 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07432 for ; Mon, 1 Nov 2004 00:03:37 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 5AAB5FB286; Mon, 1 Nov 2004 05:03:39 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EA4E9FB27A; Mon, 1 Nov 2004 05:03:36 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 89ED8FB280; Mon, 1 Nov 2004 05:03:35 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 70506FB279 for ; Mon, 1 Nov 2004 05:03:34 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id AE03089877 for ; Mon, 1 Nov 2004 07:03:32 +0200 (EET) Message-ID: <4185C339.8020507@piuha.net> Date: Mon, 01 Nov 2004 07:01:45 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] issue 5: zero address set X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit There has not been a lot of discussion of this subject on the list or in the meetings, except that in IETF-59 people opposed any kind of TCP spoofing. Unless I hear objections in the next couple of days, we can close this part of the issue. But, theoretically, we could still provide zero address sets without TCP spoofing. What do people think about this? Here's some technical analysis from a personal point of view: It seems that when the a node has no address, its peer could develop some condition which requires sending an IKE message to the node. For instance, rekeying might be necessary for some reason. Or deletion of the SAs. And on the IPsec list we have discussed the possibility of reauthentication requests. Obviously, all of these are going to fail when the node has no address. The same applies to payload packets, given that we are not doing spoofing. As a result, supporting zero address sets does not really help in situations where communication is needed during the period when there is no address. And in any case when an address is finally available, the node has to verify that the SAs are still functional. So there is really no benefit in resumption phase either. Finally, due to the unpredictability of wireless coverage, not being told about a zero address set condition is not a guarantee that the node is reachable. So we cannot easily use this as an indication to applications either. The potential benefit is that no traffic is sent to the peer's old address. This can be useful in terms of saving bandwidth, or avoiding someone else get the packets when an address is recycled. Note that a related benefit is that a laptop that gets suspended for a while does not have to re-establish SAs when it resumes. This may also mean that a user does not have to re-enter passwords or use token cards. However, it seems that this benefit can also be realized with the zero address set, simply by not informing the peer about the loss of address. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 1 06:28:36 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18709 for ; Mon, 1 Nov 2004 06:28:35 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 076D8FB286; Mon, 1 Nov 2004 11:27:57 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 692DCFB27A; Mon, 1 Nov 2004 11:27:54 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 94B76FB27C; Mon, 1 Nov 2004 11:27:52 +0000 (UTC) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 8B3EBFB257 for ; Mon, 1 Nov 2004 11:27:51 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iA1BRmrV014715 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 1 Nov 2004 13:27:48 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iA1BRlqR014712; Mon, 1 Nov 2004 13:27:47 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16774.7603.53728.169585@fireball.kivinen.iki.fi> Date: Mon, 1 Nov 2004 13:27:47 +0200 From: Tero Kivinen To: jari.arkko@piuha.net Subject: [Mobike] issue 6: scope of SA changes In-Reply-To: <418529CB.4030601@piuha.net> References: <418529CB.4030601@piuha.net> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 2 min Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari Arkko writes: > 1. Would it be useful to treat different flows or applications > in a different manner with regards to their multihoming > behaviour? For instance, keep one flow always in GPRS > but allow another flow to use LAN where available. > > Yes, optional [X] I think it is usefull feature on some scenarios, but it is not needed at all by others, so it needs to be optional. > 2. Would you like to provide this functionality through > > Separate IKE SAs and their independent addresses [X] Separate IKE SA would be fine, i.e. I do not think this so important issue that we need to add fine granularity to the SA movement. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 1 06:29:56 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18836 for ; Mon, 1 Nov 2004 06:29:54 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id ED403FB283; Mon, 1 Nov 2004 11:29:55 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C684AFB27A; Mon, 1 Nov 2004 11:29:52 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1F57FFB27C; Mon, 1 Nov 2004 11:29:51 +0000 (UTC) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id E80B3FB257 for ; Mon, 1 Nov 2004 11:29:49 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iA1BTmIR014757 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 1 Nov 2004 13:29:49 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iA1BTmKZ014754; Mon, 1 Nov 2004 13:29:48 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16774.7724.489928.1275@fireball.kivinen.iki.fi> Date: Mon, 1 Nov 2004 13:29:48 +0200 From: Tero Kivinen To: jari.arkko@piuha.net Subject: [Mobike] issue 12: interaction with other protocols doing RR In-Reply-To: <41850943.1090107@piuha.net> References: <41850943.1090107@piuha.net> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 1 min X-Total-Time: 1 min Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari Arkko writes: > I would like to suggest that we do our own specific > type of test, but allow same tests to be "reused" across > protocols where this makes sense. That is, in MOBIKE > we do our own test that verifies liveness of the address > and that the peer is indeed still the same IKEv2 > node and has knowledge of some secret keying material. > In addition, we add a note saying that the use of > the results of this test may be possible in other > protocol layers*. How about, if we simply define the requirements for our tests, and say that if those requirements are met by some other tests already done, then tests inside MOBIKE can be skipped. And then we would of course define what our tests provide, so others can skip their tests if your tests fullfill their needs too. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 1 11:04:57 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25941 for ; Mon, 1 Nov 2004 11:04:57 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 54C74FB281; Mon, 1 Nov 2004 16:04:54 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 851A6FB279; Mon, 1 Nov 2004 16:04:52 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9601AFB27A; Mon, 1 Nov 2004 16:04:50 +0000 (UTC) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id 5F768FB262 for ; Mon, 1 Nov 2004 16:04:49 +0000 (UTC) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA1G4hl28050; Mon, 1 Nov 2004 18:04:43 +0200 (EET) X-Scanned: Mon, 1 Nov 2004 18:01:18 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iA1G1Ibp022502; Mon, 1 Nov 2004 18:01:18 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00zyAOnl; Mon, 01 Nov 2004 18:00:55 EET 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 iA1G0TS29254; Mon, 1 Nov 2004 18:00:29 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 18:00:20 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 18:00:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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 12: interaction with other protocols doing RR Date: Mon, 1 Nov 2004 18:00:19 +0200 Message-ID: <125EA890549C8641A72F3809CB80DCCD1783A3@esebe056.ntc.nokia.com> Thread-Topic: [Mobike] issue 12: interaction with other protocols doing RR Thread-Index: AcTABpjXxa1o44i4Q26oAt0dQINfzgAIoevg From: To: , X-OriginalArrivalTime: 01 Nov 2004 16:00:20.0055 (UTC) FILETIME=[E32A6670:01C4C02B] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Tero Kivinen writes: > > Jari Arkko writes: > > I would like to suggest that we do our own specific > > type of test, but allow same tests to be "reused" across > > protocols where this makes sense. That is, in MOBIKE > > we do our own test that verifies liveness of the address > > and that the peer is indeed still the same IKEv2 > > node and has knowledge of some secret keying material. > > In addition, we add a note saying that the use of > > the results of this test may be possible in other > > protocol layers*. >=20 > How about, if we simply define the requirements for our tests,=20 > and say that if those requirements are met by some other tests=20 > already done, then tests inside MOBIKE can be skipped. And then=20 > we would of course define what our tests provide, so others can=20 > skip their tests if your tests fullfill their needs too.=20 I think the main requirement would be verifying that the same=20 entity that sent the address update message claiming to be at=20 address X can also receive packets sent to X. IMHO it sounds quite unlikely that any other protocol could=20 provide this information...?=20 What we could get is something like "This host has recently=20 communicated with someone at address X with protocol FOO", but we probably don't know if that someone is the sender of=20 the MOBIKE address update or its intended victim... (Well, there are cases where we actually could know it: e.g.,=20 the peer in IKE and "FOO" authenticated with the same=20 credentials, or something like that. But I think these=20 cases are quite rare...) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 1 11:21:49 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27958 for ; Mon, 1 Nov 2004 11:21:48 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7AE35FB289; Mon, 1 Nov 2004 16:21:49 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 51B25FB27C; Mon, 1 Nov 2004 16:21:47 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E2D48FB281; Mon, 1 Nov 2004 16:21:45 +0000 (UTC) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id A47C1FB279 for ; Mon, 1 Nov 2004 16:21:44 +0000 (UTC) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA1GLbe29727; Mon, 1 Nov 2004 18:21:38 +0200 (EET) X-Scanned: Mon, 1 Nov 2004 18:19:15 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iA1GJF8U027559; Mon, 1 Nov 2004 18:19:15 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00OEJ7iY; Mon, 01 Nov 2004 18:19:13 EET 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 iA1GIla06908; Mon, 1 Nov 2004 18:18:47 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 18:18:47 +0200 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 18:18:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: VS: [Mobike] issue 6: scope of SA changes Date: Mon, 1 Nov 2004 18:18:46 +0200 Message-ID: <8AA62C0ABD31B544993F7592D885280615CAAF@trebe051.ntc.nokia.com> Thread-Topic: [Mobike] issue 6: scope of SA changes Thread-Index: AcTABpbj2lJzzgdzTD2vRA6KpiU8XgAJir+3 From: To: , X-OriginalArrivalTime: 01 Nov 2004 16:18:47.0202 (UTC) FILETIME=[7713A020:01C4C02E] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0357397580==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com --===============0357397580== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQgdGhpcyBsaXR0bGUgYml0IGJldHRlciBiZWZvcmUg YW5zd2VyaW5nLg0KIA0KSWYgd2UgaGF2ZSB0aGlzIGZpbmUgZ3JhbnVsYXJpdHkgYW5kIHdlIGRv IG5vdCB3YW50IHRvIG1vdmUgc29tZSANCnN0cmVhbWluZyBkYXRhIGZyb20gV0xBTiB0byBHUFJT LCB3aGF0IHdvdWxkIGhhcHBlbiB0byB0aGVzZQ0KU0EncyB0aGF0IGFyZSB1c2VkIHRvIHByb3Rl Y3QgdGhlIHN0cmVhbWluZyBkYXRhIGR1cmluZyB0aGUgaGFuZG92ZXI/IA0KSWYgdGhleSBzdGF5 IGFzIHRoZXkgd2VyZSwgZG9lcyB0aGUgc3RyZWFtaW5nIHNlcnZlciBzZW5kIHRoZSBkYXRhIGFs bCANCnRoZSB0aW1lIHRvIHRoaXMgImxvc3QgY29ubmVjdGlvbiIsIG9yIGRvIHdlIHNvbWUgaG93 IGRlbGV0ZSB0aGUgDQoiV0xBTiBTQSdzIiB0aGF0IGFyZSBub3QgbW92ZWQgdG8gR1BSUz8gDQpX aGF0IGhhcHBlbnMgdG8gYXBwbGljYXRpb24gbGV2ZWwgY29ubmVjdGlvbj8gSXMgaXQganVzdCBn b2luZyB0byBkaWUNCmJlY2F1c2UgdGhlcmUgaXMgbm8gYWNrbm93bGVkZ2VtZW50cyBjb21pbmcg aW4/DQogDQpPciBzaG91bGQgd2UgbW92ZSBhbGwgU0EncyB0byBHUFJTIGFuZCB0aGVuIGxldCB0 aGUgYXBwbGljYXRpb24ga2lsbA0KdGhlIHVud2FudGVkIHN0cmVhbT8gDQogDQpNaWthDQogDQog DQoNCgktLS0tLUFsa3VwZXLDpGluZW4gdmllc3RpLS0tLS0gDQoJTMOkaGV0dMOkasOkOiBtb2Jp a2UtYm91bmNlc0BtYWNoc2hhdi5jb20gcHVvbGVzdGE6IGV4dCBUZXJvIEtpdmluZW4gDQoJTMOk aGV0ZXR0eTogbWEgMS4xMS4yMDA0IDM6MjcgDQoJVmFzdGFhbm90dGFqYTogamFyaS5hcmtrb0Bw aXVoYS5uZXQgDQoJS29waW86IE1PQklLRSBNYWlsaW5nIExpc3QgDQoJQWloZTogW01vYmlrZV0g aXNzdWUgNjogc2NvcGUgb2YgU0EgY2hhbmdlcw0KCQ0KCQ0KDQoJSmFyaSBBcmtrbyB3cml0ZXM6 DQoJPiAxLiBXb3VsZCBpdCBiZSB1c2VmdWwgdG8gdHJlYXQgZGlmZmVyZW50IGZsb3dzIG9yIGFw cGxpY2F0aW9ucw0KCT4gICAgIGluIGEgZGlmZmVyZW50IG1hbm5lciB3aXRoIHJlZ2FyZHMgdG8g dGhlaXIgbXVsdGlob21pbmcNCgk+ICAgICBiZWhhdmlvdXI/IEZvciBpbnN0YW5jZSwga2VlcCBv bmUgZmxvdyBhbHdheXMgaW4gR1BSUw0KCT4gICAgIGJ1dCBhbGxvdyBhbm90aGVyIGZsb3cgdG8g dXNlIExBTiB3aGVyZSBhdmFpbGFibGUuDQoJPg0KCT4gICAgIFllcywgb3B0aW9uYWwgIFtYXQ0K CQ0KCUkgdGhpbmsgaXQgaXMgdXNlZnVsbCBmZWF0dXJlIG9uIHNvbWUgc2NlbmFyaW9zLCBidXQg aXQgaXMgbm90IG5lZWRlZA0KCWF0IGFsbCBieSBvdGhlcnMsIHNvIGl0IG5lZWRzIHRvIGJlIG9w dGlvbmFsLg0KCQ0KCT4gMi4gV291bGQgeW91IGxpa2UgdG8gcHJvdmlkZSB0aGlzIGZ1bmN0aW9u YWxpdHkgdGhyb3VnaA0KCT4NCgk+ICAgICBTZXBhcmF0ZSBJS0UgU0FzIGFuZCB0aGVpciBpbmRl cGVuZGVudCBhZGRyZXNzZXMgICAgIFtYXQ0KCQ0KCVNlcGFyYXRlIElLRSBTQSB3b3VsZCBiZSBm aW5lLCBpLmUuIEkgZG8gbm90IHRoaW5rIHRoaXMgc28gaW1wb3J0YW50DQoJaXNzdWUgdGhhdCB3 ZSBuZWVkIHRvIGFkZCBmaW5lIGdyYW51bGFyaXR5IHRvIHRoZSBTQSBtb3ZlbWVudC4NCgktLQ0K CWtpdmluZW5Ac2FmZW5ldC1pbmMuY29tDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCglNb2Jpa2UgbWFpbGluZyBsaXN0DQoJTW9iaWtlQG1hY2hzaGF2 LmNvbQ0KCWh0dHBzOi8vd3d3Lm1hY2hzaGF2LmNvbS9tYWlsbWFuL2xpc3RpbmZvLmNnaS9tb2Jp a2UNCgkNCg0K --===============0357397580== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --===============0357397580==-- From mobike-bounces@machshav.com Mon Nov 1 11:36:47 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29926 for ; Mon, 1 Nov 2004 11:36:45 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id E1156FB283; Mon, 1 Nov 2004 16:36:45 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 260BCFB27A; Mon, 1 Nov 2004 16:36:43 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 57FC3FB27C; Mon, 1 Nov 2004 16:36:41 +0000 (UTC) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 94421FB279 for ; Mon, 1 Nov 2004 16:36:40 +0000 (UTC) Message-ID: <00aa01c4c031$16b074d0$656115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , "MOBIKE Mailing List" References: <41850943.1090107@piuha.net> Subject: Re: [Mobike] issue 12: interaction with other protocols doing RR Date: Mon, 1 Nov 2004 08:37:29 -0800 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.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari, > *) The example that comes to my mind is that since the > mobile node - home agent interface in mobile IPv6 runs > with IPsec, then the use of MOBIKE in that context > would provide an RR test to home registrations. That > does not exist in Mobile IPv6 at the moment, but if > it were included then Mobile IPv6 home agent service > could easier be offered to "unknown" peers. Currently > "unknown" peers are only support as correspondent > nodes. > IMHO, the lack of HA RR test in RFC 3775 is a residual vulnerability. RFC 3775 says that network operators should monitor their clients traffic and cut them off if they try bombing. But how is an operator supposed to know that? In the absence of any RR test, there's no way for the HA to know whether the MN is at the care of address to which it is directing a video stream, or whether its a bombing attack. This kind of insider attack is still possible. So I think this is an excellent idea. In fact, I think it should be used not just with "unknown" peers but also with known clients of the HA. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 1 11:38:18 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00144 for ; Mon, 1 Nov 2004 11:38:17 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 43701FB289; Mon, 1 Nov 2004 16:38:18 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D828DFB27C; Mon, 1 Nov 2004 16:38:14 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9300DFB282; Mon, 1 Nov 2004 16:38:13 +0000 (UTC) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id E4BABFB27A for ; Mon, 1 Nov 2004 16:38:12 +0000 (UTC) Message-ID: <00b401c4c031$4dd34b40$656115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , "MOBIKE Mailing List" References: <41850C64.6030004@piuha.net> Subject: Re: [Mobike] issue 14 - path testing and congestion Date: Mon, 1 Nov 2004 08:39:02 -0800 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.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Yes, I agree. jak ----- Original Message ----- From: "Jari Arkko" To: "MOBIKE Mailing List" Sent: Sunday, October 31, 2004 8:01 AM Subject: [Mobike] issue 14 - path testing and congestion > > I'd like to close this issue based on what Bill Sommerfeld > said about it: > > While there may be situations where you can ignore congestion control > best practices and get excellent benchmark results under carefully > controlled conditions, such environments tend to be unstable under > load and are therefore unsuitable for production use. > > Path failover is likely to be triggered in as the result of packet > loss. Packet loss is often caused by congestion. Sending a burst of > packets when you detect an event which may be the result of congestion > has been considered a really bad idea for about two decades now. > > We MUST NOT produce a spec which, if deployed, would force router > vendors to produce countermeasures to protect the rest of the network > from us. > > As a result, I'd like to suggest that when peers test candidate addresses > (or pairs), they SHOULD attempt testing all of them, but MUST do this > sequentially (based on an implementation-dependent priority order) and > using an exponential back-off procedure. > > Ok for everyone? I'll assume so unless I hear from you in the next > couple of days. > > Note that the unpleasant but necessary side-effect is that only a > small set of multihoming addresses on both sides is practical. On > larger sets, testing takes too long. Some math about this in > > http://www.arkko.com/publications/multi6/faildet.html#anchor9 > > --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 Nov 1 11:41:20 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00541 for ; Mon, 1 Nov 2004 11:41:19 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 5E22BFB286; Mon, 1 Nov 2004 16:41:20 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C57F2FB27C; Mon, 1 Nov 2004 16:41:17 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5C5A8FB282; Mon, 1 Nov 2004 16:41:16 +0000 (UTC) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id B2AD8FB27A for ; Mon, 1 Nov 2004 16:41:15 +0000 (UTC) Message-ID: <00b801c4c031$baed7070$656115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , "MOBIKE Mailing List" References: <418529CB.4030601@piuha.net> Subject: Re: [Mobike] issue 6: scope of SA changes Date: Mon, 1 Nov 2004 08:42:05 -0800 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.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit I'm not in favor of providing flow handover in MOBIKE at this time. I think there are some tricky issues here involving congestion and routing in access networks that need more study. In addtion, there has been some discussion of doing flow handover in MIP, and I think it might make some sense to consider both these cases together. Perhaps at some point a BOF on flow handover might be appropriate. jak ----- Original Message ----- From: "Jari Arkko" To: "MOBIKE Mailing List" Sent: Sunday, October 31, 2004 10:07 AM Subject: [Mobike] issue 6: scope of SA changes > > Lets have a consensus call on this. From the list > discussion so far I don't see enough people commenting > on this that would enable us to make decision. For > a more accurate decision, I have broken the issue down > into three questions. > > 1. Would it be useful to treat different flows or applications > in a different manner with regards to their multihoming > behaviour? For instance, keep one flow always in GPRS > but allow another flow to use LAN where available. > > Yes, mandatory [ ] > Yes, optional [ ] > No [ ] > > 2. Would you like to provide this functionality through > > Separate IPsec SAs and their independent addresses [ ] > Separate IKE SAs and their independent addresses [ ] > > 3. If you prefer the use of IPsec SAs for this purpose, > would you like > > always manage each SA separately [ ] > provide a default where all SAs are moved [ ] > > Send your answers by Wednesday, Nov 3rd, 2004. The rationale > behind your answers will help others form their opinions, so > please state also why you are answering in a particular way. > > --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 Nov 1 11:45:20 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01094 for ; Mon, 1 Nov 2004 11:45:20 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 87317FB27C; Mon, 1 Nov 2004 16:45:20 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1459BFB282; Mon, 1 Nov 2004 16:45:17 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8ECB6FB283; Mon, 1 Nov 2004 16:45:15 +0000 (UTC) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id 8AE3FFB27C for ; Mon, 1 Nov 2004 16:45:14 +0000 (UTC) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA1GjCl14826; Mon, 1 Nov 2004 18:45:12 +0200 (EET) X-Scanned: Mon, 1 Nov 2004 18:43:21 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iA1GhLgZ011283; Mon, 1 Nov 2004 18:43:21 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00cPecHW; Mon, 01 Nov 2004 18:43:19 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA1GhJS20893; Mon, 1 Nov 2004 18:43:19 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 18:43:19 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 18:43:19 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 18:43:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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 6: scope of SA changes Date: Mon, 1 Nov 2004 18:43:17 +0200 Message-ID: <125EA890549C8641A72F3809CB80DCCD1783A5@esebe056.ntc.nokia.com> Thread-Topic: [Mobike] issue 6: scope of SA changes Thread-Index: AcS/dRiQtgA1uOl3R7WcUtlcVyN44wAtxPbw From: To: , X-OriginalArrivalTime: 01 Nov 2004 16:43:18.0305 (UTC) FILETIME=[E3EC2110:01C4C031] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Jari Arkko writes: >=20 > 1. Would it be useful to treat different flows or applications > in a different manner with regards to their multihoming > behaviour? For instance, keep one flow always in GPRS > but allow another flow to use LAN where available. >=20 > Yes, mandatory [ ] > Yes, optional [X] > No [ ] > 2. Would you like to provide this functionality through >=20 > Separate IPsec SAs and their independent addresses [ ] > Separate IKE SAs and their independent addresses [X] Separate IKE SAs are IMHO the simplest way to go,=20 considering that=20 - I think that real-world MOBIKE deployments will not use this=20 kind of functionality anyway, or at least it will be extremely=20 rare in the near future.=20 - In many of those rare cases where different treatment is needed,=20 it can be handled adequately by creating several IKE SAs. - This simplifies the protocol somewhat (e.g., no need to treat=20 those addresses differently for RR purposes). - If the remaining cases (where the ability to have only a single=20 IKE SA would provide substantial user-visible benefits) become more important e.g. five years from now, we can do something about them then. =20 Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 1 14:05:29 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18209 for ; Mon, 1 Nov 2004 14:05:28 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 847EDFB281; Mon, 1 Nov 2004 19:05:26 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 89F3EFB252; Mon, 1 Nov 2004 19:05:23 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0D5FFFB262; Mon, 1 Nov 2004 19:05:21 +0000 (UTC) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id C50F7FB251 for ; Mon, 1 Nov 2004 19:05:19 +0000 (UTC) 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 iA1J5Ce01794; Mon, 1 Nov 2004 21:05:13 +0200 (EET) X-Scanned: Mon, 1 Nov 2004 21:04:40 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iA1J4eMs022600; Mon, 1 Nov 2004 21:04:40 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00W3RUl1; Mon, 01 Nov 2004 21:04:39 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA1J4cS02951; Mon, 1 Nov 2004 21:04:38 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 13:04:36 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issue 6: scope of SA changes Date: Mon, 1 Nov 2004 14:04:35 -0500 Message-ID: Thread-Topic: [Mobike] issue 6: scope of SA changes Thread-Index: AcTANWrvcGpvl0LMQB67/EmBTYnIEwAEAl6A From: To: , , X-OriginalArrivalTime: 01 Nov 2004 19:04:36.0243 (UTC) FILETIME=[A12ACE30:01C4C045] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable I agree, now may not be the time for flow handover in MOBIKE. Atul > -----Original Message----- > From: mobike-bounces@machshav.com=20 > [mailto:mobike-bounces@machshav.com]On > Behalf Of ext James Kempf > Sent: Monday, November 01, 2004 11:42 AM > To: jari.arkko@piuha.net; MOBIKE Mailing List > Subject: Re: [Mobike] issue 6: scope of SA changes >=20 >=20 > I'm not in favor of providing flow handover in MOBIKE at this=20 > time. I think > there are some tricky issues here involving congestion and=20 > routing in access > networks that need more study. In addtion, there has been=20 > some discussion of > doing flow handover in MIP, and I think it might make some=20 > sense to consider > both these cases together. Perhaps at some point a BOF on=20 > flow handover > might be appropriate. >=20 > jak >=20 >=20 > ----- Original Message -----=20 > From: "Jari Arkko" > To: "MOBIKE Mailing List" > Sent: Sunday, October 31, 2004 10:07 AM > Subject: [Mobike] issue 6: scope of SA changes >=20 >=20 > > > > Lets have a consensus call on this. From the list > > discussion so far I don't see enough people commenting > > on this that would enable us to make decision. For > > a more accurate decision, I have broken the issue down > > into three questions. > > > > 1. Would it be useful to treat different flows or applications > > in a different manner with regards to their multihoming > > behaviour? For instance, keep one flow always in GPRS > > but allow another flow to use LAN where available. > > > > Yes, mandatory [ ] > > Yes, optional [ ] > > No [ ] > > > > 2. Would you like to provide this functionality through > > > > Separate IPsec SAs and their independent addresses [ ] > > Separate IKE SAs and their independent addresses [ ] > > > > 3. If you prefer the use of IPsec SAs for this purpose, > > would you like > > > > always manage each SA separately [ ] > > provide a default where all SAs are moved [ ] > > > > Send your answers by Wednesday, Nov 3rd, 2004. The rationale > > behind your answers will help others form their opinions, so > > please state also why you are answering in a particular way. > > > > --Jari > > > > _______________________________________________ > > Mobike mailing list > > Mobike@machshav.com > > https://www.machshav.com/mailman/listinfo.cgi/mobike > > >=20 >=20 > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 1 14:05:38 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18230 for ; Mon, 1 Nov 2004 14:05:38 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id A9AE1FB297; Mon, 1 Nov 2004 19:05:39 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 37DA6FB27D; Mon, 1 Nov 2004 19:05:34 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 64637FB283; Mon, 1 Nov 2004 19:05:32 +0000 (UTC) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by machshav.com (Postfix) with ESMTP id 1C4ECFB279 for ; Mon, 1 Nov 2004 19:05:31 +0000 (UTC) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA1J5Sl03189; Mon, 1 Nov 2004 21:05:28 +0200 (EET) X-Scanned: Mon, 1 Nov 2004 21:03:31 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iA1J3V4K004864; Mon, 1 Nov 2004 21:03:31 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00cCcsOa; Mon, 01 Nov 2004 21:03:29 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA1J3Sa13494; Mon, 1 Nov 2004 21:03:28 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 13:03:26 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issue 12: interaction with other protocols doing RR Date: Mon, 1 Nov 2004 14:02:05 -0500 Message-ID: Thread-Topic: [Mobike] issue 12: interaction with other protocols doing RR Thread-Index: AcS/YgBblKizvPUkTHqeI3E1aE2KfAA4gisA From: To: , X-OriginalArrivalTime: 01 Nov 2004 19:03:26.0204 (UTC) FILETIME=[776BB3C0:01C4C045] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable I think RR should only be attempted after MOBIKE/IKE informational exchange has been validated. It should not be attempted for every possible address updates. RR is useful for an authenticated attacker only. For an unauthenticated attacker (psuedo-NAT attack) it is = wasteful. I did not understand the comment on "...but if it were included then=20 Mobile IPv6 home agent service could easier be offered to unknown = peers." Given that such a RR test done by MOBIKE can be used elsewhere and=20 similarly connectivity information elsewhere could be used in MOBIKE, MOBIKE should work on defining such cross-layer/cross-protocol APIs. Atul > -----Original Message----- > From: mobike-bounces@machshav.com=20 > [mailto:mobike-bounces@machshav.com]On > Behalf Of ext Jari Arkko > Sent: Sunday, October 31, 2004 10:48 AM > To: MOBIKE Mailing List > Subject: [Mobike] issue 12: interaction with other protocols doing RR >=20 >=20 >=20 > Background: a number of protocols employ return > routability tests. In the mobility space we have > this at least in MOBIKE, Mobile IPv6, MULTI6, and > HIP. >=20 > Tero's design document discusses some differences > these tests have in different contexts; not all > do exactly the same thing even if all at least > verify there's someone willing to respond on the > path towards the tested address. >=20 > I would like to suggest that we do our own specific > type of test, but allow same tests to be "reused" across > protocols where this makes sense. That is, in MOBIKE > we do our own test that verifies liveness of the address > and that the peer is indeed still the same IKEv2 > node and has knowledge of some secret keying material. > In addition, we add a note saying that the use of > the results of this test may be possible in other > protocol layers*. >=20 > Ok for everyone? >=20 > --Jari >=20 > *) The example that comes to my mind is that since the > mobile node - home agent interface in mobile IPv6 runs > with IPsec, then the use of MOBIKE in that context > would provide an RR test to home registrations. That > does not exist in Mobile IPv6 at the moment, but if > it were included then Mobile IPv6 home agent service > could easier be offered to "unknown" peers. Currently > "unknown" peers are only support as correspondent > nodes. >=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 Nov 1 15:02:44 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23326 for ; Mon, 1 Nov 2004 15:02:43 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7FF70FB27C; Mon, 1 Nov 2004 20:02:44 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 686CDFB255; Mon, 1 Nov 2004 20:02:43 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 28992FB262; Mon, 1 Nov 2004 20:02:41 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 0ACCCFB252 for ; Mon, 1 Nov 2004 20:02:40 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 0E3FA8986C; Mon, 1 Nov 2004 22:02:36 +0200 (EET) Message-ID: <418695F1.9070400@piuha.net> Date: Mon, 01 Nov 2004 22:00:49 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mika.Joutsenvirta@nokia.com Subject: Re: VS: [Mobike] issue 6: scope of SA changes References: <8AA62C0ABD31B544993F7592D885280615CAAF@trebe051.ntc.nokia.com> In-Reply-To: <8AA62C0ABD31B544993F7592D885280615CAAF@trebe051.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Hi Mika, > If we have this fine granularity and we do not want to move some > streaming data from WLAN to GPRS, what would happen to these > SA's that are used to protect the streaming data during the handover? > If they stay as they were, does the streaming server send the data all > the time to this "lost connection", or do we some how delete the > "WLAN SA's" that are not moved to GPRS? > What happens to application level connection? Is it just going to die > because there is no acknowledgements coming in? > > Or should we move all SA's to GPRS and then let the application kill > the unwanted stream? There's probably a few different cases. If we are talking about mobility, then it seems that you have to move everything with you to the new address in any case. (Unless you want to do something like the zero address set for some of the SAs -- this might make sense if you have high-bandwidth traffic that you don't want to come and fill you GPRS buffers. But my head hurts if I try to think about this combination of features...) Another situation is multihoming. You could have stream 1 that you always keep in GPRS and stream 2 that you move to the WLAN whenever its available. If you go out of WLAN coverage, you don't kill stream 2, you just move it back to GPRS. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 1 21:47:15 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05830 for ; Mon, 1 Nov 2004 21:47:13 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id B4957FB282; Tue, 2 Nov 2004 02:47:15 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 44254FB27A; Tue, 2 Nov 2004 02:47:14 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9E8B7FB27C; Tue, 2 Nov 2004 02:47:12 +0000 (UTC) Received: from smtp816.mail.sc5.yahoo.com (smtp816.mail.sc5.yahoo.com [66.163.170.2]) by machshav.com (Postfix) with SMTP id 08BDEFB262 for ; Tue, 2 Nov 2004 02:47:12 +0000 (UTC) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp816.mail.sc5.yahoo.com with SMTP; 2 Nov 2004 02:47:11 -0000 Message-ID: <011101c4a8f3$4c6cbb10$861167c0@adithya> From: "Mohan Parthasarathy" To: , "MOBIKE Mailing List" References: <418529CB.4030601@piuha.net> Subject: Re: [Mobike] issue 6: scope of SA changes Date: Sat, 2 Oct 2004 19:47:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > > Lets have a consensus call on this. From the list > discussion so far I don't see enough people commenting > on this that would enable us to make decision. For > a more accurate decision, I have broken the issue down > into three questions. > > 1. Would it be useful to treat different flows or applications > in a different manner with regards to their multihoming > behaviour? For instance, keep one flow always in GPRS > but allow another flow to use LAN where available. > > Yes, mandatory [ ] > Yes, optional [ X] > No [ ] > > 2. Would you like to provide this functionality through > > Separate IPsec SAs and their independent addresses [ ] > Separate IKE SAs and their independent addresses [X ] > I don't understand completely (all the consequences) as to what it means to keep some IPsec SAs at the old address while the IKE SA moves to the new address. So, i would like to keep it simple for now. -mohan > 3. If you prefer the use of IPsec SAs for this purpose, > would you like > > always manage each SA separately [ ] > provide a default where all SAs are moved [ ] > > Send your answers by Wednesday, Nov 3rd, 2004. The rationale > behind your answers will help others form their opinions, so > please state also why you are answering in a particular way. > > --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 Nov 2 09:30:31 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24205 for ; Tue, 2 Nov 2004 09:30:30 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 61CE1FB286; Tue, 2 Nov 2004 14:30:29 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A5906FB27C; Tue, 2 Nov 2004 14:30:27 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A5A45FB27D; Tue, 2 Nov 2004 14:30:26 +0000 (UTC) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id 66131FB255 for ; Tue, 2 Nov 2004 14:30:25 +0000 (UTC) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2EUMe05614; Tue, 2 Nov 2004 16:30:22 +0200 (EET) X-Scanned: Tue, 2 Nov 2004 16:27:05 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iA2ER5Z3027203; Tue, 2 Nov 2004 16:27:05 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00PkNj2E; Tue, 02 Nov 2004 16:26:20 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2EQ3a22927; Tue, 2 Nov 2004 16:26:03 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Nov 2004 08:25:44 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issue 14 - path testing and congestion Date: Tue, 2 Nov 2004 09:25:44 -0500 Message-ID: Thread-Topic: [Mobike] issue 14 - path testing and congestion Thread-Index: AcS/Y1G6KRU8tu8LRPKKCMxlVzXCrgBg59Yg From: To: , X-OriginalArrivalTime: 02 Nov 2004 14:25:44.0888 (UTC) FILETIME=[D6EA6380:01C4C0E7] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable In my opinion path-testing/path-failover should be a general module, output of which MOBIKE should use. Trying to solve this in the framework of MOBIKE may not be the right place of this=20 functionality, as this could be needed outside MOBIKE also. I would rather make use of the information gotten from some other module outside of MOBIKE. If there is none, we need to initiate a general effort rather than overloading MOBIKE in an unmodular way. Atul > -----Original Message----- > From: mobike-bounces@machshav.com=20 > [mailto:mobike-bounces@machshav.com]On > Behalf Of ext Jari Arkko > Sent: Sunday, October 31, 2004 11:02 AM > To: MOBIKE Mailing List > Subject: [Mobike] issue 14 - path testing and congestion >=20 >=20 >=20 > I'd like to close this issue based on what Bill Sommerfeld > said about it: >=20 > While there may be situations where you can ignore=20 > congestion control > best practices and get excellent benchmark results under carefully > controlled conditions, such environments tend to be unstable under > load and are therefore unsuitable for production use. >=20 > Path failover is likely to be triggered in as the result of packet > loss. Packet loss is often caused by congestion. Sending=20 > a burst of > packets when you detect an event which may be the result=20 > of congestion > has been considered a really bad idea for about two decades now. >=20 > We MUST NOT produce a spec which, if deployed, would force router > vendors to produce countermeasures to protect the rest of=20 > the network > from us. >=20 > As a result, I'd like to suggest that when peers test=20 > candidate addresses > (or pairs), they SHOULD attempt testing all of them, but MUST do this > sequentially (based on an implementation-dependent priority order) and > using an exponential back-off procedure. >=20 > Ok for everyone? I'll assume so unless I hear from you in the next > couple of days. >=20 > Note that the unpleasant but necessary side-effect is that only a > small set of multihoming addresses on both sides is practical. On > larger sets, testing takes too long. Some math about this in >=20 > http://www.arkko.com/publications/multi6/faildet.html#anchor9 >=20 > --Jari >=20 > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 3 00:14:07 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27881 for ; Wed, 3 Nov 2004 00:14:06 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id D6D3AFB27C; Wed, 3 Nov 2004 05:14:07 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C5517FB266; Wed, 3 Nov 2004 05:14:06 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 35559FB27A; Wed, 3 Nov 2004 05:14:06 +0000 (UTC) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id 46DD1FB257 for ; Wed, 3 Nov 2004 05:14:05 +0000 (UTC) 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 iA35E1E02765; Wed, 3 Nov 2004 07:14:01 +0200 (EET) X-Scanned: Wed, 3 Nov 2004 07:12:18 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iA35CIxm013451; Wed, 3 Nov 2004 07:12:18 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00ELMdic; Wed, 03 Nov 2004 07:12:18 EET 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 iA35CHa26395; Wed, 3 Nov 2004 07:12:17 +0200 (EET) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Nov 2004 07:12:18 +0200 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Nov 2004 07:12:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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 6: scope of SA changes Date: Wed, 3 Nov 2004 07:12:15 +0200 Message-ID: <8AA62C0ABD31B544993F7592D8852806145AB3@trebe051.ntc.nokia.com> Thread-Topic: [Mobike] issue 6: scope of SA changes Thread-Index: AcS/dRiUY7yq01SYQai97+Q8zYXiIAB7lxaQ From: To: , X-OriginalArrivalTime: 03 Nov 2004 05:12:17.0146 (UTC) FILETIME=[AFF8D5A0:01C4C163] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable >=20 > 1. Would it be useful to treat different flows or applications > in a different manner with regards to their multihoming > behaviour? For instance, keep one flow always in GPRS > but allow another flow to use LAN where available. >=20 > Yes, mandatory [ ] > Yes, optional [ ] > No [X] >=20 I do not see this that usefull compared to extra complexity. Maybe later on when there is better use case for it. Mika _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Nov 5 09:32:06 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16305 for ; Fri, 5 Nov 2004 09:32:04 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 601A1FB282; Fri, 5 Nov 2004 14:32:05 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E131EFB262; Fri, 5 Nov 2004 14:32:04 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B6722FB27F; Fri, 5 Nov 2004 14:32:02 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 18AF7FB255 for ; Fri, 5 Nov 2004 14:32:02 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 715BF8988D; Fri, 5 Nov 2004 16:31:59 +0200 (EET) Message-ID: <418B8E74.2060802@piuha.net> Date: Fri, 05 Nov 2004 16:30:12 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman / VPNC Subject: [Mobike] agenda for DC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Here's our planned agenda for the upcoming meeting next tuesday. We only have an hour so we want to focus on discussing the issues that we feel are of key importance. But let us know if we missed something that you believe needs to be taken up. IKEv2 Mobility and Multihoming WG Tuesday, November 9, 2004, 1700-1800 Room: Monroe East 1. Preliminaries 2. Issues discussion o Multihoming failure detection and address selection -- an introduction, Jari Arkko, 10 mins o MOBIKE failure detection, Pasi Eronen, 15 mins o Division of work between MOBIKE and other layers, Pasi Eronen, 10 mins o Threats discussion, Tero Kivinen, 15 mins 3. Wrap-up Reading list: http://www.vpnc.org/ietf-mobike/issues.html http://www.ietf.org/internet-drafts/draft-ietf-mobike-design-00.txt http://www.ietf.org/internet-drafts/draft-eronen-mobike-mopo-01.txt http://www.ietf.org/internet-drafts/draft-dupont-ikev2-addrmgmt-06.txt http://www.ietf.org/internet-drafts/draft-kivinen-mobike-protocol-01.txt http://www.ietf.org/internet-drafts/draft-arkko-multi6dt-failure-detection-00.txt _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 8 14:56:04 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21644 for ; Mon, 8 Nov 2004 14:56:03 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 08379FB257; Mon, 8 Nov 2004 19:56:04 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3116EFB251; Mon, 8 Nov 2004 19:56:03 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E36D8FB256; Mon, 8 Nov 2004 19:56:00 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 5F7AAFB24D for ; Mon, 8 Nov 2004 19:56:00 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 4456589889; Mon, 8 Nov 2004 21:55:57 +0200 (EET) Message-ID: <418FCEE0.607@piuha.net> Date: Mon, 08 Nov 2004 21:54:08 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi Eronen , MOBIKE Mailing List Subject: Re: [Mobike] issue 6: scope of SA changes References: <418529CB.4030601@piuha.net> In-Reply-To: <418529CB.4030601@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit I think we have consensus on this. Some of us see a possible need for an optional mechanism that is capable of treating some flows in different manner than others. But it appears that IKE SA based mechanisms are sufficient, i.e., no need to build specific IPsec SA treatment into the protocol. Pasi, you can update the issue list regarding #6. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 8 15:01:41 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22263 for ; Mon, 8 Nov 2004 15:01:38 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 52C0DFB27D; Mon, 8 Nov 2004 20:01:39 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0DFCFFB256; Mon, 8 Nov 2004 20:01:36 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E78FFFB257; Mon, 8 Nov 2004 20:01:34 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id DEF5AFB251 for ; Mon, 8 Nov 2004 20:01:33 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 478DB89889; Mon, 8 Nov 2004 22:01:32 +0200 (EET) Message-ID: <418FD02F.8060006@piuha.net> Date: Mon, 08 Nov 2004 21:59:43 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi Eronen , MOBIKE Mailing List Subject: Re: [Mobike] issue 5: zero address set References: <4185C339.8020507@piuha.net> In-Reply-To: <4185C339.8020507@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit So, the "no TCP spoofing" part is now closed. Pasi, can you split this issue into two parts, and close the TCP part? For the second part, let's make another try with a slightly different process this time. I think we need to be careful about not adding features unless they are absolutely required. So we are going to assume that we do NOT provide zero address sets unless we see multiple people making a case that they actually are needed, and some buy-in for these arguments by the WG. The deadline for this argumentation is Wednesday, Nov 17th. --Jari Jari Arkko wrote: > > There has not been a lot of discussion of this subject on > the list or in the meetings, except that in IETF-59 people > opposed any kind of TCP spoofing. Unless I hear objections > in the next couple of days, we can close this part of the > issue. > > But, theoretically, we could still provide zero address sets > without TCP spoofing. What do people think about this? > > Here's some technical analysis from a personal point of view: > It seems that when the a node has no address, its peer could > develop some condition which requires sending an IKE message > to the node. For instance, rekeying might be necessary for > some reason. Or deletion of the SAs. And on the IPsec list > we have discussed the possibility of reauthentication > requests. Obviously, all of these are going to fail when > the node has no address. The same applies to payload > packets, given that we are not doing spoofing. > > As a result, supporting zero address sets does not really > help in situations where communication is needed during > the period when there is no address. And in any case when > an address is finally available, the node has to verify > that the SAs are still functional. So there is really no > benefit in resumption phase either. Finally, due to the > unpredictability of wireless coverage, not being told > about a zero address set condition is not a guarantee > that the node is reachable. So we cannot easily use this > as an indication to applications either. > > The potential benefit is that no traffic is sent > to the peer's old address. This can be useful in terms > of saving bandwidth, or avoiding someone else get the > packets when an address is recycled. > > Note that a related benefit is that a laptop that gets > suspended for a while does not have to re-establish > SAs when it resumes. This may also mean that a user > does not have to re-enter passwords or use token cards. > However, it seems that this benefit can also be realized > with the zero address set, simply by not informing the > peer about the loss of address. > > --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 Nov 8 15:09:17 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23653 for ; Mon, 8 Nov 2004 15:09:16 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 390BFFB27D; Mon, 8 Nov 2004 20:09:17 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 99C07FB256; Mon, 8 Nov 2004 20:09:14 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0863BFB257; Mon, 8 Nov 2004 20:09:13 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 01758FB251 for ; Mon, 8 Nov 2004 20:09:11 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 3586589889; Mon, 8 Nov 2004 22:09:10 +0200 (EET) Message-ID: <418FD1F9.7070309@piuha.net> Date: Mon, 08 Nov 2004 22:07:21 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com, mobike@machshav.com Subject: Re: [Mobike] issue 12: interaction with other protocols doing RR References: <125EA890549C8641A72F3809CB80DCCD1783A3@esebe056.ntc.nokia.com> In-Reply-To: <125EA890549C8641A72F3809CB80DCCD1783A3@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: kivinen@iki.fi X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit We have gotten less input on this issue than on others, but the way that I read this is the following: (1) We have a basic agreement that we define what MOBIKE RR provides, and if other protocols are happy with that then they can use it without doing their own. (2) THere was a discussion if this works the other way around, i.e., from another protocol to MOBIKE. Tero argued for this and Pasi presented a counter argument. I think the counter argument made sense, and since Tero was silent I'm going to assume you were OK with it too. (3) Atul suggested that APIs be worked on. We at the IETF are typically not chartered to work on APIs; I'm sure you see obvious ways of doing this in your implementation, however. But in MOBIKE, we are chartered to actually work on one API, the PFKEY API. It may be that this would be a part of the that work, or maybe not -- time will tell. But its clear that it is not a requirement for the protocol work to proceed. So we'll remember this when and if we get to the PFKEY part. (Folks: we need to produce are base spec before we get any further!) In conclusion I think we can close this one too. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 8 15:11:40 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24244 for ; Mon, 8 Nov 2004 15:11:39 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 72888FB27D; Mon, 8 Nov 2004 20:11:40 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E7C7BFB256; Mon, 8 Nov 2004 20:11:39 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D451AFB257; Mon, 8 Nov 2004 20:11:37 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id C1D42FB251 for ; Mon, 8 Nov 2004 20:11:36 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 353C689889; Mon, 8 Nov 2004 22:11:35 +0200 (EET) Message-ID: <418FD289.8010606@piuha.net> Date: Mon, 08 Nov 2004 22:09:45 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List , Pasi Eronen , Atul.Sharma@nokia.com Subject: Re: [Mobike] issue 14 - path testing and congestion References: <41850C64.6030004@piuha.net> In-Reply-To: <41850C64.6030004@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit This issue is now closed, as suggested below. Pasi, can you mark it closed on the list? Also, Atul raised the "division of work" question that we have also been discussing in other contexts. Perhaps we should open a new issue number for that too, maybe you Pasi can set that up as well. We will discuss the division of work issue face-to-face in the meeting on Tuesday. --Jari Jari Arkko wrote: > > I'd like to close this issue based on what Bill Sommerfeld > said about it: > > While there may be situations where you can ignore congestion control > best practices and get excellent benchmark results under carefully > controlled conditions, such environments tend to be unstable under > load and are therefore unsuitable for production use. > > Path failover is likely to be triggered in as the result of packet > loss. Packet loss is often caused by congestion. Sending a burst of > packets when you detect an event which may be the result of congestion > has been considered a really bad idea for about two decades now. > > We MUST NOT produce a spec which, if deployed, would force router > vendors to produce countermeasures to protect the rest of the network > from us. > > As a result, I'd like to suggest that when peers test candidate addresses > (or pairs), they SHOULD attempt testing all of them, but MUST do this > sequentially (based on an implementation-dependent priority order) and > using an exponential back-off procedure. > > Ok for everyone? I'll assume so unless I hear from you in the next > couple of days. > > Note that the unpleasant but necessary side-effect is that only a > small set of multihoming addresses on both sides is practical. On > larger sets, testing takes too long. Some math about this in > > http://www.arkko.com/publications/multi6/faildet.html#anchor9 > > --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 Nov 9 13:26:17 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27441 for ; Tue, 9 Nov 2004 13:26:16 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id BA894FB257; Tue, 9 Nov 2004 18:26:18 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 820F1FB24D; Tue, 9 Nov 2004 18:26:17 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 89ADAFB256; Tue, 9 Nov 2004 18:26:16 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 05BC3FB246 for ; Tue, 9 Nov 2004 18:26:16 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id BC9638988B for ; Tue, 9 Nov 2004 20:26:11 +0200 (EET) Message-ID: <41910B57.8020401@piuha.net> Date: Tue, 09 Nov 2004 20:24:23 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [Mobike] room change for MOBIKE X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 8bit Note the following applies to MOBIKE too: All working groups and BOF’s that were scheduled to meet in Monroe East on Tuesday, November 9, 2004 and Wednesday, November 10 will now meet in Jefferson East. The following working groups will now meet in Jefferson East: Tuesday, November 9 at 1300-1400 IPCDN Tuesday, November 9 at 1415-1515 PANA Tuesday, November 9 at 1545-1645 IEPREP Tuesday, November 9 at 1700-1800 MOBIKE Wednesday, November 10 at 0900-1130 IDR Wednesday, November 10 at 1300-1500 MANET Wednesday, November 10 at 1530-1730 6LOWPAN _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 9 15:08:59 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07354 for ; Tue, 9 Nov 2004 15:08:58 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id D39E4FB27C; Tue, 9 Nov 2004 20:08:58 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8F9CDFB26F; Tue, 9 Nov 2004 20:08:57 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D5C17FB279; Tue, 9 Nov 2004 20:08:55 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id A00A6FB257 for ; Tue, 9 Nov 2004 20:08:54 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iA9K8fa00465; Tue, 9 Nov 2004 21:08:41 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iA9K8fSj089981; Tue, 9 Nov 2004 21:08:41 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411092008.iA9K8fSj089981@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] New issue 16: No packets from other end? In-reply-to: Your message of Thu, 28 Oct 2004 13:21:02 +0300. <4180C80E.3050604@piuha.net> Date: Tue, 09 Nov 2004 21:08:41 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: > I think MOBIKE should get use and try to get as much information from > outside as possible, but in the end it still needs to test the > possible address pairs by itself to get positive feedback that the > address pair works. > > => this is (check the address pair works) the job of the IPsec module, > not MOBIKE, at the exception of primary peer addresses for IKE messages. Let me try to understand this statement better. Are you saying that testing an address pair is the job of the ESP/AH module, => this one: the idea is that the important point is the address pair works for the service (which is IPsec, IKE is its control). or that it belongs to the IKEv2 functionality already specified (even without MOBIKE extension)? => DPD is a useful but already existing mechanism. IMHO it is not really enough in this case. I think you must mean the latter. Here's why: the current IKEv2 approach to this appears to be DPD, which works through IKEv2 messages, right? Or am I missing something? (Certainly the lack of ESP packets might be a HINT that something is wrong, but you wouldn't know if it was due to lack of need to send packets until you try with DPD.) => IPsec and IKE packets are the "same" only with UDP encapsulation... so IMHO a direct control (here some kind of DPD) in the IPsec engine is useful too, and even without mobike (i.e., problems should be detected, mobike is here only to provide a way to fix them). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 9 15:12:17 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07851 for ; Tue, 9 Nov 2004 15:12:16 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 9514CFB26F; Tue, 9 Nov 2004 20:12:17 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0D7D0FB26F; Tue, 9 Nov 2004 20:12:17 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F1151FB279; Tue, 9 Nov 2004 20:12:14 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id CB521FB257 for ; Tue, 9 Nov 2004 20:12:13 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iA9KC7a00764; Tue, 9 Nov 2004 21:12:07 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iA9KC8Sj090020; Tue, 9 Nov 2004 21:12:08 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411092012.iA9KC8Sj090020@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] New issue 16: No packets from other end? In-reply-to: Your message of Thu, 28 Oct 2004 13:41:32 +0300. <4180CCDC.3050906@piuha.net> Date: Tue, 09 Nov 2004 21:12:08 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: Vijay Devarapalli , mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: Francis Dupont wrote: > In your previous mail you wrote: > > I agree that while the IP stack (MIP6 or multi6) can determine > if there is a pair of addresses that the IP stack can use, we > still need an IKE message to figure out if the IKE endpoints > have a pair of addresses that they can use. and if the IP > stack (or a policy on the mobile node) tells MOBIKE to use a > particular address, that address should be tried first always. > > => can you define "MOBIKE to use a particular address"? I think that when Vijay said "MOBIKE" he meant the system composed of IPsec, IKEv2, and MOBIKE. Essentially, its the IKEv2 messages and IPsec AH/ESP packets that need to use an address. There may be some MOBIKE control messages too, but those are carried on top of IKEv2. And MOBIKE exists for the reason that it should help IKEv2 and IPsec traffic to go to the right address. => so you have two different usages: the IPsec one (which is important because the provided service is IPsec) and the IKEv2 one (MOBIUKE is "embedded" into IKEv2). The second is already handled by the DPD of IKEv2. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 9 16:51:24 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17401 for ; Tue, 9 Nov 2004 16:51:23 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 12392FB27D; Tue, 9 Nov 2004 21:51:24 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 38D40FB26F; Tue, 9 Nov 2004 21:51:23 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 91C5CFB279; Tue, 9 Nov 2004 21:51:21 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 486DDFB256 for ; Tue, 9 Nov 2004 21:51:20 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iA9LpDa07047; Tue, 9 Nov 2004 22:51:13 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iA9LpDSj090274; Tue, 9 Nov 2004 22:51:13 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411092151.iA9LpDSj090274@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] issue 6: scope of SA changes In-reply-to: Your message of Sun, 31 Oct 2004 20:07:07 +0200. <418529CB.4030601@piuha.net> Date: Tue, 09 Nov 2004 22:51:12 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: Lets have a consensus call on this. => consensus on a mailing list takes time... From the list discussion so far I don't see enough people commenting on this that would enable us to make decision. For a more accurate decision, I have broken the issue down into three questions. 1. Would it be useful to treat different flows or applications in a different manner with regards to their multihoming behaviour? For instance, keep one flow always in GPRS but allow another flow to use LAN where available. Yes, mandatory [X] Yes, optional [ ] No [ ] => note this is exactly the way SCTP works. 2. Would you like to provide this functionality through Separate IPsec SAs and their independent addresses [X] Separate IKE SAs and their independent addresses [ ] => one IKE SA to manage the whole thing is the simplest (so the best) solution. 3. If you prefer the use of IPsec SAs for this purpose, would you like always manage each SA separately [ ] provide a default where all SAs are moved [X] Send your answers by Wednesday, Nov 3rd, 2004. => not everybody is at 100% on this job, please give reasonable dead-lines (i.e., don't follow another WG pretty bad example :-). The rationale behind your answers will help others form their opinions, so please state also why you are answering in a particular way. => there is something forgotten: what to do with the SPD? If only SAD is updated, at the next re-keying the new SA pair will use the old addresses... In the mobility case one can even argue some SPD entries without corresponding SAs should be updated too! Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 9 16:56:09 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17795 for ; Tue, 9 Nov 2004 16:56:08 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 66219FB281; Tue, 9 Nov 2004 21:56:10 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 40DD5FB279; Tue, 9 Nov 2004 21:56:06 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AA8D8FB27A; Tue, 9 Nov 2004 21:56:04 +0000 (UTC) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by machshav.com (Postfix) with ESMTP id 13C19FB26F for ; Tue, 9 Nov 2004 21:56:04 +0000 (UTC) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iA9LSCJ05736; Tue, 9 Nov 2004 13:28:12 -0800 X-mProtect: <200411092128> Nokia Silicon Valley Messaging Protection Received: from danira-pool048150.americas.nokia.com (10.241.48.150, claiming to be "[10.241.48.150]") by darkstar.iprg.nokia.com smtpdmtUZP9; Tue, 09 Nov 2004 13:28:10 PST Message-ID: <41913CDE.4030707@iprg.nokia.com> Date: Tue, 09 Nov 2004 13:55:42 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mobike] issue 12: interaction with other protocols doing RR References: <41850943.1090107@piuha.net> <00aa01c4c031$16b074d0$656115ac@dcml.docomolabsusa.com> In-Reply-To: <00aa01c4c031$16b074d0$656115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , jari.arkko@piuha.net X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit James Kempf wrote: > Jari, > > >>*) The example that comes to my mind is that since the >>mobile node - home agent interface in mobile IPv6 runs >>with IPsec, then the use of MOBIKE in that context >>would provide an RR test to home registrations. That >>does not exist in Mobile IPv6 at the moment, but if >>it were included then Mobile IPv6 home agent service >>could easier be offered to "unknown" peers. Currently >>"unknown" peers are only support as correspondent >>nodes. >> > > > IMHO, the lack of HA RR test in RFC 3775 is a residual vulnerability. RFC > 3775 says that network operators should monitor their clients traffic and > cut them off if they try bombing. But how is an operator supposed to know > that? In the absence of any RR test, there's no way for the HA to know > whether the MN is at the care of address to which it is directing a video > stream, or whether its a bombing attack. This kind of insider attack is > still possible. > > So I think this is an excellent idea. In fact, I think it should be used not > just with "unknown" peers but also with known clients of the HA. I would rather add an RR test to Mobile IP. It could be a simple Mobility Header message probe protected by IPsec. a couple of reasons. 1. I am not sure we are going to be using MOBIKE between a MN and HA (when they are already doing Mobile IPv6 signaling. BU is your MOBIKE update message). 2. no need to have some kind of interaction between the IKE stack and the Mobile IPv6 stack Vijay _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 9 16:58:36 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18104 for ; Tue, 9 Nov 2004 16:58:35 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id C7B98FB284; Tue, 9 Nov 2004 21:58:36 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B79AFFB27A; Tue, 9 Nov 2004 21:58:35 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0AF29FB27C; Tue, 9 Nov 2004 21:58:35 +0000 (UTC) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by machshav.com (Postfix) with ESMTP id 6D318FB279 for ; Tue, 9 Nov 2004 21:58:34 +0000 (UTC) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iA9LUli10985; Tue, 9 Nov 2004 13:30:47 -0800 X-mProtect: <200411092130> Nokia Silicon Valley Messaging Protection Received: from danira-pool048150.americas.nokia.com (10.241.48.150, claiming to be "[10.241.48.150]") by darkstar.iprg.nokia.com smtpdFa0ncl; Tue, 09 Nov 2004 13:30:46 PST Message-ID: <41913D7A.4050200@iprg.nokia.com> Date: Tue, 09 Nov 2004 13:58:18 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mobike] issue 12: interaction with other protocols doing RR References: <41850943.1090107@piuha.net> <00aa01c4c031$16b074d0$656115ac@dcml.docomolabsusa.com> <41913CDE.4030707@iprg.nokia.com> In-Reply-To: <41913CDE.4030707@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: jari.arkko@piuha.net, MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit I think I pressed "send" before completing the second point > I would rather add an RR test to Mobile IP. It could be a > simple Mobility Header message probe protected by IPsec. > a couple of reasons. > 1. I am not sure we are going to be using MOBIKE between > a MN and HA (when they are already doing Mobile IPv6 > signaling. BU is your MOBIKE update message). > 2. no need to have some kind of interaction between the > IKE stack and the Mobile IPv6 stack no need to have some kind of interaction between the IKE stack and the Mobile IPv6 stack for RR test. > > Vijay > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 9 17:02:26 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18509 for ; Tue, 9 Nov 2004 17:02:24 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 50654FB27C; Tue, 9 Nov 2004 22:02:26 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7A0BEFB27A; Tue, 9 Nov 2004 22:02:21 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 797EDFB27C; Tue, 9 Nov 2004 22:02:20 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 5FD58FB257 for ; Tue, 9 Nov 2004 22:02:19 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iA9M2Da07936; Tue, 9 Nov 2004 23:02:13 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iA9M2ESj090334; Tue, 9 Nov 2004 23:02:14 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411092202.iA9M2ESj090334@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] issue 6: scope of SA changes In-reply-to: Your message of Mon, 08 Nov 2004 21:54:08 +0200. <418FCEE0.607@piuha.net> Date: Tue, 09 Nov 2004 23:02:14 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Pasi Eronen X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: I think we have consensus on this. => no, you don't or you have a strange idea of what is a consensus... (at least not mine :-) Some of us see a possible need for an optional mechanism that is capable of treating some flows in different manner than others. But it appears that IKE SA based mechanisms are sufficient, i.e., no need to build specific IPsec SA treatment into the protocol. => I disagree, in fact expressed opinions at your exception are all about the mobile context, not the multi-homing or the SCTP contexts. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 9 17:07:52 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19280 for ; Tue, 9 Nov 2004 17:07:50 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id A1E57FB285; Tue, 9 Nov 2004 22:07:52 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8841FFB280; Tue, 9 Nov 2004 22:07:51 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D518DFB283; Tue, 9 Nov 2004 22:07:50 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id ABE85FB27A for ; Tue, 9 Nov 2004 22:07:49 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iA9M7ha08502; Tue, 9 Nov 2004 23:07:43 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iA9M7iSj090359; Tue, 9 Nov 2004 23:07:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411092207.iA9M7iSj090359@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] issue 6: scope of SA changes In-reply-to: Your message of Mon, 01 Nov 2004 18:43:17 +0200. <125EA890549C8641A72F3809CB80DCCD1783A5@esebe056.ntc.nokia.com> Date: Tue, 09 Nov 2004 23:07:44 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, jari.arkko@piuha.net X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: Separate IKE SAs are IMHO the simplest way to go, considering that - I think that real-world MOBIKE deployments will not use this kind of functionality anyway, or at least it will be extremely rare in the near future. => I exactly believe the opposite. IMHO this is because you think about mobility and I think about multi-homing and SCTP... - In many of those rare cases where different treatment is needed, it can be handled adequately by creating several IKE SAs. => following this argument we can close the MOBIKE WG (:-). - This simplifies the protocol somewhat (e.g., no need to treat those addresses differently for RR purposes). => I don't understand (in fact I understand but only by refering to mobility needs :-). - If the remaining cases (where the ability to have only a single IKE SA would provide substantial user-visible benefits) become more important e.g. five years from now, we can do something about them then. => multi-homing is already 5 year late, please don't add 5 other years just because the problem doesn't interest you. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 9 17:10:02 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19543 for ; Tue, 9 Nov 2004 17:10:00 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id A9BF9FB28B; Tue, 9 Nov 2004 22:10:02 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D86CAFB283; Tue, 9 Nov 2004 22:10:01 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B21E5FB289; Tue, 9 Nov 2004 22:09:59 +0000 (UTC) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id F2A12FB280 for ; Tue, 9 Nov 2004 22:09:58 +0000 (UTC) Message-ID: <039201c4c6a8$f9ab8770$646015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Vijay Devarapalli" References: <41850943.1090107@piuha.net> <00aa01c4c031$16b074d0$656115ac@dcml.docomolabsusa.com> <41913CDE.4030707@iprg.nokia.com> Subject: Re: [Mobike] issue 12: interaction with other protocols doing RR Date: Tue, 9 Nov 2004 14:10:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , jari.arkko@piuha.net X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Vijay, > I would rather add an RR test to Mobile IP. It could be a > simple Mobility Header message probe protected by IPsec. > a couple of reasons. I've no objection to this, it might even be a better solution. > 1. I am not sure we are going to be using MOBIKE between > a MN and HA (when they are already doing Mobile IPv6 > signaling. BU is your MOBIKE update message). > 2. no need to have some kind of interaction between the > IKE stack and the Mobile IPv6 stack > I think it would be useful to compare the two solutions. I have not read your IKEv2 for MIP draft, but I am interested to know if some of the backdoor API changes in IPsec mentioned in RFC 3776 could be removed if the HA and MN support MOBIKE. Do you think this would be possible? jak _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 9 17:13:28 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19899 for ; Tue, 9 Nov 2004 17:13:26 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id EF1F5FB283; Tue, 9 Nov 2004 22:13:27 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3DBDBFB286; Tue, 9 Nov 2004 22:13:27 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 17E46FB289; Tue, 9 Nov 2004 22:13:26 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 04236FB283 for ; Tue, 9 Nov 2004 22:13:25 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iA9MDJa08861; Tue, 9 Nov 2004 23:13:19 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iA9MDJSj090394; Tue, 9 Nov 2004 23:13:19 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411092213.iA9MDJSj090394@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] issue 5: zero address set In-reply-to: Your message of Mon, 01 Nov 2004 07:01:45 +0200. <4185C339.8020507@piuha.net> Date: Tue, 09 Nov 2004 23:13:19 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com I don't believe zero address set support is so useful but I have a little concern about it: when a node has really no available addresses I prefer its peer knows this in place of just keep the last usable address and suggest it does still work... Of course, this situation should be temporary. Regards Francis.Dupont@enst-bretagne.fr PS: to come back to mobility, when a mobile goes from a physical interface to another one, in the middle it has two or zero interfaces, and both cases have "interesting" consequences (here we can see zero cases'). _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 9 17:20:22 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20575 for ; Tue, 9 Nov 2004 17:20:20 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id B3B82FB297; Tue, 9 Nov 2004 22:20:22 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4471AFB28A; Tue, 9 Nov 2004 22:20:17 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id ACD9CFB28D; Tue, 9 Nov 2004 22:20:15 +0000 (UTC) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by machshav.com (Postfix) with ESMTP id 20EABFB289 for ; Tue, 9 Nov 2004 22:20:15 +0000 (UTC) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iA9LqEl06846; Tue, 9 Nov 2004 13:52:14 -0800 X-mProtect: <200411092152> Nokia Silicon Valley Messaging Protection Received: from danira-pool048150.americas.nokia.com (10.241.48.150, claiming to be "[10.241.48.150]") by darkstar.iprg.nokia.com smtpdF28enM; Tue, 09 Nov 2004 13:52:12 PST Message-ID: <41914276.30908@iprg.nokia.com> Date: Tue, 09 Nov 2004 14:19:34 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mobike] issue 12: interaction with other protocols doing RR References: <41850943.1090107@piuha.net> <00aa01c4c031$16b074d0$656115ac@dcml.docomolabsusa.com> <41913CDE.4030707@iprg.nokia.com> <039201c4c6a8$f9ab8770$646015ac@dcml.docomolabsusa.com> In-Reply-To: <039201c4c6a8$f9ab8770$646015ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit James Kempf wrote: > Vijay, > > >>I would rather add an RR test to Mobile IP. It could be a >>simple Mobility Header message probe protected by IPsec. >>a couple of reasons. > > > I've no objection to this, it might even be a better solution. > > >>1. I am not sure we are going to be using MOBIKE between >> a MN and HA (when they are already doing Mobile IPv6 >> signaling. BU is your MOBIKE update message). >>2. no need to have some kind of interaction between the >> IKE stack and the Mobile IPv6 stack >> > > > I think it would be useful to compare the two solutions. > > I have not read your IKEv2 for MIP draft, but I am interested to know if > some of the backdoor API changes in IPsec mentioned in RFC 3776 could be nope. it is standard for anyone supporting PF_KEY. > removed if the HA and MN support MOBIKE. Do you think this would be > possible? it would be a bad idea if you the MN has to send a MOBIKE update in addition to binding update during a handoff. we should try to do it one message. there is already a secured message for doing the update (a Binding Update). Vijay _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 9 17:24:06 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20894 for ; Tue, 9 Nov 2004 17:24:06 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 0BB72FB281; Tue, 9 Nov 2004 22:24:06 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D3FD1FB257; Tue, 9 Nov 2004 22:24:03 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1D49CFB26F; Tue, 9 Nov 2004 22:24:03 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 9FEFBFB256 for ; Tue, 9 Nov 2004 22:24:02 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 4C6518988B for ; Wed, 10 Nov 2004 00:24:00 +0200 (EET) Message-ID: <41914312.3070806@piuha.net> Date: Wed, 10 Nov 2004 00:22:10 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] mobike slides are available at X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit http://www.arkko.com/publications/mobike/ _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 9 17:32:24 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21815 for ; Tue, 9 Nov 2004 17:32:23 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id CEDF1FB27C; Tue, 9 Nov 2004 22:32:22 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 36D9FFB257; Tue, 9 Nov 2004 22:32:22 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8D2FEFB26F; Tue, 9 Nov 2004 22:32:20 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 65D95FB256 for ; Tue, 9 Nov 2004 22:32:19 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iA9MW9a10040; Tue, 9 Nov 2004 23:32:09 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iA9MW9Sj090585; Tue, 9 Nov 2004 23:32:09 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411092232.iA9MW9Sj090585@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli Subject: Re: [Mobike] issue 12: interaction with other protocols doing RR In-reply-to: Your message of Tue, 09 Nov 2004 13:55:42 PST. <41913CDE.4030707@iprg.nokia.com> Date: Tue, 09 Nov 2004 23:32:09 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: jari.arkko@piuha.net, James Kempf , MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: I would rather add an RR test to Mobile IP. => I don't understand this necessity to even more damage Mobile IPv6. Perhaps it is not yet in trouble? It could be a simple Mobility Header message probe protected by IPsec. => it simply costs a RTT for a second order threat. a couple of reasons. 1. I am not sure we are going to be using MOBIKE between a MN and HA (when they are already doing Mobile IPv6 signaling. BU is your MOBIKE update message). => we are going to use either MOBIKE between a mobile VPN client and SG, or Mobile IPv6 between a MN and HA. 2. no need to have some kind of interaction between the IKE stack and the Mobile IPv6 stack => and the K flag? Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 9 17:49:04 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23709 for ; Tue, 9 Nov 2004 17:49:03 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 5BA42FB27C; Tue, 9 Nov 2004 22:49:05 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 52444FB257; Tue, 9 Nov 2004 22:49:04 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 56CA1FB26F; Tue, 9 Nov 2004 22:49:02 +0000 (UTC) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by machshav.com (Postfix) with ESMTP id C0440FB256 for ; Tue, 9 Nov 2004 22:49:01 +0000 (UTC) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iA9MLFH10871; Tue, 9 Nov 2004 14:21:15 -0800 X-mProtect: <200411092221> Nokia Silicon Valley Messaging Protection Received: from danira-pool048150.americas.nokia.com (10.241.48.150, claiming to be "[10.241.48.150]") by darkstar.iprg.nokia.com smtpdcY9HRi; Tue, 09 Nov 2004 14:21:14 PST Message-ID: <4191494A.3060407@iprg.nokia.com> Date: Tue, 09 Nov 2004 14:48:42 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] issue 12: interaction with other protocols doing RR References: <200411092232.iA9MW9Sj090585@givry.rennes.enst-bretagne.fr> In-Reply-To: <200411092232.iA9MW9Sj090585@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Francis Dupont wrote: > In your previous mail you wrote: > > I would rather add an RR test to Mobile IP. > > => I don't understand this necessity to even more damage Mobile IPv6. > Perhaps it is not yet in trouble? I agree with you. if an RR test is needed for Mobile IP, we can develop it in Mobile IPv6. I dont see MOBIKE's RR test used by Mobile IPv6. > > It could be a > simple Mobility Header message probe protected by IPsec. > > => it simply costs a RTT for a second order threat. > > a couple of reasons. > 1. I am not sure we are going to be using MOBIKE between > a MN and HA (when they are already doing Mobile IPv6 > signaling. BU is your MOBIKE update message). > > => we are going to use either MOBIKE between a mobile VPN client > and SG, or Mobile IPv6 between a MN and HA. agree completely. > > 2. no need to have some kind of interaction between the > IKE stack and the Mobile IPv6 stack > > => and the K flag? right. we dont need it for an RR test. Vijay > > Regards > > Francis.Dupont@enst-bretagne.fr > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 10 06:38:15 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25260 for ; Wed, 10 Nov 2004 06:38:13 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 5A27EFB27C; Wed, 10 Nov 2004 11:38:10 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B578CFB257; Wed, 10 Nov 2004 11:38:08 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 48777FB262; Wed, 10 Nov 2004 11:38:07 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id B48D7FB256 for ; Wed, 10 Nov 2004 11:38:06 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 5A2108988D; Wed, 10 Nov 2004 13:38:01 +0200 (EET) Message-ID: <4191FD2D.9080008@piuha.net> Date: Wed, 10 Nov 2004 13:36:13 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mobike] issue 12: interaction with other protocols doing RR References: <41850943.1090107@piuha.net> <00aa01c4c031$16b074d0$656115ac@dcml.docomolabsusa.com> <41913CDE.4030707@iprg.nokia.com> In-Reply-To: <41913CDE.4030707@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > I would rather add an RR test to Mobile IP. It could be a > simple Mobility Header message probe protected by IPsec. > a couple of reasons. > 1. I am not sure we are going to be using MOBIKE between > a MN and HA (when they are already doing Mobile IPv6 > signaling. BU is your MOBIKE update message). > 2. no need to have some kind of interaction between the > IKE stack and the Mobile IPv6 stack Yes, this is indeed another (and pretty good) alternative! But stating in the MOBIKE document that the results of the RR test are usable by "applications" leaves this choice to you (or the MIP6 WG). --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 10 08:46:25 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07797 for ; Wed, 10 Nov 2004 08:46:23 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id E59D5FB257; Wed, 10 Nov 2004 13:46:23 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6677FFB24A; Wed, 10 Nov 2004 13:46:23 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E1D70FB24D; Wed, 10 Nov 2004 13:46:21 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id BEE7FFB246 for ; Wed, 10 Nov 2004 13:46:20 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iAADkDa06046; Wed, 10 Nov 2004 14:46:13 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iAADkASj092698; Wed, 10 Nov 2004 14:46:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411101346.iAADkASj092698@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "James Kempf" Subject: Re: [Mobike] issue 12: interaction with other protocols doing RR In-reply-to: Your message of Tue, 09 Nov 2004 14:10:44 PST. <039201c4c6a8$f9ab8770$646015ac@dcml.docomolabsusa.com> Date: Wed, 10 Nov 2004 14:46:10 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: jari.arkko@piuha.net, Vijay Devarapalli , MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: > 1. I am not sure we are going to be using MOBIKE between > a MN and HA (when they are already doing Mobile IPv6 > signaling. BU is your MOBIKE update message). > 2. no need to have some kind of interaction between the > IKE stack and the Mobile IPv6 stack I think it would be useful to compare the two solutions. I have not read your IKEv2 for MIP draft, but I am interested to know if some of the backdoor API changes in IPsec mentioned in RFC 3776 could be removed if the HA and MN support MOBIKE. Do you think this would be possible? => Jak, it seems you missed an important point: Mobile IPv6 and MOBIKE are two *incompatible* solutions for the same problem (if you restrict things to IPv6 mobility without optimization). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 10 09:18:31 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10782 for ; Wed, 10 Nov 2004 09:18:30 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7D641FB257; Wed, 10 Nov 2004 14:18:31 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 14EB5FB24A; Wed, 10 Nov 2004 14:18:31 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 30E2EFB24D; Wed, 10 Nov 2004 14:18:30 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 081EFFB246 for ; Wed, 10 Nov 2004 14:18:29 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iAAEINa08363; Wed, 10 Nov 2004 15:18:23 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iAAEINSj092846; Wed, 10 Nov 2004 15:18:23 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411101418.iAAEINSj092846@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli Subject: Re: [Mobike] issue 12: interaction with other protocols doing RR In-reply-to: Your message of Tue, 09 Nov 2004 14:48:42 PST. <4191494A.3060407@iprg.nokia.com> Date: Wed, 10 Nov 2004 15:18:23 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: > => I don't understand this necessity to even more damage Mobile IPv6. > Perhaps it is not yet in trouble? I agree with you. if an RR test is needed for Mobile IP, we can develop it in Mobile IPv6. I dont see MOBIKE's RR test used by Mobile IPv6. => perhaps we don't speak about the same thing: I argue the RR test is not necessary (and as it has a cost is only a burden we should not add) for mobile IPv4/IPv6. And it should be optional for MOBIKE, i.e., it should be performed by the SG of a mobile VPN only if it is in its policy. IMHO the only thing we should talk about is what to put in the default policy (perform or not perform an RR test by default?) > => we are going to use either MOBIKE between a mobile VPN client > and SG, or Mobile IPv6 between a MN and HA. agree completely. => so the mobile IP part of this discussion is clearly outside the scope of both the WG and the list. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 10 10:34:01 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20752 for ; Wed, 10 Nov 2004 10:34:00 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 5D91BFB262; Wed, 10 Nov 2004 15:34:00 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D5777FB24D; Wed, 10 Nov 2004 15:33:59 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C05D7FB256; Wed, 10 Nov 2004 15:33:58 +0000 (UTC) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 0053CFB246 for ; Wed, 10 Nov 2004 15:33:57 +0000 (UTC) Message-ID: <043e01c4c73a$d170d5c0$646015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Francis Dupont" References: <200411101346.iAADkASj092698@givry.rennes.enst-bretagne.fr> Subject: Re: [Mobike] issue 12: interaction with other protocols doing RR Date: Wed, 10 Nov 2004 07:34:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: jari.arkko@piuha.net, Vijay Devarapalli , MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Um, thanx Francis. Your application of a baseball bat has driven the point home. :-) jak ----- Original Message ----- From: "Francis Dupont" To: "James Kempf" Cc: "Vijay Devarapalli" ; "MOBIKE Mailing List" ; Sent: Wednesday, November 10, 2004 5:46 AM Subject: Re: [Mobike] issue 12: interaction with other protocols doing RR > In your previous mail you wrote: > > > 1. I am not sure we are going to be using MOBIKE between > > a MN and HA (when they are already doing Mobile IPv6 > > signaling. BU is your MOBIKE update message). > > 2. no need to have some kind of interaction between the > > IKE stack and the Mobile IPv6 stack > > I think it would be useful to compare the two solutions. > > I have not read your IKEv2 for MIP draft, but I am interested to know if > some of the backdoor API changes in IPsec mentioned in RFC 3776 could be > removed if the HA and MN support MOBIKE. Do you think this would be > possible? > > => Jak, it seems you missed an important point: Mobile IPv6 and > MOBIKE are two *incompatible* solutions for the same problem (if > you restrict things to IPv6 mobility without optimization). > > Regards > > Francis.Dupont@enst-bretagne.fr > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Nov 11 15:31:56 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22846 for ; Thu, 11 Nov 2004 15:31:54 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 3978CFB279; Thu, 11 Nov 2004 20:31:54 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8D02EFB255; Thu, 11 Nov 2004 20:31:51 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1F5C2FB262; Thu, 11 Nov 2004 20:31:50 +0000 (UTC) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 58F98FB246 for ; Thu, 11 Nov 2004 20:31:49 +0000 (UTC) Message-ID: <06a301c4c82d$97439a10$646015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "MOBIKE Mailing List" Date: Thu, 11 Nov 2004 12:32:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Charlie Kaufman Subject: [Mobike] Mobile IP and Mobike X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit So nobody's come out and spoken directly to the issue, but there's been lots of talk around the edges. Here's my interpretation of what the interaction of Mobile IP and Mobike is. >From the discussion on the list and at the meeting this week, it sounds like Mobike and Mobile IP are separate and incompatible solutions to mobility, with orthogonal deployment scenerios. They are incompatible because deploying them together on the same box would result in duplicate "binding update" messages between the host and the tunnel endpoint (which is the home agent in Mobile IP). From this, I deduce that having both in a host stack at the same time is to be discouraged. Their deployment scenerios are orthogonal because Mobile IP is targetted at wireless network service providers and Mobike is targeted more at enterprise customers with road warriors. There might be some overlap for cases such as UMA, which is using IPsec tunnels set up using IKEv2 over WLAN to tunnel gateways through which circuit-switched GSM voice traffic and GSM signaling is directed, in addition to GPRS traffic. The UMA gateways are presumably in a wireless network operator's network. Am I missing something? Is more detailed analysis necessary to confirm this admittedly superficial description? Fire away! jak _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Nov 11 16:13:34 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28749 for ; Thu, 11 Nov 2004 16:13:33 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7E45BFB27A; Thu, 11 Nov 2004 21:13:34 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 812DFFB255; Thu, 11 Nov 2004 21:13:33 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 61A3FFB262; Thu, 11 Nov 2004 21:13:32 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 0CD07FB240 for ; Thu, 11 Nov 2004 21:13:31 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iABLDMT18786; Thu, 11 Nov 2004 22:13:22 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iABLDNSj098121; Thu, 11 Nov 2004 22:13:23 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411112113.iABLDNSj098121@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "James Kempf" Subject: Re: [Mobike] Mobile IP and Mobike In-reply-to: Your message of Thu, 11 Nov 2004 12:32:33 PST. <06a301c4c82d$97439a10$646015ac@dcml.docomolabsusa.com> Date: Thu, 11 Nov 2004 22:13:23 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Charlie Kaufman X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: >From the discussion on the list and at the meeting this week, it sounds like Mobike and Mobile IP are separate and incompatible solutions to mobility, => they are incompatible as competing signaling between the mobile node and the home agent, using the mobile IPv6 terms. One can use the routing optimization of mobile IPv6 with a correspondent node when mobike is used for the signaling with the home agent. So the context (again) does matter. with orthogonal deployment scenerios. They are incompatible because deploying them together on the same box would result in duplicate "binding update" messages between the host and the tunnel endpoint (which is the home agent in Mobile IP). => I can't disagree (:-). From this, I deduce that having both in a host stack at the same time is to be discouraged. => I disagree: even the home agent and the security gateway can have the same role they are deeply different. In fact, IMHO this convergence between security and mobility is a very good thing, at least it should obsolete my old I-D asking to avoid double tunelling! Their deployment scenerios are orthogonal because Mobile IP is targetted at wireless network service providers => this mobile == wireless == cellular credo makes no sense. and Mobike is targeted more at enterprise customers with road warriors. => in this room (SAAG session at IETF meeting) many use a nomadic VPN (aka road warrior VPN) over a wireless network. I don't believe there is a real split in usage, just that users will come from two different communities. There might be some overlap for cases such as UMA, which is using IPsec tunnels set up using IKEv2 over WLAN to tunnel gateways through which circuit-switched GSM voice traffic and GSM signaling is directed, in addition to GPRS traffic. => I can speak about GPRS: the IP service is so poor (private IPv4 addresses, filtering madness, etc) that the best way to use them for real things (i.e., to go somewhere throught the Internet) is to use L2TP, i.e., use one of the options offered by current VPNs. But mobility is not forgotten because it is needed for "vertical handovers" when you can get locally faster and cheaper than GPRS. Am I missing something? Is more detailed analysis necessary to confirm this admittedly superficial description? Fire away! => orthogonal means than the product is zero. IMHO this is far too pessimistic, and for the MOBIKE side you forget the multi-homing and SCTP contexts (do we need to change the name of the WG to avoid this bias?) Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Nov 11 16:24:31 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29863 for ; Thu, 11 Nov 2004 16:24:30 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 685A2FB27A; Thu, 11 Nov 2004 21:24:31 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E3B33FB255; Thu, 11 Nov 2004 21:24:29 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 32096FB262; Thu, 11 Nov 2004 21:24:29 +0000 (UTC) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by machshav.com (Postfix) with ESMTP id 711DAFB246 for ; Thu, 11 Nov 2004 21:24:28 +0000 (UTC) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I7100201A4Q93@mailout2.samsung.com> for mobike@machshav.com; Fri, 12 Nov 2004 06:24:26 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I7100GTTA4Q9K@mailout2.samsung.com> for mobike@machshav.com; Fri, 12 Nov 2004 06:24:26 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I7100KU5A4NBE@mmp1.samsung.com> for mobike@machshav.com; Fri, 12 Nov 2004 06:24:25 +0900 (KST) Date: Thu, 11 Nov 2004 13:24:23 -0800 From: Alper Yegin Subject: RE: [Mobike] Mobile IP and Mobike In-reply-to: <06a301c4c82d$97439a10$646015ac@dcml.docomolabsusa.com> To: "'James Kempf'" , "'MOBIKE Mailing List'" Message-id: <01f601c4c834$d1c26890$7a868182@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Cc: "'Charlie Kaufman'" X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7BIT Thanks James for bringing this up. I'm also curious about this. > So nobody's come out and spoken directly to the issue, but there's been > lots > of talk around the edges. Here's my interpretation of what the interaction > of Mobile IP and Mobike is. > > >From the discussion on the list and at the meeting this week, it sounds > like > Mobike and Mobile IP are separate and incompatible solutions to mobility, > with orthogonal deployment scenerios. They are incompatible because > deploying them together on the same box would result in duplicate "binding > update" messages between the host and the tunnel endpoint (which is the > home > agent in Mobile IP). From this, I deduce that having both in a host stack > at > the same time is to be discouraged. So, my question is: can I use Mobike instead of Mobile IPv6 to achieve the same level of IP-layer mobility management (except MIP6 route optimization)? If not, what is the delta? > Their deployment scenerios are > orthogonal because Mobile IP is targetted at wireless network service > providers and Mobike is targeted more at enterprise customers with road > warriors. I'm not sure what the protocol-level distinction is between the two deployments in this context. > There might be some overlap for cases such as UMA, which is > using > IPsec tunnels set up using IKEv2 over WLAN to tunnel gateways through > which > circuit-switched GSM voice traffic and GSM signaling is directed, in > addition to GPRS traffic. The UMA gateways are presumably in a wireless > network operator's network. > > Am I missing something? Is more detailed analysis necessary to confirm > this > admittedly superficial description? Fire away! Alper > > jak > > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Nov 11 16:39:01 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01407 for ; Thu, 11 Nov 2004 16:39:00 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id A5C6BFB27D; Thu, 11 Nov 2004 21:39:00 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BF6B2FB255; Thu, 11 Nov 2004 21:38:55 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F1930FB262; Thu, 11 Nov 2004 21:38:54 +0000 (UTC) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id EAD13FB246 for ; Thu, 11 Nov 2004 21:38:53 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iABLceJx009971 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 11 Nov 2004 23:38:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iABLcddu009968; Thu, 11 Nov 2004 23:38:39 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16787.56287.385658.935976@fireball.kivinen.iki.fi> Date: Thu, 11 Nov 2004 23:38:39 +0200 From: Tero Kivinen To: "James Kempf" Subject: [Mobike] Mobile IP and Mobike In-Reply-To: <06a301c4c82d$97439a10$646015ac@dcml.docomolabsusa.com> References: <06a301c4c82d$97439a10$646015ac@dcml.docomolabsusa.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: MOBIKE Mailing List , Charlie Kaufman X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit James Kempf writes: > So nobody's come out and spoken directly to the issue, but there's been lots > of talk around the edges. Here's my interpretation of what the interaction > of Mobile IP and Mobike is. The mobike is targeted to the environments where the other end of the connection is stable, i.e the VPN sgw or similar. The mobile ip both ends can move, and the connection is not necessarely from the mobile node to the sgw to the www-server (for example), but can also go directly between mobile node and www-server. The mobile IP can benefit from the MOBIKE when handing the mobile node and home agent connection. I.e. instead of recreating the SAs from scratch every time mobile node moves, or doing all kind of wierd IPsec processing to make simulate same stuff inside the ipsec stack, mobile IP can leave the MOBIKE to take care of the IPsec connection between the mobile node and home agent, and it only needs to concenctrate to the route optimization etc to make the connection which are not going to the home agent or home network more efficient. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Nov 11 17:07:04 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04193 for ; Thu, 11 Nov 2004 17:07:02 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id D0F91FB27C; Thu, 11 Nov 2004 22:07:02 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0B063FB255; Thu, 11 Nov 2004 22:06:59 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 59330FB262; Thu, 11 Nov 2004 22:06:57 +0000 (UTC) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id B69C9FB246 for ; Thu, 11 Nov 2004 22:06:56 +0000 (UTC) Message-ID: <06d701c4c83a$e1f7ac60$646015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Tero Kivinen" References: <06a301c4c82d$97439a10$646015ac@dcml.docomolabsusa.com> <16787.56287.385658.935976@fireball.kivinen.iki.fi> Subject: Re: [Mobike] Mobile IP and Mobike Date: Thu, 11 Nov 2004 14:07:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , Charlie Kaufman X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Tero, > The mobike is targeted to the environments where the other end of the > connection is stable, i.e the VPN sgw or similar. The mobile ip both > ends can move, and the connection is not necessarely from the mobile > node to the sgw to the www-server (for example), but can also go > directly between mobile node and www-server. > I'm not sure I understand. In both cases, presumably the mobile node is communicating with a correspondent that is not the intermediate node. In both cases, the intermediate node typically isn't moving. The mobile node can be moving, but I believe what you are saying is that in the Mobike case, the correspondent can't be move, is that it? Wrt. direct routing between the mobile node and the correspondent, yes, that's a difference. > The mobile IP can benefit from the MOBIKE when handing the mobile node > and home agent connection. I.e. instead of recreating the SAs from > scratch every time mobile node moves, or doing all kind of wierd IPsec > processing to make simulate same stuff inside the ipsec stack, mobile > IP can leave the MOBIKE to take care of the IPsec connection between > the mobile node and home agent, and it only needs to concenctrate to > the route optimization etc to make the connection which are not going > to the home agent or home network more efficient. Actually, I'm not sure I agree. Mobile IP sends a Binding Update through an ESP Auth tunnel, and could optionally also use encryption on the tunnel. If both are used, and if in addition the Mobile Node uses an ESP Auth + Enc tunnel for data traffic, it seems to me that it would be exactly the same as for Mobike. Therefore, the Mobike "binding update" message to the home agent would conflict with the Mobile IP message. jak _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Nov 11 20:09:13 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20814 for ; Thu, 11 Nov 2004 20:09:12 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id B9941FB27C; Fri, 12 Nov 2004 01:09:10 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CF116FB255; Fri, 12 Nov 2004 01:09:06 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DD4CAFB262; Fri, 12 Nov 2004 01:09:04 +0000 (UTC) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 82010FB24A for ; Fri, 12 Nov 2004 01:09:03 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iAC18s2B011941 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 12 Nov 2004 03:08:54 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iAC18qPg011938; Fri, 12 Nov 2004 03:08:52 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16788.3364.397934.783149@fireball.kivinen.iki.fi> Date: Fri, 12 Nov 2004 03:08:52 +0200 From: Tero Kivinen To: "James Kempf" Subject: Re: [Mobike] Mobile IP and Mobike In-Reply-To: <06d701c4c83a$e1f7ac60$646015ac@dcml.docomolabsusa.com> References: <06a301c4c82d$97439a10$646015ac@dcml.docomolabsusa.com> <16787.56287.385658.935976@fireball.kivinen.iki.fi> <06d701c4c83a$e1f7ac60$646015ac@dcml.docomolabsusa.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 10 min X-Total-Time: 10 min Cc: MOBIKE Mailing List , Charlie Kaufman X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit James Kempf writes: > > The mobike is targeted to the environments where the other end of the > > connection is stable, i.e the VPN sgw or similar. The mobile ip both > > ends can move, and the connection is not necessarely from the mobile > > node to the sgw to the www-server (for example), but can also go > > directly between mobile node and www-server. > > > > I'm not sure I understand. In both cases, presumably the mobile node is > communicating with a correspondent that is not the intermediate node. In > both cases, the intermediate node typically isn't moving. The mobile node > can be moving, but I believe what you are saying is that in the Mobike case, > the correspondent can't be move, is that it? In the mobike case the other end of the security association (i.e. other end of MOBIKE protocol) will typically be corporate SGW. The SGW will not move (ok, it might have multiple interfaces for high-availibility use, but it will not be mobile). All the traffic from using the MOBIKE will go through that tunnel from mobile host to the SGW, and normally then continues from the SGW to the the host INSIDE the coporate network. If mobile node wants to connect the some other host in the internet (like www.cnn.com) it will either not use MOBIKE and connect to that directly using his normal address (==i.e. the connection will be broken if the IP address changes unless mobile ip is used), or it will connect to the corporate firewall through the SGW and make all packets be routed in both directions through the tunnel. > Actually, I'm not sure I agree. Mobile IP sends a Binding Update through an > ESP Auth tunnel, and could optionally also use encryption on the tunnel. If > both are used, and if in addition the Mobile Node uses an ESP Auth + Enc > tunnel for data traffic, it seems to me that it would be exactly the same as > for Mobike. Therefore, the Mobike "binding update" message to the home agent > would conflict with the Mobile IP message. Before the mobile IP can send his AH/ESP protected binding update packet to the home agent, he needs to make have that IPsec SA up and working. If he tries to send them AFTER the previous IP address has disappeared (i.e tries to use the new IP address), then the SA does not work properly because reply packets go still back to the old address (IPsec SA is tied to the previous IP address). So what mobile IP needs to do it needs to recreate the IPsec and IKE SAs. MOBIKE can make that recreation unnecessary, because it allows mobile IP to inform MOBIKE that IP address change has occurred (or the generic mobility policy module in the device informs both MOBIKE and Mobile IP about this change) and the MOBIKE can fix the tunnel endpoint addresses of the IPsec and IKE SAs so mobile IP can use the IPsec SA tunnel to send his binding update packet to the home agent. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Nov 11 22:01:22 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00810 for ; Thu, 11 Nov 2004 22:01:21 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 3EB63FB27F; Fri, 12 Nov 2004 03:01:21 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A7CCBFB255; Fri, 12 Nov 2004 03:01:14 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D5110FB262; Fri, 12 Nov 2004 03:01:12 +0000 (UTC) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by machshav.com (Postfix) with ESMTP id EF568FB24A for ; Fri, 12 Nov 2004 03:01:11 +0000 (UTC) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iAC2Wqw31723; Thu, 11 Nov 2004 18:32:52 -0800 X-mProtect: <200411120232> Nokia Silicon Valley Messaging Protection Received: from danira-pool05148.americas.nokia.com (10.241.51.48, claiming to be "[10.241.51.48]") by darkstar.iprg.nokia.com smtpdcPRm6z; Thu, 11 Nov 2004 18:32:48 PST Message-ID: <41942748.9000902@iprg.nokia.com> Date: Thu, 11 Nov 2004 19:00:24 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Mobike] Mobile IP and Mobike References: <06a301c4c82d$97439a10$646015ac@dcml.docomolabsusa.com> <16787.56287.385658.935976@fireball.kivinen.iki.fi> <06d701c4c83a$e1f7ac60$646015ac@dcml.docomolabsusa.com> <16788.3364.397934.783149@fireball.kivinen.iki.fi> In-Reply-To: <16788.3364.397934.783149@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: James Kempf , MOBIKE Mailing List , Charlie Kaufman X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Tero Kivinen wrote: > James Kempf writes: > >>>The mobike is targeted to the environments where the other end of the >>>connection is stable, i.e the VPN sgw or similar. The mobile ip both >>>ends can move, and the connection is not necessarely from the mobile >>>node to the sgw to the www-server (for example), but can also go >>>directly between mobile node and www-server. >>> >> >>I'm not sure I understand. In both cases, presumably the mobile node is >>communicating with a correspondent that is not the intermediate node. In >>both cases, the intermediate node typically isn't moving. The mobile node >>can be moving, but I believe what you are saying is that in the Mobike case, >>the correspondent can't be move, is that it? > > > In the mobike case the other end of the security association (i.e. > other end of MOBIKE protocol) will typically be corporate SGW. The SGW > will not move (ok, it might have multiple interfaces for > high-availibility use, but it will not be mobile). All the traffic > from using the MOBIKE will go through that tunnel from mobile host to > the SGW, and normally then continues from the SGW to the the host > INSIDE the coporate network. If mobile node wants to connect the some > other host in the internet (like www.cnn.com) it will either not use > MOBIKE and connect to that directly using his normal address (==i.e. > the connection will be broken if the IP address changes unless mobile > ip is used), or it will connect to the corporate firewall through the > SGW and make all packets be routed in both directions through the > tunnel. > > >>Actually, I'm not sure I agree. Mobile IP sends a Binding Update through an >>ESP Auth tunnel, and could optionally also use encryption on the tunnel. If >>both are used, and if in addition the Mobile Node uses an ESP Auth + Enc >>tunnel for data traffic, it seems to me that it would be exactly the same as >>for Mobike. Therefore, the Mobike "binding update" message to the home agent >>would conflict with the Mobile IP message. > > > Before the mobile IP can send his AH/ESP protected binding update > packet to the home agent, he needs to make have that IPsec SA up and > working. If he tries to send them AFTER the previous IP address has > disappeared (i.e tries to use the new IP address), then the SA does > not work properly because reply packets go still back to the old > address (IPsec SA is tied to the previous IP address). IPsec SA is tied to the Home Address. IKE SA is tied to the CoA. so a Binding Update can be sent right away. Vijay > > So what mobile IP needs to do it needs to recreate the IPsec and IKE > SAs. MOBIKE can make that recreation unnecessary, because it allows > mobile IP to inform MOBIKE that IP address change has occurred (or the > generic mobility policy module in the device informs both MOBIKE and > Mobile IP about this change) and the MOBIKE can fix the tunnel > endpoint addresses of the IPsec and IKE SAs so mobile IP can use the > IPsec SA tunnel to send his binding update packet to the home agent. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Nov 12 01:07:58 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16396 for ; Fri, 12 Nov 2004 01:07:57 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 24EB5FB27A; Fri, 12 Nov 2004 06:07:56 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0BCC5FB255; Fri, 12 Nov 2004 06:07:55 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 165A5FB262; Fri, 12 Nov 2004 06:07:53 +0000 (UTC) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 07E99FB246 for ; Fri, 12 Nov 2004 06:07:52 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iAC67ZGL015295 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 12 Nov 2004 08:07:36 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iAC67Y5a015291; Fri, 12 Nov 2004 08:07:34 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16788.21286.178848.339835@fireball.kivinen.iki.fi> Date: Fri, 12 Nov 2004 08:07:34 +0200 From: Tero Kivinen To: Vijay Devarapalli Subject: Re: [Mobike] Mobile IP and Mobike In-Reply-To: <41942748.9000902@iprg.nokia.com> References: <06a301c4c82d$97439a10$646015ac@dcml.docomolabsusa.com> <16787.56287.385658.935976@fireball.kivinen.iki.fi> <06d701c4c83a$e1f7ac60$646015ac@dcml.docomolabsusa.com> <16788.3364.397934.783149@fireball.kivinen.iki.fi> <41942748.9000902@iprg.nokia.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: James Kempf , MOBIKE Mailing List , Charlie Kaufman X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Vijay Devarapalli writes: > IPsec SA is tied to the Home Address. IKE SA is tied to the CoA. > so a Binding Update can be sent right away. That is not following the IKEv1/IKEv2 RFCs nor the architecture draft. There tunnel mode SAs are tied to the IP addresses which are used to when it is negotiated in the IKE. It is not very clean solution that Mobile IP goes and modifies the internal databases of the IPsec module (SAD). If you want to use standard IPsec then you need to renegotiate the IPsec and IKE SAs before sending the binding update. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Nov 12 07:38:05 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25433 for ; Fri, 12 Nov 2004 07:38:04 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 2DA1BFB27C; Fri, 12 Nov 2004 12:38:04 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 999CAFB262; Fri, 12 Nov 2004 12:38:02 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3CF33FB266; Fri, 12 Nov 2004 12:38:01 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 96FE4FB23E for ; Fri, 12 Nov 2004 12:38:00 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 1669189890 for ; Fri, 12 Nov 2004 14:37:57 +0200 (EET) Message-ID: <4194AE39.1030103@piuha.net> Date: Fri, 12 Nov 2004 14:36:09 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Subject: Staying focused (Was: Re: [Mobike] Mobile IP and Mobike) References: <06a301c4c82d$97439a10$646015ac@dcml.docomolabsusa.com> <16787.56287.385658.935976@fireball.kivinen.iki.fi> <06d701c4c83a$e1f7ac60$646015ac@dcml.docomolabsusa.com> <16788.3364.397934.783149@fireball.kivinen.iki.fi> <41942748.9000902@iprg.nokia.com> <16788.21286.178848.339835@fireball.kivinen.iki.fi> In-Reply-To: <16788.21286.178848.339835@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Folks, Paul and I feel that this thread is not necessarily contributing much to take our design work forward. The primary goal and usage scenario for MOBIKE is outlined in the charter and it deals with a VPN user that moves around; lets focus on completing our design to reach that goal. (Mobile IPv6 RFCs rely on IPsec and IKE for a particular part of their functionality, and there are also drafts about IKEv2 usage. There are different ways that those designs might evolve -- relying either more or less on IPsec protocols and hence MOBIKE. However, our feeling is that the discussion of that would be more appropriate on the MIP6 list than in here, at least until we are at a stage where our base protocol is done and we can start to think about "MOBIKE for SCTP" or "MOBIKE for MIPv6" and other similar issues. Even then, this would have to be done in close co-operation with what people in the "application" protocol WGs want.) --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Nov 12 09:01:17 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03395 for ; Fri, 12 Nov 2004 09:01:17 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 21133FB27C; Fri, 12 Nov 2004 14:01:18 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 21BDAFB266; Fri, 12 Nov 2004 14:01:15 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 97F71FB279; Fri, 12 Nov 2004 14:01:13 +0000 (UTC) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id A7455FB23E for ; Fri, 12 Nov 2004 14:01:12 +0000 (UTC) Message-ID: <071601c4c8c0$319ec020$646015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Tero Kivinen" References: <06a301c4c82d$97439a10$646015ac@dcml.docomolabsusa.com><16787.56287.385658.935976@fireball.kivinen.iki.fi><06d701c4c83a$e1f7ac60$646015ac@dcml.docomolabsusa.com> <16788.3364.397934.783149@fireball.kivinen.iki.fi> Subject: Re: [Mobike] Mobile IP and Mobike Date: Fri, 12 Nov 2004 06:01:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , Charlie Kaufman X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Tero, > In the mobike case the other end of the security association (i.e. > other end of MOBIKE protocol) will typically be corporate SGW. The SGW > will not move (ok, it might have multiple interfaces for > high-availibility use, but it will not be mobile). All the traffic > from using the MOBIKE will go through that tunnel from mobile host to > the SGW, and normally then continues from the SGW to the the host > INSIDE the coporate network. If mobile node wants to connect the some > other host in the internet (like www.cnn.com) it will either not use > MOBIKE and connect to that directly using his normal address (==i.e. > the connection will be broken if the IP address changes unless mobile > ip is used), or it will connect to the corporate firewall through the > SGW and make all packets be routed in both directions through the > tunnel. > This is certainly not how I use my VPN today and I don't think it would be a good idea in any event to design MOBIKE so that it works this way. Typically, people use a VPN into a corporate network because they also want to derive the benefits of firewall support for external access, not simply to access hosts within the corporate LAN. Most client side IPSec VPN software grabs the entire network interface and IP stack so that external connections are not possible except through the address in the corporate network. This is a security measure, otherwise direct attacks on the host from the Internet through the local address would be possible. One can debate the wisdom of this approach, but the fact of the matter is that many corporate VPN users do use it, and most WLAN public access hotspots (which provide absolutely no security) assume that something like this scenerio is what customers will use (or SSL VPNs, which are another story). >From a technical standpoint, I also don't see why the host would need to use its local address when contacting hosts outside the corporate network. The local address is changing, but the address in the corporate network presumably isn't, or, at least, I can't see any reason why it should. So it should be possible to keep the address in the VPN gateway network constant, unless I'm missing something, and continue to tunnel through the VPN gateway, with perhaps a few lost packets while the address change signaling and processing is underway. It is true that, unlike Mobile IPv6, the host can't perform route optimization so all traffic is forced to traverse the triangle route through the VPN gateway. But Mobile IPv4 doesn't have route optimization either, so the effect for MOBIKE would be to provide approximately the same functionality as Mobile IPv4 and the Mobile IPv6 home agent to mobile node connection, except in a form that provides a more incremental upgrade path for existing VPN users, and, as compared with Mobile IPv4, with authentication that is oriented more toward corporate users and not public access networks and with support for encryption, which Mobile IPv4 does not provide at all. > Before the mobile IP can send his AH/ESP protected binding update > packet to the home agent, he needs to make have that IPsec SA up and > working. If he tries to send them AFTER the previous IP address has > disappeared (i.e tries to use the new IP address), then the SA does > not work properly because reply packets go still back to the old > address (IPsec SA is tied to the previous IP address). > > So what mobile IP needs to do it needs to recreate the IPsec and IKE > SAs. MOBIKE can make that recreation unnecessary, because it allows > mobile IP to inform MOBIKE that IP address change has occurred (or the > generic mobility policy module in the device informs both MOBIKE and > Mobile IP about this change) and the MOBIKE can fix the tunnel > endpoint addresses of the IPsec and IKE SAs so mobile IP can use the > IPsec SA tunnel to send his binding update packet to the home agent. Vijay explained this so I won't repeat it. But I'd like to point out that this is only true for MIPv6. Security for MIPv4 is much less well defined. jak _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Nov 12 09:03:55 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03610 for ; Fri, 12 Nov 2004 09:03:53 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 939CFFB285; Fri, 12 Nov 2004 14:03:54 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E63D1FB27A; Fri, 12 Nov 2004 14:03:49 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7F2DEFB27C; Fri, 12 Nov 2004 14:03:48 +0000 (UTC) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id C67A4FB266 for ; Fri, 12 Nov 2004 14:03:47 +0000 (UTC) Message-ID: <072d01c4c8c0$8df7a670$646015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Tero Kivinen" , "Vijay Devarapalli" References: <06a301c4c82d$97439a10$646015ac@dcml.docomolabsusa.com><16787.56287.385658.935976@fireball.kivinen.iki.fi><06d701c4c83a$e1f7ac60$646015ac@dcml.docomolabsusa.com><16788.3364.397934.783149@fireball.kivinen.iki.fi><41942748.9000902@iprg.nokia.com> <16788.21286.178848.339835@fireball.kivinen.iki.fi> Subject: Re: [Mobike] Mobile IP and Mobike Date: Fri, 12 Nov 2004 06:04:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , Charlie Kaufman X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Tero, > That is not following the IKEv1/IKEv2 RFCs nor the architecture draft. > There tunnel mode SAs are tied to the IP addresses which are used to > when it is negotiated in the IKE. It is not very clean solution that > Mobile IP goes and modifies the internal databases of the IPsec module > (SAD). If you want to use standard IPsec then you need to renegotiate > the IPsec and IKE SAs before sending the binding update. Right, this is exactly the point I was trying to get to. But it would lengthen the binding update time. jak _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Nov 12 09:05:26 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03809 for ; Fri, 12 Nov 2004 09:05:24 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 3EEDBFB286; Fri, 12 Nov 2004 14:05:25 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DC26CFB27A; Fri, 12 Nov 2004 14:05:21 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C7CFAFB27C; Fri, 12 Nov 2004 14:05:20 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id BDA5DFB266 for ; Fri, 12 Nov 2004 14:05:19 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iACE5AT18524; Fri, 12 Nov 2004 15:05:10 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iACE5ASj000582; Fri, 12 Nov 2004 15:05:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411121405.iACE5ASj000582@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen Subject: Re: [Mobike] Mobile IP and Mobike In-reply-to: Your message of Fri, 12 Nov 2004 03:08:52 +0200. <16788.3364.397934.783149@fireball.kivinen.iki.fi> Date: Fri, 12 Nov 2004 15:05:10 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: James Kempf , MOBIKE Mailing List , Charlie Kaufman X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: So what mobile IP needs to do it needs to recreate the IPsec and IKE SAs. => this is off topics but Tero, you are plainly wrong here. Mobile IPv6 takes care of the IPsec SAs and with the K bit set to one of the IKE SA too. And this is supported by some implementations (i.e., I can prove it :-). Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Nov 12 10:01:06 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08824 for ; Fri, 12 Nov 2004 10:01:05 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id E0063FB286; Fri, 12 Nov 2004 15:01:05 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 186C3FB27C; Fri, 12 Nov 2004 15:01:03 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 498FAFB27D; Fri, 12 Nov 2004 15:01:01 +0000 (UTC) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 00652FB27A for ; Fri, 12 Nov 2004 15:00:59 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iACF0j1c020271 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 12 Nov 2004 17:00:50 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iACF0gnq020268; Fri, 12 Nov 2004 17:00:42 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16788.53274.857380.263752@fireball.kivinen.iki.fi> Date: Fri, 12 Nov 2004 17:00:42 +0200 From: Tero Kivinen To: "James Kempf" Subject: Re: [Mobike] Mobile IP and Mobike In-Reply-To: <071601c4c8c0$319ec020$646015ac@dcml.docomolabsusa.com> References: <06a301c4c82d$97439a10$646015ac@dcml.docomolabsusa.com> <16787.56287.385658.935976@fireball.kivinen.iki.fi> <06d701c4c83a$e1f7ac60$646015ac@dcml.docomolabsusa.com> <16788.3364.397934.783149@fireball.kivinen.iki.fi> <071601c4c8c0$319ec020$646015ac@dcml.docomolabsusa.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 6 min X-Total-Time: 5 min Cc: MOBIKE Mailing List , Charlie Kaufman X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit James Kempf writes: > This is certainly not how I use my VPN today and I don't think it would be a > good idea in any event to design MOBIKE so that it works this way. > Typically, people use a VPN into a corporate network because they also want > to derive the benefits of firewall support for external access, not simply > to access hosts within the corporate LAN. Most client side IPSec VPN > software grabs the entire network interface and IP stack so that external > connections are not possible except through the address in the corporate > network. This is a security measure, otherwise direct attacks on the host > from the Internet through the local address would be possible. One can > debate the wisdom of this approach, but the fact of the matter is that many > corporate VPN users do use it, and most WLAN public access hotspots (which > provide absolutely no security) assume that something like this scenerio is > what customers will use (or SSL VPNs, which are another story). Yes, that is the main scenario of the MOBIKE. Note, that there is no need for moble IP in that case, which is the reason why I didn't present this scenario in my last time. The tunnel mode SA from the SGW to the VPN client, with the IP-address given from the SGW, and with the MOBIKE updating the tunnel endpoint addresses as the VPN client moves, is everything which is needed for mobility for that kind of simple cases. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Nov 12 10:39:25 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13294 for ; Fri, 12 Nov 2004 10:39:23 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 35171FB28B; Fri, 12 Nov 2004 15:39:24 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D2E11FB280; Fri, 12 Nov 2004 15:39:19 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 40904FB282; Fri, 12 Nov 2004 15:39:18 +0000 (UTC) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by machshav.com (Postfix) with ESMTP id ACB84FB27C for ; Fri, 12 Nov 2004 15:39:17 +0000 (UTC) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iACFBHL29689; Fri, 12 Nov 2004 07:11:17 -0800 X-mProtect: <200411121511> Nokia Silicon Valley Messaging Protection Received: from danira-pool05148.americas.nokia.com (10.241.51.48, claiming to be "[10.241.51.48]") by darkstar.iprg.nokia.com smtpd9h4DaL; Fri, 12 Nov 2004 07:11:15 PST Message-ID: <4194D90E.1000909@iprg.nokia.com> Date: Fri, 12 Nov 2004 07:38:54 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Mobike] Mobile IP and Mobike References: <06a301c4c82d$97439a10$646015ac@dcml.docomolabsusa.com> <16787.56287.385658.935976@fireball.kivinen.iki.fi> <06d701c4c83a$e1f7ac60$646015ac@dcml.docomolabsusa.com> <16788.3364.397934.783149@fireball.kivinen.iki.fi> <41942748.9000902@iprg.nokia In-Reply-To: <16788.21286.178848.339835@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: James Kempf , MOBIKE Mailing List , Charlie Kaufman X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Tero Kivinen wrote: > Vijay Devarapalli writes: > >>IPsec SA is tied to the Home Address. IKE SA is tied to the CoA. >>so a Binding Update can be sent right away. > > > That is not following the IKEv1/IKEv2 RFCs nor the architecture draft. > There tunnel mode SAs are tied to the IP addresses which are used to > when it is negotiated in the IKE. It is not very clean solution that > Mobile IP goes and modifies the internal databases of the IPsec module > (SAD). If you want to use standard IPsec then you need to renegotiate > the IPsec and IKE SAs before sending the binding update. you gotta be kidding me. :) the selectors are applied to the inner IP header, not the outer one. and the selectors are what are negotiated. we got the Mobile IPv6 + IPsec documents reviewed by numerous folks from the security area. we have interoperable implementations (infact many implementations). so, have to strongly disagree with you. anyway, this will be the last email on this thread from me. Vijay _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Nov 12 10:44:37 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13672 for ; Fri, 12 Nov 2004 10:44:35 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 00CECFB28E; Fri, 12 Nov 2004 15:44:36 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 14B91FB280; Fri, 12 Nov 2004 15:44:33 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4394DFB282; Fri, 12 Nov 2004 15:44:31 +0000 (UTC) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by machshav.com (Postfix) with ESMTP id C2658FB27C for ; Fri, 12 Nov 2004 15:44:30 +0000 (UTC) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iACFGFA04458; Fri, 12 Nov 2004 07:16:15 -0800 X-mProtect: <200411121516> Nokia Silicon Valley Messaging Protection Received: from danira-pool05148.americas.nokia.com (10.241.51.48, claiming to be "[10.241.51.48]") by darkstar.iprg.nokia.com smtpdk7IEf3; Fri, 12 Nov 2004 07:16:13 PST Message-ID: <4194DA38.4010703@iprg.nokia.com> Date: Fri, 12 Nov 2004 07:43:52 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Mobike] Mobile IP and Mobike References: <06a301c4c82d$97439a10$646015ac@dcml.docomolabsusa.com> <16787.56287.385658.935976@fireball.kivinen.iki.fi> <06d701c4c83a$e1f7ac60$646015ac@dcml.docomolabsusa.com> <16788.3364.397934.783149@fireball.kivinen.iki.fi> <071601c4c8c0$319ec020$64601 In-Reply-To: <16788.53274.857380.263752@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: James Kempf , MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Tero Kivinen wrote: > The tunnel mode SA from the SGW to the VPN client, with the IP-address > given from the SGW, and with the MOBIKE updating the tunnel endpoint > addresses as the VPN client moves, is everything which is needed for > mobility for that kind of simple cases. not really. the sessions break if I switch to another VPN SGW or if I cross security boundaries and move into the trusted network. Vijay _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Nov 12 11:17:44 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16277 for ; Fri, 12 Nov 2004 11:17:44 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id DE5A6FB28B; Fri, 12 Nov 2004 16:17:45 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DA97DFB282; Fri, 12 Nov 2004 16:17:43 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CF8D3FB285; Fri, 12 Nov 2004 16:17:42 +0000 (UTC) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [205.150.200.161]) by machshav.com (Postfix) with ESMTP id B17C9FB280 for ; Fri, 12 Nov 2004 16:17:41 +0000 (UTC) Received: from road.marajade.sandelman.ca ([130.129.133.170]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id iACGH7u25751 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 12 Nov 2004 11:17:13 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by road.marajade.sandelman.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id iACGH76P003614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Nov 2004 11:17:07 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id iACGH4ux003610; Fri, 12 Nov 2004 11:17:04 -0500 To: "James Kempf" Subject: Re: [Mobike] Mobile IP and Mobike In-Reply-To: Message from "James Kempf" of "Fri, 12 Nov 2004 06:01:59 PST." <071601c4c8c0$319ec020$646015ac@dcml.docomolabsusa.com> References: <06a301c4c82d$97439a10$646015ac@dcml.docomolabsusa.com><16787.56287.385658.935976@fireball.kivinen.iki.fi><06d701c4c83a$e1f7ac60$646015ac@dcml.docomolabsusa.com> <16788.3364.397934.783149@fireball.kivinen.iki.fi> <071601c4c8c0$319ec020$646015ac@dcml.docomolabsusa.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 12 Nov 2004 11:17:04 -0500 Message-ID: <3609.1100276224@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Cc: MOBIKE Mailing List , Charlie Kaufman , Tero Kivinen X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com -----BEGIN PGP SIGNED MESSAGE----- >>>>> "James" == James Kempf writes: James> think it would be a good idea in any event to design MOBIKE James> so that it works this way. Typically, people use a VPN into James> a corporate network because they also want to derive the James> benefits of firewall support for external access, not simply James> to access hosts within the corporate LAN. Most client side "Typical" for Windows clients, true. Virus+remove-attack risk exceeds any benefit from route optomization. Untypical for everyone else, including PDAs and other things. James> From a technical standpoint, I also don't see why the host James> would need to use its local address when contacting hosts James> outside the corporate network. The local address is changing, James> but the address in the corporate network presumably isn't, James> or, at least, I can't see any reason why it should. So it I do this all the time, as do my colleagues. We use the local address on the inside of peer-to-peer tunnels for things like SIP. All of our machines have globally unique public IPs for use inside their tunnels, and that is how we configure customer machines. This is because we have a more sophisticated IPsec policy ability. Please do not assume that the limits of current IP-Telco RemoteAccess systems define what future usage is. That's why we spent the 1980s and early 1990s working *around* the Telcos. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQZTh/oqHRg3pndX9AQEc+QQAhkEAgGnSt7xmXYX2724zdTGOWPorgv8L o+mMk9krXzMtG3SnnqSNJ6wKav3e5hVSpemwirP6yvwlC2ocUqi8eGbK/AumDH85 e1ikzkyTlIMfiNzsexpa35di9zXkEwKhGZ1kC+HNlqwuY9iweKZLRfTxNsacocPI e1YsjF+RMoc= =hvJf -----END PGP SIGNATURE----- _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Nov 12 22:32:53 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25548 for ; Fri, 12 Nov 2004 22:32:52 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id EB701FB28B; Sat, 13 Nov 2004 03:32:52 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EC1E1FB286; Sat, 13 Nov 2004 03:32:48 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DA9CBFB28B; Sat, 13 Nov 2004 03:32:46 +0000 (UTC) Received: from above.proper.com (above.proper.com [208.184.76.39]) by machshav.com (Postfix) with ESMTP id 6F9DCFB280 for ; Sat, 13 Nov 2004 03:32:46 +0000 (UTC) Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAD3WcT4069884 for ; Fri, 12 Nov 2004 19:32:39 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200411121405.iACE5ASj000582@givry.rennes.enst-bretagne.fr> References: <200411121405.iACE5ASj000582@givry.rennes.enst-bretagne.fr> Date: Fri, 12 Nov 2004 19:32:40 -0800 To: mobike@machshav.com From: Paul Hoffman / VPNC Subject: Re: [Mobike] Mobile IP and Mobike Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com At 3:05 PM +0100 11/12/04, Francis Dupont wrote: >=> this is off topics but ... Yes it certainly is, so please drop it and all related "but this isn't Moble IP" threads. One co-chair chimed in this morning, and now the other one will. We have a charter (see if you have forgotten it). It is a charter that we agreed to *long ago*. Attempts to discuss things that are clearly off-charter, particularly attempts to discuss things that are known to be in the charter of a different WG, are unproductive. If you want to change the charter, start a new thread with that in the subject. I would prefer that you didn't because we have made good progress under the current charter, but you can try. Once. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 15 04:58:04 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12230 for ; Mon, 15 Nov 2004 04:58:04 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id DF064FB27F; Mon, 15 Nov 2004 09:58:04 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DCEEEFB26F; Mon, 15 Nov 2004 09:58:01 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EF693FB277; Mon, 15 Nov 2004 09:57:59 +0000 (UTC) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 59BB4FB24A for ; Mon, 15 Nov 2004 09:57:58 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iAF9vgEw027921 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 15 Nov 2004 11:57:42 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iAF9vcef027918; Mon, 15 Nov 2004 11:57:38 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16792.32146.591047.895827@fireball.kivinen.iki.fi> Date: Mon, 15 Nov 2004 11:57:38 +0200 From: Tero Kivinen To: Vijay Devarapalli Subject: Re: [Mobike] Mobile IP and Mobike In-Reply-To: <4194D90E.1000909@iprg.nokia.com> References: <06a301c4c82d$97439a10$646015ac@dcml.docomolabsusa.com> <16787.56287.385658.935976@fireball.kivinen.iki.fi> <06d701c4c83a$e1f7ac60$646015ac@dcml.docomolabsusa.com> <16788.3364.397934.783149@fireball.kivinen.iki.fi> <41942748.9000902@iprg.nokia <4194D90E.1000909@iprg.nokia.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 9 min X-Total-Time: 8 min Cc: James Kempf , MOBIKE Mailing List , Charlie Kaufman X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Vijay Devarapalli writes: > > That is not following the IKEv1/IKEv2 RFCs nor the architecture draft. > > There tunnel mode SAs are tied to the IP addresses which are used to > > when it is negotiated in the IKE. It is not very clean solution that > > Mobile IP goes and modifies the internal databases of the IPsec module > > (SAD). If you want to use standard IPsec then you need to renegotiate > > the IPsec and IKE SAs before sending the binding update. > > > you gotta be kidding me. :) the selectors are applied to > the inner IP header, not the outer one. and the selectors are > what are negotiated. Yes, but tunnel endpoint addresses are not selectors, and they are not negotiated at all, they are taken from the IKE SA endpoint addresses. IKE SA endpoint addresses are also not negotiated, they are taken from the IP-addresses of the IKE packets. If no NAT traversal is used, then the IP-addresses will be the ones used in the initial exchange. If NAT traversal (NAT-T) is used then they SHOULD be from last authenticated packet from the other end (Note, that the IP-addresses are not negotiated). This means that the when the SGW wants to send packets to the other end it will use the exactly same OUTER IP addresses all the time, and there is no standard method in the IPsec to change that anyway. The MOBIKE is trying to define a method to do that. > we got the Mobile IPv6 + IPsec documents reviewed by numerous > folks from the security area. At least I did comment to the drafts that they require the combined mobile IP and IPsec stacks, as the Mobile IP needs to modify the data structures of the IPsec, and that kind of methods are not normally implemented in the IPsec. > we have interoperable implementations (infact many > implementations). so, have to strongly disagree with you. Of course you can combine Mobile IP and IPsec and make them to work together, there is no question about that. It just means that you cannot take IPsec from vendor A and Mobile IP from vendor B and assume that they can work together at all. With MOBIKE changes to the IPsec, you should be able to take IPsec from vendor A, MOBIKE from vendor C and Mobile IP from vendor B, and assume that they will work together (as long as IPsec and MOBIKE support the PFKEY extensions defined by the MOBIKE later). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 15 05:00:25 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12322 for ; Mon, 15 Nov 2004 05:00:23 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 4BFECFB281; Mon, 15 Nov 2004 10:00:25 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 57869FB277; Mon, 15 Nov 2004 10:00:23 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AFE04FB27C; Mon, 15 Nov 2004 10:00:21 +0000 (UTC) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id ADA50FB24A for ; Mon, 15 Nov 2004 10:00:20 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iAFA0CwU027976 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 15 Nov 2004 12:00:12 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iAFA0CnD027973; Mon, 15 Nov 2004 12:00:12 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16792.32300.199956.295951@fireball.kivinen.iki.fi> Date: Mon, 15 Nov 2004 12:00:12 +0200 From: Tero Kivinen To: Vijay Devarapalli Subject: Re: [Mobike] Mobile IP and Mobike In-Reply-To: <4194DA38.4010703@iprg.nokia.com> References: <06a301c4c82d$97439a10$646015ac@dcml.docomolabsusa.com> <16787.56287.385658.935976@fireball.kivinen.iki.fi> <06d701c4c83a$e1f7ac60$646015ac@dcml.docomolabsusa.com> <16788.3364.397934.783149@fireball.kivinen.iki.fi> <071601c4c8c0$319ec020$64601 <4194DA38.4010703@iprg.nokia.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: James Kempf , MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Vijay Devarapalli writes: > > The tunnel mode SA from the SGW to the VPN client, with the IP-address > > given from the SGW, and with the MOBIKE updating the tunnel endpoint > > addresses as the VPN client moves, is everything which is needed for > > mobility for that kind of simple cases. > > not really. the sessions break if I switch to another VPN SGW or if > I cross security boundaries and move into the trusted network. And the point being? Of course session will break if you want to break them. If you keep using the same VPN SGW all the time the sessions will not break. You can even move inside the corporate network, if you simply still keep using IPsec tunnel and send all data through the VPN SGW still sessions will not break. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 23 11:48:17 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29125 for ; Tue, 23 Nov 2004 11:48:15 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 931B9FB28B; Tue, 23 Nov 2004 16:48:17 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1654BFB286; Tue, 23 Nov 2004 16:48:16 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A5C71FB289; Tue, 23 Nov 2004 16:48:14 +0000 (UTC) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by machshav.com (Postfix) with ESMTP id B51C9FB280 for ; Tue, 23 Nov 2004 16:48:13 +0000 (UTC) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANGm0S01557 for ; Tue, 23 Nov 2004 18:48:11 +0200 (EET) X-Scanned: Tue, 23 Nov 2004 18:41:05 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iANGf5EC031390 for ; Tue, 23 Nov 2004 18:41:05 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00tF18EZ; Tue, 23 Nov 2004 18:41:04 EET 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 iANGf4a17447 for ; Tue, 23 Nov 2004 18:41:04 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 23 Nov 2004 18:41:04 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 23 Nov 2004 18:41:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Nov 2004 18:41:03 +0200 Message-ID: <125EA890549C8641A72F3809CB80DCCD1783D4@esebe056.ntc.nokia.com> Thread-Topic: IETF61 draft minutes Thread-Index: AcTRezikgCkvbLKKS7WI+ZaOp4L44g== From: To: X-OriginalArrivalTime: 23 Nov 2004 16:41:03.0531 (UTC) FILETIME=[38ADBFB0:01C4D17B] Subject: [Mobike] IETF61 draft minutes X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Hi, The draft minutes from MOBIKE WG meeting at IETF61, as well=20 as the presentations, are now available from this URL: http://www.vpnc.org/ietf-mobike/ If you have any additions or corrections to the minutes, please send them as soon as possible (I'll submit the minutes to the secretariat next week). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 29 09:07:13 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22543 for ; Mon, 29 Nov 2004 09:07:12 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 69D00FB277; Mon, 29 Nov 2004 14:07:12 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5BAAAFB255; Mon, 29 Nov 2004 14:07:11 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3B389FB256; Mon, 29 Nov 2004 14:07:10 +0000 (UTC) Received: from p2.piuha.net (unknown [131.160.192.2]) by machshav.com (Postfix) with ESMTP id C4F64FB240 for ; Mon, 29 Nov 2004 14:07:08 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 5B19A89883; Mon, 29 Nov 2004 16:07:06 +0200 (EET) Message-ID: <41AB2C78.7010806@piuha.net> Date: Mon, 29 Nov 2004 16:04:40 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] issue 5: zero address set References: <200411092213.iA9MDJSj090394@givry.rennes.enst-bretagne.fr> In-Reply-To: <200411092213.iA9MDJSj090394@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Francis Dupont wrote: > I don't believe zero address set support is so useful but I have > a little concern about it: when a node has really no available > addresses I prefer its peer knows this in place of just > keep the last usable address and suggest it does still work... > Of course, this situation should be temporary. Right. I have a sense that we have difficulties to avoid temporary disconnects no matter what we do... often in wireless we don't get to choose whether we tell the other nodes that we are going to switch or go out of coverage; we get a problem and the protocols have to live with that. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 29 09:47:59 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26040 for ; Mon, 29 Nov 2004 09:47:58 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 3824DFB266; Mon, 29 Nov 2004 14:47:59 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0AC99FB240; Mon, 29 Nov 2004 14:47:57 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AE29BFB255; Mon, 29 Nov 2004 14:47:55 +0000 (UTC) Received: from p2.piuha.net (unknown [131.160.192.2]) by machshav.com (Postfix) with ESMTP id E7932FB23C for ; Mon, 29 Nov 2004 14:47:54 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 603E889881 for ; Mon, 29 Nov 2004 16:47:53 +0200 (EET) Message-ID: <41AB361A.5090607@piuha.net> Date: Mon, 29 Nov 2004 16:45:46 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Subject: Re: [Mobike] issue 12: interaction with other protocols doing RR References: <41850943.1090107@piuha.net> <00aa01c4c031$16b074d0$656115ac@dcml.docomolabsusa.com> <41913CDE.4030707@iprg.nokia.com> <4191FD2D.9080008@piuha.net> In-Reply-To: <4191FD2D.9080008@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit We had a proposal where the results of MOBIKE RR test could be used by other protocols, if deemed useful by the designers of these other protocols. There seems to be general support for this proposal. We also had a discussion about whether this would make sense in the Mobile IPv6 space; different opinions and technical alternatives were offered. That's OK, however, because we don't get to decide this part of the problem in WG. But we can now move forward with the original issue. Here's my proposalon what the design draft should say about the matter: Replace the current text MOBIKE might also want to export the information it has done the return routability checks to the other modules, like Mobile IP, so Mobile IP does not need to do return routability checks again, if it is satisfied with the level of checks done by the MOBIKE. with this new Section: X. Employing MOBIKE results in other protocols If MOBIKE has learned about new locations or verified the validity of an address through a return routability test, can this information be useful for other protocols? When considering the basic MOBIKE VPN scenario, the answer is no. Transport and application layer protocols running inside the VPN tunnel have no consideration about the outer addresses or their status. Similarly, IP layer tunnel termination at a gateway rather than a host endpoint limits the "other protocols" that could be informed -- all application protocols at the other side are running in a node that is unaware of IPsec, IKE, or MOBIKE. However, it is conceivable that future uses or extensions of MOBIKE make such information distribution useful. For instance, if transport mode MOBIKE and SCTP were made to work together, it would likely be useful for SCTP to learn about the new addresses at the same time as MOBIKE learns them. Similarly, various IP layer mechanisms might make use of the fact that a return routability test of a specific type has already been performed. However, in all of these cases careful consideration should be applied. This consideration should answer to questions such as whether other alternative sources exist for the information, whether dependencies are created between parts that prior to this had no depedencies, and what the impacts in terms of number of messages or latency are. Reference [draft-crocker-celp-00.txt] discussed the use of common locator information pools in IPv6 multihoming context; it assumed that both transport and IP layer solutions would be used for providing multihoming, and that it would be beneficial for different protocols to coordinate their results in some manner, for instance by sharing experienced throughput information for address pairs. This may apply to MOBIKE as well, assuming it co-exists with non-IPsec protocols that are faced with the same multiaddressing choices. Nevertheless, all of this is outside the scope of current MOBIKE base protocol design and will be addressed in future work. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 29 10:14:05 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29188 for ; Mon, 29 Nov 2004 10:14:04 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 58E40FB266; Mon, 29 Nov 2004 15:14:04 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6F099FB240; Mon, 29 Nov 2004 15:14:02 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 22D03FB255; Mon, 29 Nov 2004 15:14:00 +0000 (UTC) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by machshav.com (Postfix) with ESMTP id 91440FB23E for ; Mon, 29 Nov 2004 15:13:59 +0000 (UTC) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iATFDmpv013528; Mon, 29 Nov 2004 07:13:49 -0800 (PST) Received: from 192.9.61.12 (punchin-sommerfeld.SFBay.Sun.COM [192.9.61.12]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iATFDl8p011068; Mon, 29 Nov 2004 10:13:47 -0500 (EST) Subject: Re: [Mobike] issue 5: zero address set From: Bill Sommerfeld To: jari.arkko@piuha.net In-Reply-To: <41AB2C78.7010806@piuha.net> References: <200411092213.iA9MDJSj090394@givry.rennes.enst-bretagne.fr> <41AB2C78.7010806@piuha.net> Content-Type: text/plain; charset=ASCII Message-Id: <1101741205.8082.10.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 29 Nov 2004 10:13:26 -0500 Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , Francis Dupont X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit On Mon, 2004-11-29 at 09:04, Jari Arkko wrote: > Francis Dupont wrote: > > I don't believe zero address set support is so useful but I have > > a little concern about it: when a node has really no available > > addresses I prefer its peer knows this in place of just > > keep the last usable address and suggest it does still work... > > Of course, this situation should be temporary. > > Right. I have a sense that we have difficulties to > avoid temporary disconnects no matter what we do... > often in wireless we don't get to choose whether we > tell the other nodes that we are going to switch or > go out of coverage; we get a problem and the protocols > have to live with that. I think there's a difference here between "mobile" (phone) and "nomadic" (laptop) operation; in many cases, the nomad can do a graceful shutdown prior to becoming disconnected. That graceful shutdown means that the peer can be a better network citizen (avoiding sending useless packets which may bother the next tenant of the nomad's former address). Here's an approach which makes zero address support effectively optional: Implementations which do support it must be prepared to cope with the peer losing state while they were disconnected. Implementations which don't want to support it treat it as if it were a disconnect operation. A humorous way to look at it: it's the "Terminator option" ("I'll be back") to the disconnect operation... - Bill _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 29 12:24:44 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10916 for ; Mon, 29 Nov 2004 12:24:44 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id D2466FB279; Mon, 29 Nov 2004 17:24:43 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DDCC0FB246; Mon, 29 Nov 2004 17:24:41 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 27A3FFB262; Mon, 29 Nov 2004 17:24:40 +0000 (UTC) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 42882FB240 for ; Mon, 29 Nov 2004 17:24:39 +0000 (UTC) Message-ID: <02ce01c4d638$6f050890$596015ac@dcml.docomolabsusa.com> From: "James Kempf" To: , "MOBIKE Mailing List" References: <41850943.1090107@piuha.net> <00aa01c4c031$16b074d0$656115ac@dcml.docomolabsusa.com> <41913CDE.4030707@iprg.nokia.com><4191FD2D.9080008@piuha.net> <41AB361A.5090607@piuha.net> Subject: Re: [Mobike] issue 12: interaction with other protocols doing RR Date: Mon, 29 Nov 2004 09:25:23 -0800 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.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit This text looks fine to me. jak ----- Original Message ----- From: "Jari Arkko" To: "MOBIKE Mailing List" Sent: Monday, November 29, 2004 6:45 AM Subject: Re: [Mobike] issue 12: interaction with other protocols doing RR > We had a proposal where the results of MOBIKE RR > test could be used by other protocols, if deemed > useful by the designers of these other protocols. > There seems to be general support for this proposal. > > We also had a discussion about whether this would > make sense in the Mobile IPv6 space; different > opinions and technical alternatives were offered. > That's OK, however, because we don't get to decide > this part of the problem in WG. > > But we can now move forward with the original issue. > Here's my proposalon what the design draft should > say about the matter: > > Replace the current text > > MOBIKE might also want to export the information it has done the > return routability checks to the other modules, like Mobile IP, so > Mobile IP does not need to do return routability checks again, if it > is satisfied with the level of checks done by the MOBIKE. > > with this new Section: > > X. Employing MOBIKE results in other protocols > > If MOBIKE has learned about new locations or verified > the validity of an address through a return routability test, > can this information be useful for other protocols? > > When considering the basic MOBIKE VPN scenario, the answer is > no. Transport and application layer protocols running inside > the VPN tunnel have no consideration about the outer addresses > or their status. > > Similarly, IP layer tunnel termination at a gateway rather > than a host endpoint limits the "other protocols" that could > be informed -- all application protocols at the other side > are running in a node that is unaware of IPsec, IKE, or MOBIKE. > > However, it is conceivable that future uses or extensions of > MOBIKE make such information distribution useful. For instance, > if transport mode MOBIKE and SCTP were made to work together, it > would likely be useful for SCTP to learn about the new addresses > at the same time as MOBIKE learns them. Similarly, various IP layer > mechanisms might make use of the fact that a return routability > test of a specific type has already been performed. However, in > all of these cases careful consideration should be applied. > This consideration should answer to questions such as whether other > alternative sources exist for the information, whether dependencies > are created between parts that prior to this had no depedencies, and > what the impacts in terms of number of messages or latency are. > > Reference [draft-crocker-celp-00.txt] discussed the use of > common locator information pools in IPv6 multihoming context; > it assumed that both transport and IP layer solutions would be > used for providing multihoming, and that it would be beneficial > for different protocols to coordinate their results in some manner, > for instance by sharing experienced throughput information for > address pairs. This may apply to MOBIKE as well, assuming it co-exists > with non-IPsec protocols that are faced with the same multiaddressing > choices. > > Nevertheless, all of this is outside the scope of current MOBIKE > base protocol design and will be addressed in future work. > > --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 Nov 29 13:23:54 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16687 for ; Mon, 29 Nov 2004 13:23:54 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id CB5C5FB27A; Mon, 29 Nov 2004 18:23:55 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C42F5FB262; Mon, 29 Nov 2004 18:23:53 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3F074FB266; Mon, 29 Nov 2004 18:23:52 +0000 (UTC) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by machshav.com (Postfix) with ESMTP id 3FAEBFB246 for ; Mon, 29 Nov 2004 18:23:51 +0000 (UTC) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iATHtDR07930; Mon, 29 Nov 2004 09:55:13 -0800 X-mProtect: <200411291755> Nokia Silicon Valley Messaging Protection Received: from dadhcp-172019066085.americas.nokia.com (172.19.66.85, claiming to be "[172.19.66.85]") by darkstar.iprg.nokia.com smtpdCMm3Vj; Mon, 29 Nov 2004 09:55:11 PST Message-ID: <41AB6922.5090507@iprg.nokia.com> Date: Mon, 29 Nov 2004 10:23:30 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net Subject: Re: [Mobike] issue 12: interaction with other protocols doing RR References: <41850943.1090107@piuha.net> <00aa01c4c031$16b074d0$656115ac@dcml.docomolabsusa.com> <41913CDE.4030707@iprg.nokia.com> <4191FD2D.9080008@piuha.net> <41AB361A.5090607@piuha.net> In-Reply-To: <41AB361A.5090607@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit sounds fine to me. Vijay Jari Arkko wrote: > We had a proposal where the results of MOBIKE RR > test could be used by other protocols, if deemed > useful by the designers of these other protocols. > There seems to be general support for this proposal. > > We also had a discussion about whether this would > make sense in the Mobile IPv6 space; different > opinions and technical alternatives were offered. > That's OK, however, because we don't get to decide > this part of the problem in WG. > > But we can now move forward with the original issue. > Here's my proposalon what the design draft should > say about the matter: > > Replace the current text > > MOBIKE might also want to export the information it has done the > return routability checks to the other modules, like Mobile IP, so > Mobile IP does not need to do return routability checks again, if it > is satisfied with the level of checks done by the MOBIKE. > > with this new Section: > > X. Employing MOBIKE results in other protocols > > If MOBIKE has learned about new locations or verified > the validity of an address through a return routability test, > can this information be useful for other protocols? > > When considering the basic MOBIKE VPN scenario, the answer is > no. Transport and application layer protocols running inside > the VPN tunnel have no consideration about the outer addresses > or their status. > > Similarly, IP layer tunnel termination at a gateway rather > than a host endpoint limits the "other protocols" that could > be informed -- all application protocols at the other side > are running in a node that is unaware of IPsec, IKE, or MOBIKE. > > However, it is conceivable that future uses or extensions of > MOBIKE make such information distribution useful. For instance, > if transport mode MOBIKE and SCTP were made to work together, it > would likely be useful for SCTP to learn about the new addresses > at the same time as MOBIKE learns them. Similarly, various IP layer > mechanisms might make use of the fact that a return routability > test of a specific type has already been performed. However, in > all of these cases careful consideration should be applied. > This consideration should answer to questions such as whether other > alternative sources exist for the information, whether dependencies > are created between parts that prior to this had no depedencies, and > what the impacts in terms of number of messages or latency are. > > Reference [draft-crocker-celp-00.txt] discussed the use of > common locator information pools in IPv6 multihoming context; > it assumed that both transport and IP layer solutions would be > used for providing multihoming, and that it would be beneficial > for different protocols to coordinate their results in some manner, > for instance by sharing experienced throughput information for > address pairs. This may apply to MOBIKE as well, assuming it co-exists > with non-IPsec protocols that are faced with the same multiaddressing > choices. > > Nevertheless, all of this is outside the scope of current MOBIKE > base protocol design and will be addressed in future work. > > --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 Nov 29 15:49:01 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02314 for ; Mon, 29 Nov 2004 15:49:01 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 6B4FEFB27A; Mon, 29 Nov 2004 20:48:59 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 55340FB246; Mon, 29 Nov 2004 20:48:57 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E1907FB262; Mon, 29 Nov 2004 20:48:55 +0000 (UTC) Received: from p2.piuha.net (unknown [131.160.192.2]) by machshav.com (Postfix) with ESMTP id F323AFB240 for ; Mon, 29 Nov 2004 20:48:54 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id EDB138988E for ; Mon, 29 Nov 2004 22:48:52 +0200 (EET) Message-ID: <41AB8AB5.3070802@piuha.net> Date: Mon, 29 Nov 2004 22:46:45 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] issue 4: how to signal support for MOBIKE X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit I don't think we officially closed this issue yet, but it seems that when we discussed it in the past meetings we converged on using the vendor IDs as specified in the IKEv2 spec: A Vendor ID payload MAY announce that the sender is capable to accepting certain extensions to the protocol, or it MAY simply identify the implementation as an aid in debugging. A Vendor ID payload MUST NOT change the interpretation of any information defined in this specification (i.e., the critical bit MUST be set to 0). Pasi's draft contains an example of how this would be done for MOBIKE: Implementations that support this specification MUST include a Vendor ID payload in the IKE_SA_INIT exchange (first two messages). The value for this payload is XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX (TBD). The other alternative that has been discussed is the use of the critical bit. We would define a new payload and mark it critical. Here's my reasoning why the Vendor ID payload approach seems slightly better: First, we need to remember that the initial IKEv2 exchange is at least four messages. This means that if we want to exchange capabilities and addresses, we can exchange the capabilities in the first round and then alternative address information in the second round. So I would suggest that we use the Vendor ID approach. Below you'll find my suggested text for the design draft. (A quick search revealed no previous text about the matter, but I may have missed something.) X. Indicating Support for MOBIKE A node needs to be able to trust that its address change messages are understood by the peer. Otherwise an address change may render the connection useless, and it is important that both sides realize this as early as possible. Ensuring that the messages are understood can in be arranged either by marking some IKEv2 payloads critical so that they are either processed or an error message is returned, or by using Vendor ID payloads. In the latter approach a specific string denoting MOBIKE will signal the support of the MOBIKE protocol. (Should there be optional, separable parts in the protocol there may be a need for more than one Vendor ID; this is left for further study). The recommended solution is to use Vendor ID payloads during the initial IKEv2 exchange, perhaps in the first round, so that the second round can be used for actual MOBIKE signaling, if necessary. This ensures that in all cases a MOBIKE capable node knows whether its peer supports MOBIKE or not. If the peer does support MOBIKE, the node can then use MOBIKE-specific messages and payloads, with the critical bit set to zero or one depending on the semantics of the message. If the peer does not support MOBIKE, then the node knows that, at least without NATs, a movement implies need to rerun IKEv2 from the start. Note that the node could also attempt MOBIKE optimistically with the critical bit set to one when a movement has occurred. The drawback of this approach is, however, that the an unnecessary MOBIKE message round is introduced on the first movement. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 29 23:25:33 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18715 for ; Mon, 29 Nov 2004 23:25:32 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id CCF96FB27A; Tue, 30 Nov 2004 04:25:33 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E3F56FB266; Tue, 30 Nov 2004 04:25:15 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A8E3EFB277; Tue, 30 Nov 2004 04:25:14 +0000 (UTC) Received: from p2.piuha.net (unknown [131.160.192.2]) by machshav.com (Postfix) with ESMTP id C398EFB262 for ; Tue, 30 Nov 2004 04:25:13 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 970618988A for ; Tue, 30 Nov 2004 06:25:11 +0200 (EET) Message-ID: <41ABF5A6.7010606@piuha.net> Date: Tue, 30 Nov 2004 06:23:02 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] issue 10: changing addresses or paths? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Our earlier resolution of issue 17 (if both parties have several addresses, do we assume that all pairs have connectivity between them?) was that we should NOT assume full connectivity in these cases. I believe the above resolution implies that upon a problem, we may have to switch paths, not just an address. I also explained the issue in Washington in my presentation. So I think its pretty clear that the answer to this question is that we need to be able to change paths. Suggested text below: Change design draft from 6. Changing addresses or changing the paths (issue #10, #14) The question here is, if it is enough for the MOBIKE to detect the dead-address, or do it need to detect also dead-paths. Dead-address detection means that we only detect that we cannot get packets through to that remote address by using the local IP-address given by the local IP-stack (i.e. local address selected normally by the routing information). Dead-path detection means that we need to try all possible local interfaces/IP-addresses for each remote addresses, i.e. find all possible paths between the hosts and try them all to see which of them work (or at least find one working path). Doing the dead-address detection is simpler, and there is less probe packets to be sent, thus it does not cause that much stress to the network. It also is enough for the scenarios where the connection problems are local (i.e. interfaces going down, WLAN access disappearing etc). It does not help if some router somewhere along the path breaks down, in which case rerouting the packets along another path might get around that broken router. The question is, whether rerouting around that problem inside the core network is a problem that MOBIKE needs to solve. to 6. Changing addresses or changing the paths (issue #10, #14) The question here is, if it is enough for the MOBIKE to detect the dead-address, or do it need to detect also dead-paths. Dead-address detection means that we only detect that we cannot get packets through to that remote address by using the local IP-address given by the local IP-stack (i.e. local address selected normally by the routing information). Dead-path detection means that we need to try all possible local interfaces/IP-addresses for each remote addresses, i.e. find all possible paths between the hosts and try them all to see which of them work (or at least find one working path). While performing just an address change is simpler, the existence of locally operational addresses are not, however, a guarantee that communications can be established with the peer. A failure in the routing infrastructure can prevent the sent packets from reaching their destination. Or a failure of an interface on one side can be related to the failure of an interface on the other side, making it necessary to change more than one address at a time. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 30 05:40:51 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03107 for ; Tue, 30 Nov 2004 05:40:50 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 21258FB27D; Tue, 30 Nov 2004 10:40:50 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 50EEDFB266; Tue, 30 Nov 2004 10:40:46 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 334DEFB277; Tue, 30 Nov 2004 10:40:44 +0000 (UTC) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 3B2D7FB262 for ; Tue, 30 Nov 2004 10:40:43 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iAUAebbg015561 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 30 Nov 2004 12:40:38 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iAUAeYZU015558; Tue, 30 Nov 2004 12:40:34 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16812.20002.674034.904046@fireball.kivinen.iki.fi> Date: Tue, 30 Nov 2004 12:40:34 +0200 From: Tero Kivinen To: jari.arkko@piuha.net Subject: [Mobike] issue 4: how to signal support for MOBIKE In-Reply-To: <41AB8AB5.3070802@piuha.net> References: <41AB8AB5.3070802@piuha.net> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari Arkko writes: > So I would suggest that we use the Vendor ID approach. I would suggest NOTIFY approach. I.e we send notify saying MOBIKE_SUPPORTED and thats it. Similar thatn what is done for the NAT-T or the IPCOMP_SUPPORTED or USE_TRANSPORT_MODE etc. In most cases we do not want to fail the negotiation even if the other end does not support MOBIKE, we simply revert back to redoing the authentication every time IP-addresses changes. If our final protocol is going to use notifies to send the IP-addresses, then we can use those notifies to signal the use of MOBIKE instead of separate MOBIKE_SUPPORTED notify. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 30 14:53:06 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26777 for ; Tue, 30 Nov 2004 14:53:05 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 1B162FB280; Tue, 30 Nov 2004 19:52:58 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 97014FB279; Tue, 30 Nov 2004 19:52:54 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 28DB1FB27A; Tue, 30 Nov 2004 19:52:53 +0000 (UTC) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 5AE6FFB266 for ; Tue, 30 Nov 2004 19:52:52 +0000 (UTC) Message-ID: <057b01c4d716$4e612c20$596015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Tero Kivinen" , References: <41AB8AB5.3070802@piuha.net> <16812.20002.674034.904046@fireball.kivinen.iki.fi> Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE Date: Tue, 30 Nov 2004 11:53:40 -0800 MIME-Version: 1.0 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.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit I agree with Tero. jak ----- Original Message ----- From: "Tero Kivinen" To: Cc: "MOBIKE Mailing List" Sent: Tuesday, November 30, 2004 2:40 AM Subject: [Mobike] issue 4: how to signal support for MOBIKE > Jari Arkko writes: > > So I would suggest that we use the Vendor ID approach. > > I would suggest NOTIFY approach. I.e we send notify saying > MOBIKE_SUPPORTED and thats it. Similar thatn what is done for the > NAT-T or the IPCOMP_SUPPORTED or USE_TRANSPORT_MODE etc. > > In most cases we do not want to fail the negotiation even if the other > end does not support MOBIKE, we simply revert back to redoing the > authentication every time IP-addresses changes. > > If our final protocol is going to use notifies to send the > IP-addresses, then we can use those notifies to signal the use of > MOBIKE instead of separate MOBIKE_SUPPORTED notify. > -- > 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 mailman-bounces@machshav.com Wed Dec 1 00:02:07 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29449 for ; Wed, 1 Dec 2004 00:02:07 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 633A2FB29E; Wed, 1 Dec 2004 05:02:09 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F1D6AFB2E7 for ; Wed, 1 Dec 2004 05:01:15 +0000 (UTC) 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: Wed, 01 Dec 2004 05:00:12 +0000 Precedence: bulk X-BeenThere: mailman@machshav.com X-Mailman-Version: 2.1.4 List-Id: mailman.machshav.com X-List-Administrivia: yes Sender: mailman-bounces@machshav.com Errors-To: mailman-bounces@machshav.com Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your machshav.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@machshav.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@machshav.com. Thanks! Passwords for mobike-archive@lists.ietf.org: List Password // URL ---- -------- mobike@machshav.com behoef https://www.machshav.com/mailman/options.cgi/mobike/mobike-archive%40lists.ietf.org