From mobopts-bounces@irtf.org Tue Jul 05 12:30:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpqJO-0008Ev-Vu; Tue, 05 Jul 2005 12:30:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpqJN-0008EB-JN for mobopts@megatron.ietf.org; Tue, 05 Jul 2005 12:30:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17848 for ; Tue, 5 Jul 2005 12:30:14 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpqiT-0005jL-PU for mobopts@irtf.org; Tue, 05 Jul 2005 12:56:15 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j65Fv5E15510 for ; Tue, 5 Jul 2005 08:57:05 -0700 X-mProtect: <200507051557> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14171.americas.nokia.com (172.18.141.71, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpd8uzSJ8; Tue, 05 Jul 2005 08:57:03 PDT Message-ID: <42CAB51B.6030305@iprg.nokia.com> Date: Tue, 05 Jul 2005 09:28:11 -0700 From: Rajeev Koodli 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: mobopts@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Mobopts] Meeting in Paris X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hello folks, we have requested meeting slots. Please indicate your interest in presenting with the following information. 1. Title of your talk, with a URL to the document. 2. Time needed 3. Brief summary of your work (no more than 3 - 4 sentences). Please provide this information even if you have already sent me a request. Thanks, -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jul 05 21:44:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpyy4-00057C-Ul; Tue, 05 Jul 2005 21:44:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpyy1-00055z-Qx for mobopts@megatron.ietf.org; Tue, 05 Jul 2005 21:44:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03825 for ; Tue, 5 Jul 2005 21:44:46 -0400 (EDT) Received: from [218.249.29.198] (helo=center.njtu.edu.cn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpzIo-0002oO-Kg for mobopts@irtf.org; Tue, 05 Jul 2005 22:06:19 -0400 Received: from zhanghk (remotehost [127.0.0.1]) by mail.student.njtu.edu.cn (ecMail) with ESMTP id B503918C12E; Wed, 6 Jul 2005 09:54:21 +0800 (CST) Date: Wed, 6 Jul 2005 09:39:51 +0800 From: "HKzhang@center.njtu.edu.cn" To: "waa" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20050706015421.B503918C12E@mail.student.njtu.edu.cn> X-Spam-Score: 3.5 (+++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: rajeev , mobopts Subject: [Mobopts] could you please tell me how about your applying for time slot in the meeting and how about our request of time to our draft X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0314179269==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org --===============0314179269== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGksIERlYXIgQ2hhaXJtYW4NCg0KICBJIGFtIEJpbmctWWkgWmhhbmcsIG9uZSBvZiB0aGUgYXV0 aG9yIG9mIGRyYWZ0LXpoYW5nLW1pcHNob3AtbXVsdGljYXN0LWRtYS0wMC50eHQuIFNvcnJ5IHRv IGRpc3R1cmIgeW91IGFnYWluLg0KICBGb3Igd2UgaGF2ZSBub3QgcmVjZWl2ZWQgeW91ciBtZXNz YWdlIGFib3V0IHRoZSB0aW1lIGFycmFuZ2VtZW50IGluIHRoZSA2M3JkIElFVEYgbWVldGluZyBp biBQYXJpcywgY291bGQgeW91IHBsZWFzZSB0ZWxsIG1lIGhvdyBhYm91dCB5b3VyIGFwcGx5aW5n IGZvciB0aW1lIHNsb3QgaW4gdGhlIG1lZXRpbmcgYW5kIGhvdyBhYm91dCBvdXIgcmVxdWVzdCBv ZiB0aW1lIHRvIG91ciBkcmFmdC4NCiAgVGhhbmsgeW91ciBjb250cmlidXRpb24hDQogIA0KQmVz dCByZWdhcmRzDQpEci5Ib25nLUtlIFpoYW5nDQpQcmVzaWRlbnQgb2YgQ29sbGVnZSBvZiBFbGVj dHJvbmljcyBhbmQgSW5mb3JtYXRpb24gRW5naW5lZXJpbmcsIEJlaWppbmcgSmlhb3RvbmcgVW5p dmVyc2l0eQ0KDQogCQkJCQ0KDQqhoaGhoaGhoaGhoaGhoaGhSEt6aGFuZw0KoaGhoaGhoaGhoaGh oaGhoUhLemhhbmdAY2VudGVyLm5qdHUuZWR1LmNuDQqhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDUt MDctMDYNCg== --===============0314179269== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============0314179269==-- From mobopts-bounces@irtf.org Tue Jul 05 21:45:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpyyF-0005MI-Bb; Tue, 05 Jul 2005 21:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpyyA-0005FE-2t for mobopts@megatron.ietf.org; Tue, 05 Jul 2005 21:44:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03935 for ; Tue, 5 Jul 2005 21:44:54 -0400 (EDT) Received: from [218.249.29.198] (helo=center.njtu.edu.cn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpzGS-00026I-5S for mobopts@irtf.org; Tue, 05 Jul 2005 22:03:56 -0400 Received: from zhanghk (remotehost [127.0.0.1]) by mail.student.njtu.edu.cn (ecMail) with ESMTP id 72DE018C0F9; Wed, 6 Jul 2005 09:51:54 +0800 (CST) Date: Wed, 6 Jul 2005 09:37:24 +0800 From: "HKzhang@center.njtu.edu.cn" To: "waa" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20050706015154.72DE018C0F9@mail.student.njtu.edu.cn> X-Spam-Score: 3.5 (+++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: rajeev , mobopts Subject: [Mobopts] could you please tell me how about your applying for time slot in the meeting and how about our request of time to our draft X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0639690489==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org --===============0639690489== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQpIaSwgRGVhciBDaGFpcm1hbg0KDQogIEkgYW0gQmluZy1ZaSBaaGFuZywgb25lIG9mIHRoZSBh dXRob3Igb2YgZHJhZnQtemhhbmctbWlwc2hvcC1tdWx0aWNhc3QtZG1hLTAwLnR4dC4gU29ycnkg dG8gZGlzdHVyYiB5b3UgYWdhaW4uDQogIEZvciB3ZSBoYXZlIG5vdCByZWNlaXZlZCB5b3VyIG1l c3NhZ2UgYWJvdXQgdGhlIHRpbWUgYXJyYW5nZW1lbnQgaW4gdGhlIDYzcmQgSUVURiBtZWV0aW5n IGluIFBhcmlzLCBjb3VsZCB5b3UgcGxlYXNlIHRlbGwgbWUgaG93IGFib3V0IHlvdXIgYXBwbHlp bmcgZm9yIHRpbWUgc2xvdCBpbiB0aGUgbWVldGluZyBhbmQgaG93IGFib3V0IG91ciByZXF1ZXN0 IG9mIHRpbWUgdG8gb3VyIGRyYWZ0Lg0KICBUaGFuayB5b3VyIGNvbnRyaWJ1dGlvbiENCiAgDQpC ZXN0IHJlZ2FyZHMNCkRyLkhvbmctS2UgWmhhbmcNClByZXNpZGVudCBvZiBDb2xsZWdlIG9mIEVs ZWN0cm9uaWNzIGFuZCBJbmZvcm1hdGlvbiBFbmdpbmVlcmluZywgQmVpamluZyBKaWFvdG9uZyBV bml2ZXJzaXR5DQoNCqGhoaGhoaGhoaGhoaGhoaFIS3poYW5nDQqhoaGhoaGhoaGhoaGhoaGhSEt6 aGFuZ0BjZW50ZXIubmp0dS5lZHUuY24NCqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwNS0wNy0wNg0K --===============0639690489== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============0639690489==-- From mobopts-bounces@irtf.org Tue Jul 05 22:50:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpzzE-0004yT-Gt; Tue, 05 Jul 2005 22:50:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpzzA-0004vm-0j for mobopts@megatron.ietf.org; Tue, 05 Jul 2005 22:50:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10090 for ; Tue, 5 Jul 2005 22:49:59 -0400 (EDT) Received: from [218.249.29.198] (helo=center.njtu.edu.cn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq0Dm-0006da-2v for mobopts@irtf.org; Tue, 05 Jul 2005 23:05:11 -0400 Received: from zhanghk (remotehost [127.0.0.1]) by mail.student.njtu.edu.cn (ecMail) with ESMTP id 29CC918C07B; Wed, 6 Jul 2005 10:53:13 +0800 (CST) Date: Wed, 6 Jul 2005 10:38:43 +0800 From: "HKzhang@center.njtu.edu.cn" To: "rajeev" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20050706025313.29CC918C07B@mail.student.njtu.edu.cn> X-Spam-Score: 3.5 (+++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: waa , mobopts Subject: [Mobopts] a good news, thank your contribution,Meet you in Paris X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1618679163==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org --===============1618679163== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGksIFJhamVldg0KICBUaGFuayB5b3VyIHJlcGx5LiBJIHNlZSB5b3VyIGUtbWFpbCBqdXN0IG5v dy4gSSBhbSBnbGFkIHRvIGhlYXIgdGhpcyBnb29kIG5ld3MuIEF0IGFuIGVhcmx5IHRpbWUsIEkg aGF2ZSB0aG91Z2h0IGl0IG1heWJlIGltcG9zc2libGUgZm9yIHVzIHRvIG1ha2UgcHJlc2VudCBp biB0aGlzIG1lZXRpbmcuIFNvIHRoYW5rIHlvdXIgY29udHJpYnV0aW9uLiBNeSBpbmZvcm1hdGlv biBpcyBhcyBmb2xsb3dzOg0KMS4gPCBBbiBlZmZpY2llbnQgZHluYW1pYyBtdWx0aWNhc3QgYWdl bnQgYXBwcm9hY2ggZm9yIG1vYmlsZSBJUHY2IG11bHRpY2FzdA0KPiwgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9wdWJsaWMvaWRpbmRleC5jZ2k/Y29tbWFuZD1pZF9kZXRhaWwmaWQ9MTMy NDQNCjIuIEFib3V0IDE1IG1pbnV0ZXMuIA0KMyBUaGlzIGFwcHJvYWNoIGludGVncmF0cyB0aGUg bWVyaXQgb2YgTUlQLUJUIGFuZCBNSVAtUlMgYW5kIGNvbnF1ZXIgdGhlaXIgZGlzYWR2YW5nZS4g SXQgY2FuIHJlZHVjZSB0aGUgdGltZXMgb2YgbXVsdGljYXN0IHRyZWUgcmVzdHJ1Y3R1cmluZyBh bmQgYWxsb3cgTU5zIG9wdGltaXplIG11bHRpY2FzZSByb3V0ZXMgc2ltdWx0YW5lb3VzbHkgdGhy b3VnaCBzZWxlY3Rpb25nIGEgbmV3IG11bHRpY2FzdCBhZ2VudCBkeW5hbWljYWxseS4gSW4gYWRk aXRpb24sIGluIHRoaXMgYXBwcm9hY2ggTU4gaXMgbGVmdCBvdXQgb2YgdGhlIG1vc3QgbWFuYWdl bWVudCBhbmQgdGhlIGxvYWQgaW4gTU4gaXMgbG93LiBNTiBpbiB0aGUgc2FtZSBzdWJuZXQgbWF5 IHNlbGVjdCBkaWZmZXJlbnQgRE1BIGFuZCB0aGUgbG9hZCBpbiBlYWNoIERNQSBpcyBsaWdodGVu ZWQuVGhlIHJlc3VsdHMgTlMgc2ltdWxhdGlvbiBkZW5vdGUgdGhhdCBETUEgYXBwcm9hY2ggY2Fu IGltcHJvdmUgdGhlIG5ldHdvcmsgcGVyZm9ybWFuY2UgZWZmZWN0aXZlbHkgYW5kIGFkYXB0IHRv IHRoZSBtb2JpbGUgSVB2NiBtdWx0aWNhc3QuDQogV2Ugd2lsbCBwcmFwYXJlIHNvbWUgc2xpZGVz IHRvIGRlc2NyaWJlIG91ciB3b3JrLg0KTWVldCB5b3UgaW4gUGFyaXMNCkJlc3QgcmVnYXJkcw0K SG9uZy1rZSBaaGFuZw0KDQoJCQkJIA0KoaGhoaGhoaGhoaGhoaGhoQ0KoaGhoaGhoaGhoaGhoaGh oUhLemhhbmcNCqGhoaGhoaGhoaGhoaGhoaFIS3poYW5nQGNlbnRlci5uanR1LmVkdS5jbg0KoaGh oaGhoaGhoaGhoaGhoaGhoaEyMDA1LTA3LTA2DQo= --===============1618679163== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============1618679163==-- From mobopts-bounces@irtf.org Wed Jul 06 04:11:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq501-0007Ji-65; Wed, 06 Jul 2005 04:11:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq4zz-0007J4-I0 for mobopts@megatron.ietf.org; Wed, 06 Jul 2005 04:11:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11949 for ; Wed, 6 Jul 2005 04:11:10 -0400 (EDT) Received: from mail1.rz.fhtw-berlin.de ([141.45.5.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq5Qi-0005B0-1k for mobopts@irtf.org; Wed, 06 Jul 2005 04:39:02 -0400 Received: from [141.22.17.128] (helo=[141.22.17.128]) by mail1.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42 (FreeBSD)) id 1Dq4zN-000197-FS; Wed, 06 Jul 2005 10:10:37 +0200 Message-ID: <42CB92FB.80108@fhtw-berlin.de> Date: Wed, 06 Jul 2005 10:14:51 +0200 From: Thomas Schmidt User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mobopts] Meeting in Paris References: <42CAB51B.6030305@iprg.nokia.com> In-Reply-To: <42CAB51B.6030305@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: schmidt@fhtw-berlin.de List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Dear Rajeev, as there seems to arise interest for discussion on multicast mobility for the Paris meeting we would like to apply for a slot: 1. Title: Seamless Multicast Handover in a Hierarchical Mobile IPv6 Environment (M-HMIPv6) Document: ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-schmidt-waehlisch-mhmipv6-03.txt 2. Time: 15-20 min 3. Summary: This work extends the Hierarchical Mobile IPv6 Internet Draft to include the reception and transmission of multicast traffic at the Mobile Node. It introduces handover mechanisms for IPv6 mobile multicast listeners and mobile multicast senders. Addtional focus will be denoted on efficiency (handover frequencies a.s.) as related to work published in: http://www.rz.fhtw-berlin.de/data/rz.web/content/Materialien/Projekte/mipv6/icn05-paper.pdf Thanks, thomas Rajeev Koodli wrote: > > > Hello folks, > > we have requested meeting slots. Please indicate your > interest in presenting with the following information. > > 1. Title of your talk, with a URL to the document. > 2. Time needed > 3. Brief summary of your work (no more than 3 - 4 sentences). > > Please provide this information even if you have already > sent me a request. > > Thanks, > > -Rajeev > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 06 08:06:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq8fO-0004iY-QX; Wed, 06 Jul 2005 08:06:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq8fN-0004hU-0g for mobopts@megatron.ietf.org; Wed, 06 Jul 2005 08:06:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08211 for ; Wed, 6 Jul 2005 08:06:07 -0400 (EDT) Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq8yR-0008KX-Kt for mobopts@irtf.org; Wed, 06 Jul 2005 08:26:02 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id j66Bvvrr024836; Wed, 6 Jul 2005 20:57:57 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j66BvvfH007545; Wed, 6 Jul 2005 20:57:57 +0900 (JST) Received: from ovp2.toshiba.co.jp [133.199.166.115] by tsb-wall.toshiba.co.jp with SMTP id WAA07539 ; Wed, 6 Jul 2005 20:57:57 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id j66Bvvpe011601; Wed, 6 Jul 2005 20:57:57 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id j66BvuW9025724; Wed, 6 Jul 2005 20:57:56 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id j66BvudF006007; Wed, 6 Jul 2005 20:57:56 +0900 (JST) Received: from steelhead ([172.30.24.113]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0IJ700C1GFWEZU@tsbpo1.po.toshiba.co.jp>; Wed, 6 Jul 2005 20:57:52 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Dq8Pu-0004nm-00; Wed, 06 Jul 2005 04:50:14 -0700 Date: Wed, 06 Jul 2005 07:50:14 -0400 From: Yoshihiro Ohba Subject: Re: [Mobopts] Meeting in Paris In-reply-to: <42CAB51B.6030305@iprg.nokia.com> To: Rajeev Koodli Message-id: <20050706115014.GB18341@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.9i References: <42CAB51B.6030305@iprg.nokia.com> X-Spam-Score: 2.4 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi Rajeev, We would like to present the following item: 1. "MPA Framework and Implementation Updates", by Ashutosh Dutta draft-ohba-mobopts-mpa-{framework,implementation}-01.txt (to be submitted soon) 2. Time needed 15 min. 3. "MPA (Media-independent Pre-authentication) is a mobile-assisted, secure handover optimization scheme that works over any link-layer and with any mobility management protocol. Resolution for the MPA issues raised during the previous mobopts meeting as well as the latest status of MPA implementation with Mobile IPv6 will be presented." Best regards, Yoshihiro Ohba On Tue, Jul 05, 2005 at 09:28:11AM -0700, Rajeev Koodli wrote: > > > Hello folks, > > we have requested meeting slots. Please indicate your > interest in presenting with the following information. > > 1. Title of your talk, with a URL to the document. > 2. Time needed > 3. Brief summary of your work (no more than 3 - 4 sentences). > > Please provide this information even if you have already > sent me a request. > > Thanks, > > -Rajeev > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 06 18:02:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqHyb-0007i9-Sl; Wed, 06 Jul 2005 18:02:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqHyW-0007at-Ct; Wed, 06 Jul 2005 18:02:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02467; Wed, 6 Jul 2005 18:02:33 -0400 (EDT) From: Michael.G.Williams@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqIPY-0005Nb-Uc; Wed, 06 Jul 2005 18:30:34 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j66LxD7S008440; Thu, 7 Jul 2005 00:59:13 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 01:02:17 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jul 2005 17:02:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jul 2005 15:02:12 -0700 Message-ID: <8A76136424391244A5CF0165337085375F4815@mvebe101.NOE.Nokia.com> Thread-Topic: Interest in protocols for IEEE 802.21 IS, CS, ES Thread-Index: AcWBscTY+GcB1EDLSGqEYlGAwjIGvgABVtUgAB/eFKAADCyF8AAAKZzAAAEz5iAAAbbesAAAJfow To: , , X-OriginalArrivalTime: 06 Jul 2005 22:02:13.0544 (UTC) FILETIME=[5D722280:01C58276] X-Spam-Score: 2.7 (++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: kempf@docomolabs-usa.com, gabriel_montenegro_2000@yahoo.com, rajeev@iprg.nokia.com, margaret@thingmagic.com, Basavaraj.Patil@nokia.com Subject: [Mobopts] Interest in protocols for IEEE 802.21 IS, CS, ES X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Colleagues, =20 The IEEE 802.21 working group is developing services for facilitating IP address mobility and service mobility, especially handoff across a variety of media. The group is interested in working with the relevant IETF/IRTF working groups to develop methods of carrying these services across the network. It would be ideal to discuss this at the next IETF meeting.=20 =20 There are multiple drafts currently issued or in development that are interesting and could serve as the basis for starting the work. =20 Drafts of interest include but are not limited to : =20 "Neighborhood Information Elements Discovery (NED) (draft-kempf-mobopts-nhood-discovery-00.txt), which provides a generic protocol for carrying information elements of interest to IEEE 802.21."=20 =20 "Some Requirements for a Media Independent Handover Information Service" (draft-faccin-mih-infoserv-00.txt, http://www.ctie.monash.edu.au/dna/draft-faccin-mih-infoserv-00.txt ). =20 "Architectural Implications of Link Indications" http://www.iab.org/documents/drafts/draft-iab-link-indications-01.txt =20 "Unified L2 Abstractions for L3-Driven Fast Handover" http://www.ietf.org/internet-drafts/draft-koki-mobopts-l2-abstractions-0 2.txt =20 "A Framework of Media-Independent Pre-Authentication (MPA)" http://www.ietf.org/internet-drafts/draft-ohba-mobopts-mpa-framework-00. txt=20 =20 Best Regards, Michael G. Williams IEEE 802.21 Working Group Vice Chair _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 06 18:17:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqID1-0004Ah-6S; Wed, 06 Jul 2005 18:17:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqICy-00049a-Pd for mobopts@megatron.ietf.org; Wed, 06 Jul 2005 18:17:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04455 for ; Wed, 6 Jul 2005 18:17:30 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqIe0-0008GW-B2 for mobopts@irtf.org; Wed, 06 Jul 2005 18:45:31 -0400 Message-ID: <0b1b01c58278$ab6ad980$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , , , References: <8A76136424391244A5CF0165337085375F4815@mvebe101.NOE.Nokia.com> Date: Wed, 6 Jul 2005 15:18:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: margaret@thingmagic.com, gabriel_montenegro_2000@yahoo.com, rajeev@iprg.nokia.com, Basavaraj.Patil@nokia.com Subject: [Mobopts] Re: Interest in protocols for IEEE 802.21 IS, CS, ES X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Mike, Would you like to get a BAR BOF-style meeting at IETF set up to discuss this? With the help of an AD or IAB member, I think we could get a room reserved for that purpose. jak ----- Original Message ----- From: To: ; ; Cc: ; ; ; ; ; Sent: Wednesday, July 06, 2005 3:02 PM Subject: Interest in protocols for IEEE 802.21 IS, CS, ES Colleagues, The IEEE 802.21 working group is developing services for facilitating IP address mobility and service mobility, especially handoff across a variety of media. The group is interested in working with the relevant IETF/IRTF working groups to develop methods of carrying these services across the network. It would be ideal to discuss this at the next IETF meeting. There are multiple drafts currently issued or in development that are interesting and could serve as the basis for starting the work. Drafts of interest include but are not limited to : "Neighborhood Information Elements Discovery (NED) (draft-kempf-mobopts-nhood-discovery-00.txt), which provides a generic protocol for carrying information elements of interest to IEEE 802.21." "Some Requirements for a Media Independent Handover Information Service" (draft-faccin-mih-infoserv-00.txt, http://www.ctie.monash.edu.au/dna/draft-faccin-mih-infoserv-00.txt ). "Architectural Implications of Link Indications" http://www.iab.org/documents/drafts/draft-iab-link-indications-01.txt "Unified L2 Abstractions for L3-Driven Fast Handover" http://www.ietf.org/internet-drafts/draft-koki-mobopts-l2-abstractions-0 2.txt "A Framework of Media-Independent Pre-Authentication (MPA)" http://www.ietf.org/internet-drafts/draft-ohba-mobopts-mpa-framework-00. txt Best Regards, Michael G. Williams IEEE 802.21 Working Group Vice Chair _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 06 19:04:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqIvx-0003hQ-K6; Wed, 06 Jul 2005 19:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqIvs-0003b0-TC for mobopts@megatron.ietf.org; Wed, 06 Jul 2005 19:03:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12617 for ; Wed, 6 Jul 2005 19:03:49 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqJMs-0002v2-E5 for mobopts@irtf.org; Wed, 06 Jul 2005 19:31:51 -0400 Message-ID: <0b2201c5827f$250a0bc0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Narayanan Vidya-CVN065" , , References: <1B631E11D496D711BB2800065BFCB6A11B7A71AF@il02exm13> Date: Wed, 6 Jul 2005 16:05:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , Julien Bournelle , Venkitaraman Narayanan-CNV002 , "'Tschofenig, Hannes'" Subject: [Mobopts] Review of draft-vidya-mipshop-handover-keys-aaa-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org All and all, an interesting document . Comments below. jak --------------------- Basic Architectural Comment: I got the feeling while reading through this that the authors decided for some reason to keep the base protocol completely decoupled from any dependence upon network access authentication. If so, I wonder why? In essence, the basic architectural function this protocol is trying to accomplish is to derive and distribute another set of keys as part of the host to access network AAA association, and therefore it would seem to have a natural dependence on the access network authentication protocol. The result was kind of unsatisfying, as it left the protocol somewhat ungrounded and lacking a concrete connection with a straightforward path toward implementation and deployment, when, in fact, one of the stated reasons for doing an AAA-based protocol in the first place was to make implementation and deployment simpler by leveraging off of the existing AAA infrastructure. For example, since the protocol description in Section 3 does not mention an encryption security association between the AAA server and the MN, the nonce sent by the AAA server to the MN seems to be sent in the clear, which gives an eavesdropper one piece of information that it could use in some fashion to compromise. If you read further (in particular into the Appendix) you see that, in fact, EAP can be used for this transaction, and so one of the EAP methods that support secure MN-AAA server communication could be used to maintain confidentiality on this transaction (though the document provides no details on what the EAP extension is). But if EAP isn't used, then what? My (somewhat radical) suggestion to the authors would be to redesign the protocol to couple it tightly with EAP-based network access authentication protocol. This would mean: - Incorporating the derivation of the HMK from the EAP key hiearchy which is now in Appendix A into the protocol directly - Using EAP within the network access authentication transaction to exchange parameters to derive the HMK, by defining an EAP extension for one of the extensible EAP methods. This will ensure that the transaction between the MN and AAA server is properly confidential, protecting MN anonymity and the parameters of the key derivation - Instead of defining a separate protocol for preauthentication and reauthentication upon handover (Section 4), couple the derivation of new HKs via preauthentication or reauthentication on handover to PANA pre- and reauthentication. This will allow the protocol to leverage off of the PANA work, so that the deep thinking about how to get pre- and reauthentication on handover right only needs to be done once, for PANA (where it needs to be done anyway). Incidently, if one of the reasons why this protocol was decoupled from network access authentication was to allow IEEE 802.1x or other Layer 2 protocols to be used, then this needs some rethinking. EAP is used in 802.1x anyway so it could still be used for the initial HMK derivation. And the 802.1x reauthentication isn't going to be useful for handover key reauthentication, because it only deals with APs, which are layer 2 devices, whereas this protocol must deal with ARs, which are layer 3 devices, so PANA is probably the right vehicle. Detailed Editorial and Technical Comments: Section 3, paragraph 2: This paragraph seems to be specifying use of the HMK for calculating a MAC. It might be a good idea to keep the HMK private, and use a derived key for this purpose, to avoid exposing material calculated with the HMK to attackers. Section 3, paragraph 2: As mentioned above, the nounce looks to be sent in the clear. Might be better from a confidentiality standpoint to encrypt. Similarly for the NAI. Section 3, paragraph 4 and 6: What is PRF here? Section 3.1, paragraph 2: Note that if the nounce is encrypted, it need only be exchanged once, during the initial HMK derivation. After that, fresh nounces can be derived by forward hashing from the original. Alternatively, the AAA server and MN can generate a hash chain and move backward (at the expense of having to store the hashes). This eliminates the need to send a hash out over the air each time a reauthentication is performed. The AAA server can push the appropriate nounce to the AR. Section 3.1: It is unclear to me how the MN manages keys generated by preauthentication. Essentially, the MN is setting up soft state in the network that it must manage. Yet, the specification only briefly mentions key lifetimes, and does not specify any suggested defaults, nor how the AR knows what the lifetime of the key should be. Section 4.1, v Flag - Is the MN sharing a key with itself here? Section 4.1, Seq. number - What if the message is retransmitted on a new AR? Should the MN use the same Seq. number or new? Section 5.1: This section seemed to be saying that the MN needs a key on the new AR when it hands over before it can do the FMIP signaling, is that correct? If so, I'd like to know why? The primary security issue in FMIP is not security with the new AR, but security with the old AR. The old AR is being asked by the FBU to change routing for the old CoA (i.e. set up a tunnel from the old CoA to the new), and for that purpose, it must have some indication that the entity sending the FBU is authorized to claim the CoA. The new AR gets the FNA which is typically piggybacked on the FBU, but that needs to be secured using IP address configuration security, and it can even be eliminated entirely if the MN used oDAD since its only purpose is to allow the AR to confirm whether the address is not a duplicate. For example, if the new CoA is autoconfigured, then RFC 3971 and 3972 can be used to secure the address. If the address in DHCP configured, other mechanisms are to be used. Or are the authors intending here to define a new way of performing IP address configuration security? With this comment in mind, I fail to see the urgency of having to perform the key exchange with surrounding routers immediately coupled to the handover signaling. The issue becomes ensuring the MN has a key on the router it currently is, so that when it hands over it can properly change routing. For that purpose, the MN may want to perform preauthentication in order to avoid having to establish the key once it moves to the new router, but there is no need to couple preauthentication tightly to the handover. Section 5.1, paragraph 5: The last sentence is somewhat gratuitous and can be dropped. Section 5.2, paragraph 1: Pick whether to include the Alt CoA or not. Why have two choices here? Section 5.2, paragraph 2: If the MN retransmits on the new router, does it use the same seq number? If so, how does the router/AAA server distinguish whether this is a replay attack or not? Section 5.3: It seems here that the AAA-Local must perform the key decapsulation and distribution to ARs in a roaming scenario, because it is not realistic to expect the AAA-Home to have security associations with all the ARs in a roaming partner's access network. Perhaps this could be made more clear. Section 6.2, Replay Protection, last sentence: Shouldn't this be the HMK? Section 6.2, Denial of Service, second paragraph: I am not a big fan of puzzles, because their effectiveness depends on the attacker co-operating and actually trying to solve the puzzle. A dedicated attacker will simply pump packets out at the victim, and ignore a puzzle response. This is especially an issue with DDoS, where the attacking nodes are only loosely co-ordinated and the effectivenes depends on volume. Section 6.2, Fragmentation: This statement is highly dependent on the radio layer frame size. For a small enough frame size, fragementation could still be an issue. Appendix D: Some of these suggestions involve having the ARs perform key distribution. Since the ARs are not authenticated directly to the MN, this may compromise security. Appendix E: It is heartening to see the use of formal methods for the security proof, but in the absence of a deep study of the specific syntax of the method used, I wonder how useful this section is to a reader. Also, there seem to have been some simplifications of the protocol done for the analysis. How realistic is the result as a consequence? _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 06 19:10:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqJ28-0002kJ-Bu; Wed, 06 Jul 2005 19:10:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqJ26-0002el-5E for mobopts@megatron.ietf.org; Wed, 06 Jul 2005 19:10:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13262 for ; Wed, 6 Jul 2005 19:10:19 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqJTA-0004nQ-6P for mobopts@irtf.org; Wed, 06 Jul 2005 19:38:20 -0400 Message-ID: <0b4801c58280$112fd7a0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "gabriel montenegro" , , , , References: <20050706222637.29798.qmail@web81912.mail.mud.yahoo.com> Date: Wed, 6 Jul 2005 16:11:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: margaret@thingmagic.com, rajeev@iprg.nokia.com, Basavaraj.Patil@nokia.com Subject: [Mobopts] Re: Interest in protocols for IEEE 802.21 IS, CS, ES X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Some of the things on Mike's list, like link triggers, are DNA items. We had discussed doing the InfoElements work in Mipshop prior to the MIHEP BOF discussion coming up. So now I'm completely confused what is happening, which is why I suggested the BAR BOF. Margaret, can you help us figure this out? Has the MIHEP BOF been approved? jak ----- Original Message ----- From: "gabriel montenegro" To: "James Kempf" ; ; ; ; Cc: ; ; ; Sent: Wednesday, July 06, 2005 3:26 PM Subject: Re: Interest in protocols for IEEE 802.21 IS, CS, ES > > Isn't this the subject for the proposed MIHEP BoF? What's the latest word, > is it being scheduled? Some of this discussion is quite relevant to > the MIPSHOP meeting, and the 802.21 folks are already on that agenda. > > But I agree that this is an important discussion. If the MIHEP BoF does not get > scheduled, we should have a bar BoF on the subject. > > -gabriel > > --- James Kempf wrote: > > > Mike, > > > > Would you like to get a BAR BOF-style meeting at IETF set up to discuss > > this? With the help of an AD or IAB member, I think we could get a room > > reserved for that purpose. > > > > jak > > > > ----- Original Message ----- > > From: > > To: ; ; > > Cc: ; ; > > ; ; > > ; > > Sent: Wednesday, July 06, 2005 3:02 PM > > Subject: Interest in protocols for IEEE 802.21 IS, CS, ES > > > > > > Colleagues, > > > > The IEEE 802.21 working group is developing services for facilitating IP > > address mobility and service mobility, especially handoff across a > > variety of media. The group is interested in working with the relevant > > IETF/IRTF working groups to develop methods of carrying these services > > across the network. It would be ideal to discuss this at the next IETF > > meeting. > > > > There are multiple drafts currently issued or in development that are > > interesting and could serve as the basis for starting the work. > > > > Drafts of interest include but are not limited to : > > > > "Neighborhood Information Elements Discovery (NED) > > (draft-kempf-mobopts-nhood-discovery-00.txt), which provides a generic > > protocol for carrying information elements of interest to IEEE 802.21." > > > > "Some Requirements for a Media Independent Handover Information Service" > > (draft-faccin-mih-infoserv-00.txt, > > http://www.ctie.monash.edu.au/dna/draft-faccin-mih-infoserv-00.txt > > ). > > > > "Architectural Implications of Link Indications" > > http://www.iab.org/documents/drafts/draft-iab-link-indications-01.txt > > > > > > > > "Unified L2 Abstractions for L3-Driven Fast Handover" > > http://www.ietf.org/internet-drafts/draft-koki-mobopts-l2-abstractions-0 > > 2.txt > > > > "A Framework of Media-Independent Pre-Authentication (MPA)" > > http://www.ietf.org/internet-drafts/draft-ohba-mobopts-mpa-framework-00. > > txt > > > > Best Regards, > > Michael G. Williams > > IEEE 802.21 Working Group Vice Chair > > > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Jul 08 12:03:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqvKT-0000fi-33; Fri, 08 Jul 2005 12:03:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqvKR-0000fV-Tf for mobopts@megatron.ietf.org; Fri, 08 Jul 2005 12:03:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23930 for ; Fri, 8 Jul 2005 12:03:49 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqvlq-0002y1-OX for mobopts@irtf.org; Fri, 08 Jul 2005 12:32:12 -0400 Message-ID: <105001c583d6$ce2e0690$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Date: Fri, 8 Jul 2005 09:05:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: mobopts@irtf.org Subject: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Folks, I've posted the Neighborhood Discovery draft by Rajeev and myself to the Internet Drafts directory. Until it is available, you can find it here: http://www.geocities.com/kempf42/draft-kempf-mipshop-nhood-discovery-00.txt This is the same draft as I previously posted for Mobopts, except I changed the filename to reflect the fact that this topic is now going to be discussed in MIPSHOP (I think, discussion is still ongoing). This draft is intended to partially fufill the IEEE 802.21 requirement for network information discovery. Please send comments if you have any. jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jul 11 06:39:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrvhS-0007u9-Ej; Mon, 11 Jul 2005 06:39:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrvhQ-0007ty-IG for mobopts@megatron.ietf.org; Mon, 11 Jul 2005 06:39:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28533 for ; Mon, 11 Jul 2005 06:39:41 -0400 (EDT) Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Drw9O-00007e-TW for mobopts@irtf.org; Mon, 11 Jul 2005 07:08:39 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 077DB8083; Mon, 11 Jul 2005 12:39:10 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.50) id 1Drvf6-0001Hl-Pg; Mon, 11 Jul 2005 12:37:20 +0200 Date: Mon, 11 Jul 2005 12:37:20 +0200 From: Julien Bournelle To: James Kempf Message-ID: <20050711103720.GA4932@ipv6-3.int-evry.fr> References: <1B631E11D496D711BB2800065BFCB6A11B7A71AF@il02exm13> <0b2201c5827f$250a0bc0$016115ac@dcml.docomolabsusa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0b2201c5827f$250a0bc0$016115ac@dcml.docomolabsusa.com> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 2.4 (++) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, "'Tschofenig, Hannes'" , Venkitaraman Narayanan-CNV002 , mobopts@irtf.org Subject: [Mobopts] Re: Review of draft-vidya-mipshop-handover-keys-aaa-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi james, thanks for your comments, I answer here to your basic architectural comment. On Wed, Jul 06, 2005 at 04:05:04PM -0700, James Kempf wrote: > All and all, an interesting document . Comments below. > > jak > > --------------------- > > Basic Architectural Comment: > > I got the feeling while reading through this that the authors decided for > some reason to keep the base protocol completely decoupled from any > dependence upon network access authentication. If so, I wonder why? In > essence, the basic architectural function this protocol is trying to > accomplish is to derive and distribute another set of keys as part of the > host to access network AAA association, and therefore it would seem to have > a natural dependence on the access network authentication protocol. The > result was kind of unsatisfying, as it left the protocol somewhat ungrounded > and lacking a concrete connection with a straightforward path toward > implementation and deployment, when, in fact, one of the stated reasons for > doing an AAA-based protocol in the first place was to make implementation > and deployment simpler by leveraging off of the existing AAA infrastructure. > > For example, since the protocol description in Section 3 does not mention an > encryption security association between the AAA server and the MN, the nonce > sent by the AAA server to the MN seems to be sent in the clear, which gives > an eavesdropper one piece of information that it could use in some fashion > to compromise. If you read further (in particular into the Appendix) you see > that, in fact, EAP can be used for this transaction, and so one of the EAP > methods that support secure MN-AAA server communication could be used to > maintain confidentiality on this transaction (though the document provides > no details on what the EAP extension is). But if EAP isn't used, then what? > > My (somewhat radical) suggestion to the authors would be to redesign the > protocol to couple it tightly with EAP-based network access authentication > protocol. This would mean: > > - Incorporating the derivation of the HMK from the EAP key > hiearchy which is now in Appendix A into the protocol directly > - Using EAP within the network access authentication transaction > to exchange parameters to derive the HMK, by defining an EAP extension for > one of the extensible EAP methods. This will ensure that the transaction > between the MN and AAA server is properly confidential, protecting MN > anonymity and the parameters of the key derivation > - Instead of defining a separate protocol for preauthentication > and reauthentication upon handover (Section 4), couple the derivation of new > HKs via preauthentication or reauthentication on handover to PANA pre- and > reauthentication. This will allow the protocol to leverage off of the PANA > work, so that the deep thinking about how to get pre- and reauthentication > on handover right only needs to be done once, for PANA (where it needs to be > done anyway). > > Incidently, if one of the reasons why this protocol was decoupled from > network access authentication was to allow IEEE 802.1x or other Layer 2 > protocols to be used, then this needs some rethinking. EAP is used in 802.1x > anyway so it could still be used for the initial HMK derivation. And the > 802.1x reauthentication isn't going to be useful for handover key > reauthentication, because it only deals with APs, which are layer 2 devices, > whereas this protocol must deal with ARs, which are layer 3 devices, so PANA > is probably the right vehicle. You raise an interesting issue here. Basically, we have 2 options to define a solution based on AAA: 1/ Integrate the solution to network access authentication as you propose. This imply two things: first we'll need an interface between the authenticator (NAS) and AR and second we'll need to add a mechanism to know wether or not the MN wants some keying material for FMIPv6 and to add a way to derive and carry the keying material. This mechanism could be add either at the EAP layer (implying to modify some EAP methods such as it is done in draft-giaretta-mipv6-eap-authorization-02.txt) or at layers carrying EAP packets (EAP lower-layer + AAA). In the latter case, it implies some modifications to both protocols (EAP lower -layer e.g. PANA and the AAA protocol). 2/ Define a decoupled solution as we currently propose. It is more or less what has been done for Mobile IPv4 (cf. draft-ietf-aaa-diameter-mobileip-20.txt). This solution can be used in more environments (even if http-based redirect authentication is used) but is maybe less efficient. At the moment, we have chosen the second option. However, I think that it is an interesting discussion to have. Julien > > Detailed Editorial and Technical Comments: > > Section 3, paragraph 2: This paragraph seems to be specifying use of the HMK > for calculating a MAC. It might be a good idea to keep the HMK private, and > use a derived key for this purpose, to avoid exposing material calculated > with the HMK to attackers. > Section 3, paragraph 2: As mentioned above, the nounce looks to be sent in > the clear. Might be better from a confidentiality standpoint to encrypt. > Similarly for the NAI. > > Section 3, paragraph 4 and 6: What is PRF here? > > Section 3.1, paragraph 2: Note that if the nounce is encrypted, it need only > be exchanged once, during the initial HMK derivation. After that, fresh > nounces can be derived by forward hashing from the original. Alternatively, > the AAA server and MN can generate a hash chain and move backward (at the > expense of having to store the hashes). This eliminates the need to send a > hash out over the air each time a reauthentication is performed. The AAA > server can push the appropriate nounce to the AR. > > Section 3.1: It is unclear to me how the MN manages keys generated by > preauthentication. Essentially, the MN is setting up soft state in the > network that it must manage. Yet, the specification only briefly mentions > key lifetimes, and does not specify any suggested defaults, nor how the AR > knows what the lifetime of the key should be. > > Section 4.1, v Flag - Is the MN sharing a key with itself here? > > Section 4.1, Seq. number - What if the message is retransmitted on a new AR? > Should the MN use the same Seq. number or new? > > Section 5.1: This section seemed to be saying that the MN needs a key on the > new AR when it hands over before it can do the FMIP signaling, is that > correct? If so, I'd like to know why? The primary security issue in FMIP is > not security with the new AR, but security with the old AR. The old AR is > being asked by the FBU to change routing for the old CoA (i.e. set up a > tunnel from the old CoA to the new), and for that purpose, it must have some > indication that the entity sending the FBU is authorized to claim the CoA. > The new AR gets the FNA which is typically piggybacked on the FBU, but that > needs to be secured using IP address configuration security, and it can even > be eliminated entirely if the MN used oDAD since its only purpose is to > allow the AR to confirm whether the address is not a duplicate. For example, > if the new CoA is autoconfigured, then RFC 3971 and 3972 can be used to > secure the address. If the address in DHCP configured, other mechanisms are > to be used. Or are the authors intending here to define a new way of > performing IP address configuration security? > > With this comment in mind, I fail to see the urgency of having to perform > the key exchange with surrounding routers immediately coupled to the > handover signaling. The issue becomes ensuring the MN has a key on the > router it currently is, so that when it hands over it can properly change > routing. For that purpose, the MN may want to perform preauthentication in > order to avoid having to establish the key once it moves to the new router, > but there is no need to couple preauthentication tightly to the handover. > > Section 5.1, paragraph 5: The last sentence is somewhat gratuitous and can > be dropped. > > Section 5.2, paragraph 1: Pick whether to include the Alt CoA or not. Why > have two choices here? > > Section 5.2, paragraph 2: If the MN retransmits on the new router, does it > use the same seq number? If so, how does the router/AAA server distinguish > whether this is a replay attack or not? > > Section 5.3: It seems here that the AAA-Local must perform the key > decapsulation and distribution to ARs in a roaming scenario, because it is > not realistic to expect the AAA-Home to have security associations with all > the ARs in a roaming partner's access network. Perhaps this could be made > more clear. > > Section 6.2, Replay Protection, last sentence: Shouldn't this be the HMK? > > Section 6.2, Denial of Service, second paragraph: I am not a big fan of > puzzles, because their effectiveness depends on the attacker co-operating > and actually trying to solve the puzzle. A dedicated attacker will simply > pump packets out at the victim, and ignore a puzzle response. This is > especially an issue with DDoS, where the attacking nodes are only loosely > co-ordinated and the effectivenes depends on volume. > > Section 6.2, Fragmentation: This statement is highly dependent on the radio > layer frame size. For a small enough frame size, fragementation could still > be an issue. > > Appendix D: Some of these suggestions involve having the ARs perform key > distribution. Since the ARs are not authenticated directly to the MN, this > may compromise security. > > Appendix E: It is heartening to see the use of formal methods for the > security proof, but in the absence of a deep study of the specific syntax of > the method used, I wonder how useful this section is to a reader. Also, > there seem to have been some simplifications of the protocol done for the > analysis. How realistic is the result as a consequence? > > > > > > -- julien.bournelle at int-evry.fr _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jul 11 15:32:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds40w-0001hc-GN; Mon, 11 Jul 2005 15:32:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds40u-0001hX-Ud for mobopts@megatron.ietf.org; Mon, 11 Jul 2005 15:32:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14489 for ; Mon, 11 Jul 2005 15:32:22 -0400 (EDT) Received: from havana.ucdavis.edu ([169.237.104.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds4Sx-0005u8-9X for mobopts@irtf.org; Mon, 11 Jul 2005 16:01:24 -0400 Received: from phaenicia.ucdavis.edu (phaenicia.ucdavis.edu [169.237.104.170]) by havana.ucdavis.edu (8.13.3/8.13.1/it-defang-5.4.0) with ESMTP id j6BJWFOo001075; Mon, 11 Jul 2005 12:32:15 -0700 (PDT) Received: from phaenicia.ucdavis.edu (localhost [127.0.0.1]) by phaenicia.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j6BJWE10021352; Mon, 11 Jul 2005 12:32:14 -0700 (PDT) Received: (from www@localhost) by phaenicia.ucdavis.edu (8.12.10/8.12.9/Submit) id j6BJWE1v021346; Mon, 11 Jul 2005 12:32:14 -0700 (PDT) Date: Mon, 11 Jul 2005 12:32:14 -0700 (PDT) Message-Id: <200507111932.j6BJWE1v021346@phaenicia.ucdavis.edu> To: mobopts@irtf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.156 X-Spam-Score: 2.4 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: rajeev@iprg.nokia.com Subject: [Mobopts] Re: Meeting in Paris X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Dear Rajeev, We have submitted a draft about RR test improvement and we would like to request a time slot: 1. Title: Improvement on Security and Performance of MIP6 Return Routability Test (draft-zhao-mobopts-rr-ext-00) 2. Time: 15 min 3. Summary: In this draft, we propose several extensions to improve the security and performance of MIP6 Return Routability test. Our proposal enables CN and MN to promptly and reliably detect the on-path attack and reduce the signaling overhead in a secure, efficient and back-compatible way. The core idea is to use hash chain to replace home test procedure in some circumstances and we carefully integrate hash chain into original MIP6 RR test without introducing new vulnerabilities. Although it does slightly increase the management cost of CN, we show that the extended RR test is more secure and more efficient than other approaches. Thank you very much. Sincerely, fan _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jul 11 18:33:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6pk-0003i0-D9; Mon, 11 Jul 2005 18:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6pi-0003fF-J4; Mon, 11 Jul 2005 18:33:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27059; Mon, 11 Jul 2005 18:32:59 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds7Hn-0005QE-4w; Mon, 11 Jul 2005 19:02:04 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6BM1Kn24594; Mon, 11 Jul 2005 15:01:20 -0700 X-mProtect: <200507112201> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14166.americas.nokia.com (172.18.141.66, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdnmdxxb; Mon, 11 Jul 2005 15:01:16 PDT Message-ID: <42D2F384.6050107@iprg.nokia.com> Date: Mon, 11 Jul 2005 15:32:36 -0700 From: Rajeev Koodli 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: mobopts@irtf.org, mip6@ietf.org Content-Type: multipart/mixed; boundary="------------040308060001000300010107" X-Spam-Score: 2.4 (++) X-Scan-Signature: 64b72a8e61417554b4b727cb14e7034d Cc: Subject: [Mobopts] [Fwd: FW: resubmit draft-irtf-mobopts-location-privacy-ps-00.txt with revised boilerplate] X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org This is a multi-part message in MIME format. --------------040308060001000300010107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello folks, I submitted the draft on Friday, I believe with the correct boilerplate (see attached draft). I still got an error message. Anyway, please find the Location Privacy Problem Statement draft. Regards, -Rajeev > -----Original Message----- > From: Koodli Rajeev (Nokia-NRC/MtView) > Sent: Friday, July 08, 2005 7:42 PM > To: 'internet-drafts@ietf.org' > Subject: resubmit draft-irtf-mobopts-location-privacy-ps-00.txt with revised boilerplate > > > Here it is.. > > Thanks, > > -Rajeev Koodli > > > <> > > http://people.nokia.net/~rajeev > --------------040308060001000300010107 Content-Type: text/plain; name="draft-irtf-mobopts-location-privacy-ps-00.txt" Content-Disposition: inline; filename="draft-irtf-mobopts-location-privacy-ps-00.txt" Content-Transfer-Encoding: 7bit MobOpts Research Group Rajeev Koodli INTERNET DRAFT Nokia Research Center 11 July 2005 IP Address Location Privacy and Mobile IPv6: Problem Statement draft-irtf-mobopts-location-privacy-ps-00.txt By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is a submission of the IRTF MobOpts RG. Comments should be directed to the MobOpts RG mailing list, mobopts@irtf.org. Abstract In this document, we discuss Location Privacy as applicable to Mobile IPv6. We document the concerns arising from revealing Home Address to an on-looker and from disclosing Care of Address to a correspondent. Koodli Expires 11 January 2005 [Page i] Internet Draft IP Location Privacy Problem 11 July 2005 Contents Abstract i 1. Introduction 1 2. Problem Definition 2 2.1. Disclosing the Care of Address . . . . . . . . . . . . . 2 2.2. Revealing the Home Address . . . . . . . . . . . . . . . 2 3. Problem Illustration 3 4. Conclusion 4 5. IANA Considerations 5 6. Security Considerations 5 7. Acknowledgment 5 A. Background 5 Intellectual Property Statement 6 Disclaimer of Validity 6 Copyright Statement 6 Acknowledgment 7 1. Introduction The problems of location privacy, and privacy when using IP for communication have become important. IP privacy is broadly concerned with protecting user communication from unwittingly revealing information that could be used to analyze and gather sensitive user data. Examples include gathering data at certain vantage points, collecting information related to specific traffic, and monitoring (perhaps) certain populations of users for activity during specific times of the day, etc. In this document, we refer to this as the "profiling" problem. Location privacy is concerned with the problem of revealing user roaming. A constant identifier with global scope can reveal that a user has roamed. The globally visible identifier could be a user Koodli Expires 11 January 2005 [Page 1] Internet Draft IP Location Privacy Problem 11 July 2005 identifier or a device identifier, and sometimes a binding between the two may also be available, e.g., through DNS. This problem is particularly applicable to Mobile IP where the Home Address on a visited network can reveal device roaming and, together with a user identifier (such as an NAI), can reveal user roaming. When roaming is revealed, it could lead to more targetted profiling. Even when the binding between user identifier and the Home Address is unavailable, freely available tools on the Internet can map the Home Address to the owner of the Home Prefix, which can reveal that a user from a particular ISP has roamed. So, the location privacy problem is a subset of the profiling problem in which revealing a globally visible identifier compromises a user's location privacy. In addition, a user may not wish to reveal roaming to correspondent(s). In Mobile IP, this translates to the use of Care of Address. In this document, the concerns arising from the use of a globally visible identifier, such as a Home Address, when roaming outside the home network are described. Similarly, the concerns from revealing a Care of Address to a correspondent are also outlined. The solutions to these problems are meant to be specified in a separate document. This document is only concerned with IP Address Location Privacy in the presence of IP Mobility, as applied to Mobile IPv6. It does not address the overall profiling problem. Specifically, it does not concern itself with MAC addresses. Some other work may address the problem of profiling IP and MAC identifiers (see for instance [1]). 2. Problem Definition 2.1. Disclosing the Care of Address When a Mobile IP MN roams from its home network to a visited network, use of Care of Address in communication with a correspondent reveals that the MN has roamed. The assumption here is that the correspondent somehow knows the Home Address of the MN. For instance, a correspondent may obtain it from DNS, which may contain the Home Address or the IP address of an agent to which the user identifier (such as a SIP URI) is mapped to. 2.2. Revealing the Home Address When a Mobile IP MN roams from its home network to a visited network, use of Home Address in communication with a correspondent reveals to an on-looker that the MN has roamed. When a binding of Home Address to a user identifier (such as a SIP URI or NAI) is available, the Home Address can be used to also determine that the user has roamed. This problem is independent of whether the MN uses Care of Address to communicate directly with the correspondent (i.e., uses route Koodli Expires 11 January 2005 [Page 2] Internet Draft IP Location Privacy Problem 11 July 2005 optimization), or the MN communicates via the Home Agent (i.e., uses reverse tunneling). 3. Problem Illustration This section is intended to provide the overall scope under which the above problems are applicable. Consider a Mobile Node at its home network. Whenever it is involved in IP communication, its correspondents can see an IP address valid on the home network. Elaborating further, the users involved in peer - peer communication are likely to see a user-friendly identifier such as a SIP URI, and the communication end-points in the IP stack will see IP addresses. Users uninterested in or unaware of IP communication details will not see any difference when the MN acquires a new IP address. Of course any user can ``tcpdump'' or ``ethereal'' a session, capture IP packets and map the MN's IP address to an approximate geo-location. When this mapping reveals a ``home location'' of the user, the correspondent can conclude that the user has not roamed. Assessing the physical location based on IP addresses is similar to assessing the geographical location based on the area-code of a telephone number. The granularity of the physical area corresponding to an IP address can vary depending on how sophisticated the available tools are, how often an ISP conducts its network re-numbering, etc. Now consider that the MN roams to a new IP network, acquires a Care of Address and would like to communicate with its correspondents. It can either communicate directly or reverse tunnel its packets through the Home Agent. Using reverse tunneling does not reveal the new IP address of the MN, although performance may vary depending on the particular scenario. In some instances, the performance difference could be noticeable enough to serve as a hint to the correspondent. With those correspondents with which it can disclose its new IP address ``on the wire'', the MN has the option of using route-optimized communication. The transport protocol still sees the Home Address with route optimization. Unless the correspondent runs some packet capturing utility, the user cannot see which mode (reverse tunneling or route optimization) is being used, but knows that it is communicating with the same peer whose URI it knows. This is similar to conversing with a roaming cellphone user whose phone number, like the URI, remains unchanged. Let us consider the roaming mobile node again. Regardless of whether it uses route optimization or reverse tunneling, its Home Address is revealed in data packets. When equipped with an ability to inspect packets ``on the wire'', an on-looker can determine that the MN has roamed and could possibly also determine that the user has roamed. Koodli Expires 11 January 2005 [Page 3] Internet Draft IP Location Privacy Problem 11 July 2005 This could compromise the location privacy even if the MN took steps to hide its roaming information from a correspondent. The above description is valid regardless of whether a Home Address is static or is dynamically allocated. In either case, the mapping of IP address to geo-location will most likely yield results with the same level of granularity. With the freely available tools on the Internet, this granularity is the physical address of the ISP or the organization which registers ownership of a prefix chunk. Since an ISP or an organization is not, rightly, required to provide a blue-print of its subnets, the granularity remains fairly coarse for a mobile wireless network. However, sophisticated attackers might be able to conduct site mapping and obtain more fine-grained subnet information. A compromise in location privacy could lead to more targetted profiling of user data. An eavesdropper may specifically track the traffic containing the Home Address, and monitor the movement of the Mobile Node with changing Care of Address. The profiling problem is not specific to Mobile IPv6, but could be triggered by a compromise in location privacy due to revealing the Home Address. A correspondent may take advantage of the knowledge that a user has roamed when Care of Address is revealed, and modulate actions based on such a knowledge. Such an information could cause concern to a mobile user especially when the correspondent turns out be untrustworthy. Finally, it is also worthwhile to note that both the Home Address and the Care of Address could be subject to profiling, just as any other user traffic. However, applying existing techniques to thwart profiling may have implications to Mobile IPv6 signaling performance. For instance, changing the Care of Address often would cause additional Return Routability and binding management signaling. And, changing the Home Address often has implications on IPSec security association management. These issues need to be addressed in the solutions. 4. Conclusion In this document, we have formulated the IP Location Privacy problem in the presence of Mobile IPv6. The problem can be summarized as follows: disclosing Care of Address to a correspondent and revealing Home Address to an on-looker can compromise the location privacy of a Mobile Node, and hence that of a user. Solutions to this problem are expected to specifically address the use of Mobile IPv6 addresses, and not other identifiers (such as MAC addresses). Koodli Expires 11 January 2005 [Page 4] Internet Draft IP Location Privacy Problem 11 July 2005 5. IANA Considerations There are no IANA considerations introduced by this draft. 6. Security Considerations This document discusses location privacy because of IP mobility. Solutions to provide location privacy, especially any signaling over the Internet, must be secure in order to be effective. Individual solutions must describe the security implications. 7. Acknowledgment James Kempf and Qiu Ying reviewed an earlier version and provided feedback. References [1] W. Haddad and et al. Privacy for Mobile and Multi-homed Nodes: MoMiPriv Problem Statement (work in progress). Internet Draft, Internet Engineering Task Force, October 2004. [2] J. Polk, J. Schnizlein, and M. Linsner. DHCP Option for Coordinate-based Location Configuration Information. Request for Comments 3825, Internet Engineering Task Force, July 2004. A. Background The location privacy topic is broad and often has different connotations. It also spans multiple layers in the OSI reference model. Besides, there are attributes beyond an IP address alone that can reveal hints about location. For instance, even if a correspondent is communicating with the same end-point it is used to, the ``time of the day'' attribute can reveal a hint to the user. Some roaming cellphone users may have noticed that their SMS messages carry a timestamp of their ``home network'' timezone (for location privacy or otherwise) which can reveal that the user is in a different timezone when messages are sent during ``normal'' time of the day. Furthermore, tools exist on the Internet which can map an IP address to the physical address of an ISP or the organization which owns the prefix chunk. Taking this to another step, with in-built GPS receivers on IP hosts, applications can be devised to map geo-locations to IP network information. Even without GPS receivers, geo-location can also be obtained in environments where [Geopriv] is supported, for instance as a DHCP option [2]. Koodli Expires 11 January 2005 [Page 5] Internet Draft IP Location Privacy Problem 11 July 2005 In summary, a user's physical location can be determined or guessed with some certainty and with varying levels of granularity by different means even though IP addresses themselves do not inherently provide any geo-location information. It is perhaps useful to bear this broad scope in mind as the problem of IP address location privacy in the presence of IP Mobility is addressed. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Koodli Expires 11 January 2005 [Page 6] Internet Draft IP Location Privacy Problem 11 July 2005 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Koodli Expires 11 January 2005 [Page 7] --------------040308060001000300010107 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --------------040308060001000300010107-- From mobopts-bounces@irtf.org Mon Jul 11 18:49:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds75K-0001IQ-HE; Mon, 11 Jul 2005 18:49:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds75J-0001F7-3Y for mobopts@megatron.ietf.org; Mon, 11 Jul 2005 18:49:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28212 for ; Mon, 11 Jul 2005 18:49:03 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds7XL-0005uX-Dl for mobopts@irtf.org; Mon, 11 Jul 2005 19:18:07 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6BMHPb09316 for ; Mon, 11 Jul 2005 15:17:25 -0700 X-mProtect: <200507112217> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14166.americas.nokia.com (172.18.141.66, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdUglMcA; Mon, 11 Jul 2005 15:17:23 PDT Message-ID: <42D2F74B.7040908@iprg.nokia.com> Date: Mon, 11 Jul 2005 15:48:43 -0700 From: Rajeev Koodli 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: mobopts@irtf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Subject: [Mobopts] New topics for the RG X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1848779144==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org This is a multi-part message in MIME format. --===============1848779144== Content-Type: multipart/alternative; boundary="------------060201050206030108070001" This is a multi-part message in MIME format. --------------060201050206030108070001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello folks, we have covered some topics in the RG for a while now. In fact, some of the documents we have produced are ready or nearly ready for IETF working groups to take on. Specifically, o the RO enhancements document has got very good reviews and will be revised o the security association establishment for handovers is now in the hands of MIPSHOP. One of the RG documents is a potential solution candidate. o we have had multiple discussions on using, enhancing FMIP. o context transfers has been discussed, especially in the context of PANA, and I believe there will be a document of some sort. o there has been discussion about L2 triggers and their implementation for handovers. I hope we will be able to wrap up a document. If I missed anything, please do list. So, I guess it's okay to say we have had some useful work done Now, it is time to re-consider our charter items. What sorts of topics are folks interested in working on? I would like to broaden our scope to consider Mobility on the Internet in general. Some possible topics for discussion below in no preference order. Please comment, suggest your topics and provide a brief justification. - multicast and mobility. A specific problem is what address should the MN use as its source IP address so that its packets are not discarded due to a) RPF checks, and b) source-specific multicast. To pass a), you need the MN to use CoA, but to pass b), you need HoA. How to convice multiple receivers about CoA and HoA binding? Is RR even an option? :-) - mobility (and traffic) patterns in a WLAN (e.g., a campus network). This should provide a better sense of traffic for admission control as well as network-controlled handovers. - what is the scope of IP paging in a converged WLAN - WWAN environment? Is it a real problem? Worthwhile documenting in any case? - architectural barriers to optimizing inter-domain handovers. Although we have some understanding of improving delay and packet loss during handovers across IP networks, how applicable are they across different autonomous systems? Would the policy barriers allow optimizations? Is this an example of "tussle in cyberspace"? - privacy topics related to mobility - Others -Rajeev --------------060201050206030108070001 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Hello folks,

we have covered some topics in the RG for a while now. In fact,
some of the documents we have produced are ready or nearly ready
for IETF working groups to take on. Specifically,

o the RO enhancements document has got very good reviews and will
   be revised
o the security association establishment for handovers is now in the
   hands of MIPSHOP. One of the RG documents is a potential solution
   candidate.
o  we have had multiple discussions on using, enhancing FMIP.
o context transfers has been discussed, especially in the context of PANA,
   and I believe there will be a document of some sort.
o there has been discussion about L2 triggers and their implementation for
   handovers. I hope we will be able to wrap up a document.

If I missed anything, please do list.

So, I guess it's okay to say we have had some useful work done

Now, it is time to re-consider our charter items. What sorts of topics
are folks interested in working on?  I would like to broaden our scope to
consider Mobility on the Internet in general. Some possible topics for
discussion below in no preference order. Please comment, suggest your
topics and provide a brief justification.

- multicast and mobility. A specific problem is what address should the MN
  use as its source IP address so that its packets are not discarded due to a) RPF checks,
  and b) source-specific multicast. To pass a), you need the MN to use CoA, but to
  pass b), you need HoA. How to convice multiple receivers about CoA and HoA binding?
  Is RR even an option? :-)

- mobility (and traffic) patterns in a WLAN (e.g., a campus network). This should provide
  a better sense of traffic for admission control as well as network-controlled handovers.
 
- what is the scope of IP paging in a converged WLAN - WWAN environment?
  Is it a real problem? Worthwhile documenting in any case?

- architectural barriers to optimizing inter-domain handovers. Although we have
   some understanding of improving delay and packet loss during handovers across
   IP networks, how applicable are they across different autonomous systems? Would
   the policy barriers allow optimizations? Is this an example of "tussle in cyberspace"?
  
- privacy topics related to mobility

- Others

-Rajeev


--------------060201050206030108070001-- --===============1848779144== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============1848779144==-- From mobopts-bounces@irtf.org Mon Jul 11 21:19:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds9QY-0003xU-Hu; Mon, 11 Jul 2005 21:19:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds9QX-0003xP-GL for mobopts@megatron.ietf.org; Mon, 11 Jul 2005 21:19:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13511 for ; Mon, 11 Jul 2005 21:19:11 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds9sd-0004Oq-BL for mobopts@irtf.org; Mon, 11 Jul 2005 21:48:16 -0400 Received: from jurassic.eng.sun.com ([129.146.68.36]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j6C1JAIi001561; Mon, 11 Jul 2005 18:19:10 -0700 (PDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with SMTP id j6C1JAIF710653; Mon, 11 Jul 2005 18:19:10 -0700 (PDT) Message-Id: <200507120119.j6C1JAIF710653@jurassic.eng.sun.com> Date: Mon, 11 Jul 2005 18:18:22 -0700 (PDT) From: Samita Chakrabarti Subject: Re: [Mobopts] New topics for the RG To: rajeev@iprg.nokia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: PzcKa5upxXnh8McXpG2V4g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 2.4 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi Rajeev, --- Now, it is time to re-consider our charter items. What sorts of topics are folks interested in working on? I would like to broaden our scope to consider Mobility on the Internet in general. Some possible topics for discussion below in no preference order. Please comment, suggest your topics and provide a brief justification. --- How about starting some discussion on LowPan mobility ? Currently 6Lowpan wg does not have mobility in the charter. Mobility in sensor networks is a research topic - though parts of it can be addressed by Manet protocols. I have published a draft recently to discuss the goals and requirements of lowpan mobility. Would like to see some discussion in mobopts irtg wg. draft-chakrabarti-mobopts-lowpan-req-00.txt Thanks, -Samita _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jul 11 22:36:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsAdF-0005BV-F4; Mon, 11 Jul 2005 22:36:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsAdE-0005BP-Ld for mobopts@megatron.ietf.org; Mon, 11 Jul 2005 22:36:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17323 for ; Mon, 11 Jul 2005 22:36:22 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsB5L-0006WK-4i for mobopts@irtf.org; Mon, 11 Jul 2005 23:05:28 -0400 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 11E614C13D for ; Tue, 12 Jul 2005 11:34:37 +0900 (JST) Date: Tue, 12 Jul 2005 11:35:48 +0900 From: Thierry Ernst To: mobopts@irtf.org Subject: Re: [Mobopts] New topics for the RG Message-Id: <20050712113548.73011654.ernst@sfc.wide.ad.jp> In-Reply-To: <200507120119.j6C1JAIF710653@jurassic.eng.sun.com> References: <200507120119.j6C1JAIF710653@jurassic.eng.sun.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org > Now, it is time to re-consider our charter items. What sorts of topics > are folks interested in working on? I would like to broaden our scope > to consider Mobility on the Internet in general. Some possible topics > for discussion below in no preference order. Please comment, suggest > your topics and provide a brief justification. > --- > > How about starting some discussion on LowPan mobility ? > Currently 6Lowpan wg does not have mobility in the charter. > Mobility in sensor networks is a research topic - though > parts of it can be addressed by Manet protocols. Well, once sensors are IP-enabled, NEMO is likely more appropriate than MANET, from a complexity point of view: - no need to manage mobiility: MR does everything - sensors may not be wireless nodes: MANET is pointless - MR can deals with security aspects on behalf of sensors Thierry > I have published a draft recently to discuss the goals and > requirements of lowpan mobility. Would like to see some > discussion in mobopts irtg wg. > draft-chakrabarti-mobopts-lowpan-req-00.txt _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jul 11 23:23:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsBMv-0003Sr-KO; Mon, 11 Jul 2005 23:23:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsBMt-0003Ol-Va for mobopts@megatron.ietf.org; Mon, 11 Jul 2005 23:23:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20638 for ; Mon, 11 Jul 2005 23:23:29 -0400 (EDT) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsBox-00082Y-Pu for mobopts@irtf.org; Mon, 11 Jul 2005 23:52:36 -0400 Received: from breeze.research.telcordia.com (breeze.research.telcordia.com [192.4.16.9]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id j6C3MlNL018388; Mon, 11 Jul 2005 23:22:47 -0400 (EDT) Received: from research.telcordia.com (localhost [127.0.0.1]) by breeze.research.telcordia.com (8.8.8/8.8.8) with ESMTP id XAA22396; Mon, 11 Jul 2005 23:22:47 -0400 (EDT) Message-Id: <200507120322.XAA22396@breeze.research.telcordia.com> To: Rajeev Koodli Subject: Re: [Mobopts] New topics for the RG In-reply-to: Your message of "Mon, 11 Jul 2005 15:48:43 PDT." <42D2F74B.7040908@iprg.nokia.com> Date: Mon, 11 Jul 2005 23:22:47 -0400 From: Ashutosh Dutta X-Spam-Score: 2.9 (++) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Rajeev, I think you have got a good list of items here. I think optimization for Multicast Mobility will be a useful area more so for SSM type. Mobility Optimization across heterogeneous networks (WLAN-WWAN) is another interesting area although it may overlap with MIHEP BOF to some extent. Optimization for Inter-domain mobility taking authentication, security into account is another interesting area. Thanks Ashutosh > - multicast and mobility. A specific problem is what address should the MN > use as its source IP address so that its packets are not discarded due > to a) RPF checks, > and b) source-specific multicast. To pass a), you need the MN to use > CoA, but to > pass b), you need HoA. How to convice multiple receivers about CoA and > HoA binding? > Is RR even an option? :-) > > - mobility (and traffic) patterns in a WLAN (e.g., a campus network). > This should provide > a better sense of traffic for admission control as well as network-controlled handovers. > > - what is the scope of IP paging in a converged WLAN - WWAN environment? > Is it a real problem? Worthwhile documenting in any case? > > - architectural barriers to optimizing inter-domain handovers. Although > we have > some understanding of improving delay and packet loss during > handovers across > IP networks, how applicable are they across different autonomous > systems? Would > the policy barriers allow optimizations? Is this an example of > "tussle in cyberspace"? > > - privacy topics related to mobility > > - Others > > -Rajeev > > > > --------------060201050206030108070001 > Content-Type: text/html; charset=us-ascii > Content-Transfer-Encoding: 7bit > > > > > > > > > > > > > > >
>
> Hello folks,
>
> we have covered some topics in the RG for a while now. In fact,
> some of the documents we have produced are ready or nearly ready
> for IETF working groups to take on. Specifically,
>
> o the RO enhancements document has got very good reviews and will
>    be revised
> o the security association establishment for handovers is now in the
>    hands of MIPSHOP. One of the RG documents is a potential solution
>    candidate.
> o  we have had multiple discussions on using, enhancing FMIP.
> o context transfers has been discussed, especially in the context of > PANA,
>    and I believe there will be a document of some sort.
> o there has been discussion about L2 triggers and their implementation > for
>    handovers. I hope we will be able to wrap up a document.
>
> If I missed anything, please do list.
>
> So, I guess it's okay to say we have had some useful work done
>
> Now, it is time to re-consider our charter items. What sorts of topics
> are folks interested in working on?  I would like to broaden our scope > to
> consider Mobility on the Internet in general. Some possible topics for
> discussion below in no preference order. Please comment, suggest your
> topics and provide a brief justification.
>
> - multicast and mobility. A specific problem is what address should the > MN
>   use as its source IP address so that its packets are not discarded > due to a) RPF checks,
>   and b) source-specific multicast. To pass a), you need the MN to use > CoA, but to
>   pass b), you need HoA. How to convice multiple receivers about CoA > and HoA binding?
>   Is RR even an option? :-)
>
> - mobility (and traffic) patterns in a WLAN (e.g., a campus network). > This should > provide
>   a better sense of traffic for admission control as well as > network-controlled handovers.
>   >
> - what is the scope of IP paging in a converged WLAN - WWAN > environment?
>   Is it a real problem? Worthwhile documenting in any case?
>
> - architectural barriers to optimizing inter-domain handovers. Although > we have
>    some understanding of improving delay and packet loss during > handovers across
>    IP networks, > how applicable are they across different autonomous systems? Would
>    the > policy barriers allow optimizations? Is this an example of "tussle in > cyberspace"?
>   
> - privacy topics related to mobility
>
> - Others
>
> -Rajeev
>
>
> > > > --------------060201050206030108070001-- > > > > --===============1848779144== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > > --===============1848779144==-- > > Ashutosh _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jul 11 23:50:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsBn5-0003hX-LT; Mon, 11 Jul 2005 23:50:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsBn4-0003h3-7H for mobopts@megatron.ietf.org; Mon, 11 Jul 2005 23:50:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22457 for ; Mon, 11 Jul 2005 23:50:35 -0400 (EDT) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsCFB-0000Yp-D3 for mobopts@irtf.org; Tue, 12 Jul 2005 00:19:42 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 248B28004AD; Tue, 12 Jul 2005 06:50:23 +0300 (EEST) Date: Tue, 12 Jul 2005 06:50:23 +0300 (EEST) From: Wassim Haddad To: Rajeev Koodli In-Reply-To: <42D2F384.6050107@iprg.nokia.com> Message-ID: References: <42D2F384.6050107@iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 2.4 (++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: mip6@ietf.org, mobopts@irtf.org Subject: [Mobopts] Re: [Mip6] [Fwd: FW: resubmit draft-irtf-mobopts-location-privacy-ps-00.txt with revised boilerplate] X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi Rajeev, Thanks for writing this draft. I just want to add that tracing the BU messages via the sequence number can also reveal in real time to an eavesdropper the path taken by an unknown mobile node, i.e., by linking the BU messages and consequently the pseudo-IP addresses. However, the ability to follow the movements in real time, combined with some prior infos about one particular target can lead to break the user's anonymity. IMHO, it makes sense to add such scenario in the problem statement. We have addressed this particular issue in our "anonymity and unlinkability solution for omipv6" (draft-haddad-privacy-omipv6-anonymity-00). Regards, Wassim H. On Mon, 11 Jul 2005, Rajeev Koodli wrote: > > Hello folks, > > I submitted the draft on Friday, I believe with the correct boilerplate > (see attached draft). I still got an error message. > > Anyway, please find the Location Privacy Problem Statement draft. > > Regards, > > -Rajeev > > > > -----Original Message----- > > > From: Koodli Rajeev (Nokia-NRC/MtView) > > Sent: Friday, July 08, 2005 7:42 PM > > To: 'internet-drafts@ietf.org' > > Subject: resubmit draft-irtf-mobopts-location-privacy-ps-00.txt with revised boilerplate > > > > > > Here it is.. > > > > Thanks, > > > > -Rajeev Koodli > > > > > <> > > > > http://people.nokia.net/~rajeev > > > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jul 12 02:30:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsEI7-00051a-GL; Tue, 12 Jul 2005 02:30:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsEI5-00051S-Op for mobopts@megatron.ietf.org; Tue, 12 Jul 2005 02:30:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22630 for ; Tue, 12 Jul 2005 02:30:48 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsEkD-0005C4-Kk for mobopts@irtf.org; Tue, 12 Jul 2005 02:59:55 -0400 Received: from ep_ms3_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJI001HL4QW4E@mailout3.samsung.com> for mobopts@irtf.org; Tue, 12 Jul 2005 15:30:32 +0900 (KST) Received: from ep_spt03 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJI00JK64QWUE@ms3.samsung.com> for mobopts@irtf.org; Tue, 12 Jul 2005 15:30:32 +0900 (KST) Content-return: prohibited Date: Tue, 12 Jul 2005 06:28:56 +0000 (GMT) From: Daniel Park Subject: Re: Re: [Mobopts] New topics for the RG To: Thierry Ernst Message-id: <0IJI00JK74QWUE@ms3.samsung.com> MIME-version: 1.0 X-Priority: 3 Msgkey: 20050712063014922@soohong.park X-MTR: 20050712063014922@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.17 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: "mobopts@irtf.org" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soohong.park@samsung.com List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0052823548==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org --===============0052823548== Content-return: prohibited Content-type: text/html; charset=windows-1252 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Samsung Enterprise Portal mySingle

(I think this thread should be moved into 6lowpan w.g., not mobopts)

 

>Well, once sensors are IP-enabled, NEMO is likely more appropriate than
>MANET, from a complexity point of view:
>- no need to manage mobiility: MR does everything 
>- sensors may not be wireless nodes: MANET is pointless
>- MR can deals with security aspects on behalf of sensors

 

Are you saying that NEMO protocols are be able to be applied for

6lowpan node which has very severe  limited code and resource ?

Or are you assuming any NEMO lightweight version ?

 

Regarding MANET protocol, it is already enabled on lowpan

network (802.15.4) such as ZigBee. Also, as far as I am

concern, 6lowpan does not have any NEMO issues.
 

 

Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics

 

 


--===============0052823548== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============0052823548==-- From mobopts-bounces@irtf.org Tue Jul 12 02:44:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsEVa-000064-FD; Tue, 12 Jul 2005 02:44:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsEVZ-00005z-Ik for mobopts@megatron.ietf.org; Tue, 12 Jul 2005 02:44:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23578 for ; Tue, 12 Jul 2005 02:44:44 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsExi-0005cn-Iz for mobopts@irtf.org; Tue, 12 Jul 2005 03:13:51 -0400 Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJI00GZE5E6J2@mailout2.samsung.com> for mobopts@irtf.org; Tue, 12 Jul 2005 15:44:30 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IJI00H0R5DWB4@mmp2.samsung.com> for mobopts@irtf.org; Tue, 12 Jul 2005 15:44:30 +0900 (KST) Date: Tue, 12 Jul 2005 12:10:55 +0530 From: Syam Madanapalli Subject: Re: Re: [Mobopts] New topics for the RG To: soohong.park@samsung.com, Thierry Ernst Message-id: <01f401c586ac$acefc9e0$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=Windows-1252; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <0IJI00JK74QWUE@ms3.samsung.com> X-Spam-Score: 2.4 (++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7BIT Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi Daniel, I think what Thierry has said is NEMO runs on a mobile router behind which the sensor devices are located. So Mobility is supported for the sensor devices without implementing the mobility protocols on memory constrained sensor devices. But I think there can be a wireless sensor devices which may need MANET support. -Syam ----- Original Message ----- From: "Daniel Park" To: "Thierry Ernst" Cc: Sent: Tuesday, July 12, 2005 11:58 AM Subject: Re: Re: [Mobopts] New topics for the RG > Samsung Enterprise Portal mySingle(I think this thread should be moved > into 6lowpan w.g., not mobopts) > > > >>Well, once sensors are IP-enabled, NEMO is likely more appropriate than >>MANET, from a complexity point of view: >>- no need to manage mobiility: MR does everything >>- sensors may not be wireless nodes: MANET is pointless >>- MR can deals with security aspects on behalf of sensors > > > > > Are you saying that NEMO protocols are be able to be applied for > > 6lowpan node which has very severe limited code and resource ? > > Or are you assuming any NEMO lightweight version ? > > > > Regarding MANET protocol, it is already enabled on lowpan > > network (802.15.4) such as ZigBee. Also, as far as I am > > concern, 6lowpan does not have any NEMO issues. > > > > > Regards > > > > Daniel (Soohong Daniel Park) > > Mobile Platform Laboratory. SAMSUNG Electronics > > > > > > -------------------------------------------------------------------------------- > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jul 12 03:04:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsEoY-0005kI-Rz; Tue, 12 Jul 2005 03:04:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsEoW-0005iM-FE for mobopts@megatron.ietf.org; Tue, 12 Jul 2005 03:04:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24529 for ; Tue, 12 Jul 2005 03:04:19 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsFGf-0006EZ-0y for mobopts@irtf.org; Tue, 12 Jul 2005 03:33:26 -0400 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 74D834CC51; Tue, 12 Jul 2005 16:02:34 +0900 (JST) Date: Tue, 12 Jul 2005 16:03:46 +0900 From: Thierry Ernst To: Syam Madanapalli Subject: Re: [Mobopts] New topics for the RG Message-Id: <20050712160346.2ef3a171.ernst@sfc.wide.ad.jp> In-Reply-To: <01f401c586ac$acefc9e0$59476c6b@sisodomain.com> References: <0IJI00JK74QWUE@ms3.samsung.com> <01f401c586ac$acefc9e0$59476c6b@sisodomain.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: soohong.park@samsung.com, mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org > I think what Thierry has said is NEMO runs on a mobile router behind > which the sensor devices are located. So Mobility is supported for the > sensor devices > without implementing the mobility protocols on memory constrained > sensor devices. Correct, this is what I meant. The scenario we consider is IPv6 sensors deployed in a vehicle. We do have such IPv6 sensors developped by WIDE, information is retrieved with SNMP, and electric supply is provided by a Hub. To answer Daniel's, any IPv6 node that complies to 6lowpan requirements can be put behind a NEMO-enabled mobile router, at not additional cost since the MR is doing all the mobility management. > But I think there can be a wireless sensor devices which may need > MANET support. Yes, this may be requested in such situations, but unless I'm mistaken running an ad-hoc routing protocol is more energy consumming that a simple IPv6 node behind a NEMO MR (from a sensor's point of view, not from the overall system's point of view since a MR is also consuming energy). Thierry > -Syam > > > ----- Original Message ----- > From: "Daniel Park" > To: "Thierry Ernst" > Cc: > Sent: Tuesday, July 12, 2005 11:58 AM > Subject: Re: Re: [Mobopts] New topics for the RG > > > > Samsung Enterprise Portal mySingle(I think this thread should be > > moved into 6lowpan w.g., not mobopts) > > > > > > > >>Well, once sensors are IP-enabled, NEMO is likely more appropriate > >than>MANET, from a complexity point of view: > >>- no need to manage mobiility: MR does everything > >>- sensors may not be wireless nodes: MANET is pointless > >>- MR can deals with security aspects on behalf of sensors > > > > > > > > > > Are you saying that NEMO protocols are be able to be applied for > > > > 6lowpan node which has very severe limited code and resource ? > > > > Or are you assuming any NEMO lightweight version ? > > > > > > > > Regarding MANET protocol, it is already enabled on lowpan > > > > network (802.15.4) such as ZigBee. Also, as far as I am > > > > concern, 6lowpan does not have any NEMO issues. > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jul 12 03:13:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsExE-0008Fi-O2; Tue, 12 Jul 2005 03:13:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsExA-0008FJ-2P for mobopts@megatron.ietf.org; Tue, 12 Jul 2005 03:13:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25269 for ; Tue, 12 Jul 2005 03:13:15 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsFPI-0006cA-Lk for mobopts@irtf.org; Tue, 12 Jul 2005 03:42:22 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 12 Jul 2005 09:13:03 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6C7CwDg012413; Tue, 12 Jul 2005 09:12:58 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 09:12:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Re: [Mobopts] New topics for the RG Date: Tue, 12 Jul 2005 09:12:51 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01141091@xmb-ams-337.emea.cisco.com> Thread-Topic: Re: [Mobopts] New topics for the RG Thread-Index: AcWGrX1nStgA/pVMQVCjTtPLQo/lMwAAlg1Q From: "Pascal Thubert \(pthubert\)" To: "Syam Madanapalli" , , "Thierry Ernst" X-OriginalArrivalTime: 12 Jul 2005 07:12:57.0665 (UTC) FILETIME=[21579B10:01C586B1] X-Spam-Score: 2.4 (++) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable Cc: manemo@mobileip.jp, mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Yes, we have scenarios like that in NEMO and NEMO-Route Optimization to enable the backhaul if the traffic from the sensors. The Sensors could be dumb IPv6 nodes and all the routing/backhaul would be handled by the mobile routers. MRs could be collocated with the sensors or flying drones gathering data. When MRs attach to other MRs to provide the service, we get into a hybrid case where NEMO and MANET could collaborate so that a specific instance of MANET is used to support Route Optimization for NEMO. And NEMO would transport the sensors data, back to the central office where they can be analyzed.=20 In fact, some of us created a mailing list around that issue and called it MANEMO, MANET for NEMO. The idea is to define the MANET that would best help NEMO considering the NEMO RO requirements. MANEMO did not have a BOF yet. Maybe in Canada for IETF 64? Pascal >-----Original Message----- >From: mobopts-bounces@irtf.org [mailto:mobopts-bounces@irtf.org] On Behalf >Of Syam Madanapalli >Sent: Tuesday, July 12, 2005 8:41 AM >To: soohong.park@samsung.com; Thierry Ernst >Cc: mobopts@irtf.org >Subject: Re: Re: [Mobopts] New topics for the RG > >Hi Daniel, > >I think what Thierry has said is NEMO runs on a mobile router behind which >the sensor devices are located. So Mobility is supported for the sensor >devices >without implementing the mobility protocols on memory constrained sensor >devices. > >But I think there can be a wireless sensor devices which may need MANET >support. > >-Syam > > >----- Original Message ----- >From: "Daniel Park" >To: "Thierry Ernst" >Cc: >Sent: Tuesday, July 12, 2005 11:58 AM >Subject: Re: Re: [Mobopts] New topics for the RG > > >> Samsung Enterprise Portal mySingle(I think this thread should be moved >> into 6lowpan w.g., not mobopts) >> >> >> >>>Well, once sensors are IP-enabled, NEMO is likely more appropriate than >>>MANET, from a complexity point of view: >>>- no need to manage mobiility: MR does everything >>>- sensors may not be wireless nodes: MANET is pointless >>>- MR can deals with security aspects on behalf of sensors >> >> >> >> >> Are you saying that NEMO protocols are be able to be applied for >> >> 6lowpan node which has very severe limited code and resource ? >> >> Or are you assuming any NEMO lightweight version ? >> >> >> >> Regarding MANET protocol, it is already enabled on lowpan >> >> network (802.15.4) such as ZigBee. Also, as far as I am >> >> concern, 6lowpan does not have any NEMO issues. >> >> >> >> >> Regards >> >> >> >> Daniel (Soohong Daniel Park) >> >> Mobile Platform Laboratory. SAMSUNG Electronics >> >> >> >> >> >> > > >----------------------------------------------------------------------- ---- >----- > > >> _______________________________________________ >> Mobopts mailing list >> Mobopts@irtf.org >> https://www1.ietf.org/mailman/listinfo/mobopts >> > > >_______________________________________________ >Mobopts mailing list >Mobopts@irtf.org >https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jul 12 03:55:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsFc9-0005fh-Su; Tue, 12 Jul 2005 03:55:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsFc8-0005fc-1Y for mobopts@megatron.ietf.org; Tue, 12 Jul 2005 03:55:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28644 for ; Tue, 12 Jul 2005 03:55:34 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsG4G-00006v-SF for mobopts@irtf.org; Tue, 12 Jul 2005 04:24:42 -0400 Received: from ep_ms3_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJI007CL8O7DZ@mailout3.samsung.com> for mobopts@irtf.org; Tue, 12 Jul 2005 16:55:19 +0900 (KST) Received: from ep_spt03 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJI001JP8O78C@ms3.samsung.com> for mobopts@irtf.org; Tue, 12 Jul 2005 16:55:19 +0900 (KST) Content-return: prohibited Date: Tue, 12 Jul 2005 07:53:42 +0000 (GMT) From: Daniel Park Subject: Re: RE: Re: [Mobopts] New topics for the RG To: "Pascal Thubert (pthubert)" Message-id: <0IJI001JQ8O78C@ms3.samsung.com> MIME-version: 1.0 X-Priority: 3 Msgkey: 20050712075501502@soohong.park X-MTR: 20050712075501502@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.17 X-Spam-Score: 3.8 (+++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "manemo@mobileip.jp" , "mobopts@irtf.org" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soohong.park@samsung.com List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0850061354==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org --===============0850061354== Content-return: prohibited Content-type: text/html; charset=windows-1252 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Samsung Enterprise Portal mySingle

Thierry, sorry for my misunderstanding...:-)

 

>The Sensors could be dumb IPv6 nodes and all the 

>routing/backhaul would be handled by the mobile 

>routers. MRs could be collocated with the sensors or 

>flying drones gathering data.

 

Above mention seems like an interoperability issue

of 6lowpan except adding NEMO into our  gateway.

http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-interoperability-00.txt

Let me know your view on this.

 

 

Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics

 

 


--===============0850061354== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============0850061354==-- From mobopts-bounces@irtf.org Tue Jul 12 04:31:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsGAV-0007DT-UL; Tue, 12 Jul 2005 04:31:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsGAU-0007DH-AA for mobopts@megatron.ietf.org; Tue, 12 Jul 2005 04:31:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00979 for ; Tue, 12 Jul 2005 04:31:04 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsGcd-0001TG-Us for mobopts@irtf.org; Tue, 12 Jul 2005 05:00:13 -0400 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C9553DC4E; Tue, 12 Jul 2005 10:30:55 +0200 (CEST) Received: from [10.1.1.115] ([10.1.1.115]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 10:30:55 +0200 Message-ID: <42D37FBD.9020804@netlab.nec.de> Date: Tue, 12 Jul 2005 10:30:53 +0200 From: Telemaco Melia User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mobopts] New topics for the RG References: <42D2F74B.7040908@iprg.nokia.com> In-Reply-To: <42D2F74B.7040908@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2005 08:30:55.0728 (UTC) FILETIME=[05AF5F00:01C586BC] X-Spam-Score: 2.4 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: Rui Aguiar , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi Rajeev, of course we are interested to provide input on the network initiated handover topic. We are currently revising the draft and we should be able to submit version 01 by the end of the week. In the meanwhile I would like to trigger the discussion on the mailing list based on version 00. regards, Telemaco > > - mobility (and traffic) patterns in a WLAN (e.g., a campus network). > This should provide > a better sense of traffic for admission control as well as > network-controlled handovers. > >https://www1.ietf.org/mailman/listinfo/mobopts > > -- Telemaco Melia telemaco.melia@netlab.nec.de Research Staff Member Tel: +49 (0) 6221 90511-42 Network Laboratories Fax: +49 (0) 6221 90511-55 NEC Europe Ltd. Web: http://www.netlab.nec.de Kurfrsten-Anlage 36 D-69115 Heidelberg Germany _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jul 12 07:30:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsIxk-0004j3-2z; Tue, 12 Jul 2005 07:30:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsIxh-0004io-WD for mobopts@megatron.ietf.org; Tue, 12 Jul 2005 07:30:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12096 for ; Tue, 12 Jul 2005 07:30:04 -0400 (EDT) Received: from mail-gw1.york.ac.uk ([144.32.128.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsJPr-00081o-Pc for mobopts@irtf.org; Tue, 12 Jul 2005 07:59:13 -0400 Received: from grouse (grouse.ohm.york.ac.uk [144.32.137.104]) by mail-gw1.york.ac.uk (8.12.10/8.12.10) with SMTP id j6CBTmcM006034; Tue, 12 Jul 2005 12:29:48 +0100 (BST) Message-ID: <015b01c586d5$89e1f490$68892090@grouse> From: "Ji Zhang" To: "Rajeev Koodli" References: <42D2F74B.7040908@iprg.nokia.com> Subject: Re: [Mobopts] New topics for the RG Date: Tue, 12 Jul 2005 12:33:34 +0100 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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-York-MailScanner: Found to be clean X-York-MailScanner-From: jz105@york.ac.uk X-Spam-Score: 3.3 (+++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: Soohong Daniel Park , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi Rajeev, Thanks a lot for your summary. We would like to recommend the following topic to be considered for the charter: Deliver link layer characteristic information (e.g. bandwidth...) to a mobile node's communication peers using mobility control messages (i.e. binding updates or registration requests), so that the communication peers of the mobile node can control their traffic flows accordingly. The idea is based on the draft http://www.ietf.org/internet-drafts/draft-daniel-mip-link-characteristic-02.txt. With this approach, the potential problems (i.e. capacity overspending or underutilization) on access link capacity changes (especially on vertical handovers) can be solved. The proposal is suitable for both MIPv4 and MIPv6, regardless of the type of the transport protocol used. Simulations will be done in the near future to test its performance. Any comments and questions are welcome. Regards, Ji > > Now, it is time to re-consider our charter items. What sorts of topics > are folks interested in working on? I would like to broaden our scope to > consider Mobility on the Internet in general. Some possible topics for > discussion below in no preference order. Please comment, suggest your > topics and provide a brief justification. > > - multicast and mobility. A specific problem is what address should the MN > use as its source IP address so that its packets are not discarded due > to a) RPF checks, > and b) source-specific multicast. To pass a), you need the MN to use > CoA, but to > pass b), you need HoA. How to convice multiple receivers about CoA and > HoA binding? > Is RR even an option? :-) > > - mobility (and traffic) patterns in a WLAN (e.g., a campus network). > This should provide > a better sense of traffic for admission control as well as > network-controlled handovers. > > - what is the scope of IP paging in a converged WLAN - WWAN environment? > Is it a real problem? Worthwhile documenting in any case? > > - architectural barriers to optimizing inter-domain handovers. Although > we have > some understanding of improving delay and packet loss during > handovers across > IP networks, how applicable are they across different autonomous > systems? Would > the policy barriers allow optimizations? Is this an example of > "tussle in cyberspace"? > > - privacy topics related to mobility > > - Others > > -Rajeev > > > ---------------------------------------------------------------------------- ---- > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jul 12 12:56:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsO3K-00064H-4B; Tue, 12 Jul 2005 12:56:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsO3I-00063q-AY for mobopts@megatron.ietf.org; Tue, 12 Jul 2005 12:56:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15666 for ; Tue, 12 Jul 2005 12:56:05 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsOVP-0006Nr-MK for mobopts@irtf.org; Tue, 12 Jul 2005 13:25:19 -0400 Message-ID: <046201c58702$91fdf070$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Rajeev Koodli" References: <200507120322.XAA22396@breeze.research.telcordia.com> Subject: Re: [Mobopts] New topics for the RG Date: Tue, 12 Jul 2005 09:55:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Rajeev, One item that has come up in the INT chairs list discussion on localized mobility management is the scalability of using host routes for lmm. jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jul 12 17:38:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsSSH-0002y1-Mp; Tue, 12 Jul 2005 17:38:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqXvb-0001MA-FG; Thu, 07 Jul 2005 11:04:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15615; Thu, 7 Jul 2005 11:04:36 -0400 (EDT) From: stefano.faccin@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqYMm-0004jK-S9; Thu, 07 Jul 2005 11:32:46 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j67F1H3d031900; Thu, 7 Jul 2005 18:01:20 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 18:04:26 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 10:04:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2005 10:04:17 -0500 Message-ID: <33B0AB1B4BA65042831AE04C0836E2038DC878@daebe101.NOE.Nokia.com> Thread-Topic: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES Thread-Index: AcWCgFmtyOn6QW7xRvOWeVNDsk32nwAhA1Rw To: , , , , , X-OriginalArrivalTime: 07 Jul 2005 15:04:23.0927 (UTC) FILETIME=[2933E870:01C58305] X-Spam-Score: 2.7 (++) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 12 Jul 2005 17:38:16 -0400 Cc: margaret@thingmagic.com, rajeev@iprg.nokia.com, Basavaraj.Patil@nokia.com Subject: [Mobopts] RE: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org James, I guess the reference to triggers may have been a bit misleading. They = are relevant from the point of view that the drafts refer to some of the = technical aspects that the MIH services cover, but the focus here is not = specifically on the triggers between L2 and L3. If the MIHEP BOF is = approved, and if we coordinate the discussion with MIPSHOP, I believe we = will be able to cover the various aspects without requiring any other = BOFs. Stefano -----Original Message----- From: owner-dna@ecselists.eng.monash.edu.au [mailto:owner-dna@ecselists.eng.monash.edu.au]On Behalf Of ext James Kempf Sent: Wednesday, July 06, 2005 18:12 To: gabriel montenegro; Williams Michael.G (Nokia-ES/MtView); mipshop@ietf.org; mobopts@irtf.org; dna@eng.monash.edu.au Cc: Greg.Daley@eng.monash.edu.au; margaret@thingmagic.com; rajeev@iprg.nokia.com; Patil Basavaraj (Nokia-NET/Dallas) Subject: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES Some of the things on Mike's list, like link triggers, are DNA items. We = had discussed doing the InfoElements work in Mipshop prior to the MIHEP BOF discussion coming up. So now I'm completely confused what is happening, which is why I suggested the BAR BOF. Margaret, can you help us figure this out? Has the MIHEP BOF been = approved? jak ----- Original Message -----=20 From: "gabriel montenegro" To: "James Kempf" ; ; ; ; Cc: ; ; ; Sent: Wednesday, July 06, 2005 3:26 PM Subject: Re: Interest in protocols for IEEE 802.21 IS, CS, ES > > Isn't this the subject for the proposed MIHEP BoF? What's the latest = word, > is it being scheduled? Some of this discussion is quite relevant to > the MIPSHOP meeting, and the 802.21 folks are already on that agenda. > > But I agree that this is an important discussion. If the MIHEP BoF = does not get > scheduled, we should have a bar BoF on the subject. > > -gabriel > > --- James Kempf wrote: > > > Mike, > > > > Would you like to get a BAR BOF-style meeting at IETF set up to = discuss > > this? With the help of an AD or IAB member, I think we could get a = room > > reserved for that purpose. > > > > jak > > > > ----- Original Message -----=20 > > From: > > To: ; ; > > Cc: ; ; > > ; ; > > ; > > Sent: Wednesday, July 06, 2005 3:02 PM > > Subject: Interest in protocols for IEEE 802.21 IS, CS, ES > > > > > > Colleagues, > > > > The IEEE 802.21 working group is developing services for = facilitating IP > > address mobility and service mobility, especially handoff across a > > variety of media. The group is interested in working with the = relevant > > IETF/IRTF working groups to develop methods of carrying these = services > > across the network. It would be ideal to discuss this at the next = IETF > > meeting. > > > > There are multiple drafts currently issued or in development that = are > > interesting and could serve as the basis for starting the work. > > > > Drafts of interest include but are not limited to : > > > > "Neighborhood Information Elements Discovery (NED) > > (draft-kempf-mobopts-nhood-discovery-00.txt), which provides a = generic > > protocol for carrying information elements of interest to IEEE = 802.21." > > > > "Some Requirements for a Media Independent Handover Information = Service" > > (draft-faccin-mih-infoserv-00.txt, > > http://www.ctie.monash.edu.au/dna/draft-faccin-mih-infoserv-00.txt > > = ). > > > > "Architectural Implications of Link Indications" > > = http://www.iab.org/documents/drafts/draft-iab-link-indications-01.txt > > = > > > > > > "Unified L2 Abstractions for L3-Driven Fast Handover" > > = http://www.ietf.org/internet-drafts/draft-koki-mobopts-l2-abstractions-0 > > 2.txt > > > > "A Framework of Media-Independent Pre-Authentication (MPA)" > > = http://www.ietf.org/internet-drafts/draft-ohba-mobopts-mpa-framework-00. > > txt > > > > Best Regards, > > Michael G. Williams > > IEEE 802.21 Working Group Vice Chair > > > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jul 12 17:38:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsSSI-0002ye-41; Tue, 12 Jul 2005 17:38:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqZMk-0008B5-58 for mobopts@megatron.ietf.org; Thu, 07 Jul 2005 12:36:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23803 for ; Thu, 7 Jul 2005 12:36:38 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqZns-0006P1-8i for mobopts@irtf.org; Thu, 07 Jul 2005 13:04:50 -0400 Message-ID: <0e4601c58312$34d17780$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , , , , , References: <33B0AB1B4BA65042831AE04C0836E2038DC878@daebe101.NOE.Nokia.com> Date: Thu, 7 Jul 2005 09:37:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 12 Jul 2005 17:38:16 -0400 Cc: margaret@thingmagic.com, rajeev@iprg.nokia.com, Basavaraj.Patil@nokia.com Subject: [Mobopts] Re: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Stefano, There is also Yoshi Obha's draft on media-independent pre-authentication. Having read a draft of the 802.21 spec, I don't recall anything specifically in this area, but from Mike's email, it sounds as if they are interested in it. Was the intent of MIHEP to cover that too? jak ----- Original Message ----- From: To: ; ; ; ; ; Cc: ; ; ; Sent: Thursday, July 07, 2005 8:04 AM Subject: RE: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES James, I guess the reference to triggers may have been a bit misleading. They are relevant from the point of view that the drafts refer to some of the technical aspects that the MIH services cover, but the focus here is not specifically on the triggers between L2 and L3. If the MIHEP BOF is approved, and if we coordinate the discussion with MIPSHOP, I believe we will be able to cover the various aspects without requiring any other BOFs. Stefano -----Original Message----- From: owner-dna@ecselists.eng.monash.edu.au [mailto:owner-dna@ecselists.eng.monash.edu.au]On Behalf Of ext James Kempf Sent: Wednesday, July 06, 2005 18:12 To: gabriel montenegro; Williams Michael.G (Nokia-ES/MtView); mipshop@ietf.org; mobopts@irtf.org; dna@eng.monash.edu.au Cc: Greg.Daley@eng.monash.edu.au; margaret@thingmagic.com; rajeev@iprg.nokia.com; Patil Basavaraj (Nokia-NET/Dallas) Subject: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES Some of the things on Mike's list, like link triggers, are DNA items. We had discussed doing the InfoElements work in Mipshop prior to the MIHEP BOF discussion coming up. So now I'm completely confused what is happening, which is why I suggested the BAR BOF. Margaret, can you help us figure this out? Has the MIHEP BOF been approved? jak ----- Original Message ----- From: "gabriel montenegro" To: "James Kempf" ; ; ; ; Cc: ; ; ; Sent: Wednesday, July 06, 2005 3:26 PM Subject: Re: Interest in protocols for IEEE 802.21 IS, CS, ES > > Isn't this the subject for the proposed MIHEP BoF? What's the latest word, > is it being scheduled? Some of this discussion is quite relevant to > the MIPSHOP meeting, and the 802.21 folks are already on that agenda. > > But I agree that this is an important discussion. If the MIHEP BoF does not get > scheduled, we should have a bar BoF on the subject. > > -gabriel > > --- James Kempf wrote: > > > Mike, > > > > Would you like to get a BAR BOF-style meeting at IETF set up to discuss > > this? With the help of an AD or IAB member, I think we could get a room > > reserved for that purpose. > > > > jak > > > > ----- Original Message ----- > > From: > > To: ; ; > > Cc: ; ; > > ; ; > > ; > > Sent: Wednesday, July 06, 2005 3:02 PM > > Subject: Interest in protocols for IEEE 802.21 IS, CS, ES > > > > > > Colleagues, > > > > The IEEE 802.21 working group is developing services for facilitating IP > > address mobility and service mobility, especially handoff across a > > variety of media. The group is interested in working with the relevant > > IETF/IRTF working groups to develop methods of carrying these services > > across the network. It would be ideal to discuss this at the next IETF > > meeting. > > > > There are multiple drafts currently issued or in development that are > > interesting and could serve as the basis for starting the work. > > > > Drafts of interest include but are not limited to : > > > > "Neighborhood Information Elements Discovery (NED) > > (draft-kempf-mobopts-nhood-discovery-00.txt), which provides a generic > > protocol for carrying information elements of interest to IEEE 802.21." > > > > "Some Requirements for a Media Independent Handover Information Service" > > (draft-faccin-mih-infoserv-00.txt, > > http://www.ctie.monash.edu.au/dna/draft-faccin-mih-infoserv-00.txt > > ). > > > > "Architectural Implications of Link Indications" > > http://www.iab.org/documents/drafts/draft-iab-link-indications-01.txt > > > > > > > > "Unified L2 Abstractions for L3-Driven Fast Handover" > > http://www.ietf.org/internet-drafts/draft-koki-mobopts-l2-abstractions-0 > > 2.txt > > > > "A Framework of Media-Independent Pre-Authentication (MPA)" > > http://www.ietf.org/internet-drafts/draft-ohba-mobopts-mpa-framework-00. > > txt > > > > Best Regards, > > Michael G. Williams > > IEEE 802.21 Working Group Vice Chair > > > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jul 12 17:38:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsSSI-0002zD-Jz; Tue, 12 Jul 2005 17:38:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqZuy-0003RK-N7; Thu, 07 Jul 2005 13:12:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26554; Thu, 7 Jul 2005 13:12:05 -0400 (EDT) From: stefano.faccin@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqaMC-0002DG-2C; Thu, 07 Jul 2005 13:40:17 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j67H6uCg012972; Thu, 7 Jul 2005 20:06:57 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 20:11:51 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 12:11:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2005 12:11:48 -0500 Message-ID: <33B0AB1B4BA65042831AE04C0836E2033BBAA4@daebe101.NOE.Nokia.com> Thread-Topic: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES Thread-Index: AcWDEjXbcycTYGhBRB673gIRPcnENQABEpaw To: , , , , , X-OriginalArrivalTime: 07 Jul 2005 17:11:49.0436 (UTC) FILETIME=[F647FFC0:01C58316] X-Spam-Score: 2.7 (++) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 12 Jul 2005 17:38:16 -0400 Cc: margaret@thingmagic.com, rajeev@iprg.nokia.com, Basavaraj.Patil@nokia.com Subject: [Mobopts] RE: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org James, thanks for bringing this up. Yoshi's work is definitely interesting and = relevant to the area of 802.21, as Michael says. So far 802.21 has not = been working on security aspects, but I do not rule out the group may = work on them in the future. Therefore, as far as the present relevance = of Yoshi's material with 802.21 work and requirements, that would be a = whole separate discussion by itself. Again, I think it is relevant, but = I'm afraid if we pull this into the MIHEP discussion now (without having = had a similar discussion in 802.21) we may just stir up more mud and = divert the discussion from the main topic. Stefano -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, July 07, 2005 11:38 To: Faccin Stefano (Nokia-NRC/Dallas); gabriel_montenegro_2000@yahoo.com; Williams Michael.G (Nokia-ES/MtView); mipshop@ietf.org; mobopts@irtf.org; dna@eng.monash.edu.au Cc: Greg.Daley@eng.monash.edu.au; margaret@thingmagic.com; rajeev@iprg.nokia.com; Patil Basavaraj (Nokia-NET/Dallas) Subject: Re: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES Stefano, There is also Yoshi Obha's draft on media-independent = pre-authentication. Having read a draft of the 802.21 spec, I don't recall anything = specifically in this area, but from Mike's email, it sounds as if they are interested = in it. Was the intent of MIHEP to cover that too? jak ----- Original Message -----=20 From: To: ; ; ; ; ; Cc: ; ; ; Sent: Thursday, July 07, 2005 8:04 AM Subject: RE: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES James, I guess the reference to triggers may have been a bit misleading. They = are relevant from the point of view that the drafts refer to some of the technical aspects that the MIH services cover, but the focus here is not specifically on the triggers between L2 and L3. If the MIHEP BOF is approved, and if we coordinate the discussion with MIPSHOP, I believe we will be able to cover the various aspects without requiring any other = BOFs. Stefano -----Original Message----- From: owner-dna@ecselists.eng.monash.edu.au [mailto:owner-dna@ecselists.eng.monash.edu.au]On Behalf Of ext James Kempf Sent: Wednesday, July 06, 2005 18:12 To: gabriel montenegro; Williams Michael.G (Nokia-ES/MtView); mipshop@ietf.org; mobopts@irtf.org; dna@eng.monash.edu.au Cc: Greg.Daley@eng.monash.edu.au; margaret@thingmagic.com; rajeev@iprg.nokia.com; Patil Basavaraj (Nokia-NET/Dallas) Subject: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES Some of the things on Mike's list, like link triggers, are DNA items. We = had discussed doing the InfoElements work in Mipshop prior to the MIHEP BOF discussion coming up. So now I'm completely confused what is happening, which is why I suggested the BAR BOF. Margaret, can you help us figure this out? Has the MIHEP BOF been = approved? jak ----- Original Message -----=20 From: "gabriel montenegro" To: "James Kempf" ; ; ; ; Cc: ; ; ; Sent: Wednesday, July 06, 2005 3:26 PM Subject: Re: Interest in protocols for IEEE 802.21 IS, CS, ES > > Isn't this the subject for the proposed MIHEP BoF? What's the latest = word, > is it being scheduled? Some of this discussion is quite relevant to > the MIPSHOP meeting, and the 802.21 folks are already on that agenda. > > But I agree that this is an important discussion. If the MIHEP BoF = does not get > scheduled, we should have a bar BoF on the subject. > > -gabriel > > --- James Kempf wrote: > > > Mike, > > > > Would you like to get a BAR BOF-style meeting at IETF set up to = discuss > > this? With the help of an AD or IAB member, I think we could get a = room > > reserved for that purpose. > > > > jak > > > > ----- Original Message -----=20 > > From: > > To: ; ; > > Cc: ; ; > > ; ; > > ; > > Sent: Wednesday, July 06, 2005 3:02 PM > > Subject: Interest in protocols for IEEE 802.21 IS, CS, ES > > > > > > Colleagues, > > > > The IEEE 802.21 working group is developing services for = facilitating IP > > address mobility and service mobility, especially handoff across a > > variety of media. The group is interested in working with the = relevant > > IETF/IRTF working groups to develop methods of carrying these = services > > across the network. It would be ideal to discuss this at the next = IETF > > meeting. > > > > There are multiple drafts currently issued or in development that = are > > interesting and could serve as the basis for starting the work. > > > > Drafts of interest include but are not limited to : > > > > "Neighborhood Information Elements Discovery (NED) > > (draft-kempf-mobopts-nhood-discovery-00.txt), which provides a = generic > > protocol for carrying information elements of interest to IEEE = 802.21." > > > > "Some Requirements for a Media Independent Handover Information = Service" > > (draft-faccin-mih-infoserv-00.txt, > > http://www.ctie.monash.edu.au/dna/draft-faccin-mih-infoserv-00.txt > > = ). > > > > "Architectural Implications of Link Indications" > > = http://www.iab.org/documents/drafts/draft-iab-link-indications-01.txt > > = > > > > > > "Unified L2 Abstractions for L3-Driven Fast Handover" > > = http://www.ietf.org/internet-drafts/draft-koki-mobopts-l2-abstractions-0 > > 2.txt > > > > "A Framework of Media-Independent Pre-Authentication (MPA)" > > = http://www.ietf.org/internet-drafts/draft-ohba-mobopts-mpa-framework-00. > > txt > > > > Best Regards, > > Michael G. Williams > > IEEE 802.21 Working Group Vice Chair > > > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jul 12 18:26:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsTDI-0005YX-RT; Tue, 12 Jul 2005 18:26:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsTDH-0005YG-Cp for mobopts@megatron.ietf.org; Tue, 12 Jul 2005 18:26:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25262 for ; Tue, 12 Jul 2005 18:26:48 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsTfW-0007xi-5I for mobopts@irtf.org; Tue, 12 Jul 2005 18:56:05 -0400 Received: from jurassic.eng.sun.com ([129.146.104.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j6CMQgGY022814; Tue, 12 Jul 2005 16:26:42 -0600 (MDT) Received: from eng.Sun.COM (vpn-129-150-29-178.SFBay.Sun.COM [129.150.29.178]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6CMQf9Y260563; Tue, 12 Jul 2005 15:26:42 -0700 (PDT) Message-ID: <42D4439C.3030801@eng.Sun.COM> Date: Tue, 12 Jul 2005 15:26:36 -0700 From: Samita Chakrabarti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20041117 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [Mobopts] New topics for the RG References: <200507120119.j6C1JAIF710653@jurassic.eng.sun.com> <20050712113548.73011654.ernst@sfc.wide.ad.jp> In-Reply-To: <20050712113548.73011654.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita.Chakrabarti@Sun.COM List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Thierry Ernst wrote: >>Now, it is time to re-consider our charter items. What sorts of topics >>are folks interested in working on? I would like to broaden our scope >>to consider Mobility on the Internet in general. Some possible topics >>for discussion below in no preference order. Please comment, suggest >>your topics and provide a brief justification. >>--- >> >>How about starting some discussion on LowPan mobility ? >>Currently 6Lowpan wg does not have mobility in the charter. >>Mobility in sensor networks is a research topic - though >>parts of it can be addressed by Manet protocols. > > > Well, once sensors are IP-enabled, NEMO is likely more appropriate than > MANET, from a complexity point of view: > - no need to manage mobiility: MR does everything > - sensors may not be wireless nodes: MANET is pointless > - MR can deals with security aspects on behalf of sensors > Hi Thierry, One of the MANET protocols (AODV) variant is being used in Zigbee networks. Besides people have also played with other manet reactive protocols in the sensor networks. MANET protocols are more appropriate in adhoc/unstructured networks. However, NEMO ideas could be useful for moving ip-enabled sensor networks. But this is too much into solution space. LowPan network is quite different than regular Internet network; we need to first understand the issues/requirement in that network. All that apply in Internet, may not be applicable directly in mesh networks such as LowPan. Thanks, -Samita _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 13 13:36:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DslAC-0006j9-Jh; Wed, 13 Jul 2005 13:36:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DslA9-0006i0-1g for mobopts@megatron.ietf.org; Wed, 13 Jul 2005 13:36:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05879 for ; Wed, 13 Jul 2005 13:36:46 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DslcX-0004Ok-Ll for mobopts@irtf.org; Wed, 13 Jul 2005 14:06:13 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6DH4wV23862; Wed, 13 Jul 2005 10:04:58 -0700 X-mProtect: <200507131704> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14166.americas.nokia.com (172.18.141.66, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdo4a2Y2; Wed, 13 Jul 2005 10:04:56 PDT Message-ID: <42D55113.6010700@iprg.nokia.com> Date: Wed, 13 Jul 2005 10:36:19 -0700 From: Rajeev Koodli 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: Samita Chakrabarti Subject: Re: [Mobopts] New topics for the RG References: <200507120119.j6C1JAIF710653@jurassic.eng.sun.com> In-Reply-To: <200507120119.j6C1JAIF710653@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi Samita and others, I think this is an interesting and worthwhile topic for the RG. We need to acknowledge that MIP, NEMO exist. However scope of this area calls for a fresh look. So, all approaches, including MIP-NEMO, should be welcome. Regards, -Rajeev Samita Chakrabarti wrote: >Hi Rajeev, > >--- >Now, it is time to re-consider our charter items. What sorts of topics >are folks interested in working on? I would like to broaden our scope to >consider Mobility on the Internet in general. Some possible topics for >discussion below in no preference order. Please comment, suggest your >topics and provide a brief justification. >--- > >How about starting some discussion on LowPan mobility ? >Currently 6Lowpan wg does not have mobility in the charter. >Mobility in sensor networks is a research topic - though >parts of it can be addressed by Manet protocols. > >I have published a draft recently to discuss the goals and >requirements of lowpan mobility. Would like to see some >discussion in mobopts irtg wg. >draft-chakrabarti-mobopts-lowpan-req-00.txt > >Thanks, >-Samita > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 13 13:39:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DslD5-0008Ep-7F; Wed, 13 Jul 2005 13:39:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DslD2-0008Ek-My for mobopts@megatron.ietf.org; Wed, 13 Jul 2005 13:39:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05980 for ; Wed, 13 Jul 2005 13:39:45 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DslfT-0004UF-FU for mobopts@irtf.org; Wed, 13 Jul 2005 14:09:13 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6DH7wB26742; Wed, 13 Jul 2005 10:07:58 -0700 X-mProtect: <200507131707> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14166.americas.nokia.com (172.18.141.66, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdREKAGt; Wed, 13 Jul 2005 10:07:56 PDT Message-ID: <42D551C8.8050108@iprg.nokia.com> Date: Wed, 13 Jul 2005 10:39:20 -0700 From: Rajeev Koodli 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: Telemaco Melia Subject: Re: [Mobopts] New topics for the RG References: <42D2F74B.7040908@iprg.nokia.com> <42D37FBD.9020804@netlab.nec.de> In-Reply-To: <42D37FBD.9020804@netlab.nec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: Rui Aguiar , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Telemaco, good to hear about your interest. Note however that I am specifically referring to WLAN mobility and traffic patterns. This should lead to some interesting control algorithm design. Of course, networ-controlled handovers on their own are also interesting. Regards, -Rajeev Telemaco Melia wrote: > Hi Rajeev, > > of course we are interested to provide input on the network initiated > handover topic. > We are currently revising the draft and we should be able to submit > version 01 by the end of the week. > In the meanwhile I would like to trigger the discussion on the mailing > list based on version 00. > > regards, > Telemaco > >> >> - mobility (and traffic) patterns in a WLAN (e.g., a campus network). >> This should provide >> a better sense of traffic for admission control as well as >> network-controlled handovers. >> >> https://www1.ietf.org/mailman/listinfo/mobopts >> >> > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 13 13:52:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DslPR-0006hL-LD; Wed, 13 Jul 2005 13:52:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DslPP-0006hG-75 for mobopts@megatron.ietf.org; Wed, 13 Jul 2005 13:52:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06940 for ; Wed, 13 Jul 2005 13:52:34 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dslrr-0004y2-3L for mobopts@irtf.org; Wed, 13 Jul 2005 14:21:59 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6DHKfM07748; Wed, 13 Jul 2005 10:20:41 -0700 X-mProtect: <200507131720> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14166.americas.nokia.com (172.18.141.66, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpd2t8pOg; Wed, 13 Jul 2005 10:20:39 PDT Message-ID: <42D554C2.3040705@iprg.nokia.com> Date: Wed, 13 Jul 2005 10:52:02 -0700 From: Rajeev Koodli 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: Ji Zhang Subject: Re: [Mobopts] New topics for the RG References: <42D2F74B.7040908@iprg.nokia.com> <015b01c586d5$89e1f490$68892090@grouse> In-Reply-To: <015b01c586d5$89e1f490$68892090@grouse> X-Spam-Score: 2.9 (++) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: Soohong Daniel Park , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0575873668==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org This is a multi-part message in MIME format. --===============0575873668== Content-Type: multipart/alternative; boundary="------------040800020707060807000900" This is a multi-part message in MIME format. --------------040800020707060807000900 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I have seen interest in this topic. However, I think the topic is more than just end-to-end event notification (Disclaimer: I have not read the latest version). It could affect traffic on the Internet. So, before we could go ahead with the solution(s), we need to carefully look into the broader problem, including "cross-layer design" implications, congestion-control etc. Would you be interested in looking into those first? Regards, -Rajeev ps: A while ago, MIP group looked into the problem of end-to-end QoS problem definition and requirements. I feel the problems are similar. Ji Zhang wrote: >Hi Rajeev, > >Thanks a lot for your summary. > >We would like to recommend the following topic to be considered for the >charter: > >Deliver link layer characteristic information (e.g. bandwidth...) to a >mobile node's communication peers using mobility control messages (i.e. >binding updates or registration requests), so that the communication peers >of the mobile node can control their traffic flows accordingly. The idea is >based on the draft >http://www.ietf.org/internet-drafts/draft-daniel-mip-link-characteristic-02.txt. >With this approach, the potential problems (i.e. capacity overspending or >underutilization) on access link capacity changes (especially on vertical >handovers) can be solved. The proposal is suitable for both MIPv4 and MIPv6, >regardless of the type of the transport protocol used. Simulations will be >done in the near future to test its performance. > >Any comments and questions are welcome. > >Regards, >Ji > > > > >>Now, it is time to re-consider our charter items. What sorts of topics >>are folks interested in working on? I would like to broaden our scope to >>consider Mobility on the Internet in general. Some possible topics for >>discussion below in no preference order. Please comment, suggest your >>topics and provide a brief justification. >> >>- multicast and mobility. A specific problem is what address should the MN >> use as its source IP address so that its packets are not discarded due >>to a) RPF checks, >> and b) source-specific multicast. To pass a), you need the MN to use >>CoA, but to >> pass b), you need HoA. How to convice multiple receivers about CoA and >>HoA binding? >> Is RR even an option? :-) >> >>- mobility (and traffic) patterns in a WLAN (e.g., a campus network). >>This should provide >> a better sense of traffic for admission control as well as >>network-controlled handovers. >> >>- what is the scope of IP paging in a converged WLAN - WWAN environment? >> Is it a real problem? Worthwhile documenting in any case? >> >>- architectural barriers to optimizing inter-domain handovers. Although >>we have >> some understanding of improving delay and packet loss during >>handovers across >> IP networks, how applicable are they across different autonomous >>systems? Would >> the policy barriers allow optimizations? Is this an example of >>"tussle in cyberspace"? >> >>- privacy topics related to mobility >> >>- Others >> >>-Rajeev >> >> >> >> >> > > >---------------------------------------------------------------------------- >---- > > > > >>_______________________________________________ >>Mobopts mailing list >>Mobopts@irtf.org >>https://www1.ietf.org/mailman/listinfo/mobopts >> >> >> > > >_______________________________________________ >Mobopts mailing list >Mobopts@irtf.org >https://www1.ietf.org/mailman/listinfo/mobopts > > --------------040800020707060807000900 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Hi,

I have seen interest in this topic. However, I think the topic is
more than just end-to-end event notification (Disclaimer: I have not
read the latest version). It could affect traffic on the Internet.
So, before we could go ahead with the solution(s), we need to
carefully look into the broader problem, including "cross-layer
design" implications, congestion-control etc. Would you be
interested in looking into those first?

Regards,

-Rajeev

ps: A while ago, MIP group looked into the problem of end-to-end
     QoS problem definition and requirements. I feel the problems are
     similar.


Ji Zhang wrote:
Hi Rajeev,

Thanks a lot for your summary.

We would like to recommend the following topic to be considered for the
charter:

Deliver link layer characteristic information (e.g. bandwidth...) to a
mobile node's communication peers using mobility control messages  (i.e.
binding updates or registration requests), so that the communication peers
of the mobile node can control their traffic flows accordingly. The idea is
based on the draft
http://www.ietf.org/internet-drafts/draft-daniel-mip-link-characteristic-02.txt.
With this approach, the potential problems (i.e. capacity overspending or
underutilization) on access link capacity changes (especially on vertical
handovers) can be solved. The proposal is suitable for both MIPv4 and MIPv6,
regardless of the type of the transport protocol used. Simulations will be
done in the near future to test its performance.

Any comments and questions are welcome.

Regards,
Ji


  
Now, it is time to re-consider our charter items. What sorts of topics
are folks interested in working on?  I would like to broaden our scope to
consider Mobility on the Internet in general. Some possible topics for
discussion below in no preference order. Please comment, suggest your
topics and provide a brief justification.

- multicast and mobility. A specific problem is what address should the MN
  use as its source IP address so that its packets are not discarded due
to a) RPF checks,
  and b) source-specific multicast. To pass a), you need the MN to use
CoA, but to
  pass b), you need HoA. How to convice multiple receivers about CoA and
HoA binding?
  Is RR even an option? :-)

- mobility (and traffic) patterns in a WLAN (e.g., a campus network).
This should provide
  a better sense of traffic for admission control as well as
network-controlled handovers.

- what is the scope of IP paging in a converged WLAN - WWAN environment?
  Is it a real problem? Worthwhile documenting in any case?

- architectural barriers to optimizing inter-domain handovers. Although
we have
   some understanding of improving delay and packet loss during
handovers across
   IP networks, how applicable are they across different autonomous
systems? Would
   the policy barriers allow optimizations? Is this an example of
"tussle in cyberspace"?

- privacy topics related to mobility

- Others

-Rajeev



    


----------------------------------------------------------------------------
----


  
_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts

    


_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts
--------------040800020707060807000900-- --===============0575873668== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============0575873668==-- From mobopts-bounces@irtf.org Wed Jul 13 13:53:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DslQY-0007Yx-C9; Wed, 13 Jul 2005 13:53:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DslQW-0007XR-O7 for mobopts@megatron.ietf.org; Wed, 13 Jul 2005 13:53:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07022 for ; Wed, 13 Jul 2005 13:53:43 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dslsx-0004zz-R6 for mobopts@irtf.org; Wed, 13 Jul 2005 14:23:09 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6DHLt808774; Wed, 13 Jul 2005 10:21:55 -0700 X-mProtect: <200507131721> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14166.americas.nokia.com (172.18.141.66, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdJkKyly; Wed, 13 Jul 2005 10:21:54 PDT Message-ID: <42D5550E.6010506@iprg.nokia.com> Date: Wed, 13 Jul 2005 10:53:18 -0700 From: Rajeev Koodli 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: [Mobopts] New topics for the RG References: <200507120322.XAA22396@breeze.research.telcordia.com> <046201c58702$91fdf070$016115ac@dcml.docomolabsusa.com> In-Reply-To: <046201c58702$91fdf070$016115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org James Kempf wrote: >Rajeev, > >One item that has come up in the INT chairs list discussion on localized >mobility management is the scalability of using host routes for lmm. > > > Sounds like an excellent problem to get some empirical (i.e., simulation) data on. -Rajeev > jak > > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 13 14:46:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsmFS-0002GA-Jy; Wed, 13 Jul 2005 14:46:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsmFQ-0002G5-GA for mobopts@megatron.ietf.org; Wed, 13 Jul 2005 14:46:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10441 for ; Wed, 13 Jul 2005 14:46:19 -0400 (EDT) From: Michael.G.Williams@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsmhq-0006kC-RO for mobopts@irtf.org; Wed, 13 Jul 2005 15:15:45 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6DIkAEe029419; Wed, 13 Jul 2005 21:46:15 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jul 2005 21:46:11 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jul 2005 13:46:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobopts] New topics for the RG Date: Wed, 13 Jul 2005 11:46:07 -0700 Message-ID: <8A76136424391244A5CF0165337085375F4DC4@mvebe101.NOE.Nokia.com> Thread-Topic: [Mobopts] New topics for the RG Thread-Index: AcWH10yDOYNMRXhHT72BkRTm511UmAAAwpJQ To: X-OriginalArrivalTime: 13 Jul 2005 18:46:08.0879 (UTC) FILETIME=[220CF7F0:01C587DB] X-Spam-Score: 2.7 (++) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: quoted-printable Cc: jz105@york.ac.uk, rajeev@iprg.nokia.com, soohong.park@samsung.com, mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Colleagues, =20 The following draft is of interest to the IEEE 802.21 community and I encourage everyone to be familiar with the concepts. =20 http://www.ietf.org/internet-drafts/draft-daniel-mip-link-characteristic -02.txt =20 Please notice in particular the implications of defining IEEE 802.21 parameterization of link change events and possible re-parameterization of them in another layer. Coordination between groups and goals would be useful here. =20 Also, the suggestion of combining link event reporting with a MIP-based protocol has been discussed in our forum. =20 Best Regards, Michael G. Williams, IEEE 802.21 Vice Chair ________________________________ From: mobopts-bounces@irtf.org [mailto:mobopts-bounces@irtf.org] On Behalf Of ext Rajeev Koodli Sent: Wednesday, July 13, 2005 10:52 AM To: Ji Zhang Cc: Soohong Daniel Park; mobopts@irtf.org Subject: Re: [Mobopts] New topics for the RG Hi, I have seen interest in this topic. However, I think the topic is more than just end-to-end event notification (Disclaimer: I have not read the latest version). It could affect traffic on the Internet.=20 So, before we could go ahead with the solution(s), we need to carefully look into the broader problem, including "cross-layer design" implications, congestion-control etc. Would you be=20 interested in looking into those first?=20 Regards, -Rajeev ps: A while ago, MIP group looked into the problem of end-to-end QoS problem definition and requirements. I feel the problems are similar. Ji Zhang wrote: Hi Rajeev, =09 Thanks a lot for your summary. =09 We would like to recommend the following topic to be considered for the charter: =09 Deliver link layer characteristic information (e.g. bandwidth...) to a mobile node's communication peers using mobility control messages (i.e. binding updates or registration requests), so that the communication peers of the mobile node can control their traffic flows accordingly. The idea is based on the draft =09 http://www.ietf.org/internet-drafts/draft-daniel-mip-link-characteristic -02.txt. With this approach, the potential problems (i.e. capacity overspending or underutilization) on access link capacity changes (especially on vertical handovers) can be solved. The proposal is suitable for both MIPv4 and MIPv6, regardless of the type of the transport protocol used. Simulations will be done in the near future to test its performance. =09 Any comments and questions are welcome. =09 Regards, Ji =09 =09 =20 Now, it is time to re-consider our charter items. What sorts of topics are folks interested in working on? I would like to broaden our scope to consider Mobility on the Internet in general. Some possible topics for discussion below in no preference order. Please comment, suggest your topics and provide a brief justification. =09 - multicast and mobility. A specific problem is what address should the MN use as its source IP address so that its packets are not discarded due to a) RPF checks, and b) source-specific multicast. To pass a), you need the MN to use CoA, but to pass b), you need HoA. How to convice multiple receivers about CoA and HoA binding? Is RR even an option? :-) =09 - mobility (and traffic) patterns in a WLAN (e.g., a campus network). This should provide a better sense of traffic for admission control as well as network-controlled handovers. =09 - what is the scope of IP paging in a converged WLAN - WWAN environment? Is it a real problem? Worthwhile documenting in any case? =09 - architectural barriers to optimizing inter-domain handovers. Although we have some understanding of improving delay and packet loss during handovers across IP networks, how applicable are they across different autonomous systems? Would the policy barriers allow optimizations? Is this an example of "tussle in cyberspace"? =09 - privacy topics related to mobility =09 - Others =09 -Rajeev =09 =09 =09 =20 =09 =09 =09 ------------------------------------------------------------------------ ---- ---- =09 =09 =20 _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts =09 =20 =09 =09 _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts =20 _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 13 15:26:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsmsY-0006Gk-8b; Wed, 13 Jul 2005 15:26:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsmsW-0006EC-E4 for mobopts@megatron.ietf.org; Wed, 13 Jul 2005 15:26:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14160 for ; Wed, 13 Jul 2005 15:26:42 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsnKx-00082L-O6 for mobopts@irtf.org; Wed, 13 Jul 2005 15:56:09 -0400 Received: from ep_ms3_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJK00MHJZC3LC@mailout1.samsung.com> for mobopts@irtf.org; Thu, 14 Jul 2005 04:26:28 +0900 (KST) Received: from ep_spt01 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJK00H2LZC3WA@ms3.samsung.com> for mobopts@irtf.org; Thu, 14 Jul 2005 04:26:27 +0900 (KST) Content-return: prohibited Date: Wed, 13 Jul 2005 19:25:12 +0000 (GMT) From: Daniel Park Subject: Re: Re: [Mobopts] New topics for the RG To: Rajeev Koodli Message-id: <30263814.1121282765889.JavaMail.weblogic@ep_ml08> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20050713192605876@soohong.park X-MTR: 20050713192605876@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Spam-Score: 3.2 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7BIT Cc: Ji Zhang , "mobopts@irtf.org" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soohong.park@samsung.com List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Rajeev, >I have seen interest in this topic. However, I think the topic is >more than just end-to-end event notification (Disclaimer: I have not >read the latest version). It could affect traffic on the Internet. >So, before we could go ahead with the solution(s), we need to >carefully look into the broader problem, including "cross-layer >design" implications, congestion-control etc. Would you be >interested in looking into those first? >ps: A while ago, MIP group looked into the problem of end-to-end >QoS problem definition and requirements. I feel the problems are >similar. Your mention seems to me that we can not solve this issue within ietf-related WG, so my suggestion is... Shall we try to achieve this task including problem definition,requirement and solution in this RG ? Or do we need a new group (either ietf or irtf) ? thought ? Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory. SAMSUNG Electronics _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 13 15:38:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsn3v-0004lh-5T; Wed, 13 Jul 2005 15:38:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsn3s-0004lc-UI for mobopts@megatron.ietf.org; Wed, 13 Jul 2005 15:38:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14846 for ; Wed, 13 Jul 2005 15:38:27 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsnWK-0008VT-K5 for mobopts@irtf.org; Wed, 13 Jul 2005 16:07:54 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6DJ6bp32137; Wed, 13 Jul 2005 12:06:37 -0700 X-mProtect: <200507131906> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14166.americas.nokia.com (172.18.141.66, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdGr6rie; Wed, 13 Jul 2005 12:06:35 PDT Message-ID: <42D56D98.5040409@iprg.nokia.com> Date: Wed, 13 Jul 2005 12:38:00 -0700 From: Rajeev Koodli 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: soohong.park@samsung.com Subject: Re: [Mobopts] New topics for the RG References: <30263814.1121282765889.JavaMail.weblogic@ep_ml08> In-Reply-To: <30263814.1121282765889.JavaMail.weblogic@ep_ml08> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Ji Zhang , "mobopts@irtf.org" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Daniel Park wrote: >Shall we try to achieve this task including problem >definition,requirement and solution in this RG ? > > > I think if there is interest in looking into the broader problem, it is worthwhile for MobOpts. Especially interesting would be the experimental results. My only caution is understanding the problem and its implications should take precedence over solutions. -Rajeev >Or do we need a new group (either ietf or irtf) ? > >thought ? > > > >Regards > >Daniel (Soohong Daniel Park) >Mobile Platform Laboratory. SAMSUNG Electronics > > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 13 17:18:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsocK-0005qs-Lt; Wed, 13 Jul 2005 17:18:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsocJ-0005nX-3L for mobopts@megatron.ietf.org; Wed, 13 Jul 2005 17:18:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14751 for ; Wed, 13 Jul 2005 17:18:04 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsp4l-0002oE-Ri for mobopts@irtf.org; Wed, 13 Jul 2005 17:47:33 -0400 Message-ID: <0abe01c587f0$66ea7770$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Singh Ajoy-ASINGH1" , References: Subject: Re: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt Date: Wed, 13 Jul 2005 14:18:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit Cc: 'Eunsoo Shim' , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi Ajoy, Here is a list of problems Rajeev and I had when we tried to use CARD to define NED: - The information source is always an AR. If the source is an "information server" or an L2 device like an AP but with IP capability, or even involves an L2.5 transport protocol like EAPoL, then CARD isn't relevent. But let's suppose you can extract the options out of CARD and try to use them. Then you run into the problems below. - Most 802 protocols don't like the CARD format of a bunch of disconnected blocks of bits. CARD's format was strictly defined by it's transport mechanism, namely as options over ICMP ND messages. Once you liberate the application from that transport format, the disconnected blocks format doesn't make sense anymore. Something like EAP (after which NED is modelled) does. - CARD privileges certain network information elements (like resolution of AP addresses to AR addresses) above others. This is due to the built in design assumption that the primary application for CARD is a kind of cross-link ARP or ND to find the router's address (which, by the way, duplicates what FMIP does). Now, there is no reason to priviledge this particular application above others in 802.21 InfoElements, and NED doesn't. All applications use the IANA registry, and must be defined. NED still uses AP/BS addresses as the initial identifier for the network, because that is what the host will see so it is really the only way the host can tell the server what network it is interested in. - CARD has two ways to do capability querying (preferences and requirements). I've never seen the logic of having two ways to do the same thing, and despite the objections of an expert reviewer about the questionable nature of this design decision when Seamoby was completing the draft, the WG opted to include both in the final design. - CARD handles fragmentation of final results using a "context-id". This is necessary because of the blocks of bits format and ICMP transport. I think it makes more sense to define the InfoElements logically, and let the transport handle the fragmentation. - The length field in CARD options is 8 bits, due to the blocks of bits format. This required us to define the units of the length as "8 octets" which leads to some potential for wasted padding. We honestly *did* really try to use CARD for NED, in fact, I wrote an initial draft for it, but it was really not very satisfying from a design standpoint. So, in the end, the only thing we ended up reusing is the IANA registry for network capabilities and for L2 Technologies, because they are really crucial for exensibility. As to "how the proposed draft solves the 802.21 problems better than CARD", I'll leave answering that up to 802.21 people. Suffice to say, Rajeev and I believe NED does solve those problems, and we're prepared to work with 802.21 and MIPSHOP to fill any gaps that they may find. Also, BTW, I suggest you read Stefano and Greg's draft. They've also proposed an InfoElements protocol. jak ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: "'James Kempf'" ; Cc: ; "'Marco Liebsch'" ; "'Eunsoo Shim'" Sent: Tuesday, July 12, 2005 7:34 PM Subject: RE: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt > Hi James, > > I finally managed to read your proposed nhodd draft. > After reading the draft, I am not really convinced why we need to define a new CARD like protocol in IETF again. I am aware of IEEE 802.21 activity. I am still trying to understand how the newly proposed draft solves the problem of IEEE 802.21 any better than existing CARD protocol. In my view perhaps taking the CARD protocol to standard track is better idea than trying to invent a new protocol to solve the problem. > > Regards, > Ajoy > > -----Original Message----- > From: mobopts-bounces@rtf.org [mailto:mobopts-bounces@irtf.org] On Behalf Of James Kempf > Sent: Friday, July 08, 2005 11:05 AM > To: mipshop@ietf.org > Cc: mobopts@irtf.org > Subject: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt > > Folks, > > I've posted the Neighborhood Discovery draft by Rajeev and myself to the > Internet Drafts directory. Until it is available, you can find it here: > > http://www.geocities.com/kempf42/draft-kempf-mipshop-nhood-discovery-00.txt > > This is the same draft as I previously posted for Mobopts, except I changed > the filename to reflect the fact that this topic is now going to be > discussed in MIPSHOP (I think, discussion is still ongoing). > > This draft is intended to partially fufill the IEEE 802.21 requirement for > network information discovery. > > Please send comments if you have any. > > jak > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 13 20:49:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsrux-0002y1-9J; Wed, 13 Jul 2005 20:49:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsruv-0002xt-E9 for mobopts@megatron.ietf.org; Wed, 13 Jul 2005 20:49:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28157 for ; Wed, 13 Jul 2005 20:49:31 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DssNP-0000VG-M0 for mobopts@irtf.org; Wed, 13 Jul 2005 21:19:01 -0400 Received: from ep_ms3_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJL008HSEA56N@mailout1.samsung.com> for mobopts@irtf.org; Thu, 14 Jul 2005 09:49:17 +0900 (KST) Received: from ep_spt01 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJL00M7TEA5UE@ms3.samsung.com> for mobopts@irtf.org; Thu, 14 Jul 2005 09:49:17 +0900 (KST) Content-return: prohibited Date: Thu, 14 Jul 2005 00:48:01 +0000 (GMT) From: Daniel Park Subject: Re: Re: [Mobopts] New topics for the RG To: Rajeev Koodli Message-id: <0IJL00M7UEA5UE@ms3.samsung.com> MIME-version: 1.0 X-Priority: 3 Msgkey: 20050714004916750@soohong.park X-MTR: 20050714004916750@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.17 X-Spam-Score: 3.8 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Ji Zhang , "mobopts@irtf.org" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soohong.park@samsung.com List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0296117989==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org --===============0296117989== Content-return: prohibited Content-type: text/html; charset=windows-1252 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Samsung Enterprise Portal mySingle

>I think if there is interest in looking into the broader problem,
>it is worthwhile for MobOpts. Especially interesting would be
>the experimental results. My only caution is understanding the
>problem and its implications should take precedence over
>solutions.

I see, if this issue is too much large to be treated in

mobopts, then we can consider a new BoF in IETF.

But,  mobopts is still so perferable in my mind...

 

 

Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics

 

 


--===============0296117989== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============0296117989==-- From mobopts-bounces@irtf.org Thu Jul 14 11:33:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt5iF-0002X3-3C; Thu, 14 Jul 2005 11:33:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt5iD-0002WD-Rl; Thu, 14 Jul 2005 11:33:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22526; Thu, 14 Jul 2005 11:33:19 -0400 (EDT) From: stefano.faccin@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt6Ao-00071W-MR; Thu, 14 Jul 2005 12:02:57 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6EFTsvs013364; Thu, 14 Jul 2005 18:29:54 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 18:33:12 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 10:33:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mipshop] RE: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt Date: Thu, 14 Jul 2005 10:33:06 -0500 Message-ID: <33B0AB1B4BA65042831AE04C0836E2033BBB22@daebe101.NOE.Nokia.com> Thread-Topic: [Mipshop] RE: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt Thread-Index: AcWIiKBsZWL4uAlRT5axGpwcYBQI3AAAKZKA To: , , X-OriginalArrivalTime: 14 Jul 2005 15:33:06.0769 (UTC) FILETIME=[54FCFC10:01C58889] X-Spam-Score: 2.7 (++) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Content-Transfer-Encoding: quoted-printable Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Guys, do you mind if we copy these e-mails also on the MIHEP list? Thanks > -----Original Message----- > From: mipshop-bounces@ietf.org [mailto:mipshop-bounces@ietf.org]On > Behalf Of ext Singh Ajoy-ASINGH1 > Sent: Thursday, July 14, 2005 10:25 > To: 'James Kempf'; 'mipshop@ietf.org' > Cc: 'Marco Liebsch'; 'mobopts@irtf.org' > Subject: [Mipshop] RE: [Mobopts] > draft-kempf-mipshop-nhood-discovery-00.txt >=20 >=20 > Hi James,=20 >=20 > Please find my inline comments.=20 >=20 > Regards, > Ajoy=20 >=20 > -----Original Message----- > From: James Kempf [mailto:Kempf@docomolabs-usa.com]=20 > Sent: Wednesday, July 13, 2005 4:18 PM > To: Singh Ajoy-ASINGH1; mipshop@ietf.org > Cc: mobopts@irtf.org; 'Marco Liebsch'; 'Eunsoo Shim' > Subject: Re: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt >=20 > Hi Ajoy, >=20 > Here is a list of problems Rajeev and I had when we tried to=20 > use CARD to > define NED: >=20 > - The information source is always an AR. If the source is an=20 > "information > server" or an L2 device like an AP but with IP capability, or=20 > even involves > an L2.5 transport protocol like EAPoL, then CARD isn't=20 > relevent. But let's > suppose you can extract the options out of CARD and try to=20 > use them. Then > you run into the problems below. >=20 > Ajoy-> CARD is an IP layer protocol. Being a IP layer=20 > protocol, it can easily accommodate a scenario where MIH=20 > function is implemented on a standalone server or an AP that=20 > is reachable using IP based transport.=20 > Please note that 802.21 is defining MIH function for 802.XX,=20 > 3GPP2 and 3GPP and it is difficult to have a common MAC layer=20 > protocol that can be used in all of the above technologies.=20 > This was one of motivation why 802.21 is also looking at IP=20 > based transport. If this is not the case, you can extend=20 > 802.11 and 802.16 using MAC extension for the information service. =20 >=20 >=20 > - Most 802 protocols don't like the CARD format of a bunch of=20 > disconnected > blocks of bits. CARD's format was strictly defined by it's transport > mechanism, namely as options over ICMP ND messages. Once you=20 > liberate the > application from that transport format, the disconnected blocks format > doesn't make sense anymore. Something like EAP (after which=20 > NED is modelled) > does. >=20 > Ajoy-> I do not quite understand your argument here. CARD is=20 > using TLV encoding and TLV encoding is used in 802.11 as well=20 > as most of IP based protocol.=20 >=20 > - CARD privileges certain network information elements (like=20 > resolution of > AP addresses to AR addresses) above others. This is due to=20 > the built in > design assumption that the primary application for CARD is a kind of > cross-link ARP or ND to find the router's address (which, by the way, > duplicates what FMIP does). >=20 > Ajoy-> CARD is NOT limited to FMIPv6. CARD can be used to=20 > other mobility protocol as well.=20 >=20 >=20 > Now, there is no reason to priviledge this > particular application above others in 802.21 InfoElements,=20 > and NED doesn't. > All applications use the IANA registry, and must be defined.=20 > NED still uses > AP/BS addresses as the initial identifier for the network,=20 > because that is > what the host will see so it is really the only way the host=20 > can tell the > server what network it is interested in. > - CARD has two ways to do capability querying (preferences and > requirements). I've never seen the logic of having two ways=20 > to do the same > thing, and despite the objections of an expert reviewer about the > questionable nature of this design decision when Seamoby was=20 > completing the > draft, the WG opted to include both in the final design. >=20 > Ajoy-> Again, I do not understand your comment. Preference=20 > and requirements are two different things. We have explained=20 > this earlier as well. =20 >=20 > - CARD handles fragmentation of final results using a=20 > "context-id". This is > necessary because of the blocks of bits format and ICMP=20 > transport. I think > it makes more sense to define the InfoElements logically, and let the > transport handle the fragmentation. > - The length field in CARD options is 8 bits, due to the=20 > blocks of bits > format. This required us to define the units of the length as=20 > "8 octets" > which leads to some potential for wasted padding. >=20 > Ajoy-> This depends upon the actual capability being used.=20 > Some potential padding is always possible in any protocol so=20 > I do not why it is bad. =20 >=20 > We honestly *did* really try to use CARD for NED, in fact, I wrote an > initial draft for it, but it was really not very satisfying=20 > from a design > standpoint. So, in the end, the only thing we ended up=20 > reusing is the IANA > registry for network capabilities and for L2 Technologies,=20 > because they are > really crucial for extensibility. >=20 > Ajoy-> It would have been if you would involved CARD folks in=20 > this discussion as well. I can't comment about something that=20 > I am not really aware of.=20 >=20 > As to "how the proposed draft solves the 802.21 problems=20 > better than CARD", > I'll leave answering that up to 802.21 people.=20 >=20 >=20 > Ajoy-> I have been part of 802.21 discussion. I do represent=20 > here my view of 802.21.=20 >=20 > Suffice to say, Rajeev and I > believe NED does solve those problems, and we're prepared to work with > 802.21 and MIPSHOP to fill any gaps that they may find. >=20 > Also, BTW, I suggest you read Stefano and Greg's draft. They've also > proposed an InfoElements protocol. >=20 > Ajoy-> I will definitely do. In fact I had discussion with=20 > Stefano on 802.21 list about CARD.=20 >=20 > jak >=20 >=20 >=20 >=20 > ----- Original Message ----- > From: "Singh Ajoy-ASINGH1" > To: "'James Kempf'" ; > Cc: ; "'Marco Liebsch'"=20 > ; > "'Eunsoo Shim'" > Sent: Tuesday, July 12, 2005 7:34 PM > Subject: RE: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt >=20 >=20 > > Hi James, > > > > I finally managed to read your proposed nhodd draft. > > After reading the draft, I am not really convinced why we=20 > need to define a > new CARD like protocol in IETF again. I am aware of IEEE=20 > 802.21 activity. I > am still trying to understand how the newly proposed draft solves the > problem of IEEE 802.21 any better than existing CARD=20 > protocol. In my view > perhaps taking the CARD protocol to standard track is better idea than > trying to invent a new protocol to solve the problem. > > > > Regards, > > Ajoy > > > > -----Original Message----- > > From: mobopts-bounces@rtf.org=20 > [mailto:mobopts-bounces@irtf.org] On Behalf > Of James Kempf > > Sent: Friday, July 08, 2005 11:05 AM > > To: mipshop@ietf.org > > Cc: mobopts@irtf.org > > Subject: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt > > > > Folks, > > > > I've posted the Neighborhood Discovery draft by Rajeev and=20 > myself to the > > Internet Drafts directory. Until it is available, you can=20 > find it here: > > > > > http://www.geocities.com/kempf42/draft-kempf-mipshop-nhood-dis covery-00.txt > > This is the same draft as I previously posted for Mobopts, except I changed > the filename to reflect the fact that this topic is now going to be > discussed in MIPSHOP (I think, discussion is still ongoing). > > This draft is intended to partially fufill the IEEE 802.21 requirement = for > network information discovery. > > Please send comments if you have any. > > jak > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mipshop mailing list Mipshop@ietf.org https://www1.ietf.org/mailman/listinfo/mipshop _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jul 14 12:26:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt6XK-0007ri-Ei; Thu, 14 Jul 2005 12:26:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt6XI-0007rX-Ia; Thu, 14 Jul 2005 12:26:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26766; Thu, 14 Jul 2005 12:26:05 -0400 (EDT) Received: from oak.research.panasonic.com ([150.169.1.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt6zw-0000kb-Cw; Thu, 14 Jul 2005 12:55:44 -0400 Received: from redwood.research.panasonic.com (ftp.research.panasonic.com [150.169.3.2] (may be forged)) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j6EGPakn020602; Thu, 14 Jul 2005 12:25:36 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 5D5701E922B; Thu, 14 Jul 2005 12:16:29 -0400 (EDT) Received: from [150.169.17.2] (unknown [150.169.17.2])by redwood.research.panasonic.com (Postfix) with ESMTP id A08031E81A0; Thu, 14 Jul 2005 12:16:28 -0400 (EDT) Message-ID: <42D69201.8060109@research.panasonic.com> Date: Thu, 14 Jul 2005 12:25:37 -0400 From: Eunsoo Shim User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Singh Ajoy-ASINGH1 , "'James Kempf'" Subject: Re: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:6 M:0 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.4 (++) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Content-Transfer-Encoding: 7bit Cc: "'mipshop@ietf.org'" , "'mobopts@irtf.org'" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Please let me add a few comments in this discussion. My comments are inline. Regards, Eunsoo >Here is a list of problems Rajeev and I had when we tried to use CARD to >define NED: > >- The information source is always an AR. If the source is an "information >server" or an L2 device like an AP but with IP capability, or even involves >an L2.5 transport protocol like EAPoL, then CARD isn't relevent. But let's >suppose you can extract the options out of CARD and try to use them. Then >you run into the problems below. > >Ajoy-> CARD is an IP layer protocol. Being a IP layer protocol, it can easily accommodate a scenario where MIH function is implemented on a standalone server or an AP that is reachable using IP based transport. >Please note that 802.21 is defining MIH function for 802.XX, 3GPP2 and 3GPP and it is difficult to have a common MAC layer protocol that can be used in all of the above technologies. This was one of motivation why 802.21 is also looking at IP based transport. If this is not the case, you can extend 802.11 and 802.16 using MAC extension for the information service. > > > [eunsoo] Ajoy pointed out, CARD can be easily used for any network entity in addition to ARs, that is, CARD can be used between the MN and "the information server for 802.21 IS". >- Most 802 protocols don't like the CARD format of a bunch of disconnected >blocks of bits. CARD's format was strictly defined by it's transport >mechanism, namely as options over ICMP ND messages. Once you liberate the >application from that transport format, the disconnected blocks format >doesn't make sense anymore. Something like EAP (after which NED is modelled) >does. > >Ajoy-> I do not quite understand your argument here. CARD is using TLV encoding and TLV encoding is used in 802.11 as well as most of IP based protocol. CARD options have been used over ICMP on MN-AR interface and over SCTP/UDP over AR-AR interface. > > > [eunsoo] The CARD specification (rfc4066) shows how the CARD message can be delivered over SCTP and ICMP. I understand Marco implemented CARD on top of UDP and used it for his experiment. Based on this fact, I don't quite understand James' comment saying "CARD's format was strictly defined by its transport mechanism". >- CARD privileges certain network information elements (like resolution of >AP addresses to AR addresses) above others. This is due to the built in >design assumption that the primary application for CARD is a kind of >cross-link ARP or ND to find the router's address (which, by the way, >duplicates what FMIP does). > >Ajoy-> CARD is NOT limited to FMIPv6. It can be used to other mobility protocol as well. > > > [eunsoo] I clearly said in the past during the discussion in the SeaMoby WG that CARD's functionality was collecting information about access networking (covering L2 as well as L3 information) and distributing the information. Mapping AP addresses to AR IP addresses is a part of the functionality. CARD can support FMIP very well, which is an important advantage of CARD. Moreover, CARD can be used for any application that requires information about the current and neighboring access points and access routers. It is apparant that CARD can deliver even information about the whole access network. > Now, there is no reason to priviledge this >particular application above others in 802.21 InfoElements, and NED doesn't. > > [eunsoo] As said above, CARD can support both of FMIP and 802.21 IS well. Supporting FMIP very well is not a problem but rather an advantage since fast handoff is important obviously. >All applications use the IANA registry, and must be defined. NED still uses >AP/BS addresses as the initial identifier for the network, because that is >what the host will see so it is really the only way the host can tell the >server what network it is interested in. >- CARD has two ways to do capability querying (preferences and >requirements). I've never seen the logic of having two ways to do the same >thing, and despite the objections of an expert reviewer about the >questionable nature of this design decision when Seamoby was completing the >draft, the WG opted to include both in the final design. > >Ajoy-> Again, I do not understand your comment. Preference and requirements are two different things. We have explained this earlier as well. > > [eunsoo] 802.21 is talking about filters for 802.21 IS. The Preferences and Requirements Suboptions of CARD are filters that can satisfy the filter functionality of 802.21 IS. >- CARD handles fragmentation of final results using a "context-id". This is >necessary because of the blocks of bits format and ICMP transport. I think >it makes more sense to define the InfoElements logically, and let the >transport handle the fragmentation. >- The length field in CARD options is 8 bits, due to the blocks of bits >format. This required us to define the units of the length as "8 octets" >which leads to some potential for wasted padding. > >Ajoy-> This depends upon the actual capability being used. Some potential padding is always possible in any protocol so I do not see why it is bad. > >We honestly *did* really try to use CARD for NED, in fact, I wrote an >initial draft for it, but it was really not very satisfying from a design >standpoint. So, in the end, the only thing we ended up reusing is the IANA >registry for network capabilities and for L2 Technologies, because they are >really crucial for extensibility. > >Ajoy-> It would have been nice if you would have involved CARD folks in this discussion as well. I can't comment about something that I am not really aware of. > >As to "how the proposed draft solves the 802.21 problems better than CARD", >I'll leave answering that up to 802.21 people. > > >Ajoy-> I have been part of 802.21 discussion. I do represent here my view of 802.21. > >Suffice to say, Rajeev and I >believe NED does solve those problems, and we're prepared to work with >802.21 and MIPSHOP to fill any gaps that they may find. > >Also, BTW, I suggest you read Stefano and Greg's draft. They've also >proposed an InfoElements protocol. > >Ajoy-> I will definitely do so. In fact I had discussion with Stefano on 802.21 list about CARD. > > jak > > > > >----- Original Message ----- >From: "Singh Ajoy-ASINGH1" >To: "'James Kempf'" ; >Cc: ; "'Marco Liebsch'" ; >"'Eunsoo Shim'" >Sent: Tuesday, July 12, 2005 7:34 PM >Subject: RE: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt > > > > >>Hi James, >> >>I finally managed to read your proposed nhodd draft. >>After reading the draft, I am not really convinced why we need to define a >> >> >new CARD like protocol in IETF again. I am aware of IEEE 802.21 activity. I >am still trying to understand how the newly proposed draft solves the >problem of IEEE 802.21 any better than existing CARD protocol. In my view >perhaps taking the CARD protocol to standard track is better idea than >trying to invent a new protocol to solve the problem. > > >>Regards, >>Ajoy >> >>-----Original Message----- >>From: mobopts-bounces@rtf.org [mailto:mobopts-bounces@irtf.org] On Behalf >> >> >Of James Kempf > > >>Sent: Friday, July 08, 2005 11:05 AM >>To: mipshop@ietf.org >>Cc: mobopts@irtf.org >>Subject: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt >> >>Folks, >> >>I've posted the Neighborhood Discovery draft by Rajeev and myself to the >>Internet Drafts directory. Until it is available, you can find it here: >> >> >> >> >http://www.geocities.com/kempf42/draft-kempf-mipshop-nhood-discovery-00.txt > > >>This is the same draft as I previously posted for Mobopts, except I >> >> >changed > > >>the filename to reflect the fact that this topic is now going to be >>discussed in MIPSHOP (I think, discussion is still ongoing). >> >>This draft is intended to partially fufill the IEEE 802.21 requirement for >>network information discovery. >> >>Please send comments if you have any. >> >> jak >> >> >>_______________________________________________ >>Mobopts mailing list >>Mobopts@irtf.org >>https://www1.ietf.org/mailman/listinfo/mobopts >> >> >> > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jul 14 13:05:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt79r-0005JC-KP; Thu, 14 Jul 2005 13:05:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt79o-0005J4-UA; Thu, 14 Jul 2005 13:05:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29495; Thu, 14 Jul 2005 13:05:54 -0400 (EDT) From: stefano.faccin@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt7cS-00029B-Vc; Thu, 14 Jul 2005 13:35:33 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6EH2PGs026634; Thu, 14 Jul 2005 20:02:30 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 20:05:44 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 12:05:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: [Mipshop] RE: [Mobopts] Interest in protocols for IEEE 802.21 IS, CS, ES Date: Thu, 14 Jul 2005 12:05:39 -0500 Message-ID: <33B0AB1B4BA65042831AE04C0836E2035F86C0@daebe101.NOE.Nokia.com> Thread-Topic: RE: [Mipshop] RE: [Mobopts] Interest in protocols for IEEE 802.21 IS, CS, ES Thread-Index: AcWIj3v7JTwteuTKRretTqV4uFv5ZAABcz+a References: To: , X-OriginalArrivalTime: 14 Jul 2005 17:05:40.0299 (UTC) FILETIME=[432669B0:01C58896] X-Spam-Score: 2.7 (++) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Content-Transfer-Encoding: quoted-printable Cc: dna@eng.monash.edu.au, mipshop@ietf.org, margaret@thingmagic.com, Basavaraj.Patil@nokia.com, mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Ajoy, Daniel, I guees perhaps we're diverging a bit. Please keep in mind that MIHEP = has been proposed exactly to discuss these aspects, since 802.21 cannot = by itself define L3 and above protocols. Daniel, even if L3 and above = protocols are outside the scope of 802.21, 802.21 has unique knowledge = of the requirements for L3 transport of its services. we're not saying = that 802.21 shall specify such protocols, but that close coordination = would be beneficial. At the same time, 802.21 needs help from IETF to = ensure that its services will be transported over L3. I am copying also = the MIHEP list, so other people interested in this discussion are also = copied. =20 Stefano =20 P.S. here is the information for the MIHEP (Media Independent Handoff = Enabling Protocols) mailing list. To subscribe, send an e-mail to majordomo@ecselists.eng.monash.edu.au, = with the words "subscribe mihep" in the message body. A confirmation = e-mail will be sent to you. To post, send an e-mail to mihep@eng.monash.edu.au. The mailing list archive can be found on the WWW at: = http://ecselists.eng.monash.edu.au/~warchive/mihep. =20 ________________________________ From: mipshop-bounces@ietf.org on behalf of ext Singh Ajoy-ASINGH1 Sent: Wed 7/13/2005 1:07 PM To: 'soohong.park@samsung.com' Cc: 'margaret@thingmagic.com'; 'mipshop@ietf.org'; = 'kempf@docomolabs-usa.com'; 'Marco Liebsch'; 'rajeev@iprg.nokia.com'; = 'dna@eng.monash.edu.au'; 'gabriel_montenegro_2000@yahoo.com'; Patil = Basavaraj (Nokia-NET/Dallas); 'mobopts@irtf.org' Subject: RE: RE: [Mipshop] RE: [Mobopts] Interest in protocols for IEEE = 802.21 IS, CS, ES Soohong, If MIHEP is not going to discuss IP layer protocol then why are we = proposing MIH as an IETF BOF. Please clarify. I have access to IEEE = 802.21 spec so I know about it. The suggested spec does not rule out the = possibility of Layer 3 transport. Please refer to table on page 63.=20 Regards, Ajoy -----Original Message----- From: soohong.park@samsung.com [mailto:soohong.park@samsung.com] Sent: Wednesday, July 13, 2005 12:05 PM To: Singh Ajoy-ASINGH1 Cc: 'Michael.G.Williams@nokia.com'; 'mipshop@ietf.org'; = 'mobopts@irtf.org'; 'dna@eng.monash.edu.au'; 'kempf@docomolabs-usa.com'; = 'Marco Liebsch'; 'rajeev@iprg.nokia.com'; 'margaret@thingmagic.com'; = 'gabriel_montenegro_2000@yahoo.com'; 'Basavaraj.Patil@nokia.com' Subject: Re: RE: [Mipshop] RE: [Mobopts] Interest in protocols for IEEE = 802.21 IS, CS, ES >However, I do not think that using IP transport is ruled out >by existing IEEE 802.21 spec. If we use IP transport then why >can't CARD be used. Singh, I didn't say *ruled out by 802.21*. Please remind that layer 3 and higher layer protocol are beyond scope of 802.21 specification. 802.21 is to define a media independent handover architecture on the layer 2.5. (21-05-0240-01-0000-Joint_Harmonized_MIH_Proposal_Draft_Text) I am not sure but MIHEN is able to be an available place to discuss what you concern. Regards, Daniel (SoohongDaniel Park) Mobile PlatformLaboratory. SAMSUNG Electronics ------- Original Message ------- Sender : SinghAjoy-ASINGH1 Date : Jul 13, 2005 13:07 Title : [Mipshop] RE: [Mobopts]Interest in protocols for IEEE 802.21 IS, = CS, ES Hi Michael, I do not see any mention of CARD protocol here. I think CARD is more = appropriate candidate for IEEE 802.21 information service protocol. CARD = is now published as experimental RFC. So, I would request that we should = focus to advance CARD protocol to standard track and then use CARD for = information service unless we can really find good reason to define a = new protocol. Perhaps you might remember that I have mentioned use of CARD protocol in = one of earlier IEEE 802.21 meetings but I could not continue to = participate in subsequent IEEE meeting due to personal reason. Regards, Ajoy -----Original Message----- From: mobopts-bounces@irtf.org [mailto:mobopts-bounces@irtf.org] On = Behalf Of Michael.G.Williams@nokia.com Sent: Wednesday, July 06, 2005 5:02 PM To: mipshop@ietf.org; mobopts@irtf.org; dna@eng.monash.edu.au Cc: kempf@docomolabs-usa.com; gabriel_montenegro_2000@yahoo.com; = rajeev@iprg.nokia.com; margaret@thingmagic.com; = Basavaraj.Patil@nokia.com Subject: [Mobopts] Interest in protocols for IEEE 802.21 IS, CS, ES Colleagues, The IEEE 802.21 working group is developing services for facilitating IP address mobility and service mobility, especially handoff across a variety of media. The group is interested in working with the relevant IETF/IRTF working groups to develop methods of carrying these services across the network. It would be ideal to discuss this at the next IETF meeting. There are multiple drafts currently issued or in development that are interesting and could serve as the basis for starting the work. =20 Drafts of interest include but are not limited to : "Neighborhood Information Elements Discovery (NED) (draft-kempf-mobopts-nhood-discovery-00.txt), which provides a generic protocol for carrying information elements of interest to IEEE 802.21." "Some Requirements for a Media Independent Handover Information Service" (draft-faccin-mih-infoserv-00.txt, http://www.ctie.monash.edu.au/dna/draft-faccin-mih-infoserv-00.txt ). "Architectural Implications of Link Indications" http://www.iab.org/documents/drafts/draft-iab-link-indications-01.txt "Unified L2 Abstractions for L3-Driven Fast Handover" http://www.ietf.org/internet-drafts/draft-koki-mobopts-l2-abstractions-0 2.txt "A Framework of Media-Independent Pre-Authentication (MPA)" http://www.ietf.org/internet-drafts/draft-ohba-mobopts-mpa-framework-00. txt Best Regards, Michael G. Williams IEEE 802.21 Working Group Vice Chair _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mipshop mailing list Mipshop@ietf.org https://www1.ietf.org/mailman/listinfo/mipshop =20 Regards =20 Regards =20 Daniel (Soohong Daniel Park) Mobile Platform Laboratory. SAMSUNG Electronics _______________________________________________ Mipshop mailing list Mipshop@ietf.org https://www1.ietf.org/mailman/listinfo/mipshop _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jul 14 14:04:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt84q-0004c7-LB; Thu, 14 Jul 2005 14:04:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt84o-0004bu-Rt; Thu, 14 Jul 2005 14:04:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05242; Thu, 14 Jul 2005 14:04:49 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt8XS-0004po-S7; Thu, 14 Jul 2005 14:34:28 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6EHWug26531; Thu, 14 Jul 2005 10:32:56 -0700 X-mProtect: <200507141732> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14166.americas.nokia.com (172.18.141.66, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdtbuoSd; Thu, 14 Jul 2005 10:32:53 PDT Message-ID: <42D6A923.4050307@iprg.nokia.com> Date: Thu, 14 Jul 2005 11:04:19 -0700 From: Rajeev Koodli 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: Singh Ajoy-ASINGH1 References: In-Reply-To: X-Spam-Score: 2.9 (++) X-Scan-Signature: af2aae76ea468dc53420d9ba52ca6045 Cc: "'mipshop@ietf.org'" , 'James Kempf' , "'mobopts@irtf.org'" Subject: [Mobopts] Re: draft-kempf-mipshop-nhood-discovery-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1280250742==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org This is a multi-part message in MIME format. --===============1280250742== Content-Type: multipart/alternative; boundary="------------080301080901070703020607" This is a multi-part message in MIME format. --------------080301080901070703020607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ajoy, the motivation behind the NED draft was to - present a single protocol framework for carrying Request-Reply messages between peers in a transport-independent fashion. This came about from a prolonged discussion regarding recharter items for MIPSHOP. I did not hear from you then.. - allow FMIP, CARD and 802.21 all to use a transport-independent protocol that defines message format and option formats. Each protocol can then define and use its own transport for its purpose. All three have their own purpose. - FMIP is interested solely in subnet information corresponding to an an AP-ID for fast routing purposes - CARD is interested is using the neighborhood information for target router selection. If this is *not* the primary purpose of CARD, then I question its relevance here. - 802.21 is interested in the IS, where .21-specific payload query and responses need to be supported. And, an L3 protocol does not exist yet. - make use of the common IANA registry for allocating Type numbers for protocol-specific messages and options. As it has turned out, the above protocols were not designed with a harmonized message and option format in mind. One could argue that FMIP or CARD _can be made to serve that purpose_, but that's a topic of past discussion. We have decided to split the task into "generic message structure" and "protocol-specific carrier", and believe that CARD should also benefit from it. As FMIP editor, I am comfortable moving forward with NED as a starting point. I see CARD as a potential companion protocol which can help a Mobile Node in selecting a target router. I don't see it as the protocol framework for other protocols to use. Regards, -Rajeev Singh Ajoy-ASINGH1 wrote: >Hi James, > >Please find my inline comments. > >Regards, >Ajoy > >-----Original Message----- >From: James Kempf [mailto:Kempf@docomolabs-usa.com] >Sent: Wednesday, July 13, 2005 4:18 PM >To: Singh Ajoy-ASINGH1; mipshop@ietf.org >Cc: mobopts@irtf.org; 'Marco Liebsch'; 'Eunsoo Shim' >Subject: Re: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt > >Hi Ajoy, > >Here is a list of problems Rajeev and I had when we tried to use CARD to >define NED: > >- The information source is always an AR. If the source is an "information >server" or an L2 device like an AP but with IP capability, or even involves >an L2.5 transport protocol like EAPoL, then CARD isn't relevent. But let's >suppose you can extract the options out of CARD and try to use them. Then >you run into the problems below. > >Ajoy-> CARD is an IP layer protocol. Being a IP layer protocol, it can easily accommodate a scenario where MIH function is implemented on a standalone server or an AP that is reachable using IP based transport. >Please note that 802.21 is defining MIH function for 802.XX, 3GPP2 and 3GPP and it is difficult to have a common MAC layer protocol that can be used in all of the above technologies. This was one of motivation why 802.21 is also looking at IP based transport. If this is not the case, you can extend 802.11 and 802.16 using MAC extension for the information service. > > >- Most 802 protocols don't like the CARD format of a bunch of disconnected >blocks of bits. CARD's format was strictly defined by it's transport >mechanism, namely as options over ICMP ND messages. Once you liberate the >application from that transport format, the disconnected blocks format >doesn't make sense anymore. Something like EAP (after which NED is modelled) >does. > >Ajoy-> I do not quite understand your argument here. CARD is using TLV encoding and TLV encoding is used in 802.11 as well as most of IP based protocol. > >- CARD privileges certain network information elements (like resolution of >AP addresses to AR addresses) above others. This is due to the built in >design assumption that the primary application for CARD is a kind of >cross-link ARP or ND to find the router's address (which, by the way, >duplicates what FMIP does). > >Ajoy-> CARD is NOT limited to FMIPv6. CARD can be used to other mobility protocol as well. > > > Now, there is no reason to priviledge this >particular application above others in 802.21 InfoElements, and NED doesn't. >All applications use the IANA registry, and must be defined. NED still uses >AP/BS addresses as the initial identifier for the network, because that is >what the host will see so it is really the only way the host can tell the >server what network it is interested in. >- CARD has two ways to do capability querying (preferences and >requirements). I've never seen the logic of having two ways to do the same >thing, and despite the objections of an expert reviewer about the >questionable nature of this design decision when Seamoby was completing the >draft, the WG opted to include both in the final design. > >Ajoy-> Again, I do not understand your comment. Preference and requirements are two different things. We have explained this earlier as well. > >- CARD handles fragmentation of final results using a "context-id". This is >necessary because of the blocks of bits format and ICMP transport. I think >it makes more sense to define the InfoElements logically, and let the >transport handle the fragmentation. >- The length field in CARD options is 8 bits, due to the blocks of bits >format. This required us to define the units of the length as "8 octets" >which leads to some potential for wasted padding. > >Ajoy-> This depends upon the actual capability being used. Some potential padding is always possible in any protocol so I do not why it is bad. > >We honestly *did* really try to use CARD for NED, in fact, I wrote an >initial draft for it, but it was really not very satisfying from a design >standpoint. So, in the end, the only thing we ended up reusing is the IANA >registry for network capabilities and for L2 Technologies, because they are >really crucial for extensibility. > >Ajoy-> It would have been if you would involved CARD folks in this discussion as well. I can't comment about something that I am not really aware of. > >As to "how the proposed draft solves the 802.21 problems better than CARD", >I'll leave answering that up to 802.21 people. > > >Ajoy-> I have been part of 802.21 discussion. I do represent here my view of 802.21. > >Suffice to say, Rajeev and I >believe NED does solve those problems, and we're prepared to work with >802.21 and MIPSHOP to fill any gaps that they may find. > >Also, BTW, I suggest you read Stefano and Greg's draft. They've also >proposed an InfoElements protocol. > >Ajoy-> I will definitely do. In fact I had discussion with Stefano on 802.21 list about CARD. > > jak > > > > >----- Original Message ----- >From: "Singh Ajoy-ASINGH1" >To: "'James Kempf'" ; >Cc: ; "'Marco Liebsch'" ; >"'Eunsoo Shim'" >Sent: Tuesday, July 12, 2005 7:34 PM >Subject: RE: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt > > > > >>Hi James, >> >>I finally managed to read your proposed nhodd draft. >>After reading the draft, I am not really convinced why we need to define a >> >> >new CARD like protocol in IETF again. I am aware of IEEE 802.21 activity. I >am still trying to understand how the newly proposed draft solves the >problem of IEEE 802.21 any better than existing CARD protocol. In my view >perhaps taking the CARD protocol to standard track is better idea than >trying to invent a new protocol to solve the problem. > > >>Regards, >>Ajoy >> >>-----Original Message----- >>From: mobopts-bounces@rtf.org [mailto:mobopts-bounces@irtf.org] On Behalf >> >> >Of James Kempf > > >>Sent: Friday, July 08, 2005 11:05 AM >>To: mipshop@ietf.org >>Cc: mobopts@irtf.org >>Subject: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt >> >>Folks, >> >>I've posted the Neighborhood Discovery draft by Rajeev and myself to the >>Internet Drafts directory. Until it is available, you can find it here: >> >> >> >> >http://www.geocities.com/kempf42/draft-kempf-mipshop-nhood-discovery-00.txt > > >>This is the same draft as I previously posted for Mobopts, except I >> >> >changed > > >>the filename to reflect the fact that this topic is now going to be >>discussed in MIPSHOP (I think, discussion is still ongoing). >> >>This draft is intended to partially fufill the IEEE 802.21 requirement for >>network information discovery. >> >>Please send comments if you have any. >> >> jak >> >> >>_______________________________________________ >>Mobopts mailing list >>Mobopts@irtf.org >>https://www1.ietf.org/mailman/listinfo/mobopts >> >> >> > > >_______________________________________________ >Mipshop mailing list >Mipshop@ietf.org >https://www1.ietf.org/mailman/listinfo/mipshop > > --------------080301080901070703020607 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Ajoy,

the motivation behind the NED draft was to

- present a single protocol framework for carrying Request-Reply
  messages between peers in a transport-independent fashion. This
  came about from a prolonged discussion regarding recharter items
  for MIPSHOP. I did not hear from you then..
- allow FMIP, CARD and 802.21 all to use a transport-independent protocol
   that defines message format and option formats. Each protocol can then
   define and use its own transport for its purpose. All three have their own
   purpose.
   - FMIP is interested solely in subnet information corresponding to an
      an AP-ID for fast routing purposes
   - CARD is interested is using the neighborhood information for target
      router selection. If this is *not* the primary purpose of CARD, then I
      question its relevance here.
   - 802.21 is interested in the IS, where .21-specific payload query and
      responses need to be supported. And, an L3 protocol does not exist yet.
- make use of the common IANA registry for allocating Type numbers for
   protocol-specific messages and options.

As it has turned out, the above protocols were not designed with a harmonized
message and option format in mind. One could argue that FMIP or CARD
_can be made to serve that purpose_, but that's a topic of past discussion.
We have decided to split the task into "generic message structure" and
"protocol-specific carrier", and believe that CARD should also benefit from it.

As FMIP editor, I am comfortable moving forward with NED as a
starting point. I see CARD as a potential companion protocol which
can help a Mobile Node in selecting a target router. I don't see it as the
protocol framework for other protocols to use.

Regards,

-Rajeev


Singh Ajoy-ASINGH1 wrote:
Hi James, 

Please find my inline comments. 

Regards,
Ajoy 

-----Original Message-----
From: James Kempf [mailto:Kempf@docomolabs-usa.com] 
Sent: Wednesday, July 13, 2005 4:18 PM
To: Singh Ajoy-ASINGH1; mipshop@ietf.org
Cc: mobopts@irtf.org; 'Marco Liebsch'; 'Eunsoo Shim'
Subject: Re: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt

Hi Ajoy,

Here is a list of problems Rajeev and I had when we tried to use CARD to
define NED:

- The information source is always an AR. If the source is an "information
server" or an L2 device like an AP but with IP capability, or even involves
an L2.5 transport protocol like EAPoL, then CARD isn't relevent. But let's
suppose you can extract the options out of CARD and try to use them. Then
you run into the problems below.

Ajoy-> CARD is an IP layer protocol. Being a IP layer protocol, it can easily accommodate a scenario where MIH function is implemented on a standalone server or an AP that is reachable using IP based transport. 
Please note that 802.21 is defining MIH function for 802.XX, 3GPP2 and 3GPP and it is difficult to have a common MAC layer protocol that can be used in all of the above technologies. This was one of motivation why 802.21 is also looking at IP based transport. If this is not the case, you can extend 802.11 and 802.16 using MAC extension for the information service.  


- Most 802 protocols don't like the CARD format of a bunch of disconnected
blocks of bits. CARD's format was strictly defined by it's transport
mechanism, namely as options over ICMP ND messages. Once you liberate the
application from that transport format, the disconnected blocks format
doesn't make sense anymore. Something like EAP (after which NED is modelled)
does.

Ajoy-> I do not quite understand your argument here. CARD is using TLV encoding and TLV encoding is used in 802.11 as well as most of IP based protocol. 

- CARD privileges certain network information elements (like resolution of
AP addresses to AR addresses) above others. This is due to the built in
design assumption that the primary application for CARD is a kind of
cross-link ARP or ND to find the router's address (which, by the way,
duplicates what FMIP does).

Ajoy-> CARD is NOT limited to FMIPv6. CARD can be used to other mobility protocol as well. 


 Now, there is no reason to priviledge this
particular application above others in 802.21 InfoElements, and NED doesn't.
All applications use the IANA registry, and must be defined. NED still uses
AP/BS addresses as the initial identifier for the network, because that is
what the host will see so it is really the only way the host can tell the
server what network it is interested in.
- CARD has two ways to do capability querying (preferences and
requirements). I've never seen the logic of having two ways to do the same
thing, and despite the objections of an expert reviewer about the
questionable nature of this design decision when Seamoby was completing the
draft, the WG opted to include both in the final design.

Ajoy-> Again, I do not understand your comment. Preference and requirements are two different things. We have explained this earlier as well.  

-  CARD handles fragmentation of final results using a "context-id". This is
necessary because of the blocks of bits format and ICMP transport. I think
it makes more sense to define the InfoElements logically, and let the
transport handle the fragmentation.
- The length field in CARD options is 8 bits, due to the blocks of bits
format. This required us to define the units of the length as "8 octets"
which leads to some potential for wasted padding.

Ajoy-> This depends upon the actual capability being used. Some potential padding is always possible in any protocol so I do not why it is bad.  

We honestly *did* really try to use CARD for NED, in fact, I wrote an
initial draft for it, but it was really not very satisfying from a design
standpoint. So, in the end, the only thing we ended up reusing is the IANA
registry for network capabilities and for L2 Technologies, because they are
really crucial for extensibility.

Ajoy-> It would have been if you would involved CARD folks in this discussion as well. I can't comment about something that I am not really aware of. 

As to "how the proposed draft solves the 802.21 problems better than CARD",
I'll leave answering that up to 802.21 people. 


Ajoy-> I have been part of 802.21 discussion. I do represent here my view of 802.21. 

Suffice to say, Rajeev and I
believe NED does solve those problems, and we're prepared to work with
802.21 and MIPSHOP to fill any gaps that they may find.

Also, BTW, I suggest you read Stefano and Greg's draft. They've also
proposed an InfoElements protocol.

Ajoy-> I will definitely do. In fact I had discussion with Stefano on 802.21 list about CARD. 

            jak




----- Original Message -----
From: "Singh Ajoy-ASINGH1" <ASINGH1@motorola.com>
To: "'James Kempf'" <kempf@docomolabs-usa.com>; <mipshop@ietf.org>
Cc: <mobopts@irtf.org>; "'Marco Liebsch'" <marco.liebsch@netlab.nec.de>;
"'Eunsoo Shim'" <eunsoo@research.panasonic.com>
Sent: Tuesday, July 12, 2005 7:34 PM
Subject: RE: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt


  
Hi James,

I finally managed to read your proposed nhodd draft.
After reading the draft, I am not really convinced why we need to define a
    
new CARD like protocol in IETF again. I am aware of IEEE 802.21 activity. I
am still trying to understand how the newly proposed draft solves the
problem of IEEE 802.21 any better than existing CARD protocol. In my view
perhaps taking the CARD protocol to standard track is better idea than
trying to invent a new protocol to solve the problem.
  
Regards,
Ajoy

-----Original Message-----
From: mobopts-bounces@rtf.org [mailto:mobopts-bounces@irtf.org] On Behalf
    
Of James Kempf
  
Sent: Friday, July 08, 2005 11:05 AM
To: mipshop@ietf.org
Cc: mobopts@irtf.org
Subject: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt

Folks,

I've posted the Neighborhood Discovery draft by Rajeev and myself to the
Internet Drafts directory. Until it is available, you can find it here:


    
http://www.geocities.com/kempf42/draft-kempf-mipshop-nhood-discovery-00.txt
  
This is the same draft as I previously posted for Mobopts, except I
    
changed
  
the filename to reflect the fact that this topic is now going to be
discussed in MIPSHOP (I think, discussion is still ongoing).

This draft is intended to partially fufill the IEEE 802.21 requirement for
network information discovery.

Please send comments if you have any.

            jak


_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts

    


_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop
--------------080301080901070703020607-- --===============1280250742== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============1280250742==-- From mobopts-bounces@irtf.org Thu Jul 14 17:40:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtBRm-0006XK-55; Thu, 14 Jul 2005 17:40:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtBRj-0006OH-BI for mobopts@megatron.ietf.org; Thu, 14 Jul 2005 17:40:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00721 for ; Thu, 14 Jul 2005 17:40:40 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtBuP-0000AC-2G for mobopts@irtf.org; Thu, 14 Jul 2005 18:10:21 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6EL8oc26811; Thu, 14 Jul 2005 14:08:50 -0700 X-mProtect: <200507142108> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14166.americas.nokia.com (172.18.141.66, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdTFkgYa; Thu, 14 Jul 2005 14:08:47 PDT Message-ID: <42D6DBBE.60006@iprg.nokia.com> Date: Thu, 14 Jul 2005 14:40:14 -0700 From: Rajeev Koodli 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: soohong.park@samsung.com Subject: Re: [Mobopts] New topics for the RG References: <0IJL00M7UEA5UE@ms3.samsung.com> In-Reply-To: <0IJL00M7UEA5UE@ms3.samsung.com> X-Spam-Score: 3.4 (+++) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: Ji Zhang , "mobopts@irtf.org" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0379697683==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org This is a multi-part message in MIME format. --===============0379697683== Content-Type: multipart/alternative; boundary="------------060604080901050205070309" This is a multi-part message in MIME format. --------------060604080901050205070309 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Daniel Park wrote: > >I think if there is interest in looking into the broader problem, > >it is worthwhile for MobOpts. Especially interesting would be > >the experimental results. My only caution is understanding the > >problem and its implications should take precedence over > >solutions. > > I see, if this issue is too much large to be treated in > > mobopts, then we can consider a new BoF in IETF. > > But, mobopts is still so perferable in my mind... > Let me clarify. I didn't imply that it is too big for MobOpts. On the other hand, it would be worthwhile to investigate the problem space and solutions, in that order. Hope this helps. -Rajeev > > > > > Regards > > > > Daniel (Soohong Daniel Park) > > Mobile Platform Laboratory. SAMSUNG Electronics > > > > > > >------------------------------------------------------------------------ > >_______________________________________________ >Mobopts mailing list >Mobopts@irtf.org >https://www1.ietf.org/mailman/listinfo/mobopts > > --------------060604080901050205070309 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Daniel Park wrote:
Samsung Enterprise Portal mySingle

>I think if there is interest in looking into the broader problem,
>it is worthwhile for MobOpts. Especially interesting would be
>the experimental results. My only caution is understanding the
>problem and its implications should take precedence over
>solutions.

I see, if this issue is too much large to be treated in

mobopts, then we can consider a new BoF in IETF.

But, mobopts is still so perferable in my mind...

Let me clarify. I didn't imply that it is too big
for MobOpts. On the other hand, it would be
worthwhile to investigate the problem space and
solutions, in that order.
Hope this helps.

-Rajeev

Regards

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics



_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts
--------------060604080901050205070309-- --===============0379697683== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============0379697683==-- From mobopts-bounces@irtf.org Thu Jul 14 17:55:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtBfy-0004Rq-W9; Thu, 14 Jul 2005 17:55:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtBfw-0004PL-Pz for mobopts@megatron.ietf.org; Thu, 14 Jul 2005 17:55:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09204 for ; Thu, 14 Jul 2005 17:55:22 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtC8c-0003Cu-HX for mobopts@irtf.org; Thu, 14 Jul 2005 18:25:03 -0400 Message-ID: <0e3601c588be$b6522e10$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Singh Ajoy-ASINGH1" , References: Subject: Re: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt Date: Thu, 14 Jul 2005 14:55:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Ajoy, > - The information source is always an AR. If the source is an "information > server" or an L2 device like an AP but with IP capability, or even involves > an L2.5 transport protocol like EAPoL, then CARD isn't relevent. But let's > suppose you can extract the options out of CARD and try to use them. Then > you run into the problems below. > > Ajoy-> CARD is an IP layer protocol. Being a IP layer protocol, it can easily accommodate a scenario where MIH function is implemented on a standalone server or an AP that is reachable using IP based transport. > Please note that 802.21 is defining MIH function for 802.XX, 3GPP2 and 3GPP and it is difficult to have a common MAC layer protocol that can be used in all of the above technologies. This was one of motivation why 802.21 is also looking at IP based transport. If this is not the case, you can extend 802.11 and 802.16 using MAC extension for the information service. > I believe Mike responded on this. > > - Most 802 protocols don't like the CARD format of a bunch of disconnected > blocks of bits. CARD's format was strictly defined by it's transport > mechanism, namely as options over ICMP ND messages. Once you liberate the > application from that transport format, the disconnected blocks format > doesn't make sense anymore. Something like EAP (after which NED is modelled) > does. > > Ajoy-> I do not quite understand your argument here. CARD is using TLV encoding and TLV encoding is used in 802.11 as well as most of IP based protocol. CARD options have been used over ICMP on MN-AR interface and over SCTP/UDP over AR-AR interface. > The on-the-wire format of CARD is based on RFC 2461 Options. That isn't an appropriate format for a widely applicable solution, especially for 802.21. > - CARD privileges certain network information elements (like resolution of > AP addresses to AR addresses) above others. This is due to the built in > design assumption that the primary application for CARD is a kind of > cross-link ARP or ND to find the router's address (which, by the way, > duplicates what FMIP does). > > Ajoy-> CARD is NOT limited to FMIPv6. It can be used to other mobility protocol as well. > I guess I didn't make my point very well. My main point is that CARD has singled out a specific application - cross link ARP - and designed in specific option types for that - L2 ID and Address - while others are carried in the Capability Container. From the point of view of a generalized protocol, that doesn't make much sense. It only makes much sense if one knows the history of CARD. > > Now, there is no reason to priviledge this > particular application above others in 802.21 InfoElements, and NED doesn't. > All applications use the IANA registry, and must be defined. NED still uses > AP/BS addresses as the initial identifier for the network, because that is > what the host will see so it is really the only way the host can tell the > server what network it is interested in. > - CARD has two ways to do capability querying (preferences and > requirements). I've never seen the logic of having two ways to do the same > thing, and despite the objections of an expert reviewer about the > questionable nature of this design decision when Seamoby was completing the > draft, the WG opted to include both in the final design. > > Ajoy-> Again, I do not understand your comment. Preference and requirements are two different things. We have explained this earlier as well. > It was explained, I didn't buy the explanation when I was WG chair (and neither did the expert reviewers BTW), and I don't buy it now. That's why this distinction isn't in NED. > We honestly *did* really try to use CARD for NED, in fact, I wrote an > initial draft for it, but it was really not very satisfying from a design > standpoint. So, in the end, the only thing we ended up reusing is the IANA > registry for network capabilities and for L2 Technologies, because they are > really crucial for extensibility. > > Ajoy-> It would have been nice if you would have involved CARD folks in this discussion as well. I can't comment about something that I am not really aware of. > So everytime someone wants to use CARD for something they have to include the CARD folks into the design? Doesn't sound like a very scalable design process to me. jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jul 14 23:40:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtH3g-0000qj-B6; Thu, 14 Jul 2005 23:40:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtH3d-0000qb-6q; Thu, 14 Jul 2005 23:40:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04426; Thu, 14 Jul 2005 23:40:10 -0400 (EDT) Received: from oak.research.panasonic.com ([150.169.1.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtHWM-0005nr-0D; Fri, 15 Jul 2005 00:09:55 -0400 Received: from redwood.research.panasonic.com (birch.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j6F3dfOS013893; Thu, 14 Jul 2005 23:39:41 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id D00DC1E923B; Thu, 14 Jul 2005 23:30:33 -0400 (EDT) Received: from [150.169.17.2] (unknown [150.169.17.2])by redwood.research.panasonic.com (Postfix) with ESMTP id 8015E1E9239; Thu, 14 Jul 2005 23:30:33 -0400 (EDT) Message-ID: <42D72FFE.8000800@research.panasonic.com> Date: Thu, 14 Jul 2005 23:39:42 -0400 From: Eunsoo Shim User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mipshop] Re: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt References: <0e3601c588be$b6522e10$016115ac@dcml.docomolabsusa.com> In-Reply-To: <0e3601c588be$b6522e10$016115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:13 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 2.4 (++) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Content-Transfer-Encoding: quoted-printable Cc: Singh Ajoy-ASINGH1 , mipshop@ietf.org, mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org James, Please see my inline comments. >>- The information source is always an AR. If the source is an "informat= ion >>server" or an L2 device like an AP but with IP capability, or even >> =20 >> >involves > =20 > >>an L2.5 transport protocol like EAPoL, then CARD isn't relevent. But le= t's >>suppose you can extract the options out of CARD and try to use them. Th= en >>you run into the problems below. >> >>Ajoy-> CARD is an IP layer protocol. Being a IP layer protocol, it can >> =20 >> >easily accommodate a scenario where MIH function is implemented on a >standalone server or an AP that is reachable using IP based transport. > =20 > >>Please note that 802.21 is defining MIH function for 802.XX, 3GPP2 and >> =20 >> >3GPP and it is difficult to have a common MAC layer protocol that can be >used in all of the above technologies. This was one of motivation why 80= 2.21 >is also looking at IP based transport. If this is not the case, you can >extend 802.11 and 802.16 using MAC extension for the information service= . > =20 > > >I believe Mike responded on this. > > =20 > >>- Most 802 protocols don't like the CARD format of a bunch of disconnec= ted >>blocks of bits. CARD's format was strictly defined by it's transport >>mechanism, namely as options over ICMP ND messages. Once you liberate t= he >>application from that transport format, the disconnected blocks format >>doesn't make sense anymore. Something like EAP (after which NED is >> =20 >> >modelled) > =20 > >>does. >> >>Ajoy-> I do not quite understand your argument here. CARD is using TLV >> =20 >> >encoding and TLV encoding is used in 802.11 as well as most of IP based >protocol. CARD options have been used over ICMP on MN-AR interface and o= ver >SCTP/UDP over AR-AR interface. > =20 > > >The on-the-wire format of CARD is based on RFC 2461 Options. That isn't = an >appropriate format for a widely applicable solution, especially for 802.= 21. > > =20 > I don't see any base for this subjective statement. Could you elaborate=20 this? >>- CARD privileges certain network information elements (like resolution= of >>AP addresses to AR addresses) above others. This is due to the built in >>design assumption that the primary application for CARD is a kind of >>cross-link ARP or ND to find the router's address (which, by the way, >>duplicates what FMIP does). >> >>Ajoy-> CARD is NOT limited to FMIPv6. It can be used to other mobility >> =20 >> >protocol as well. > =20 > > >I guess I didn't make my point very well. My main point is that CARD has >singled out a specific application - cross link ARP - and designed in >specific option types for that - L2 ID and Address - while others are >carried in the Capability Container. From the point of view of a general= ized >protocol, that doesn't make much sense. It only makes much sense if one >knows the history of CARD. > > =20 > You remember that SeaMoby WG produced drafts=20 "draft-ietf-seamoby-card-requirements-02.txt" to which you also made=20 contributions. According to the draft, the requirements for CARD include the following: - Identifying the IP address of a CAR (3.1) - Support for inter-technology handoffs (3.2) - capability discovery (3.4) - dependence on a mobility management protocol --- CARD MUST NOT depend=20 on a particular mobility management protocol (3.10) Your message gives an impression that CARD was designed mainly for=20 mapping AP address to AR IP address. But as you agreed on the CARD=20 requirements draft, CARD was designed to support much more than the=20 cross-link ARP. In particular, inter-technology handoff support is at=20 least very very closely related to what 802.21's media indepent handoff=20 is about. The draft "draft-ietf-seamoby-card-issues-04.txt" to which you again=20 contributed lists a number of possible application examples: - Load balancing between ARs. =96 Bandwidth-intensive applications. =96 Minimization of cost. =96 Inter-technology handovers. =96 Adaptability to changing topology without Ad hoc routing schemes. Certainly CARD is not designed to do everything human beings can=20 imagine. But it was designed to be general enough to satisfy the above=20 requirements and the above application examples, at least. You are saying "from the viewpoint of a generalized protocol". What do=20 you mean by "generalized protocol"? >> Now, there is no reason to priviledge this >>particular application above others in 802.21 InfoElements, and NED >> =20 >> >doesn't. > =20 > >>All applications use the IANA registry, and must be defined. NED still >> =20 >> >uses > =20 > >>AP/BS addresses as the initial identifier for the network, because that= is >>what the host will see so it is really the only way the host can tell t= he >>server what network it is interested in. >>- CARD has two ways to do capability querying (preferences and >>requirements). I've never seen the logic of having two ways to do the s= ame >>thing, and despite the objections of an expert reviewer about the >>questionable nature of this design decision when Seamoby was completing >> =20 >> >the > =20 > >>draft, the WG opted to include both in the final design. >> >>Ajoy-> Again, I do not understand your comment. Preference and >> =20 >> >requirements are two different things. We have explained this earlier as >well. > =20 > > >It was explained, I didn't buy the explanation when I was WG chair (and >neither did the expert reviewers BTW), and I don't buy it now. That's wh= y >this distinction isn't in NED. > > =20 > That's quite unfortunate. Please take a look at the requirements of=20 802.21 IS compiled by 802.21 WG. They include filters. Even schemas are=20 mentioned. For anyone to say something of CARD is not necessary for=20 802.21 IS and to propose a kind of subset of CARD, she/he should refer=20 to the 802.21 IS requirements. Following the good method adopted by many IETF WGs, I believe 802.21 IS=20 requirements should be clarified first of all. Then existing protocols=20 (primarily CARD in this case) should be compared to the requirements and=20 discussed. Based on the result, we can say what is necessary and=20 unnecessary and what needs to be changed, added or created. >>We honestly *did* really try to use CARD for NED, in fact, I wrote an >>initial draft for it, but it was really not very satisfying from a desi= gn >>standpoint. So, in the end, the only thing we ended up reusing is the I= ANA >>registry for network capabilities and for L2 Technologies, because they >> =20 >> >are > =20 > >>really crucial for extensibility. >> >>Ajoy-> It would have been nice if you would have involved CARD folks in >> =20 >> >this discussion as well. I can't comment about something that I am not >really aware of. > =20 > > >So everytime someone wants to use CARD for something they have to includ= e >the CARD folks into the design? Doesn't sound like a very scalable desig= n >process to me. > > =20 > Regards, Eunsoo _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Jul 15 16:01:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWNf-0003it-V9; Fri, 15 Jul 2005 16:01:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWNd-0003fs-OO for mobopts@megatron.ietf.org; Fri, 15 Jul 2005 16:01:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14103 for ; Fri, 15 Jul 2005 16:01:51 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtWqV-0000aF-5f for mobopts@irtf.org; Fri, 15 Jul 2005 16:31:44 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6FJU2h12922 for ; Fri, 15 Jul 2005 12:30:02 -0700 X-mProtect: <200507151930> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14166.americas.nokia.com (172.18.141.66, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdOzEDjk; Fri, 15 Jul 2005 12:30:01 PDT Message-ID: <42D81619.4000405@iprg.nokia.com> Date: Fri, 15 Jul 2005 13:01:29 -0700 From: Rajeev Koodli 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: "mobopts@irtf.org" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Subject: [Mobopts] Agenda for Paris meeting X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hello folks, here it is.. If I have missed anything, let me know asap. Regards, -Rajeev 1. Introduction, status update (chairs, 5 minutes) 2. "Link Characteristics Information for Mobile IP", SD Park and J. Korhonen, 10 minutes draft-daniel-mip-link-characteristic-02.txt 3. "LowPan Mobility Requirements and Goals", S. Chakrabarti draft-chakrabarti-mobopts-lowpan-req-00, 15 minutes 4. "Link Triggers and TARZAN implementation update", K. Mitsuya 10 minutes 5. "An efficient dynamic multicast agent approach for mobile IPv6 multicast", HK Zhang draft-zhang-mipshop-multicast-dma-00.txt, 15 minutes 6. "Seamless Multicast Handover in a Hierarchical Mobile IPv6 Environment (M-HMIPv6)", T. Schmidt draft-schmidt-waehlisch-mhmipv6-03.txt, 15 minutes 7. "MPA Framework and Implementation Updates", by A. Dutta draft-ohba-mobopts-mpa-{framework,implementation}-01.txt, 15 minutes 8. "Secure Proxy Neighbor Discovery using Multi-key CGAs", J. Kempf draft-kempf-mobopts-ringsig-ndproxy-00.txt, 15 minutes _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Sat Jul 16 23:53:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du0DE-00048y-O8; Sat, 16 Jul 2005 23:53:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du0DD-00048q-5k for mobopts@megatron.ietf.org; Sat, 16 Jul 2005 23:53:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18332 for ; Sat, 16 Jul 2005 23:53:04 -0400 (EDT) Message-Id: <200507170353.XAA18332@ietf.org> Received: from csnet1.cs.tsinghua.edu.cn ([166.111.68.226]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Du0gF-0004CA-3f for mobopts@irtf.org; Sun, 17 Jul 2005 00:23:14 -0400 Received: (qmail 22633 invoked by uid 0); 17 Jul 2005 04:09:02 -0000 Received: from unknown (HELO cy) (yong@219.243.215.254) by csnet1.cs.tsinghua.edu.cn with SMTP; 17 Jul 2005 04:09:02 -0000 Date: Sun, 17 Jul 2005 11:52:18 +0800 From: "Yong" To: "Telemaco Melia" , "Rajeev Koodli" Subject: Re: Re: [Mobopts] New topics for the RG X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: Rui Aguiar , "mobopts@irtf.org" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi, Rajeev, We think that this topic is very interesting for current Mobile IPv6 deployment. Currently, we are working on mobile ipv6 deployment based on network controlled handover solution in the area of nation-wide campus network. In the first stage, we are going to build 100 experimental campus networks by the end of this year. In the second stage, we plan to expand to 1000 universities in the following two or three years. Please kindly check the following draft: http://www.ietf.org/internet-drafts/draft-cui-mobopts-hcf-wlan-00.txt cheers -Yong ======= 2005-07-12 16:30:53 You wrote ======= >Hi Rajeev, > >of course we are interested to provide input on the network initiated >handover topic. >We are currently revising the draft and we should be able to submit >version 01 by the end of the week. >In the meanwhile I would like to trigger the discussion on the mailing >list based on version 00. > >regards, >Telemaco > >> >> - mobility (and traffic) patterns in a WLAN (e.g., a campus network). >> This should provide >> a better sense of traffic for admission control as well as >> network-controlled handovers. >> >>https://www1.ietf.org/mailman/listinfo/mobopts >> >> > > >-- >Telemaco Melia telemaco.melia@netlab.nec.de >Research Staff Member Tel: +49 (0) 6221 90511-42 >Network Laboratories Fax: +49 (0) 6221 90511-55 >NEC Europe Ltd. Web: http://www.netlab.nec.de >Kurfrsten-Anlage 36 >D-69115 Heidelberg >Germany > > > >_______________________________________________ >Mobopts mailing list >Mobopts@irtf.org >https://www1.ietf.org/mailman/listinfo/mobopts > ======================================= Best regards, 11:36:45 2005-07-17 ******************************************************** * Yong Cui * * Ph.D, Department of Computer Science & Technology * * Tsinghua University, Beijing, P.R.China(100084) * * Tel: (8610)-62795818-6859 * * Email: yong@csnet1.cs.tsinghua.edu.cn * ******************************************************** _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Sun Jul 17 08:10:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du7yG-0001Cr-BT; Sun, 17 Jul 2005 08:10:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du7yF-0001Cg-5r for mobopts@megatron.ietf.org; Sun, 17 Jul 2005 08:10:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00163 for ; Sun, 17 Jul 2005 08:10:09 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX186GUBr1SrqPfMVomVA1RZNPiUXqknJVvI=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du8RS-00023R-ON for mobopts@irtf.org; Sun, 17 Jul 2005 08:40:23 -0400 Received: from hsi-kbw-082-212-035-085.hsi.kabelbw.de ([82.212.35.85] helo=[192.168.123.123]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1Du7yB-00059b-KF; Sun, 17 Jul 2005 14:10:09 +0200 Message-ID: <42DA4A9E.2030004@tm.uka.de> Date: Sun, 17 Jul 2005 14:10:06 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [Mobopts] About RO enhancements References: <20050610113515.6f297676.ernst@sfc.wide.ad.jp> In-Reply-To: <20050610113515.6f297676.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: -1.8 (-) X-Spam-Status: No X-Spam-Score: 2.4 (++) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Jari Arkko , Gabriel Montenegro , MOBOPTS X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0989583871==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0989583871== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2257DCCEA3961C5A5C95E10A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2257DCCEA3961C5A5C95E10A Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > - I wonder if it wouldn't be useful to have a (minimum) thought about > Mobile Routers, and not only about Mobile Hosts. > > - Also, speaking about enhancement, I think it would be wise to > consider the case of a Correspondent Router instead of the > Correspondent Node. [...] Hi Thierry, thanks for your review and comments. I agreee that route-optimization support for NEMO is important. E.g., you can think about Personal Area Networks, or Internet access in public transportation. Especially in the latter, mobile nodes may not necessarily be able to speak Mobile IPv6 themselves. NEMO also identifies interesting fields for future research. E.g., it might nicely fit together with infrastructure-based security techniques such as this: [42] Castelluccia, Claude., Montenegro, Gabriel., Laganier, Julien., and Christoph. Neumann, "Hindering Eavesdropping via IPv6 Opportunistic Encryption", Proceedings of the European Symposium on Research in Computer Security , September 2004. In this light, I wrote an additional sub-section for section "Enhancement Toolbox" on mobile and correspondent routers. Also, I added a paragraph an this topic to sub-section "Future Research" of section "Analysis". Regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Thierry Ernst wrote: > Dear all, > > I've read the current RO Enhancement document (as of June 9th) > http://doc.tm.uka.de/2005/draft-irtf-mobopts-ro-enhancements-01-pre.txt > > > I have 2 points to make: > > - I wonder if it wouldn't be useful to have a (minimum) thought about > Mobile Routers, and not only about Mobile Hosts. > > - Also, speaking about enhancement, I think it would be wise to > consider the case of a Correspondent Router instead of the > Correspondent Node. Well, the rationale is that all CNs have to be > modified to bring any new RO feature, but this could be avoided if > mobility was managed but a router in the CN network (or presumably on > the path between the CN and the MN). I think this could come in > light of section 6.2.2 where a "infrastructure-based-RO" method is > mentioned. > > I think such consideration wouldn't harm Mobopts since this is an > IRTF WG. > > Any thoughts ? > > For your information, the NEMO WG is chartered to produce an analysis > document about RO in the NEMO context. The NEMO WG recently agreed > to adopt the forthcoming merge of several individual drafts as the a > NEMO WG document. Authors are presently working on that document > which should be issued before Paris meeting. Might be useful to keep > a close eye on effort in both NEMO IETF WG and Mopbopts IRTF WG. > > Thierry --------------enig2257DCCEA3961C5A5C95E10A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC2kqewstEk8gl2rURAlQXAKCXTjV5RyeJH1YIZ+eDRjj9aIkprgCg13BL +TADHoG1jjtC74C5vPxmrh0= =HAJB -----END PGP SIGNATURE----- --------------enig2257DCCEA3961C5A5C95E10A-- --===============0989583871== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============0989583871==-- From mobopts-bounces@irtf.org Sun Jul 17 08:11:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du7zy-0001yN-S9; Sun, 17 Jul 2005 08:11:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du7zw-0001xU-0F; Sun, 17 Jul 2005 08:11:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00217; Sun, 17 Jul 2005 08:11:54 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX185mnJJiF2YAAMP/phcE3qzwmHq71uYR+g=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du8T9-0002Do-5b; Sun, 17 Jul 2005 08:42:08 -0400 Received: from hsi-kbw-082-212-035-085.hsi.kabelbw.de ([82.212.35.85] helo=[192.168.123.123]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1Du7zq-0005BR-9T; Sun, 17 Jul 2005 14:11:53 +0200 Message-ID: <42DA4B04.4010209@tm.uka.de> Date: Sun, 17 Jul 2005 14:11:48 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Gerardo Giaretta References: In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: -1.7 (-) X-Spam-Status: No X-Spam-Score: 2.4 (++) X-Scan-Signature: 748ed3980abc7d4bd6a14905626ff64e Cc: mip6@ietf.org, Rajeev Koodli , Jari Arkko , mobopts@irtf.org Subject: [Mobopts] Re: Review of draft-irtf-mobopts-ro-enhancements-00 X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1958771657==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1958771657== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFB871CA55EA4344CDA1D3D13" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFB871CA55EA4344CDA1D3D13 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Gerardo, you had one more comment concerning the section on processing improvements: > Not necessarily. However, even without any reference, some more > details can be useful. As you mention RR was designed with low > computational complexity in mind. If you state that it can be too > expensive, you should at least provide some examples, scenarios or > data. Thinking more about this, I tend to conclude that the complexity of the return-routability procedure is already very low. One may further reduce processing requirements through easier ways to compute the Home and Care-of Keygen Tokens, or the KBM. But that's probably not so urgent. Here is the new text: 5.17 Processing Improvements One goal for designing the return-routability procedure was to limit its computational complexity to a minimum. The processing overhead for route optimization should thus be acceptable in general. However, some alternatives to the return-routability procedure use stronger cryptographic algorithms, such as public-key cryptography. This can be more taxing on processing resources, especially for low- provisioned handheld devices. Here, it may help to replace RSA algorithms with ECC techniques. Regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Gerardo Giaretta wrote: > Hi Christian, > > thanks for your replay. Some comments below... > > >> Hi Gerardo, >> >> thanks again for reviewing the doc. Some responses below. You can >> check the new version at >> >> http://doc.tm.uka.de/2005/draft-irtf-mobopts-ro-enhancements-0 >> 1-pre.txt >> >> - Christian >> >> ++++ >> >> >>> General comment: I think the draft is very well-written and >> >> provide a >> >>> complete analysis of the topic. The unique general issue I found >>> is that it is very long. I agree with James' comment that the >>> draft could be shortened removing some sections that are not >>> completely in the scope of the draft (e.g. section 5.13 and 5.14, >>> more about these sections below). >> >> Ok, will do that. >> >> >>> More detailed comments: >>> >>> - section 1, paragraph 4 "In the opposite direction, the mobile >>> node may tunnel packets to the home agent". I think this sentence >>> is not completely correct, or at least a bit misleading. If route >>> optimization is not used, the MN MUST tunnel packets to the HA. >>> Is "MAY" used in this sentence to highlight that the MN can >>> choose to use bidirectional tunneling or route optimization? >> >> You are right, the text is misleading. The idea was that RO is the >> alternative, and the MN may choose (provided the CN supports RO). >> But, again, this is confusing, so I changed it. >> >> >>> - section 1, paragraph 10 "This can lead to handover delay >>> unacceptable for many real-time or interactive applications like >>> Voice over IP (VoIP) and audio or video streaming". I'd suggest >>> to remove audio/video streaming here. Streaming applications are >>> not real-time nor interactive: they usually buffer few seconds of >>> the movie/sound and thus are usually not affected by MIPv6 >>> handover latency. At least this is what we have experimented in >>> our labs. >> >> Would you say that rapid handovers and small buffers in >> less-provisioned devices can be an issue with streaming? >> > > > Yes, it can be an issue. But this depends on the device capabilities > and not on strong application requirements. Usually, in most > streaming applications, buffer size is configurable and has a default > value of few seconds. > > >> Anyway, I changed the text. >> > > > Good. > > >>> - section 3.1, paragraph 7 "The mobile node must compute a >>> message-authentication code keyed with the Home and Care-of >>> Keygen Token". Actually the MAC is keyed with the Kbm, that is a >>> 20 octets SHA-1 hash of the concatenation of Home and Care-of >>> Keygen Token >> >> Right, this was imprecise. Corrected it. >> >> >>> - section 4.1, paragraph 1: I would mention explicitly that the >>> handoff latency for a route-optimized communication is longer >>> than for a bi-directional tunneled communication. >> >> Yes, it's added. >> >> >>> - section 4.1, paragraph 2: since the CN is not always required >>> to send the BA, I wonder why the MN should by default wait for >>> the BA. Or are you suggesting the MN asks the CN an ack? If so, I >>> think the sentence should be rephrased. >> >> Right. >> >> >>> - section 4.1, paragraph 3 "But more generally, mobile >> >> nodes wait for >> >>> the home registration to be completed and acknowledged before >>> initiating the correspondent registration". Are you >> >> referring to some >> >>> specific implementations? I'm asking this because the open source >>> implementation we use in our labs does not wait the BA. >> >> Kame-Shisa does it. We added the optimization not to wait for the >> BA from the HA. >> >> Actually, not waiting for the BA is not standard-conform. RFC 3775 >> says that the lifetime of correspondent registrations must not >> exceed that of the home registration. And the latter becomes known >> to the MN only with the BA. >> >> I don't think this requirement is critical, though. After all, >> it's up to the MN to request the CN lifetime anyway. It could just >> ignore the home-registration lifetime. >> > > > I tend to agree on this. This implementation choice can improve > performance. > > > >>> - section 4.4, paragraph 2: I would add references to >>> draft-koodli-mip6-location-privacy-00 and to >>> draft-koodli-mip6-location-privacy-solutions-00 >> >> Definitely a good idea. >> >> >>> - section 5.2, paragraph 1: What do you mean by "close to >> >> the mobile >> >>> node"? Shouldn't it be "on the path between MN and HA"? >> >> The critical link on the patch between the MN and the HA is a >> wireless first hop. >> >> Anyway, the text is unclear. Rewrote that sentence. >> >> >>> - section 5.3, paragraph 2: the sentence is not clear to >> >> me. The last >> >>> BA is referred to BA from CN, I suppose. If so, I think it >> >> should be >> >>> mentioned explicitly. >> >> Done. >> >> >>> - section 5.13: as mentioned before I think this section is not >>> really in the scope of the draft. If you think it is, I'd suggest >>> to include some more text explaining how HMIPv6 influences RO >> >> operations >> >>> (e.g. reduction of signaling overhead). The same applies to >>> section 5.14. I think that FMIPv6 has even less impact on RO than >>> HMIPv6. So I suggest you include some more text to explain how >>> these protocols are tied to RO. >> >> It seems there is pretty much agreement in that FMIPv6 and HMIPv6 >> should be removed from this particular document. >> >> >>> - section 5.16, last sentence: are there simulations that prove >>> that RR can be too expensive? A reference could be helpful. >> >> I don't have such a reference. Is your suggestion to remove the >> section in this case? >> > > > Not necessarily. However, even without any reference, some more > details can be useful. As you mention RR was designed with low > computational complexity in mind. If you state that it can be too > expensive, you should at least provide some examples, scenarios or > data. > > --Gerardo > > >>> - section 6.2.1, last paragraph: HMIPv6 causes always a tunneling >>> overhead that is not present in plain MIPv6. Therefore, some >>> localized mobility protocols always cause overhead and not only >>> "in some situations". >> >> That's right. But I have already removed that sub-section. >> >> >>> - section 6.2.2, paragraph 1 "On the other hand, nodes that do >>> share a common secret should be allowed to omit the home-address >>> test". Isn't required that the common secret is tied to the Home >>> Address used in order to remove the home address test? >> >> You are right. Added that. >> >> >>> Editorial comments: >>> >>> - section 4.1, last paragraph: Section 6.3.1 should be in >> >> brackets or >> >>> similar >> >> Oops, it's done. >> >> >>> - section 5.1, paragraph 2: s/IP-ddress/IP-address >> >> Ok. >> >> >>> - section 5.7, paragraph 5: s/its is the data/it is the data >> >> Ok. >> >> >>> - section 5.8, paragraph 2: s/it in general/it is in general >> >> Ok. >> >> >>> Hope this helps. >> >> It did. ;) >> >> Thanks, - Christian >> >> -- Christian Vogt, Institute of Telematics, University of Karlsruhe >> www.tm.uka.de/~chvogt/pubkey/ >> >> >> >> Gerardo Giaretta wrote: >> >>> Hi Christian and Jari, >>> >>> Raj requested me to review draft-irtf-mobopts-ro-enhancements-00. >>> Here are some comments and question. >>> >>> General comment: I think the draft is very well-written and >> >> provide a >> >>> complete analysis of the topic. The unique general issue I found >>> is that it is very long. I agree with James' comment that the >>> draft could be shortened removing some sections that are not >>> completely in the scope of the draft (e.g. section 5.13 and 5.14, >>> more about these sections below). >>> >>> More detailed comments: >>> >>> - section 1, paragraph 4 "In the opposite direction, the mobile >>> node may tunnel packets to the home agent". I think this sentence >>> is not completely correct, or at least a bit misleading. If route >>> optimization is not used, the MN MUST tunnel packets to the HA. >>> Is "MAY" used in this sentence to highlight that the MN can >>> choose to use bidirectional tunneling or route optimization? >>> >>> - section 1, paragraph 10 "This can lead to handover delay >>> unacceptable for many real-time or interactive applications like >>> Voice over IP (VoIP) and audio or video streaming". I'd suggest >>> to remove audio/video streaming here. Streaming applications are >>> not real-time nor interactive: they usually buffer few seconds of >>> the movie/sound and thus are usually not affected by MIPv6 >>> handover latency. At least this is what we have experimented in >>> our labs. >>> >>> - section 3.1, paragraph 7 "The mobile node must compute a >>> message-authentication code keyed with the Home and Care-of >>> Keygen Token". Actually the MAC is keyed with the Kbm, that is a >>> 20 octets SHA-1 hash of the concatenation of Home and Care-of >>> Keygen Token >>> >>> - section 4.1, paragraph 1: I would mention explicitly that the >>> handoff latency for a route-optimized communication is longer >>> than for a bi-directional tunneled communication. >>> >>> - section 4.1, paragraph 2: since the CN is not always required >>> to send the BA, I wonder why the MN should by default wait for >>> the BA. Or are you suggesting the MN asks the CN an ack? If so, I >>> think the sentence should be rephrased. >>> >>> - section 4.1, paragraph 3 "But more generally, mobile >> >> nodes wait for >> >>> the home registration to be completed and acknowledged before >>> initiating the correspondent registration". Are you >> >> referring to some >> >>> specific implementations? I'm asking this because the open source >>> implementation we use in our labs does not wait the BA. >>> >>> - section 4.4, paragraph 2: I would add references to >>> draft-koodli-mip6-location-privacy-00 and to >>> draft-koodli-mip6-location-privacy-solutions-00 >>> >>> - section 5.2, paragraph 1: What do you mean by "close to >> >> the mobile >> >>> node"? Shouldn't it be "on the path between MN and HA"? >>> >>> - section 5.3, paragraph 2: the sentence is not clear to >> >> me. The last >> >>> BA is referred to BA from CN, I suppose. If so, I think it >> >> should be >> >>> mentioned explicitly. >>> >>> - section 5.13: as mentioned before I think this section is not >>> really in the scope of the draft. If you think it is, I'd suggest >>> to include some more text explaining how HMIPv6 influences RO >> >> operations >> >>> (e.g. reduction of signaling overhead). The same applies to >>> section 5.14. I think that FMIPv6 has even less impact on RO than >>> HMIPv6. So I suggest you include some more text to explain how >>> these protocols are tied to RO. >>> >>> - section 5.16, last sentence: are there simulations that prove >>> that RR can be too expensive? A reference could be helpful. >>> >>> - section 6.2.1, last paragraph: HMIPv6 causes always a tunneling >>> overhead that is not present in plain MIPv6. Therefore, some >>> localized mobility protocols always cause overhead and not only >>> "in some situations". >>> >>> - section 6.2.2, paragraph 1 "On the other hand, nodes that do >>> share a common secret should be allowed to omit the home-address >>> test". Isn't required that the common secret is tied to the Home >>> Address used in order to remove the home address test? >>> >>> >>> Editorial comments: >>> >>> - section 4.1, last paragraph: Section 6.3.1 should be in >> >> brackets or >> >>> similar >>> >>> - section 5.1, paragraph 2: s/IP-ddress/IP-address >>> >>> - section 5.7, paragraph 5: s/its is the data/it is the data >>> >>> - section 5.8, paragraph 2: s/it in general/it is in general >>> >>> >>> Hope this helps. >>> >>> Regards, --Gerardo >>> >>> >>> >>> >>> >>> >>> Gruppo Telecom Italia - Direzione e coordinamento di Telecom >>> Italia S.p.A. >>> >>> >> >> ==================================================================== >> >> >>> CONFIDENTIALITY NOTICE This message and its attachments are >> >> addressed >> >>> solely to the persons above and may contain confidential >> >> information. >> >>> If you have received the message in error, be informed that any >>> use of the content hereof is prohibited. Please return it >>> immediately to the sender and delete the message. Should you have >>> any questions, please send an e_mail to MailAdmin@tilab.com. >>> Thank you >>> ==================================================================== >>> >> >> > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia > S.p.A. > > ==================================================================== > CONFIDENTIALITY NOTICE This message and its attachments are addressed > solely to the persons above and may contain confidential information. > If you have received the message in error, be informed that any use > of the content hereof is prohibited. Please return it immediately to > the sender and delete the message. Should you have any questions, > please send an e_mail to MailAdmin@tilab.com. Thank you > ==================================================================== --------------enigFB871CA55EA4344CDA1D3D13 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC2ksEwstEk8gl2rURAohTAKCbO0qjt1MEJTyH/tdfOyBtAXz8KQCgs0Aa avvJ5W6DgoVkfMtAwaA0ErM= =0X09 -----END PGP SIGNATURE----- --------------enigFB871CA55EA4344CDA1D3D13-- --===============1958771657== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============1958771657==-- From mobopts-bounces@irtf.org Sun Jul 17 08:14:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du82Z-0002GI-78; Sun, 17 Jul 2005 08:14:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du82W-0002GA-U2; Sun, 17 Jul 2005 08:14:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00372; Sun, 17 Jul 2005 08:14:35 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX18Zmv9OAngwWJFvG3NA9bamlRg8IlKgiGY=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du8Vk-0002OV-0h; Sun, 17 Jul 2005 08:44:48 -0400 Received: from hsi-kbw-082-212-035-085.hsi.kabelbw.de ([82.212.35.85] helo=[192.168.123.123]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1Du82O-0005Ga-AQ; Sun, 17 Jul 2005 14:14:34 +0200 Message-ID: <42DA4BA2.6040205@tm.uka.de> Date: Sun, 17 Jul 2005 14:14:26 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: James Kempf References: <0abd01c56246$fe2927f0$016115ac@dcml.docomolabsusa.com> <42A7CF48.2040807@tm.uka.de> <00b101c56d0a$aefca2a0$016115ac@dcml.docomolabsusa.com> In-Reply-To: <00b101c56d0a$aefca2a0$016115ac@dcml.docomolabsusa.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: -1.2 (-) X-Spam-Status: No X-Spam-Score: 2.4 (++) X-Scan-Signature: f560cc438c8be83d0aa5c816c29b481c Cc: MIP6 , Jari Arkko , Rajeev Koodli , MOBOPTS Subject: [Mobopts] Re: [Mip6] Review of draft-irtf-mobopts-ro-enhancements-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0176790910==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0176790910== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig177D579897C75D1A967D63CC" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig177D579897C75D1A967D63CC Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi James, thanks for your additional comments. My responses are inline. >>> Section 4.2, 3rd & 4th para: I've never been convinced that a >>> mobile node would want to keep optimized routes hot while it was >>> in dormant mode, and this example doesn't convince me either. >>> Route optimization helps with RTT latency, and such latency is an >>> issue primarily in real time traffic. The example given here, a >>> messaging server (presumably IM), is a store and forward system >>> that will derive little benefit from keeping routes hot during >>> optimization. Even for real time traffic, like VoIP, the CN still >>> has to do SIP signaling to initiate the connection, and while >>> there is some amount of urgency to the signaling above a store >>> and forward application, it still is not going to suffer if the >>> traffic is routed through the home agent. The latency involved in >>> initiating the IP connection with the dormant mode mobile node >>> through paging is likely to exceed any benefit from keeping >>> optimized routes hot. >> >> Should we remove the example and say instead that it be worthwhile >> to save the wireless bandwidth? > > Yes, I think that should be enough. Ok, this is done. >>> Section 5, para 1: Are the tradeoffs between universal >>> applicablity v.s. efficiency discussed in this paper anywhere? >>> This would be the ideal paper to have the discussion. >> >> It's mentioned where pre-configuration is discussed, for instance. > > Might be good to give it a more prominant place, perhaps up front. It > is a good architectural point, that should not get lost in the > details of the various techniques. Yes, that's true. I added the following section to the Introduction section: ++++ This paper describes, classifies, and evaluates strategies that can enhance or optimize Mobile IPv6 route optimization. These optimizations have different objectives: Some of them tackle signaling latency or overhead, while others focus on security improvements. Again others seek to increase protocol robustness or to add to the functionality of base Mobile IPv6. When it comes to evaluating a particular optimization, it is important to not only regard its relative improvement over standard Mobile IPv6, but to also consider the optimization's costs in terms of hardware upgrades, software modifications, and manual configuration, as well as its applicability to different scenarios and ease of deployment. E.g., end-to-end techniques like Mobile IPv6 route optimization itself have a natural lower bound with respect to signaling latency of one round- trip time. (It takes the first one-way time to signal a new care-of address to a peer; the second one-way time is needed by the first packet to arrive at the new care-of address.) To reduce the latency below one round-trip time, some optimizations make use of network infrastructure. While the benefit of such infrastructure can be enormous, the associated acquisition and maintenance costs are a disadvantage that needs to be kept in mind. Also, infrastructure- based optimizations are ineffective when the infrastructure is unavailable. (This may, e.g., be the case when a mobile node switches to a different administrative domain.) Though end-to-end optimizations are slower, they are usually cheaper and easier to deploy, and they are operable without network support. ++++ >>> Section 5.5, para 2: Later in the paper, you discuss this, but >>> the statistical uniqueness properties of CGAs suggest that the >>> care-of test might not be needed since the probability of another >>> node having exactly the same interface identifier is fairly low. >>> I think you should state that here. It is the same tradeoff that >>> optimistic DAD makes. The argument you advance later in the paper >>> that the attacker can still mount an attack on the subnet is >>> irrelevent. An attacker can do that without using route >>> optimization, by creating a zombie and programming it to iterate >>> through non-existant addresses in the victim subnet. >> >> I think there is still an issue with CGAs and RO of which one needs >> to be aware: >> >> An attacker could use any interface identifier in order to bomb a >> certain network. The only thing that matters in such a case is the >> network prefix. >> >> Route optimization does not create the issue with flooding, but it >> can aggravate it. You get amplification without programming a >> zombie and distributing viral software. And if you choose to >> program a zombie nonetheless, the zombie can misuse route >> optimization for you. (In the latter case, the zombie would contact >> a large set of powerful correspondent nodes, download large files, >> and redirect those files to the target network. This is "more >> efficient" compared to when the zombie alone sends packets.) >> > > > OK, so it sounds as if RO using CGA w.o. an RR test will provide > additional leverage to an attacker, right? Perhaps you could explain > this a little more in the draft? I added the following two paragraphs to section "Mobility-Related Security Threats :: Flooding Attacks": ++++ Note that a redirection-based flooding attack can be combined with the conventional strategy where the attacker infects and takes over control of zombies. The attacker could infect multiple zombies, and each of those could in turn persuade multiple correspondent nodes to send packets to a common victim. The base of correspondent nodes that could be misused would be substantial, because support for Mobile IPv6 route optimization is recommended to all IPv6 nodes [14]. This is why RFC 3775 prevents redirection-based flooding attacks through care-of-address test. Cryptographically Bound Identifiers (CBIDs, cf. Section 5.9) may be used to partly mitigate the risk of flooding, because a correspondent node can verify whether the interface identifier of a mobile node's (or the attacker's) care-of address is correct. However, CBIDs do not guarantee the correctness of the address prefix. A malicous node could therefore still bomb a certain network even though it may not be able to target a particular node within that network. ++++ >>> Section 5.7: I think it might be worthwhile to include a >>> paragragh describing how the mobile node's credit is measured. I >>> recently attempted to construct a bandwidth measuring algorithm >>> and found it not so simple. There are probably very simple ways >>> to do it, but I think they may not be obvious to the casual >>> reader. >> >> The basic mode for CBA is just packet counting, or rather byte >> counting. Paragraph 3 explains this already, I think. > > Hmm, so things like bursts and such are not accounted for? It seems > like a MN wanting to game the system or even an attacker could simply > bombard the CN with traffic, build up a huge account, then use that > to mount an attack. I guess I need to read the CBA draft again, it's > been a while since I read it. See my response at http://www1.ietf.org/mail-archive/web/mobopts/current/msg00439.html >> Perhaps, what you are having in mind is how the CN comes up with a >> rate limit? CBA has a loose data-rate limit in that the credit >> ages over time. So a MN cannot acquire credit slowly and use it up >> all at once. But that's said in the text as well. > > Does the CN also use an algorithm where it reduces the credit if it > thinks that the MN is gaming or it is being bombarded in order to > build up enough credit to launch an attack? IKE does something like > this, it reduces the timeout on cookies during IKE_INIT if it thinks > it is under DoS attack. Again, see http://www1.ietf.org/mail-archive/web/mobopts/current/msg00439.html >> Bandwidth and throughput measurements are not so simple. Care-of >> Address Spot Checks can be used to find approximations, which are >> good enough for the purpose of CBA. Maybe, this is what was >> unclear to you? > > Yes, perhaps a little more detail would be useful, but I guess > ultimately people need to read the CBA draft. I replaced quite a bit of text in section "Credit-Based Authorization". It should be much more understandable now. >>> Section 5.7, para 5.7: I wonder if the Spot Check tokens aren't a >>> potential state depletion threat. Since they are essentially per >>> flow state, an attacker could iterate creating a bunch of flows >>> until the victim's Spot Check token storage was exhausted. >> >> No, the tokens for spot checks can be derived similar to how the CN >> creates Home and Care-of Keygen Tokens. Do you think this should >> be explained in the text? I think it may lead too far. > > OK, I think people can go back to the original source if they want > the detail. I agree. >>> Section 6.2.4: Can CBA somehow get rid of the need to >>> re-authorize every 7 minutes? If the MN is building credit, then >>> perhaps it doesn't need to re-authorize because its ability to >>> attack is limited by the credit. Of course, the issue of the home >>> address test would have to be addressed too, but I think it >>> worthwhile to explore this, since the signaling overhead of RR is >>> onerous. >> >> It can. We wrote that down in > > http://www.watersprings.org/pub/id/draft-arkko-mipv6-binding-lifetime-extension-00.txt > > > Good. Ok. >> But why would CGA and CBA have a problem with this? Both CGA and >> CBA have a very large applicability; CGA with respect to >> home-address authentication/authorization and CBA with respect to >> moving the care-of-address test out of the "critical phase" (which >> we now have defined ;) ). >> >> Foremost, the independence of CGA from infrastructure (you don't >> need the certification authorities) is very attractive. And CBA >> applies to basically every IP-mobility protocol. > > Yes, that is exactly my point. These two approaches have the right > kind of properties for a next-gen solution that should be of wide > appeal, the others so far don't. :-) Alright, that's it. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ James Kempf wrote: > Hi Christian, > > Thanx for the response. Below, a couple of follow-ups. > > jak > > -------------------------------------------------------- > > >>> Section 4.2, 3rd & 4th para: I've never been convinced that a >>> mobile node would want to keep optimized routes hot while it was >>> in dormant mode, and this example doesn't convince me either. >>> Route optimization helps with RTT latency, and such latency is an >>> issue primarily in real time traffic. The example given here, a >>> messaging server (presumably IM), is a store and forward system >>> that will derive little benefit from keeping routes hot during >>> optimization. Even for real time traffic, like VoIP, the CN still >>> has to do SIP signaling to initiate the connection, and while >>> there is some amount of urgency to the signaling above a store >>> and forward application, it still is not going to suffer if the >>> traffic is routed through the home agent. The latency involved in >>> initiating the IP connection with the dormant mode mobile node >>> through paging is likely to exceed any benefit from keeping >>> optimized routes hot. >> >> Should we remove the example and say instead that it be worthwhile >> to save the wireless bandwidth? >> > > > Yes, I think that should be enough. > > >>> Section 5, para 1: Are the tradeoffs between universal >>> applicablity v.s. efficiency discussed in this paper anywhere? >>> This would be the ideal paper to have the discussion. >> >> It's mentioned where pre-configuration is discussed, for instance. >> > > > Might be good to give it a more prominant place, perhaps up front. It > is a good architectural point, that should not get lost in the > details of the various techniques. > > >>> Section 5.5, para 2: Later in the paper, you discuss this, but >>> the statistical uniqueness properties of CGAs suggest that the >>> care-of test might not be needed since the probability of another >>> node having exactly the same interface identifier is fairly low. >>> I think you should state that here. It is the same tradeoff that >>> optimistic DAD makes. The argument you advance later in the paper >>> that the attacker can still mount an attack on the subnet is >>> irrelevent. An attacker can do that without using route >>> optimization, by creating a zombie and programming it to iterate >>> through non-existant addresses in the victim subnet. >> >> I think there is still an issue with CGAs and RO of which one needs >> to be aware: >> >> An attacker could use any interface identifier in order to bomb a >> certain network. The only thing that matters in such a case is the >> network prefix. >> >> Route optimization does not create the issue with flooding, but it >> can aggravate it. You get amplification without programming a >> zombie and distributing viral software. And if you choose to >> program a zombie nonetheless, the zombie can misuse route >> optimization for you. (In the latter case, the zombie would contact >> a large set of powerful correspondent nodes, download large files, >> and redirect those files to the target network. This is "more >> efficient" compared to when the zombie alone sends packets.) >> > > > OK, so it sounds as if RO using CGA w.o. an RR test will provide additional > leverage to an attacker, right? Perhaps you could explain this a little more > in the draft? > > > >>> Section 5.7: I think it might be worthwhile to include a >>> paragragh describing how the mobile node's credit is measured. I >>> recently attempted to construct a bandwidth measuring algorithm >>> and found it not so simple. There are probably very simple ways >>> to do it, but I think they may not be obvious to the casual >>> reader. >> >> The basic mode for CBA is just packet counting, or rather byte >> counting. Paragraph 3 explains this already, I think. >> > > > Hmm, so things like bursts and such are not accounted for? It seems > like a MN wanting to game the system or even an attacker could simply > bombard the CN with traffic, build up a huge account, then use that > to mount an attack. > I guess I need to read the CBA draft again, it's been a while since I > read it. > > >> Perhaps, what you are having in mind is how the CN comes up with a >> rate limit? CBA has a loose data-rate limit in that the credit >> ages over time. So a MN cannot acquire credit slowly and use it up >> all at once. But that's said in the text as well. >> > > > Does the CN also use an algorithm where it reduces the credit if it > thinks that the MN is gaming or it is being bombarded in order to > build up enough credit to launch an attack? IKE does something like > this, it reduces the timeout on cookies during IKE_INIT if it thinks > it is under DoS attack. > > >> Bandwidth and throughput measurements are not so simple. Care-of >> Address Spot Checks can be used to find approximations, which are >> good enough for the purpose of CBA. Maybe, this is what was >> unclear to you? >> > > > Yes, perhaps a little more detail would be useful, but I guess > ultimately people need to read the CBA draft. > > >>> Section 5.7, para 5.7: I wonder if the Spot Check tokens aren't a >>> potential state depletion threat. Since they are essentially per >>> flow state, an attacker could iterate creating a bunch of flows >>> until the victim's Spot Check token storage was exhausted. >> >> No, the tokens for spot checks can be derived similar to how the CN >> creates Home and Care-of Keygen Tokens. Do you think this should >> be explained in the text? I think it may lead too far. >> > > > > OK, I think people can go back to the original source if they want > the detail. > > >>> Section 6.2.4: Can CBA somehow get rid of the need to >>> re-authorize every 7 minutes? If the MN is building credit, then >>> perhaps it doesn't need to re-authorize because its ability to >>> attack is limited by the credit. Of course, the issue of the home >>> address test would have to be addressed too, but I think it >>> worthwhile to explore this, since the signaling overhead of RR is >>> onerous. >> >> It can. We wrote that down in >> > > http://www.watersprings.org/pub/id/draft-arkko-mipv6-binding-lifetime-extension-00.txt > > > Good. > > >> But why would CGA and CBA have a problem with this? Both CGA and >> CBA have a very large applicability; CGA with respect to >> home-address authentication/authorization and CBA with respect to >> moving the care-of-address test out of the "critical phase" (which >> we now have defined ;) ). >> >> Foremost, the independence of CGA from infrastructure (you don't >> need the certification authorities) is very attractive. And CBA >> applies to basically every IP-mobility protocol. >> > > > Yes, that is exactly my point. These two approaches have the right > kind of properties for a next-gen solution that should be of wide > appeal, the others > so far don't. > > jak --------------enig177D579897C75D1A967D63CC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC2kuiwstEk8gl2rURAu3cAJ9LstAhekHhw8zSGerYRMH8qtp84gCfeNfU HjSSW4WaI5aF92yjdRqDmng= =gbtB -----END PGP SIGNATURE----- --------------enig177D579897C75D1A967D63CC-- --===============0176790910== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============0176790910==-- From mobopts-bounces@irtf.org Sun Jul 17 08:21:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du89Z-0003rF-4Q; Sun, 17 Jul 2005 08:21:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du89X-0003r7-RT; Sun, 17 Jul 2005 08:21:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00743; Sun, 17 Jul 2005 08:21:50 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1/cIZwOh6RhbVDZA5CryscnIu8RJHp4tLE=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du8cl-0002kJ-L5; Sun, 17 Jul 2005 08:52:03 -0400 Received: from hsi-kbw-082-212-035-085.hsi.kabelbw.de ([82.212.35.85] helo=[192.168.123.123]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1Du89T-0005RF-NK; Sun, 17 Jul 2005 14:21:50 +0200 Message-ID: <42DA4D5A.7070601@tm.uka.de> Date: Sun, 17 Jul 2005 14:21:46 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: MOBOPTS , MIP6 X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: -1.6 (-) X-Spam-Status: No X-Spam-Score: 2.4 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Jari Arkko , Rajeev Koodli Subject: [Mobopts] Draft-irtf-mobopts-ro-enhancements-00.txt Revised X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0142838393==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0142838393== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7C2BBC1EE440D50CB445A24E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7C2BBC1EE440D50CB445A24E Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi everybody, draft-irtf-mobopts-ro-enhancements-00.txt has been thoroughly reviewed by Samita Chakrabarti, Francis Dupont, Thierry Ernst, Gerardo Giaretta, James Kempf, Rajeev Koodli, Gabriel Montenegro, and Vidya Narayanan (in alphabetical order). Thanks to all of them. I incorporated most of the suggestions from these folks. The new version is now available at http://doc.tm.uka.de/2005/draft-irtf-mobopts-ro-enhancements-01-pre.txt and I will submit it tomorrow at 6:00 am ET. BTW, the draft has a dedicated Acknowledgements section, right after the Introduction, referring to the many reviews that we got. Regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ --------------enig7C2BBC1EE440D50CB445A24E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC2k1awstEk8gl2rURArBEAKCiSpzpywFAkGdSmjYukZ/tGTFf2wCfXhBO et5unllqp8xLfTqQvDYF06A= =19Cx -----END PGP SIGNATURE----- --------------enig7C2BBC1EE440D50CB445A24E-- --===============0142838393== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============0142838393==-- From mobopts-bounces@irtf.org Sun Jul 17 08:29:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du8Gy-0006qy-Fd; Sun, 17 Jul 2005 08:29:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du8Gu-0006nR-M0 for mobopts@megatron.ietf.org; Sun, 17 Jul 2005 08:29:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01070 for ; Sun, 17 Jul 2005 08:29:27 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX18pcpdB4RCM+AzIF/GjDMZuBwB9pnJX0U4=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du8k8-0003Dj-Es for mobopts@irtf.org; Sun, 17 Jul 2005 08:59:40 -0400 Received: from hsi-kbw-082-212-035-085.hsi.kabelbw.de ([82.212.35.85] helo=[192.168.123.123]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1Du8Gn-0005cD-Ue; Sun, 17 Jul 2005 14:29:26 +0200 Message-ID: <42DA4F20.3010202@tm.uka.de> Date: Sun, 17 Jul 2005 14:29:20 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mobopts] Agenda for Paris meeting References: <42D81619.4000405@iprg.nokia.com> In-Reply-To: <42D81619.4000405@iprg.nokia.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: -2.4 (--) X-Spam-Status: No X-Spam-Score: 2.4 (++) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Jari Arkko , "mobopts@irtf.org" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1096450226==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1096450226== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6EC1B7F2198F18AB9A4685F2" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6EC1B7F2198F18AB9A4685F2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Rajeev, I'd like to give a brief update on draft-irtf-mobopts-ro-enhancements-00/01.txt. This will focus on... - Who reviewed version 00 of the draft? - What are the main changes from version 00 to 01? - Solicit a discussion on whether to drop the text on HMIPv6 and FMIPv6. The update won't take longer than 10 minutes. Kind regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Rajeev Koodli wrote: > > > Hello folks, > > here it is.. If I have missed anything, let me know asap. > > Regards, > > -Rajeev > > > 1. Introduction, status update (chairs, 5 minutes) > > 2. "Link Characteristics Information for Mobile IP", SD Park and J. > Korhonen, 10 minutes draft-daniel-mip-link-characteristic-02.txt > > 3. "LowPan Mobility Requirements and Goals", S. Chakrabarti > draft-chakrabarti-mobopts-lowpan-req-00, 15 minutes > > 4. "Link Triggers and TARZAN implementation update", K. Mitsuya 10 > minutes > > 5. "An efficient dynamic multicast agent approach for mobile IPv6 > multicast", HK Zhang draft-zhang-mipshop-multicast-dma-00.txt, 15 > minutes > > 6. "Seamless Multicast Handover in a Hierarchical Mobile IPv6 > Environment (M-HMIPv6)", T. Schmidt > draft-schmidt-waehlisch-mhmipv6-03.txt, 15 minutes > > 7. "MPA Framework and Implementation Updates", by A. Dutta > draft-ohba-mobopts-mpa-{framework,implementation}-01.txt, 15 minutes > > 8. "Secure Proxy Neighbor Discovery using Multi-key CGAs", J. Kempf > draft-kempf-mobopts-ringsig-ndproxy-00.txt, 15 minutes --------------enig6EC1B7F2198F18AB9A4685F2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC2k8gwstEk8gl2rURAlZvAJ0UcVbvV3E07+jLjKp2G/TvGUGOugCggZsB UGAIeACJaQPhh4CbZCCqeI0= =i7Az -----END PGP SIGNATURE----- --------------enig6EC1B7F2198F18AB9A4685F2-- --===============1096450226== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============1096450226==-- From mobopts-bounces@irtf.org Sun Jul 17 08:45:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du8WB-0003O6-1m; Sun, 17 Jul 2005 08:45:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du8W8-0003KW-Pd for mobopts@megatron.ietf.org; Sun, 17 Jul 2005 08:45:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01724 for ; Sun, 17 Jul 2005 08:45:10 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du8zL-00046H-9M for mobopts@irtf.org; Sun, 17 Jul 2005 09:15:24 -0400 Received: from [192.168.1.2] (p54AB9635.dip0.t-ipconnect.de [84.171.150.53]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 13BB51BAC4D; Sun, 17 Jul 2005 14:45:01 +0200 (CEST) Message-ID: <42DA52CD.1030008@netlab.nec.de> Date: Sun, 17 Jul 2005 14:45:01 +0200 From: Telemaco Melia User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mobopts] Agenda for Paris meeting References: <42D81619.4000405@iprg.nokia.com> In-Reply-To: <42D81619.4000405@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: "mobopts@irtf.org" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Rajeev, We intend to have an update on the ID "draft-melia-mobopts-niho-fmip-01.txt". It will take between 5 and 10 minutes. Content of the presentation will follow. regards, Telemaco Rajeev Koodli wrote: > > > Hello folks, > > here it is.. If I have missed anything, let me know asap. > > Regards, > > -Rajeev > > > 1. Introduction, status update (chairs, 5 minutes) > > 2. "Link Characteristics Information for Mobile IP", SD Park and > J. Korhonen, 10 minutes > draft-daniel-mip-link-characteristic-02.txt > > 3. "LowPan Mobility Requirements and Goals", S. Chakrabarti > draft-chakrabarti-mobopts-lowpan-req-00, 15 minutes > > 4. "Link Triggers and TARZAN implementation update", K. Mitsuya > 10 minutes > > 5. "An efficient dynamic multicast agent approach for mobile IPv6 > multicast", HK Zhang > draft-zhang-mipshop-multicast-dma-00.txt, 15 minutes > > 6. "Seamless Multicast Handover in a Hierarchical > Mobile IPv6 Environment (M-HMIPv6)", T. Schmidt > draft-schmidt-waehlisch-mhmipv6-03.txt, 15 minutes > > 7. "MPA Framework and Implementation Updates", by A. Dutta > draft-ohba-mobopts-mpa-{framework,implementation}-01.txt, > 15 minutes > > 8. "Secure Proxy Neighbor Discovery using Multi-key CGAs", J. Kempf > draft-kempf-mobopts-ringsig-ndproxy-00.txt, 15 minutes > > > > > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jul 18 04:52:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuRMx-0003TX-P8; Mon, 18 Jul 2005 04:52:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuRMw-0003TJ-DV for mobopts@megatron.ietf.org; Mon, 18 Jul 2005 04:52:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23539 for ; Mon, 18 Jul 2005 04:52:56 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuRqJ-0007K9-VZ for mobopts@irtf.org; Mon, 18 Jul 2005 05:23:21 -0400 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 9ADE6D9E8; Mon, 18 Jul 2005 10:52:39 +0200 (CEST) Received: from [10.1.1.115] ([10.1.1.115]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jul 2005 10:52:39 +0200 Message-ID: <42DB6DD7.2000102@netlab.nec.de> Date: Mon, 18 Jul 2005 10:52:39 +0200 From: Telemaco Melia User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "mobopts@irtf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2005 08:52:39.0525 (UTC) FILETIME=[0D498150:01C58B76] X-Spam-Score: 2.4 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Rui Aguiar Subject: [Mobopts] draft-melia-mobopts-niho-fmip-01.txt updated X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi folks, Please find at the following link ftp://195.37.70.21/pub/internet-drafts/draft-melia-mobopts-niho-fmip-01.txt version 01 (at least until does not get public). Some considerations have been added in section 5.4 and 5.5. There are three related documents to be considered. -- "draft-daniel-mip-link-characteristic-02" and "draft-cui-mobopts-hcf-wlan-00" are relevant for section 5.4 (Technology Customization and Optimizations). -- "draft-vidya-mipshop-handover-keys-aaa-00" for section 5.5 (Security Considerations) The document takes into account WG requirements (e.g. WLAN optimizations). Due to the increasing interest on this topic we believe it should be considered for the rechartering of the WG. We hope this work could serve as a good starting point Comments are welcome, especially from the authors of the above mentioned drafts. Let us discuss on the mailing list regards, Telemaco -- Telemaco Melia telemaco.melia@netlab.nec.de Research Staff Member Tel: +49 (0) 6221 90511-42 Network Laboratories Fax: +49 (0) 6221 90511-55 NEC Europe Ltd. Web: http://netlab.nec.de Kurfrsten-Anlage 36 D-69115 Heidelberg Germany _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jul 18 05:44:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuSAR-0006CK-Vp; Mon, 18 Jul 2005 05:44:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuSAO-0006AN-Hd for mobopts@megatron.ietf.org; Mon, 18 Jul 2005 05:44:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26322 for ; Mon, 18 Jul 2005 05:44:02 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuSdl-0002Pw-Qz for mobopts@irtf.org; Mon, 18 Jul 2005 06:14:27 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IJT0093LH2FFB@dns2.cselt.it> for mobopts@irtf.org; Mon, 18 Jul 2005 11:30:15 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 11:42:12 +0200 Date: Mon, 18 Jul 2005 11:43:47 +0200 From: Gerardo Giaretta To: Christian Vogt Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Re: Review of draft-irtf-mobopts-ro-enhancements-00 thread-index: AcWLbwCTdkEXI55HRFOeIaVXkbXZfQADhiCQ Content-Class: urn:content-classes:message X-OriginalArrivalTime: 18 Jul 2005 09:42:12.0843 (UTC) FILETIME=[F985D3B0:01C58B7C] X-Spam-Score: 2.4 (++) X-Scan-Signature: 57b3d456dc4730784e7070d5c6b7d14f Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, Rajeev Koodli , Jari Arkko , mobopts@irtf.org Subject: [Mobopts] RE: [Mip6] Re: Review of draft-irtf-mobopts-ro-enhancements-00 X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi Christian, the text sounds good to me. Thanks, --Gerardo > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On=20 > Behalf Of Christian Vogt > Sent: domenica 17 luglio 2005 14.12 > To: Gerardo Giaretta > Cc: mip6@ietf.org; Rajeev Koodli; Jari Arkko; mobopts@irtf.org > Subject: [Mip6] Re: Review of draft-irtf-mobopts-ro-enhancements-00 >=20 > Hi Gerardo, >=20 > you had one more comment concerning the section on processing=20 > improvements: >=20 > > Not necessarily. However, even without any reference, some more > > details can be useful. As you mention RR was designed with low > > computational complexity in mind. If you state that it can be too > > expensive, you should at least provide some examples, scenarios or > > data. >=20 > Thinking more about this, I tend to conclude that the=20 > complexity of the > return-routability procedure is already very low. One may further > reduce processing requirements through easier ways to compute the Home > and Care-of Keygen Tokens, or the KBM. But that's probably=20 > not so urgent. >=20 > Here is the new text: >=20 > 5.17 Processing Improvements >=20 > One goal for designing the return-routability procedure=20 > was to limit > its computational complexity to a minimum. The=20 > processing overhead > for route optimization should thus be acceptable in general. > However, some alternatives to the return-routability procedure use > stronger cryptographic algorithms, such as public-key=20 > cryptography. > This can be more taxing on processing resources,=20 > especially for low- > provisioned handheld devices. Here, it may help to replace RSA > algorithms with ECC techniques. >=20 > Regards, >=20 > - Christian >=20 > -- > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ >=20 >=20 >=20 > Gerardo Giaretta wrote: > > Hi Christian, > > > > thanks for your replay. Some comments below... > > > > > >> Hi Gerardo, > >> > >> thanks again for reviewing the doc. Some responses below. You can > >> check the new version at > >> > >> http://doc.tm.uka.de/2005/draft-irtf-mobopts-ro-enhancements-0 > >> 1-pre.txt > >> > >> - Christian > >> > >> ++++ > >> > >> > >>> General comment: I think the draft is very well-written and > >> > >> provide a > >> > >>> complete analysis of the topic. The unique general issue I found > >>> is that it is very long. I agree with James' comment that the > >>> draft could be shortened removing some sections that are not > >>> completely in the scope of the draft (e.g. section 5.13 and 5.14, > >>> more about these sections below). > >> > >> Ok, will do that. > >> > >> > >>> More detailed comments: > >>> > >>> - section 1, paragraph 4 "In the opposite direction, the mobile > >>> node may tunnel packets to the home agent". I think this sentence > >>> is not completely correct, or at least a bit misleading. If route > >>> optimization is not used, the MN MUST tunnel packets to the HA. > >>> Is "MAY" used in this sentence to highlight that the MN can > >>> choose to use bidirectional tunneling or route optimization? > >> > >> You are right, the text is misleading. The idea was that RO is the > >> alternative, and the MN may choose (provided the CN supports RO). > >> But, again, this is confusing, so I changed it. > >> > >> > >>> - section 1, paragraph 10 "This can lead to handover delay > >>> unacceptable for many real-time or interactive applications like > >>> Voice over IP (VoIP) and audio or video streaming". I'd suggest > >>> to remove audio/video streaming here. Streaming applications are > >>> not real-time nor interactive: they usually buffer few seconds of > >>> the movie/sound and thus are usually not affected by MIPv6 > >>> handover latency. At least this is what we have experimented in > >>> our labs. > >> > >> Would you say that rapid handovers and small buffers in > >> less-provisioned devices can be an issue with streaming? > >> > > > > > > Yes, it can be an issue. But this depends on the device capabilities > > and not on strong application requirements. Usually, in most > > streaming applications, buffer size is configurable and has=20 > a default > > value of few seconds. > > > > > >> Anyway, I changed the text. > >> > > > > > > Good. > > > > > >>> - section 3.1, paragraph 7 "The mobile node must compute a > >>> message-authentication code keyed with the Home and Care-of > >>> Keygen Token". Actually the MAC is keyed with the Kbm, that is a > >>> 20 octets SHA-1 hash of the concatenation of Home and Care-of > >>> Keygen Token > >> > >> Right, this was imprecise. Corrected it. > >> > >> > >>> - section 4.1, paragraph 1: I would mention explicitly that the > >>> handoff latency for a route-optimized communication is longer > >>> than for a bi-directional tunneled communication. > >> > >> Yes, it's added. > >> > >> > >>> - section 4.1, paragraph 2: since the CN is not always required > >>> to send the BA, I wonder why the MN should by default wait for > >>> the BA. Or are you suggesting the MN asks the CN an ack? If so, I > >>> think the sentence should be rephrased. > >> > >> Right. > >> > >> > >>> - section 4.1, paragraph 3 "But more generally, mobile > >> > >> nodes wait for > >> > >>> the home registration to be completed and acknowledged before > >>> initiating the correspondent registration". Are you > >> > >> referring to some > >> > >>> specific implementations? I'm asking this because the open source > >>> implementation we use in our labs does not wait the BA. > >> > >> Kame-Shisa does it. We added the optimization not to wait for the > >> BA from the HA. > >> > >> Actually, not waiting for the BA is not standard-conform. RFC 3775 > >> says that the lifetime of correspondent registrations must not > >> exceed that of the home registration. And the latter becomes known > >> to the MN only with the BA. > >> > >> I don't think this requirement is critical, though. After all, > >> it's up to the MN to request the CN lifetime anyway. It could just > >> ignore the home-registration lifetime. > >> > > > > > > I tend to agree on this. This implementation choice can improve > > performance. > > > > > > > >>> - section 4.4, paragraph 2: I would add references to > >>> draft-koodli-mip6-location-privacy-00 and to > >>> draft-koodli-mip6-location-privacy-solutions-00 > >> > >> Definitely a good idea. > >> > >> > >>> - section 5.2, paragraph 1: What do you mean by "close to > >> > >> the mobile > >> > >>> node"? Shouldn't it be "on the path between MN and HA"? > >> > >> The critical link on the patch between the MN and the HA is a > >> wireless first hop. > >> > >> Anyway, the text is unclear. Rewrote that sentence. > >> > >> > >>> - section 5.3, paragraph 2: the sentence is not clear to > >> > >> me. The last > >> > >>> BA is referred to BA from CN, I suppose. If so, I think it > >> > >> should be > >> > >>> mentioned explicitly. > >> > >> Done. > >> > >> > >>> - section 5.13: as mentioned before I think this section is not > >>> really in the scope of the draft. If you think it is, I'd suggest > >>> to include some more text explaining how HMIPv6 influences RO > >> > >> operations > >> > >>> (e.g. reduction of signaling overhead). The same applies to > >>> section 5.14. I think that FMIPv6 has even less impact on RO than > >>> HMIPv6. So I suggest you include some more text to explain how > >>> these protocols are tied to RO. > >> > >> It seems there is pretty much agreement in that FMIPv6 and HMIPv6 > >> should be removed from this particular document. > >> > >> > >>> - section 5.16, last sentence: are there simulations that prove > >>> that RR can be too expensive? A reference could be helpful. > >> > >> I don't have such a reference. Is your suggestion to remove the > >> section in this case? > >> > > > > > > Not necessarily. However, even without any reference, some more > > details can be useful. As you mention RR was designed with low > > computational complexity in mind. If you state that it can be too > > expensive, you should at least provide some examples, scenarios or > > data. > > > > --Gerardo > > > > > >>> - section 6.2.1, last paragraph: HMIPv6 causes always a tunneling > >>> overhead that is not present in plain MIPv6. Therefore, some > >>> localized mobility protocols always cause overhead and not only > >>> "in some situations". > >> > >> That's right. But I have already removed that sub-section. > >> > >> > >>> - section 6.2.2, paragraph 1 "On the other hand, nodes that do > >>> share a common secret should be allowed to omit the home-address > >>> test". Isn't required that the common secret is tied to the Home > >>> Address used in order to remove the home address test? > >> > >> You are right. Added that. > >> > >> > >>> Editorial comments: > >>> > >>> - section 4.1, last paragraph: Section 6.3.1 should be in > >> > >> brackets or > >> > >>> similar > >> > >> Oops, it's done. > >> > >> > >>> - section 5.1, paragraph 2: s/IP-ddress/IP-address > >> > >> Ok. > >> > >> > >>> - section 5.7, paragraph 5: s/its is the data/it is the data > >> > >> Ok. > >> > >> > >>> - section 5.8, paragraph 2: s/it in general/it is in general > >> > >> Ok. > >> > >> > >>> Hope this helps. > >> > >> It did. ;) > >> > >> Thanks, - Christian > >> > >> -- Christian Vogt, Institute of Telematics, University of Karlsruhe > >> www.tm.uka.de/~chvogt/pubkey/ > >> > >> > >> > >> Gerardo Giaretta wrote: > >> > >>> Hi Christian and Jari, > >>> > >>> Raj requested me to review draft-irtf-mobopts-ro-enhancements-00. > >>> Here are some comments and question. > >>> > >>> General comment: I think the draft is very well-written and > >> > >> provide a > >> > >>> complete analysis of the topic. The unique general issue I found > >>> is that it is very long. I agree with James' comment that the > >>> draft could be shortened removing some sections that are not > >>> completely in the scope of the draft (e.g. section 5.13 and 5.14, > >>> more about these sections below). > >>> > >>> More detailed comments: > >>> > >>> - section 1, paragraph 4 "In the opposite direction, the mobile > >>> node may tunnel packets to the home agent". I think this sentence > >>> is not completely correct, or at least a bit misleading. If route > >>> optimization is not used, the MN MUST tunnel packets to the HA. > >>> Is "MAY" used in this sentence to highlight that the MN can > >>> choose to use bidirectional tunneling or route optimization? > >>> > >>> - section 1, paragraph 10 "This can lead to handover delay > >>> unacceptable for many real-time or interactive applications like > >>> Voice over IP (VoIP) and audio or video streaming". I'd suggest > >>> to remove audio/video streaming here. Streaming applications are > >>> not real-time nor interactive: they usually buffer few seconds of > >>> the movie/sound and thus are usually not affected by MIPv6 > >>> handover latency. At least this is what we have experimented in > >>> our labs. > >>> > >>> - section 3.1, paragraph 7 "The mobile node must compute a > >>> message-authentication code keyed with the Home and Care-of > >>> Keygen Token". Actually the MAC is keyed with the Kbm, that is a > >>> 20 octets SHA-1 hash of the concatenation of Home and Care-of > >>> Keygen Token > >>> > >>> - section 4.1, paragraph 1: I would mention explicitly that the > >>> handoff latency for a route-optimized communication is longer > >>> than for a bi-directional tunneled communication. > >>> > >>> - section 4.1, paragraph 2: since the CN is not always required > >>> to send the BA, I wonder why the MN should by default wait for > >>> the BA. Or are you suggesting the MN asks the CN an ack? If so, I > >>> think the sentence should be rephrased. > >>> > >>> - section 4.1, paragraph 3 "But more generally, mobile > >> > >> nodes wait for > >> > >>> the home registration to be completed and acknowledged before > >>> initiating the correspondent registration". Are you > >> > >> referring to some > >> > >>> specific implementations? I'm asking this because the open source > >>> implementation we use in our labs does not wait the BA. > >>> > >>> - section 4.4, paragraph 2: I would add references to > >>> draft-koodli-mip6-location-privacy-00 and to > >>> draft-koodli-mip6-location-privacy-solutions-00 > >>> > >>> - section 5.2, paragraph 1: What do you mean by "close to > >> > >> the mobile > >> > >>> node"? Shouldn't it be "on the path between MN and HA"? > >>> > >>> - section 5.3, paragraph 2: the sentence is not clear to > >> > >> me. The last > >> > >>> BA is referred to BA from CN, I suppose. If so, I think it > >> > >> should be > >> > >>> mentioned explicitly. > >>> > >>> - section 5.13: as mentioned before I think this section is not > >>> really in the scope of the draft. If you think it is, I'd suggest > >>> to include some more text explaining how HMIPv6 influences RO > >> > >> operations > >> > >>> (e.g. reduction of signaling overhead). The same applies to > >>> section 5.14. I think that FMIPv6 has even less impact on RO than > >>> HMIPv6. So I suggest you include some more text to explain how > >>> these protocols are tied to RO. > >>> > >>> - section 5.16, last sentence: are there simulations that prove > >>> that RR can be too expensive? A reference could be helpful. > >>> > >>> - section 6.2.1, last paragraph: HMIPv6 causes always a tunneling > >>> overhead that is not present in plain MIPv6. Therefore, some > >>> localized mobility protocols always cause overhead and not only > >>> "in some situations". > >>> > >>> - section 6.2.2, paragraph 1 "On the other hand, nodes that do > >>> share a common secret should be allowed to omit the home-address > >>> test". Isn't required that the common secret is tied to the Home > >>> Address used in order to remove the home address test? > >>> > >>> > >>> Editorial comments: > >>> > >>> - section 4.1, last paragraph: Section 6.3.1 should be in > >> > >> brackets or > >> > >>> similar > >>> > >>> - section 5.1, paragraph 2: s/IP-ddress/IP-address > >>> > >>> - section 5.7, paragraph 5: s/its is the data/it is the data > >>> > >>> - section 5.8, paragraph 2: s/it in general/it is in general > >>> > >>> > >>> Hope this helps. > >>> > >>> Regards, --Gerardo > >>> > >>> > >>> > >>> > >>> > >>> > >>> Gruppo Telecom Italia - Direzione e coordinamento di Telecom > >>> Italia S.p.A. > >>> > >>> > >> > >>=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> > >>> CONFIDENTIALITY NOTICE This message and its attachments are > >> > >> addressed > >> > >>> solely to the persons above and may contain confidential > >> > >> information. > >> > >>> If you have received the message in error, be informed that any > >>> use of the content hereof is prohibited. Please return it > >>> immediately to the sender and delete the message. Should you have > >>> any questions, please send an e_mail to MailAdmin@tilab.com. > >>> Thank you > >>>=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> > >> > >> > > > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia > > S.p.A. > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > CONFIDENTIALITY NOTICE This message and its attachments are=20 > addressed > > solely to the persons above and may contain confidential=20 > information. > > If you have received the message in error, be informed that any use > > of the content hereof is prohibited. Please return it immediately to > > the sender and delete the message. Should you have any questions, > > please send an e_mail to MailAdmin@tilab.com. Thank you > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jul 18 07:43:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuU2M-0004C2-PL; Mon, 18 Jul 2005 07:43:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuU2L-0004Bx-9X for mobopts@megatron.ietf.org; Mon, 18 Jul 2005 07:43:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02703 for ; Mon, 18 Jul 2005 07:43:52 -0400 (EDT) From: jouni.korhonen@teliasonera.com Received: from ceiling.dave.sonera.fi ([131.177.130.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuUVj-0001kl-2a for mobopts@irtf.org; Mon, 18 Jul 2005 08:14:17 -0400 Received: from ceiling.dave.sonera.fi (localhost [127.0.0.1]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id j6IBhVNo002055 for ; Mon, 18 Jul 2005 14:43:31 +0300 (EEST) Received: from FITMS201MB.tcad.telia.se (fitms201ca.tcad.telia.se [131.177.121.203]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id j6IBhT7C002035; Mon, 18 Jul 2005 14:43:31 +0300 (EEST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6617.27 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: Re: [Mobopts] New topics for the RG Date: Mon, 18 Jul 2005 14:43:29 +0300 Message-ID: <07B14A720C46C344AC96AAA64F5D6A31014911DB@FITMS201MB.tcad.telia.se> Thread-Topic: Re: [Mobopts] New topics for the RG Thread-Index: AcWLjfT/6Naj1B73TDCACHkkeXbi9Q== To: , X-Spam-Score: 2.7 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi, Checking the new topics for the RG few of them look particularly interesting. I have a couple of comments and questions regarding them. [snip snap] > - mobility (and traffic) patterns in a WLAN (e.g., a campus network). This should provide > a better sense of traffic for admission control as well as network-controlled handovers. [snip snap] > - architectural barriers to optimizing inter-domain handovers. Although we have > some understanding of improving delay and packet loss during handovers across > IP networks, how applicable are they across different autonomous systems? Would > the policy barriers allow optimizations? Is this an example of "tussle in cyberspace"? [snip snap] As I work for an operator and am involved in other SDOs these two topics look very interesting (network controlled handovers and inter-domain handovers). I'm just wondering if those could also be studied from a "steering of roaming" point of view, where the handover decision could=20 be based on or at least weighted by home operator policies and predefined prioritization of roaming partners? At least not particularly disabling such use case of the possible solution. Very roughly put I would assume that this kind of approach of "guiding" handover decision requires a mechanism to inform the mobility management point about networks & network identities available to MN even if the networks belong to different administrative domains. A mechanism to signal back the home network preferences of the networks before the handover takes place (or immediately after the handover) in the MN is needed. Also a possibility to suggest a handover from network side between binding updates would be a definitive plus. Would this group be interested in this topic from the angle I described it? Cheers, Jouni --=20 Jouni Korhonen - Senior Researcher Wireless Mobility Services TeliaSonera _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jul 18 13:25:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuZMv-00074u-Ek; Mon, 18 Jul 2005 13:25:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuZMt-00074p-WA for mobopts@megatron.ietf.org; Mon, 18 Jul 2005 13:25:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29722 for ; Mon, 18 Jul 2005 13:25:25 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuZqM-0008N0-Rd for mobopts@irtf.org; Mon, 18 Jul 2005 13:55:55 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6IGrU729814 for ; Mon, 18 Jul 2005 09:53:30 -0700 X-mProtect: <200507181653> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14166.americas.nokia.com (172.18.141.66, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdTuLfAO; Mon, 18 Jul 2005 09:53:29 PDT Message-ID: <42DBE5F0.2080406@iprg.nokia.com> Date: Mon, 18 Jul 2005 10:25:04 -0700 From: Rajeev Koodli 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: "mobopts@irtf.org" Subject: [Fwd: [Mobopts] Agenda for Paris meeting] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Folks, I had missed Title: Improvement on Security and Performance of MIP6 Return Routability Test (draft-zhao-mobopts-rr-ext-00) Time: 15 min from Fan Zhao (request sent on July 11). I have received quite a few new requests for presentation. As you can see, we have 5 minutes remaining in the current 2 hour slot. So, I will not be able to accommodate the new requests. We can try the following: - I will see if I can get a 2 1/2 hour slot. FYI: I had asked for two separate slots for 2 and 2.5 hours. I am afraid an additional 1/2 hour is still not sufficient. So, - meet informally, Monday night from 19.30 - 20.30 or higher subject to facilities closure. I am assuming that they would let us use a room. What do folks think? NOTE: The agenda below is for Thursday, as it appears in the official meeting times.. Regards, -Rajeev 1. Introduction, status update (chairs, 5 minutes) 2. "Link Characteristics Information for Mobile IP", SD Park and J. Korhonen, 10 minutes draft-daniel-mip-link-characteristic-02.txt 3. "LowPan Mobility Requirements and Goals", S. Chakrabarti draft-chakrabarti-mobopts-lowpan-req-00, 15 minutes 4. "Link Triggers and TARZAN implementation update", K. Mitsuya 10 minutes 5. "An efficient dynamic multicast agent approach for mobile IPv6 multicast", HK Zhang draft-zhang-mipshop-multicast-dma-00.txt, 15 minutes 6. "Seamless Multicast Handover in a Hierarchical Mobile IPv6 Environment (M-HMIPv6)", T. Schmidt draft-schmidt-waehlisch-mhmipv6-03.txt, 15 minutes 7. "MPA Framework and Implementation Updates", by A. Dutta draft-ohba-mobopts-mpa-{framework,implementation}-01.txt, 15 minutes 8. "Secure Proxy Neighbor Discovery using Multi-key CGAs", J. Kempf draft-kempf-mobopts-ringsig-ndproxy-00.txt, 15 minutes 9. "Improvement on Security and Performance of MIP6 Return Routability Test", F Zhao draft-zhao-mobopts-rr-ext-00, 15 minutes. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jul 19 04:03:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dun4k-0006q5-An; Tue, 19 Jul 2005 04:03:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dun4h-0006po-Ot for mobopts@megatron.ietf.org; Tue, 19 Jul 2005 04:03:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18250 for ; Tue, 19 Jul 2005 04:03:33 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DunYG-0001Gz-Un for mobopts@irtf.org; Tue, 19 Jul 2005 04:34:10 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6J83UqK020930 for ; Tue, 19 Jul 2005 17:03:30 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6J83TDS000787 for ; Tue, 19 Jul 2005 17:03:29 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6J83SLB000775 for ; Tue, 19 Jul 2005 17:03:28 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6J83RcN010772 for ; Tue, 19 Jul 2005 17:03:27 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6J83QS2010749 for ; Tue, 19 Jul 2005 17:03:26 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6J83PQE021136 for ; Tue, 19 Jul 2005 17:03:25 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6J83PfY018477 for ; Tue, 19 Jul 2005 17:03:25 +0900 (JST) Received: from imd.m.ecl.ntt.co.jp (imd0.m.ecl.ntt.co.jp [129.60.5.142]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6J83P3T018474 for ; Tue, 19 Jul 2005 17:03:25 +0900 (JST) Received: from imd.m.ecl.ntt.co.jp by imd.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with SMTP id RAA12160 for ; Tue, 19 Jul 2005 17:03:25 +0900 (JST) Message-Id: <200507190803.RAA12160@imd.m.ecl.ntt.co.jp> Date: Tue, 19 Jul 2005 17:01:27 +0900 From: Takeshi Ogawa X-Mailer: EdMax Ver2.85.3F MIME-Version: 1.0 To: mobopts@irtf.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 4.4 (++++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Subject: [Mobopts] draft-ogawa-mobopts-dhcpv4-fho-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi MobOpts people, I have posted a new draft, DHCPv4 Extensions and Option for Fast Handovers. It is ported from "DHCPv6 options for Fast Handovers", and I suppose it is worth to be used if some kind of macro mobility (e. g., SIP) is used, but any micro-mobility management protocols (e. g., FMIPv4) are not. I cannot attend 63rd meeting, but would like to have comments on the draft from people in MobOpts on this ML. Thanks in advance. Regards, - Takeshi Internet-Drafts@ietf.org wrote: > > > > Title : DHCPv4 Extensions and Option for Fast Handovers > Author(s) : T. Ogawa > Filename : draft-ogawa-mobopts-dhcpv4-fho-00.txt > Pages : > Date : 2005-7-12 > > When a standard IPv4 node (mobile node: MN) changes its wireless > network attachment point (performs a handover), it gets new IP layer > configuration information (e.g., its new IP address and the addresses > of new routers) from a DHCP server and changes its IP layer > configuration. During such a handover process, it cannot send or > receive IP packets to/from its corresponding node (CN), so a service > disruption is caused. In this document, we introduce new DHCPv4 > extensions and an option (Fast Handover Option) for fast handovers. > This protocol is ported from DHCPv6 options for Fast Handovers [6]. > It enables DHCP servers to send new configuration information to MNs > before a handover to be used after the handover, so MNs can have > shorter handover processing times. It is noted that DHCP servers and > MNs implementing this protocol can achieve fast handovers with > standard IPv4 routers without any other micro-mobility management > protocols. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ogawa-mobopts-dhcpv4-fho-00.txt _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jul 19 08:27:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DurCO-00073T-7p; Tue, 19 Jul 2005 08:27:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DurCN-00073O-5Z for mobopts@megatron.ietf.org; Tue, 19 Jul 2005 08:27:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08705 for ; Tue, 19 Jul 2005 08:27:45 -0400 (EDT) Message-Id: <200507191227.IAA08705@ietf.org> Received: from csnet1.cs.tsinghua.edu.cn ([166.111.68.226]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Durfu-0004bV-7N for mobopts@irtf.org; Tue, 19 Jul 2005 08:58:24 -0400 Received: (qmail 2487 invoked by uid 0); 19 Jul 2005 12:45:23 -0000 Received: from unknown (HELO cy) (yong@219.243.215.254) by csnet1.cs.tsinghua.edu.cn with SMTP; 19 Jul 2005 12:45:23 -0000 Date: Tue, 19 Jul 2005 20:27:07 +0800 From: "Yong" To: "Rajeev Koodli" , "mobopts@irtf.org" Subject: Re: [Fwd: [Mobopts] Agenda for Paris meeting] X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Dear Rajeev, We are expecting that the network-controlled handover could be discussed on this IETF meeting. These candidate time you suggest is fine for us. Thanks for your consideration! -Yong ======= 2005-07-19 01:25:04 You wrote ======= > > >Folks, > >I had missed > >Title: Improvement on Security and Performance >of MIP6 Return Routability Test >(draft-zhao-mobopts-rr-ext-00) > >Time: 15 min > >from Fan Zhao (request sent on July 11). > > >I have received quite a few new requests for presentation. >As you can see, we have 5 minutes remaining in the current >2 hour slot. So, I will not be able to accommodate the >new requests. We can try the following: > >- I will see if I can get a 2 1/2 hour slot. FYI: I had asked > for two separate slots for 2 and 2.5 hours. I am afraid an additional > 1/2 hour is still not sufficient. So, >- meet informally, Monday night from 19.30 - 20.30 or higher subject > to facilities closure. I am assuming that they would let us use a > room. > >What do folks think? > >NOTE: The agenda below is for Thursday, as it appears in the official >meeting times.. > >Regards, > >-Rajeev > > >1. Introduction, status update (chairs, 5 minutes) > >2. "Link Characteristics Information for Mobile IP", SD Park and > J. Korhonen, 10 minutes > draft-daniel-mip-link-characteristic-02.txt > >3. "LowPan Mobility Requirements and Goals", S. Chakrabarti > draft-chakrabarti-mobopts-lowpan-req-00, 15 minutes > >4. "Link Triggers and TARZAN implementation update", K. Mitsuya > 10 minutes > >5. "An efficient dynamic multicast agent approach for mobile IPv6 > multicast", HK Zhang > draft-zhang-mipshop-multicast-dma-00.txt, 15 minutes > >6. "Seamless Multicast Handover in a Hierarchical > Mobile IPv6 Environment (M-HMIPv6)", T. Schmidt > draft-schmidt-waehlisch-mhmipv6-03.txt, 15 minutes > >7. "MPA Framework and Implementation Updates", by A. Dutta > draft-ohba-mobopts-mpa-{framework,implementation}-01.txt, > 15 minutes > >8. "Secure Proxy Neighbor Discovery using Multi-key CGAs", J. Kempf > draft-kempf-mobopts-ringsig-ndproxy-00.txt, 15 minutes > >9. "Improvement on Security and Performance of MIP6 Return Routability > Test", F Zhao > draft-zhao-mobopts-rr-ext-00, 15 minutes. > > > > >_______________________________________________ >Mobopts mailing list >Mobopts@irtf.org >https://www1.ietf.org/mailman/listinfo/mobopts > > > >_______________________________________________ >Mobopts mailing list >Mobopts@irtf.org >https://www1.ietf.org/mailman/listinfo/mobopts > ======================================= _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jul 19 09:34:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DusFF-00028A-8E; Tue, 19 Jul 2005 09:34:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DusFD-000280-6i for mobopts@megatron.ietf.org; Tue, 19 Jul 2005 09:34:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13373 for ; Tue, 19 Jul 2005 09:34:45 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dusip-0007DR-KH for mobopts@irtf.org; Tue, 19 Jul 2005 10:05:25 -0400 Received: from [219.101.140.31] (030.pacifictokyo.jp [219.101.140.31]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8FF501BAC4D; Tue, 19 Jul 2005 15:34:28 +0200 (CEST) Message-ID: <42DD015F.9040900@netlab.nec.de> Date: Tue, 19 Jul 2005 15:34:23 +0200 From: Telemaco Melia User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yong Subject: Re: [Fwd: [Mobopts] Agenda for Paris meeting] References: <200507191227.IAA08705@ietf.org> In-Reply-To: <200507191227.IAA08705@ietf.org> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Cc: Rajeev Koodli , "mobopts@irtf.org" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi all, Fine with me to fix the meeting on Monday evening. I agree that the network initiated handover should be an agenda item. Would this meeting to take effective decisions? We could coordinate a joint presentation if needed. regards, Telemaco Yong wrote: >Dear Rajeev, > >We are expecting that the network-controlled handover could be >discussed on this IETF meeting. These candidate time you suggest >is fine for us. > >Thanks for your consideration! > >-Yong > >======= 2005-07-19 01:25:04 You wrote ======= > > > >>Folks, >> >>I had missed >> >>Title: Improvement on Security and Performance >>of MIP6 Return Routability Test >>(draft-zhao-mobopts-rr-ext-00) >> >>Time: 15 min >> >> >> >>from Fan Zhao (request sent on July 11). > > >>I have received quite a few new requests for presentation. >>As you can see, we have 5 minutes remaining in the current >>2 hour slot. So, I will not be able to accommodate the >>new requests. We can try the following: >> >>- I will see if I can get a 2 1/2 hour slot. FYI: I had asked >> for two separate slots for 2 and 2.5 hours. I am afraid an additional >> 1/2 hour is still not sufficient. So, >>- meet informally, Monday night from 19.30 - 20.30 or higher subject >> to facilities closure. I am assuming that they would let us use a >> room. >> >>What do folks think? >> >>NOTE: The agenda below is for Thursday, as it appears in the official >>meeting times.. >> >>Regards, >> >>-Rajeev >> >> >>1. Introduction, status update (chairs, 5 minutes) >> >>2. "Link Characteristics Information for Mobile IP", SD Park and >> J. Korhonen, 10 minutes >> draft-daniel-mip-link-characteristic-02.txt >> >>3. "LowPan Mobility Requirements and Goals", S. Chakrabarti >> draft-chakrabarti-mobopts-lowpan-req-00, 15 minutes >> >>4. "Link Triggers and TARZAN implementation update", K. Mitsuya >> 10 minutes >> >>5. "An efficient dynamic multicast agent approach for mobile IPv6 >> multicast", HK Zhang >> draft-zhang-mipshop-multicast-dma-00.txt, 15 minutes >> >>6. "Seamless Multicast Handover in a Hierarchical >> Mobile IPv6 Environment (M-HMIPv6)", T. Schmidt >> draft-schmidt-waehlisch-mhmipv6-03.txt, 15 minutes >> >>7. "MPA Framework and Implementation Updates", by A. Dutta >> draft-ohba-mobopts-mpa-{framework,implementation}-01.txt, >> 15 minutes >> >>8. "Secure Proxy Neighbor Discovery using Multi-key CGAs", J. Kempf >> draft-kempf-mobopts-ringsig-ndproxy-00.txt, 15 minutes >> >>9. "Improvement on Security and Performance of MIP6 Return Routability >> Test", F Zhao >> draft-zhao-mobopts-rr-ext-00, 15 minutes. >> >> >> >> >>_______________________________________________ >>Mobopts mailing list >>Mobopts@irtf.org >>https://www1.ietf.org/mailman/listinfo/mobopts >> >> >> >>_______________________________________________ >>Mobopts mailing list >>Mobopts@irtf.org >>https://www1.ietf.org/mailman/listinfo/mobopts >> >> >> > >======================================= > > > > >_______________________________________________ >Mobopts mailing list >Mobopts@irtf.org >https://www1.ietf.org/mailman/listinfo/mobop > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jul 19 17:24:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuzaD-0005yN-AB; Tue, 19 Jul 2005 17:24:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duza4-0005pu-Ej for mobopts@megatron.ietf.org; Tue, 19 Jul 2005 17:24:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06234 for ; Tue, 19 Jul 2005 17:24:45 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv03e-0007TQ-Vx for mobopts@irtf.org; Tue, 19 Jul 2005 17:55:29 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j6JLXuL2018041 for ; Tue, 19 Jul 2005 14:33:56 -0700 (MST) Received: from il02exm13.corp.mot.com (il02exm13.corp.mot.com [10.0.111.24]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j6JLTwqw005362 for ; Tue, 19 Jul 2005 16:29:58 -0500 (CDT) Received: by il02exm13 with Internet Mail Service (5.5.2657.72) id ; Tue, 19 Jul 2005 16:24:34 -0500 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A71D7@il02exm13> From: Narayanan Vidya-CVN065 To: "'James Kempf'" , mipshop@ietf.org, mobopts@irtf.org Date: Tue, 19 Jul 2005 16:24:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 2.4 (++) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: Gerardo Giaretta , Julien Bournelle , Venkitaraman Narayanan-CNV002 , "'Tschofenig, Hannes'" Subject: [Mobopts] RE: Review of draft-vidya-mipshop-handover-keys-aaa-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org James, Thanks for the detailed review comments. First, let me try to respond to your comment on the architecture below. Please see inline for other comments. Regarding the architecture, you guessed right about the motivation for decoupling this protocol from network access authentication. It was to allow this protocol to work over heterogeneous L2 protocols. The HMK derivation itself, as you say, can be tied to network access and derived using extensions to EAP (which was the point of Appendix A). However, tying the derivation of the HK itself every time the MN roams to a new AR to network access seems a little restrictive to me. The thought is that the protocol should be usable when the MN hands off among any of these technologies - 802.11, 802.16, GPRS, and even say proprietary L2 protocols. Now, you mentioned tying this to PANA. The point I struggle with is this - do we believe that there is reason for PANA support to be ubiquitous? When there is a lower layer protocol that carries EAP, why would there be a need to support PANA in the network? I see PANA being used when the lower layer protocol is unable to carry EAP. Is this not true? Tying handover key derivation to PANA implies every AR that supports FMIP is required to support PANA - is this necessarily true? The actual protocol for deriving the HK itself (once the HMK is available) is very simple and is a single roundtrip protocol. ARs that support FMIP will need to support this protocol. By tying this to PANA, are we not creating dependency on a protocol that is not really required to support secure FMIP? Please correct me if I'm wrong, but to me, that seems to complicate the protocol. Also, the thought was this protocol could be used for any MN-AR communication that must be secured (such as CxTP, for instance and also IPv4 fast handoffs), although the draft currently is only detailed with FMIP in mind. Prior to writing the draft, we (the authors) had discussions on the protocol's dependency on network access authentication and for simplicity, decided to decouple the actual HK derivation from it. I do, however, agree that the HMK derivation based on EAP should be integrated into the main document - it was left as an Appendix mainly to allow someone to use pre-shared HMKs if need be - but, it would make sense for that to be part of the main spec. Thoughts on this? > > For example, since the protocol description in Section 3 does > not mention an encryption security association between the > AAA server and the MN, the nonce sent by the AAA server to > the MN seems to be sent in the clear, which gives an > eavesdropper one piece of information that it could use in > some fashion to compromise. If you read further (in > particular into the Appendix) you see that, in fact, EAP can > be used for this transaction, and so one of the EAP methods > that support secure MN-AAA server communication could be used > to maintain confidentiality on this transaction (though the > document provides no details on what the EAP extension is). > But if EAP isn't used, then what? > I am trying to understand the need for the nonce to be encrypted - there is nothing that an eavesdropper can do with the nonce without knowing the HMK - and the HMK is never sent out. Also, the HK, when sent to the AR is encrypted - so, what does encrypting the nonce really achieve? The nonces are usually sent in the clear in other protocols as well (for e.g. Mobile IP when used with MIP-AAA to generate dynamic keys, etc.) - so, that seemed okay. Are we missing something? > My (somewhat radical) suggestion to the authors would be to > redesign the protocol to couple it tightly with EAP-based > network access authentication protocol. This would mean: > > - Incorporating the derivation of the HMK from > the EAP key hiearchy which is now in Appendix A into the > protocol directly Agreed. This makes sense - we can revise the draft to include this. > - Using EAP within the network access > authentication transaction to exchange parameters to derive > the HMK, by defining an EAP extension for one of the > extensible EAP methods. This will ensure that the transaction > between the MN and AAA server is properly confidential, > protecting MN anonymity and the parameters of the key derivation Protecting MN anonymity makes sense and as we detail the contents of Appendix A and integrate it with the main document, this should be ironed out. I am still, however, wondering about the need to encrypt the nonce. > - Instead of defining a separate protocol for > preauthentication and reauthentication upon handover (Section > 4), couple the derivation of new HKs via preauthentication or > reauthentication on handover to PANA pre- and > reauthentication. This will allow the protocol to leverage > off of the PANA work, so that the deep thinking about how to > get pre- and reauthentication on handover right only needs to > be done once, for PANA (where it needs to be done anyway). > As I mentioned earlier, this is the part that I am not sure about - PANA defines pre- and reauth for the link layer and I see this being used when the lower layer doesn't already do EAP - does it really make sense to extend it to be used for L3 handovers as well? > Incidently, if one of the reasons why this protocol was > decoupled from network access authentication was to allow > IEEE 802.1x or other Layer 2 protocols to be used, then this > needs some rethinking. EAP is used in 802.1x anyway so it > could still be used for the initial HMK derivation. And the > 802.1x reauthentication isn't going to be useful for handover > key reauthentication, because it only deals with APs, which > are layer 2 devices, whereas this protocol must deal with > ARs, which are layer 3 devices, so PANA is probably the right vehicle. > > Detailed Editorial and Technical Comments: > > Section 3, paragraph 2: This paragraph seems to be specifying > use of the HMK for calculating a MAC. It might be a good idea > to keep the HMK private, and use a derived key for this > purpose, to avoid exposing material calculated with the HMK > to attackers. > Yes, this makes sense. We will correct this in v01. > Section 3, paragraph 2: As mentioned above, the nounce looks > to be sent in the clear. Might be better from a > confidentiality standpoint to encrypt. Similarly for the NAI. > Same question as before for the nonce. For the NAI, would it not be sufficient to provide a means of deriving an identity (or even multiple identities) to use as part of HMK derivation, so that MN privacy is protected? Encryption of these parameters should be simple enough - so, if you think that it will be better to do so, that can certainly be done. > Section 3, paragraph 4 and 6: What is PRF here? That was a miss on our part - should have stated HMAC-SHA1 as the pseudo-random function to be used. Will add this. > > Section 3.1, paragraph 2: Note that if the nounce is > encrypted, it need only be exchanged once, during the initial > HMK derivation. After that, fresh nounces can be derived by > forward hashing from the original. Alternatively, the AAA > server and MN can generate a hash chain and move backward (at > the expense of having to store the hashes). This eliminates > the need to send a hash out over the air each time a > reauthentication is performed. The AAA server can push the > appropriate nounce to the AR. Interesting thought on forward hashing. Regarding pushing the nonce to the AR - the AR does not have the HMK and hence, cannot derive the HK; so, the AAA server really needs to give the AR the HK - am I misunderstanding you here? > > Section 3.1: It is unclear to me how the MN manages keys > generated by preauthentication. Essentially, the MN is > setting up soft state in the network that it must manage. > Yet, the specification only briefly mentions key lifetimes, > and does not specify any suggested defaults, nor how the AR > knows what the lifetime of the key should be. > The AAA server does send a recommended lifetime to the AR (and the AR forwards that to the MN). However, the AAA server does not maintain any state about the lifetime itself and hence, it is up to the MN and AR to enforce the lifetime. Perhaps, the text can add more clarity on this. > Section 4.1, v Flag - Is the MN sharing a key with itself here? Oops. Good catch - it is an error. The "MN" at the end of that sentence should be "AR". > > Section 4.1, Seq. number - What if the message is > retransmitted on a new AR? Should the MN use the same Seq. > number or new? > For a given message ID, the sequence number is never repeated. Retransmissions are identified by the use of the same message ID (sequence number must be incremented though). A HKReq message is always sent to the AR with which the MN desires to share a HK. It may be sent via an old AR while the MN is attached to that oAR (note that the IP destination of that packet will still be the target AR with which it expects to share the HK). So, if the MN attaches to a new AR and does a retransmission, it should still use the same message ID - for a HKReq sent to ARn, a retransmission to the same ARn should always use the same message ID. Did I answer your question here? > Section 5.1: This section seemed to be saying that the MN > needs a key on the new AR when it hands over before it can do > the FMIP signaling, is that correct? If so, I'd like to know > why? The primary security issue in FMIP is not security with > the new AR, but security with the old AR. The old AR is being > asked by the FBU to change routing for the old CoA (i.e. set > up a tunnel from the old CoA to the new), and for that > purpose, it must have some indication that the entity sending > the FBU is authorized to claim the CoA. The new AR gets the > FNA which is typically piggybacked on the FBU, but that needs > to be secured using IP address configuration security, and it > can even be eliminated entirely if the MN used oDAD since its > only purpose is to allow the AR to confirm whether the > address is not a duplicate. For example, if the new CoA is > autoconfigured, then RFC 3971 and 3972 can be used to secure > the address. If the address in DHCP configured, other > mechanisms are to be used. Or are the authors intending here > to define a new way of performing IP address configuration security? > > With this comment in mind, I fail to see the urgency of > having to perform the key exchange with surrounding routers > immediately coupled to the handover signaling. The issue > becomes ensuring the MN has a key on the router it currently > is, so that when it hands over it can properly change > routing. For that purpose, the MN may want to perform > preauthentication in order to avoid having to establish the > key once it moves to the new router, but there is no need to > couple preauthentication tightly to the handover. > No, it is not mandated to derive a key with a new AR before the MN hands over. We used a "SHOULD" there, since deriving a key prior to handoff will be good practice for an MN that moves quickly between ARs on different subnets. The HK is only used with the FBU (so, you are right - it is needed only with the oAR, so the MN could potentially derive the key after it handsoff). This also becomes useful when this protocol is used to support MN-AR security for other protocols that may need the key to be present sooner for any communication (not within the scope of description in v00). > Section 5.1, paragraph 5: The last sentence is somewhat > gratuitous and can be dropped. > Ok. > Section 5.2, paragraph 1: Pick whether to include the Alt CoA > or not. Why have two choices here? > Most of the time, the source address of the packet should be sufficient in determining the CoA of the MN. However, the Alt CoA was included as a means for the MN to convey its CoA, if the source IP address is subject to change enroute - in IPv4, I can think of NATs causing this problem - but then, Alt CoA won't solve that anyway. So, maybe this is not required? The CoA itself is required to be bound to the HK mainly so that when the AR receives the FBU, it is able to locate the correct key to use for that MN. Having a provision for an SPI in the FBU will make this very clean and remove the need for this. In fact, the protocol itself can be simplified further if the FBU had a means of carrying an SPI. This is something we would like to discuss with you and Rajeev at Paris. I will send out a separate email on this topic, so that this email doesn't get out of control. > Section 5.2, paragraph 2: If the MN retransmits on the new > router, does it use the same seq number? If so, how does the > router/AAA server distinguish whether this is a replay attack or not? > A HKReq that was transmitted earlier to the AR (via an oAR) would have had the same message ID, if the MN is trying to retransmit a message. If an AR receives a HKReq with the same message ID and same sequence number, the packet is dropped. The sequence number must always start at 1 for a new message ID and then be incremented for every retransmission. A new HKReq (that is not a retransmission) must have a new message ID. If the text in the document is not clear on this, we can try to clarify it better. > Section 5.3: It seems here that the AAA-Local must perform > the key decapsulation and distribution to ARs in a roaming > scenario, because it is not realistic to expect the AAA-Home > to have security associations with all the ARs in a roaming > partner's access network. Perhaps this could be made more clear. > Yes, in a roaming case, this will be true. We can add some text to make that clear. > Section 6.2, Replay Protection, last sentence: Shouldn't this > be the HMK? No, it is really the HK. The sequence number must be unique for every retransmission (i.e., when the message ID is the same). Unless the MN is involved in a lot of retransmissions, a new HKReq must typically result in a new HK. Even when the MN is trying to verify the HKReq, it must be using a different message ID. Does that make sense? > > Section 6.2, Denial of Service, second paragraph: I am not a > big fan of puzzles, because their effectiveness depends on > the attacker co-operating and actually trying to solve the > puzzle. A dedicated attacker will simply pump packets out at > the victim, and ignore a puzzle response. This is especially > an issue with DDoS, where the attacking nodes are only > loosely co-ordinated and the effectivenes depends on volume. > You are right. DoS attacks are really impossible to eliminate completely - the question is whether this approach may mitigate it. > Section 6.2, Fragmentation: This statement is highly > dependent on the radio layer frame size. For a small enough > frame size, fragementation could still be an issue. It does not seem like this protocol may need to solve this, right? Perhaps, this section can be removed? > > Appendix D: Some of these suggestions involve having the ARs > perform key distribution. Since the ARs are not authenticated > directly to the MN, this may compromise security. > Yes, this is true. This is among the reasons why we didn't consider any of these approaches for the protocol. We may have missed stating that. We included this appendix to essentially explain why some of the other seemingly simple approaches were not so desirable. > Appendix E: It is heartening to see the use of formal methods > for the security proof, but in the absence of a deep study of > the specific syntax of the method used, I wonder how useful > this section is to a reader. Also, there seem to have been > some simplifications of the protocol done for the analysis. > How realistic is the result as a consequence? > I agree with you here. It was hard to do a comprehensive analysis at this early stage of the document. So, a minimal analysis was included. Hannes, would you like to add something here? Thanks, Vidya _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jul 19 18:15:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv0NO-0000Na-Ol; Tue, 19 Jul 2005 18:15:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv0NM-0000Mn-KI for mobopts@megatron.ietf.org; Tue, 19 Jul 2005 18:15:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02635 for ; Tue, 19 Jul 2005 18:15:41 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv0r2-0000J2-PA for mobopts@irtf.org; Tue, 19 Jul 2005 18:46:26 -0400 Message-ID: <005101c58caf$5efc36c0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Narayanan Vidya-CVN065" , , References: <1B631E11D496D711BB2800065BFCB6A11B7A71D7@il02exm13> Date: Tue, 19 Jul 2005 15:15:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 2c6813ed945e40b4b5bea39da243c669 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , Julien Bournelle , Venkitaraman Narayanan-CNV002 , "'Tschofenig, Hannes'" Subject: [Mobopts] Re: Review of draft-vidya-mipshop-handover-keys-aaa-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Vidya, > Regarding the architecture, you guessed right about the motivation for decoupling this protocol from network access authentication. It was to allow this protocol to work over heterogeneous L2 protocols. The HMK derivation itself, as you say, can be tied to network access and derived using extensions to EAP (which was the point of Appendix A). However, tying the derivation of the HK itself every time the MN roams to a new AR to network access seems a little restrictive to me. The thought is that the protocol should be usable when the MN hands off among any of these technologies - 802.11, 802.16, GPRS, and even say proprietary L2 protocols. > > Now, you mentioned tying this to PANA. The point I struggle with is this - do we believe that there is reason for PANA support to be ubiquitous? When there is a lower layer protocol that carries EAP, why would there be a need to support PANA in the network? I see PANA being used when the lower layer protocol is unable to carry EAP. Is this not true? Tying handover key derivation to PANA implies every AR that supports FMIP is required to support PANA - is this necessarily true? > We've just been going through a similar discussion on the MIP6 list about SEND and HA list security. I think the meta-problem you're having is the following: "If I make my protocol dependent on X, Y, and Z, then people who don't deploy X, Y, and Z won't use my protocol and so it won't get as widely deployed as if I did not make it dependent on X, Y, and Z." I believe this is a misconception. I believe that it is more important to have a well designed wireless Internet protocol architecture, with functionality cleanly partitioned between various protocols. Because if the protocol architecture is clean and well designed, then people will have a stronger incentive to deploy it than if the architecture is messy with lots of duplicated functionality. If your protocol is excessively complex because is incorporates a lot of stuff that other protocols do more elegantly, nobody is going to deploy it even if they don't deploy X, Y, and Z, and they certainly won't deploy it if they do deploy X, Y, and Z because they already have the bits and pieces that your protocol incorporates. They will write their own extensions that do what's needed without incorporating the duplicated bits. So I think it is more in the interests of getting your protocol deployed to actually make it depend on well designed base protocols like EAP, to keep the wireless Internet architecture protocol suite well designed. Regarding EAP specifically, EAP runs over multiple link layers. It now is available on 802.11, 802.16 and GPRS. I don't know about proprietary L2 but I'd say that if the L2 is proprietary, then interoperability probably isn't important since there is only one company involved, so an IETF standard isn't needed (and if the vendor owning the protocol really is interested in interoperability, they will use EAP because that is the IETF standard). I think it is safe to say that, going forward, EAP will be available on future L2 protocols except for maybe 802.15-style protocols that are more of an ad hoc nature. Regarding PANA, again, I don't know that it will be ubiquitous, but I don't think it matters. Even if PANA is not used for network access authentication, there's no reason why people can't deploy a subset for handover key derivation. Does this make sense? > The actual protocol for deriving the HK itself (once the HMK is available) is very simple and is a single roundtrip protocol. ARs that support FMIP will need to support this protocol. By tying this to PANA, are we not creating dependency on a protocol that is not really required to support secure FMIP? Please correct me if I'm wrong, but to me, that seems to complicate the protocol. Also, the thought was this protocol could be used for any MN-AR communication that must be secured (such as CxTP, for instance and also IPv4 fast handoffs), although the draft currently is only detailed with FMIP in mind. > Well, some protocol is required to do this, right? So whether FMIP depends on some new protocol or PANA really doesn't matter. Since PANA is well along in the standardization process, why not use it? > Prior to writing the draft, we (the authors) had discussions on the protocol's dependency on network access authentication and for simplicity, decided to decouple the actual HK derivation from it. I do, however, agree that the HMK derivation based on EAP should be integrated into the main document - it was left as an Appendix mainly to allow someone to use pre-shared HMKs if need be - but, it would make sense for that to be part of the main spec. > > Thoughts on this? > As I mentioned, the attraction of this protocol is that it can leverage off the AAA infrastructure for network access authentication. So by not doing that, I think you are undercutting your strongest argument. I also don't see this particular key derivation as being contrary to EAP's stated goal of only supporting network access authentication (this is an argument that people have made against, for example, using EAP to configure MIP6 HA addresses). > > > > For example, since the protocol description in Section 3 does > > not mention an encryption security association between the > > AAA server and the MN, the nonce sent by the AAA server to > > the MN seems to be sent in the clear, which gives an > > eavesdropper one piece of information that it could use in > > some fashion to compromise. If you read further (in > > particular into the Appendix) you see that, in fact, EAP can > > be used for this transaction, and so one of the EAP methods > > that support secure MN-AAA server communication could be used > > to maintain confidentiality on this transaction (though the > > document provides no details on what the EAP extension is). > > But if EAP isn't used, then what? > > > > I am trying to understand the need for the nonce to be encrypted - there is nothing that an eavesdropper can do with the nonce without knowing the HMK - and the HMK is never sent out. Also, the HK, when sent to the AR is encrypted - so, what does encrypting the nonce really achieve? The nonces are usually sent in the clear in other protocols as well (for e.g. Mobile IP when used with MIP-AAA to generate dynamic keys, etc.) - so, that seemed okay. Are we missing something? > See below on the hashing. > > > My (somewhat radical) suggestion to the authors would be to > > redesign the protocol to couple it tightly with EAP-based > > network access authentication protocol. This would mean: > > > > - Incorporating the derivation of the HMK from > > the EAP key hiearchy which is now in Appendix A into the > > protocol directly > > > Agreed. This makes sense - we can revise the draft to include this. > > OK. > > > - Using EAP within the network access > > authentication transaction to exchange parameters to derive > > the HMK, by defining an EAP extension for one of the > > extensible EAP methods. This will ensure that the transaction > > between the MN and AAA server is properly confidential, > > protecting MN anonymity and the parameters of the key derivation > > > Protecting MN anonymity makes sense and as we detail the contents of Appendix A and integrate it with the main document, this should be ironed out. I am still, however, wondering about the need to encrypt the nonce. > OK. > > > - Instead of defining a separate protocol for > > preauthentication and reauthentication upon handover (Section > > 4), couple the derivation of new HKs via preauthentication or > > reauthentication on handover to PANA pre- and > > reauthentication. This will allow the protocol to leverage > > off of the PANA work, so that the deep thinking about how to > > get pre- and reauthentication on handover right only needs to > > be done once, for PANA (where it needs to be done anyway). > > > > As I mentioned earlier, this is the part that I am not sure about - PANA defines pre- and reauth for the link layer and I see this being used when the lower layer doesn't already do EAP - does it really make sense to extend it to be used for L3 handovers as well? > I think PANA uses EAP too, right? It is basically a container for carrying EAP, like EAPoL or IKEv2 is. > > > Incidently, if one of the reasons why this protocol was > > decoupled from network access authentication was to allow > > IEEE 802.1x or other Layer 2 protocols to be used, then this > > needs some rethinking. EAP is used in 802.1x anyway so it > > could still be used for the initial HMK derivation. And the > > 802.1x reauthentication isn't going to be useful for handover > > key reauthentication, because it only deals with APs, which > > are layer 2 devices, whereas this protocol must deal with > > ARs, which are layer 3 devices, so PANA is probably the right vehicle. > > > > Detailed Editorial and Technical Comments: > > > > Section 3, paragraph 2: This paragraph seems to be specifying > > use of the HMK for calculating a MAC. It might be a good idea > > to keep the HMK private, and use a derived key for this > > purpose, to avoid exposing material calculated with the HMK > > to attackers. > > > > > Yes, this makes sense. We will correct this in v01. > > OK. > > Section 3, paragraph 2: As mentioned above, the nounce looks > > to be sent in the clear. Might be better from a > > confidentiality standpoint to encrypt. Similarly for the NAI. > > > > > Same question as before for the nonce. For the NAI, would it not be sufficient to provide a means of deriving an identity (or even multiple identities) to use as part of HMK derivation, so that MN privacy is protected? Encryption of these parameters should be simple enough - so, if you think that it will be better to do so, that can certainly be done. > Protecting the NAI is primarily a privacy/anonymity problem. > > > Section 3, paragraph 4 and 6: What is PRF here? > > > That was a miss on our part - should have stated HMAC-SHA1 as the pseudo-random function to be used. Will add this. > OK. > > > > Section 3.1, paragraph 2: Note that if the nounce is > > encrypted, it need only be exchanged once, during the initial > > HMK derivation. After that, fresh nounces can be derived by > > forward hashing from the original. Alternatively, the AAA > > server and MN can generate a hash chain and move backward (at > > the expense of having to store the hashes). This eliminates > > the need to send a hash out over the air each time a > > reauthentication is performed. The AAA server can push the > > appropriate nounce to the AR. > > > Interesting thought on forward hashing. Regarding pushing the nonce to the AR - the AR does not have the HMK and hence, cannot derive the HK; so, the AAA server really needs to give the AR the HK - am I misunderstanding you here? > Sorry, I meant the AAA server. > > > > Section 3.1: It is unclear to me how the MN manages keys > > generated by preauthentication. Essentially, the MN is > > setting up soft state in the network that it must manage. > > Yet, the specification only briefly mentions key lifetimes, > > and does not specify any suggested defaults, nor how the AR > > knows what the lifetime of the key should be. > > > > > The AAA server does send a recommended lifetime to the AR (and the AR forwards that to the MN). However, the AAA server does not maintain any state about the lifetime itself and hence, it is up to the MN and AR to enforce the lifetime. Perhaps, the text can add more clarity on this. > Yes. But why should the MN trust the AR on the lifetime? There is no authenticated relationship between the AR and MN. > > > Section 4.1, v Flag - Is the MN sharing a key with itself here? > > > Oops. Good catch - it is an error. The "MN" at the end of that sentence should be "AR". > OK. > > > > Section 4.1, Seq. number - What if the message is > > retransmitted on a new AR? Should the MN use the same Seq. > > number or new? > > > > For a given message ID, the sequence number is never repeated. Retransmissions are identified by the use of the same message ID (sequence number must be incremented though). A HKReq message is always sent to the AR with which the MN desires to share a HK. It may be sent via an old AR while the MN is attached to that oAR (note that the IP destination of that packet will still be the target AR with which it expects to share the HK). So, if the MN attaches to a new AR and does a retransmission, it should still use the same message ID - for a HKReq sent to ARn, a retransmission to the same ARn should always use the same message ID. Did I answer your question here? > Yes but I think you need to make it clearer in the draft how retransmissions work. > > > Section 5.1: This section seemed to be saying that the MN > > needs a key on the new AR when it hands over before it can do > > the FMIP signaling, is that correct? If so, I'd like to know > > why? The primary security issue in FMIP is not security with > > the new AR, but security with the old AR. The old AR is being > > asked by the FBU to change routing for the old CoA (i.e. set > > up a tunnel from the old CoA to the new), and for that > > purpose, it must have some indication that the entity sending > > the FBU is authorized to claim the CoA. The new AR gets the > > FNA which is typically piggybacked on the FBU, but that needs > > to be secured using IP address configuration security, and it > > can even be eliminated entirely if the MN used oDAD since its > > only purpose is to allow the AR to confirm whether the > > address is not a duplicate. For example, if the new CoA is > > autoconfigured, then RFC 3971 and 3972 can be used to secure > > the address. If the address in DHCP configured, other > > mechanisms are to be used. Or are the authors intending here > > to define a new way of performing IP address configuration security? > > > > With this comment in mind, I fail to see the urgency of > > having to perform the key exchange with surrounding routers > > immediately coupled to the handover signaling. The issue > > becomes ensuring the MN has a key on the router it currently > > is, so that when it hands over it can properly change > > routing. For that purpose, the MN may want to perform > > preauthentication in order to avoid having to establish the > > key once it moves to the new router, but there is no need to > > couple preauthentication tightly to the handover. > > > > > No, it is not mandated to derive a key with a new AR before the MN hands over. We used a "SHOULD" there, since deriving a key prior to handoff will be good practice for an MN that moves quickly between ARs on different subnets. The HK is only used with the FBU (so, you are right - it is needed only with the oAR, so the MN could potentially derive the key after it handsoff). This also becomes useful when this protocol is used to support MN-AR security for other protocols that may need the key to be present sooner for any communication (not within the scope of description in v00). > Again, I think the draft could be clearer on this. It needs to emphasize that preauthentication is primarily an optimization. > > > Section 5.1, paragraph 5: The last sentence is somewhat > > gratuitous and can be dropped. > > > > Ok. > > > Section 5.2, paragraph 1: Pick whether to include the Alt CoA > > or not. Why have two choices here? > > > > Most of the time, the source address of the packet should be sufficient in determining the CoA of the MN. However, the Alt CoA was included as a means for the MN to convey its CoA, if the source IP address is subject to change enroute - in IPv4, I can think of NATs causing this problem - but then, Alt CoA won't solve that anyway. So, maybe this is not required? > I can't see any place in MIP6 that it would be required. > The CoA itself is required to be bound to the HK mainly so that when the AR receives the FBU, it is able to locate the correct key to use for that MN. Having a provision for an SPI in the FBU will make this very clean and remove the need for this. In fact, the protocol itself can be simplified further if the FBU had a means of carrying an SPI. This is something we would like to discuss with you and Rajeev at Paris. I will send out a separate email on this topic, so that this email doesn't get out of control. > OK. > > > Section 5.2, paragraph 2: If the MN retransmits on the new > > router, does it use the same seq number? If so, how does the > > router/AAA server distinguish whether this is a replay attack or not? > > > > A HKReq that was transmitted earlier to the AR (via an oAR) would have had the same message ID, if the MN is trying to retransmit a message. If an AR receives a HKReq with the same message ID and same sequence number, the packet is dropped. The sequence number must always start at 1 for a new message ID and then be incremented for every retransmission. A new HKReq (that is not a retransmission) must have a new message ID. If the text in the document is not clear on this, we can try to clarify it better. > Yes, as above, it needs to be clarified. I did not get this from reading the draft. > > > Section 5.3: It seems here that the AAA-Local must perform > > the key decapsulation and distribution to ARs in a roaming > > scenario, because it is not realistic to expect the AAA-Home > > to have security associations with all the ARs in a roaming > > partner's access network. Perhaps this could be made more clear. > > > > Yes, in a roaming case, this will be true. We can add some text to make that clear. > > OK. > > Section 6.2, Replay Protection, last sentence: Shouldn't this > > be the HMK? > > No, it is really the HK. The sequence number must be unique for every retransmission (i.e., when the message ID is the same). Unless the MN is involved in a lot of retransmissions, a new HKReq must typically result in a new HK. Even when the MN is trying to verify the HKReq, it must be using a different message ID. Does that make sense? > OK, I understand now. Again, I think the draft needs to be clearer about how the sequence number is used in retransmission. > > > > Section 6.2, Denial of Service, second paragraph: I am not a > > big fan of puzzles, because their effectiveness depends on > > the attacker co-operating and actually trying to solve the > > puzzle. A dedicated attacker will simply pump packets out at > > the victim, and ignore a puzzle response. This is especially > > an issue with DDoS, where the attacking nodes are only > > loosely co-ordinated and the effectivenes depends on volume. > > > > > You are right. DoS attacks are really impossible to eliminate completely - the question is whether this approach may mitigate it. > > Puzzles are fashionable, so I can understand why you might want to keep them in. But, again, I don't see that they will really provide any help against a dedidated attacker (and, in fact, against the most common type of DoS attack on the Internet today). > > Section 6.2, Fragmentation: This statement is highly > > dependent on the radio layer frame size. For a small enough > > frame size, fragementation could still be an issue. > > It does not seem like this protocol may need to solve this, right? Perhaps, this section can be removed? > Yes. > > > > Appendix D: Some of these suggestions involve having the ARs > > perform key distribution. Since the ARs are not authenticated > > directly to the MN, this may compromise security. > > > > Yes, this is true. This is among the reasons why we didn't consider any of these approaches for the protocol. We may have missed stating that. We included this appendix to essentially explain why some of the other seemingly simple approaches were not so desirable. > OK. I think this could be dropped from the draft, since it does not contribute to explaining the protocol. jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 20 05:50:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvBDy-0000z8-J3; Wed, 20 Jul 2005 05:50:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvBDw-0000z0-Os for mobopts@megatron.ietf.org; Wed, 20 Jul 2005 05:50:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27197 for ; Wed, 20 Jul 2005 05:50:42 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvBhh-0004Wf-V5 for mobopts@irtf.org; Wed, 20 Jul 2005 06:21:33 -0400 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id A6C394C9FC for ; Wed, 20 Jul 2005 18:48:53 +0900 (JST) Date: Wed, 20 Jul 2005 18:50:14 +0900 From: Thierry Ernst To: mobopts@irtf.org Subject: Re: [Mobopts] New topics for the RG Message-Id: <20050720185014.083a41f0.ernst@sfc.wide.ad.jp> In-Reply-To: <07B14A720C46C344AC96AAA64F5D6A31014911DB@FITMS201MB.tcad.telia.se> References: <07B14A720C46C344AC96AAA64F5D6A31014911DB@FITMS201MB.tcad.telia.se> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi Jouni, You may have interest into following the Monami6 BOF at next IETF (http://www.nautilus6.org/ietf) as we may run across something close to your below interests. Thierry On Mon, 18 Jul 2005 14:43:29 +0300 jouni.korhonen@teliasonera.com wrote: > Hi, > > Checking the new topics for the RG few of them look particularly > interesting. I have a couple of comments and questions regarding them. > > [snip snap] > > > - mobility (and traffic) patterns in a WLAN (e.g., a campus > > network). > This should provide > > a better sense of traffic for admission control as well as > network-controlled handovers. > > [snip snap] > > > - architectural barriers to optimizing inter-domain handovers. > Although we have > > some understanding of improving delay and packet loss during > handovers across > > IP networks, how applicable are they across different autonomous > systems? Would > > the policy barriers allow optimizations? Is this an example of > "tussle in cyberspace"? > > [snip snap] > > As I work for an operator and am involved in other SDOs these two > topics look very interesting > (network controlled handovers and inter-domain handovers). I'm just > wondering if those could > also be studied from a "steering of roaming" point of view, where the > handover decision could > be based on or at least weighted by home operator policies and > predefined prioritization of > roaming partners? At least not particularly disabling such use case of > the possible solution. > > Very roughly put I would assume that this kind of approach of > "guiding" handover decision requires > a mechanism to inform the mobility management point about networks & > network identities available > to MN even if the networks belong to different administrative domains. > A mechanism to signal back > the home network preferences of the networks before the handover takes > place (or immediately after > the handover) in the MN is needed. Also a possibility to suggest a > handover from network side > between binding updates would be a definitive plus. > > Would this group be interested in this topic from the angle I > described it? > > Cheers, > Jouni > > -- _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 20 10:01:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvF8w-0003Be-O1; Wed, 20 Jul 2005 10:01:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvF8t-0003Ai-O3 for mobopts@megatron.ietf.org; Wed, 20 Jul 2005 10:01:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17222 for ; Wed, 20 Jul 2005 10:01:45 -0400 (EDT) Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvFch-0004Ft-3d for mobopts@irtf.org; Wed, 20 Jul 2005 10:32:38 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id AA67184DE; Wed, 20 Jul 2005 16:00:03 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.50) id 1DvF5G-0005g9-Dp; Wed, 20 Jul 2005 15:58:02 +0200 Date: Wed, 20 Jul 2005 15:58:02 +0200 From: Julien Bournelle To: James Kempf Message-ID: <20050720135802.GE21022@ipv6-3.int-evry.fr> References: <1B631E11D496D711BB2800065BFCB6A11B7A71D7@il02exm13> <005101c58caf$5efc36c0$016115ac@dcml.docomolabsusa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005101c58caf$5efc36c0$016115ac@dcml.docomolabsusa.com> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 2.4 (++) X-Scan-Signature: bb7a33d18683bf5063a44e640cf125f1 Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, "'Tschofenig, Hannes'" , Venkitaraman Narayanan-CNV002 , mobopts@irtf.org Subject: [Mobopts] Re: Review of draft-vidya-mipshop-handover-keys-aaa-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi james, On Tue, Jul 19, 2005 at 03:15:29PM -0700, James Kempf wrote: > Vidya, > > > Regarding the architecture, you guessed right about the motivation for > decoupling this protocol from network access authentication. It was to allow > this protocol to work over heterogeneous L2 protocols. The HMK derivation > itself, as you say, can be tied to network access and derived using > extensions to EAP (which was the point of Appendix A). However, tying the > derivation of the HK itself every time the MN roams to a new AR to network > access seems a little restrictive to me. The thought is that the protocol > should be usable when the MN hands off among any of these technologies - > 802.11, 802.16, GPRS, and even say proprietary L2 protocols. > > > > Now, you mentioned tying this to PANA. The point I struggle with is this - > do we believe that there is reason for PANA support to be ubiquitous? When > there is a lower layer protocol that carries EAP, why would there be a need > to support PANA in the network? I see PANA being used when the lower layer > protocol is unable to carry EAP. Is this not true? Tying handover key > derivation to PANA implies every AR that supports FMIP is required to > support PANA - is this necessarily true? > > > > We've just been going through a similar discussion on the MIP6 list about > SEND and HA list security. > > I think the meta-problem you're having is the following: > > "If I make my protocol dependent on X, Y, and Z, then people who don't > deploy X, Y, and Z won't use my protocol and so it won't get as widely > deployed as if I did not make it dependent on X, Y, and Z." > > I believe this is a misconception. I believe that it is more important to > have a well designed wireless Internet protocol architecture, with > functionality cleanly partitioned between various protocols. Because if the > protocol architecture is clean and well designed, then people will have a > stronger incentive to deploy it than if the architecture is messy with lots > of duplicated functionality. If your protocol is excessively complex because > is incorporates a lot of stuff that other protocols do more elegantly, > nobody is going to deploy it even if they don't deploy X, Y, and Z, and they > certainly won't deploy it if they do deploy X, Y, and Z because they already > have the bits and pieces that your protocol incorporates. They will write > their own extensions that do what's needed without incorporating the > duplicated bits. > > So I think it is more in the interests of getting your protocol deployed to > actually make it depend on well designed base protocols like EAP, to keep > the wireless Internet architecture protocol suite well designed. > > Regarding EAP specifically, EAP runs over multiple link layers. It now is > available on 802.11, 802.16 and GPRS. I don't know about proprietary L2 but > I'd say that if the L2 is proprietary, then interoperability probably isn't > important since there is only one company involved, so an IETF standard > isn't needed (and if the vendor owning the protocol really is interested in > interoperability, they will use EAP because that is the IETF standard). I > think it is safe to say that, going forward, EAP will be available on future > L2 protocols except for maybe 802.15-style protocols that are more of an ad > hoc nature. We could certainly define a way to provide a key both for MN and AR during the network authentication phase. EAP provides a way to create key for application (AMSK) (Appendix A of our draft). Thus we need to define a key specific for FMIPv6 and a way for the EAP authenticator to push the keying material to appropriate AR (not defined in the current draft). The problem that I can see is after IP handover, how do the MN get a new key ? If we continue to rely on EAP, it will imply a reauthentication from scratch. Any comments ? Julien > > Regarding PANA, again, I don't know that it will be ubiquitous, but I don't > think it matters. Even if PANA is not used for network access > authentication, there's no reason why people can't deploy a subset for > handover key derivation. > > Does this make sense? > > > The actual protocol for deriving the HK itself (once the HMK is available) > is very simple and is a single roundtrip protocol. ARs that support FMIP > will need to support this protocol. By tying this to PANA, are we not > creating dependency on a protocol that is not really required to support > secure FMIP? Please correct me if I'm wrong, but to me, that seems to > complicate the protocol. Also, the thought was this protocol could be used > for any MN-AR communication that must be secured (such as CxTP, for instance > and also IPv4 fast handoffs), although the draft currently is only detailed > with FMIP in mind. > > > > Well, some protocol is required to do this, right? So whether FMIP depends > on some new protocol or PANA really doesn't matter. Since PANA is well along > in the standardization process, why not use it? > > > Prior to writing the draft, we (the authors) had discussions on the > protocol's dependency on network access authentication and for simplicity, > decided to decouple the actual HK derivation from it. I do, however, agree > that the HMK derivation based on EAP should be integrated into the main > document - it was left as an Appendix mainly to allow someone to use > pre-shared HMKs if need be - but, it would make sense for that to be part of > the main spec. > > > > Thoughts on this? > > > > As I mentioned, the attraction of this protocol is that it can leverage off > the AAA infrastructure for network access authentication. So by not doing > that, I think you are undercutting your strongest argument. I also don't see > this particular key derivation as being contrary to EAP's stated goal of > only supporting network access authentication (this is an argument that > people have made against, for example, using EAP to configure MIP6 HA > addresses). > > > > > > > For example, since the protocol description in Section 3 does > > > not mention an encryption security association between the > > > AAA server and the MN, the nonce sent by the AAA server to > > > the MN seems to be sent in the clear, which gives an > > > eavesdropper one piece of information that it could use in > > > some fashion to compromise. If you read further (in > > > particular into the Appendix) you see that, in fact, EAP can > > > be used for this transaction, and so one of the EAP methods > > > that support secure MN-AAA server communication could be used > > > to maintain confidentiality on this transaction (though the > > > document provides no details on what the EAP extension is). > > > But if EAP isn't used, then what? > > > > > > > I am trying to understand the need for the nonce to be encrypted - there > is nothing that an eavesdropper can do with the nonce without knowing the > HMK - and the HMK is never sent out. Also, the HK, when sent to the AR is > encrypted - so, what does encrypting the nonce really achieve? The nonces > are usually sent in the clear in other protocols as well (for e.g. Mobile IP > when used with MIP-AAA to generate dynamic keys, etc.) - so, that seemed > okay. Are we missing something? > > > > See below on the hashing. > > > > > > My (somewhat radical) suggestion to the authors would be to > > > redesign the protocol to couple it tightly with EAP-based > > > network access authentication protocol. This would mean: > > > > > > - Incorporating the derivation of the HMK from > > > the EAP key hiearchy which is now in Appendix A into the > > > protocol directly > > > > > > Agreed. This makes sense - we can revise the draft to include this. > > > > > > OK. > > > > > > - Using EAP within the network access > > > authentication transaction to exchange parameters to derive > > > the HMK, by defining an EAP extension for one of the > > > extensible EAP methods. This will ensure that the transaction > > > between the MN and AAA server is properly confidential, > > > protecting MN anonymity and the parameters of the key derivation > > > > > > Protecting MN anonymity makes sense and as we detail the contents of > Appendix A and integrate it with the main document, this should be ironed > out. I am still, however, wondering about the need to encrypt the nonce. > > > > OK. > > > > > > - Instead of defining a separate protocol for > > > preauthentication and reauthentication upon handover (Section > > > 4), couple the derivation of new HKs via preauthentication or > > > reauthentication on handover to PANA pre- and > > > reauthentication. This will allow the protocol to leverage > > > off of the PANA work, so that the deep thinking about how to > > > get pre- and reauthentication on handover right only needs to > > > be done once, for PANA (where it needs to be done anyway). > > > > > > > As I mentioned earlier, this is the part that I am not sure about - PANA > defines pre- and reauth for the link layer and I see this being used when > the lower layer doesn't already do EAP - does it really make sense to extend > it to be used for L3 handovers as well? > > > > I think PANA uses EAP too, right? It is basically a container for carrying > EAP, like EAPoL or IKEv2 is. > > > > > > Incidently, if one of the reasons why this protocol was > > > decoupled from network access authentication was to allow > > > IEEE 802.1x or other Layer 2 protocols to be used, then this > > > needs some rethinking. EAP is used in 802.1x anyway so it > > > could still be used for the initial HMK derivation. And the > > > 802.1x reauthentication isn't going to be useful for handover > > > key reauthentication, because it only deals with APs, which > > > are layer 2 devices, whereas this protocol must deal with > > > ARs, which are layer 3 devices, so PANA is probably the right vehicle. > > > > > > Detailed Editorial and Technical Comments: > > > > > > Section 3, paragraph 2: This paragraph seems to be specifying > > > use of the HMK for calculating a MAC. It might be a good idea > > > to keep the HMK private, and use a derived key for this > > > purpose, to avoid exposing material calculated with the HMK > > > to attackers. > > > > > > > > > Yes, this makes sense. We will correct this in v01. > > > > > > OK. > > > > Section 3, paragraph 2: As mentioned above, the nounce looks > > > to be sent in the clear. Might be better from a > > > confidentiality standpoint to encrypt. Similarly for the NAI. > > > > > > > > > Same question as before for the nonce. For the NAI, would it not be > sufficient to provide a means of deriving an identity (or even multiple > identities) to use as part of HMK derivation, so that MN privacy is > protected? Encryption of these parameters should be simple enough - so, if > you think that it will be better to do so, that can certainly be done. > > > > Protecting the NAI is primarily a privacy/anonymity problem. > > > > > > Section 3, paragraph 4 and 6: What is PRF here? > > > > > > That was a miss on our part - should have stated HMAC-SHA1 as the > pseudo-random function to be used. Will add this. > > > > OK. > > > > > > > Section 3.1, paragraph 2: Note that if the nounce is > > > encrypted, it need only be exchanged once, during the initial > > > HMK derivation. After that, fresh nounces can be derived by > > > forward hashing from the original. Alternatively, the AAA > > > server and MN can generate a hash chain and move backward (at > > > the expense of having to store the hashes). This eliminates > > > the need to send a hash out over the air each time a > > > reauthentication is performed. The AAA server can push the > > > appropriate nounce to the AR. > > > > > > Interesting thought on forward hashing. Regarding pushing the nonce to the > AR - the AR does not have the HMK and hence, cannot derive the HK; so, the > AAA server really needs to give the AR the HK - am I misunderstanding you > here? > > > > Sorry, I meant the AAA server. > > > > > > > Section 3.1: It is unclear to me how the MN manages keys > > > generated by preauthentication. Essentially, the MN is > > > setting up soft state in the network that it must manage. > > > Yet, the specification only briefly mentions key lifetimes, > > > and does not specify any suggested defaults, nor how the AR > > > knows what the lifetime of the key should be. > > > > > > > > > The AAA server does send a recommended lifetime to the AR (and the AR > forwards that to the MN). However, the AAA server does not maintain any > state about the lifetime itself and hence, it is up to the MN and AR to > enforce the lifetime. Perhaps, the text can add more clarity on this. > > > > Yes. But why should the MN trust the AR on the lifetime? There is no > authenticated relationship between the AR and MN. > > > > > > Section 4.1, v Flag - Is the MN sharing a key with itself here? > > > > > > Oops. Good catch - it is an error. The "MN" at the end of that sentence > should be "AR". > > > > OK. > > > > > > > Section 4.1, Seq. number - What if the message is > > > retransmitted on a new AR? Should the MN use the same Seq. > > > number or new? > > > > > > > For a given message ID, the sequence number is never repeated. > Retransmissions are identified by the use of the same message ID (sequence > number must be incremented though). A HKReq message is always sent to the AR > with which the MN desires to share a HK. It may be sent via an old AR while > the MN is attached to that oAR (note that the IP destination of that packet > will still be the target AR with which it expects to share the HK). So, if > the MN attaches to a new AR and does a retransmission, it should still use > the same message ID - for a HKReq sent to ARn, a retransmission to the same > ARn should always use the same message ID. Did I answer your question here? > > > > Yes but I think you need to make it clearer in the draft how retransmissions > work. > > > > > > Section 5.1: This section seemed to be saying that the MN > > > needs a key on the new AR when it hands over before it can do > > > the FMIP signaling, is that correct? If so, I'd like to know > > > why? The primary security issue in FMIP is not security with > > > the new AR, but security with the old AR. The old AR is being > > > asked by the FBU to change routing for the old CoA (i.e. set > > > up a tunnel from the old CoA to the new), and for that > > > purpose, it must have some indication that the entity sending > > > the FBU is authorized to claim the CoA. The new AR gets the > > > FNA which is typically piggybacked on the FBU, but that needs > > > to be secured using IP address configuration security, and it > > > can even be eliminated entirely if the MN used oDAD since its > > > only purpose is to allow the AR to confirm whether the > > > address is not a duplicate. For example, if the new CoA is > > > autoconfigured, then RFC 3971 and 3972 can be used to secure > > > the address. If the address in DHCP configured, other > > > mechanisms are to be used. Or are the authors intending here > > > to define a new way of performing IP address configuration security? > > > > > > With this comment in mind, I fail to see the urgency of > > > having to perform the key exchange with surrounding routers > > > immediately coupled to the handover signaling. The issue > > > becomes ensuring the MN has a key on the router it currently > > > is, so that when it hands over it can properly change > > > routing. For that purpose, the MN may want to perform > > > preauthentication in order to avoid having to establish the > > > key once it moves to the new router, but there is no need to > > > couple preauthentication tightly to the handover. > > > > > > > > > No, it is not mandated to derive a key with a new AR before the MN hands > over. We used a "SHOULD" there, since deriving a key prior to handoff will > be good practice for an MN that moves quickly between ARs on different > subnets. The HK is only used with the FBU (so, you are right - it is needed > only with the oAR, so the MN could potentially derive the key after it > handsoff). This also becomes useful when this protocol is used to support > MN-AR security for other protocols that may need the key to be present > sooner for any communication (not within the scope of description in v00). > > > > Again, I think the draft could be clearer on this. It needs to emphasize > that preauthentication is primarily an optimization. > > > > > > Section 5.1, paragraph 5: The last sentence is somewhat > > > gratuitous and can be dropped. > > > > > > > Ok. > > > > > Section 5.2, paragraph 1: Pick whether to include the Alt CoA > > > or not. Why have two choices here? > > > > > > > Most of the time, the source address of the packet should be sufficient in > determining the CoA of the MN. However, the Alt CoA was included as a means > for the MN to convey its CoA, if the source IP address is subject to change > enroute - in IPv4, I can think of NATs causing this problem - but then, Alt > CoA won't solve that anyway. So, maybe this is not required? > > > > I can't see any place in MIP6 that it would be required. > > > The CoA itself is required to be bound to the HK mainly so that when the > AR receives the FBU, it is able to locate the correct key to use for that > MN. Having a provision for an SPI in the FBU will make this very clean and > remove the need for this. In fact, the protocol itself can be simplified > further if the FBU had a means of carrying an SPI. This is something we > would like to discuss with you and Rajeev at Paris. I will send out a > separate email on this topic, so that this email doesn't get out of control. > > > > OK. > > > > > > Section 5.2, paragraph 2: If the MN retransmits on the new > > > router, does it use the same seq number? If so, how does the > > > router/AAA server distinguish whether this is a replay attack or not? > > > > > > > A HKReq that was transmitted earlier to the AR (via an oAR) would have had > the same message ID, if the MN is trying to retransmit a message. If an AR > receives a HKReq with the same message ID and same sequence number, the > packet is dropped. The sequence number must always start at 1 for a new > message ID and then be incremented for every retransmission. A new HKReq > (that is not a retransmission) must have a new message ID. If the text in > the document is not clear on this, we can try to clarify it better. > > > > Yes, as above, it needs to be clarified. I did not get this from reading the > draft. > > > > > > Section 5.3: It seems here that the AAA-Local must perform > > > the key decapsulation and distribution to ARs in a roaming > > > scenario, because it is not realistic to expect the AAA-Home > > > to have security associations with all the ARs in a roaming > > > partner's access network. Perhaps this could be made more clear. > > > > > > > Yes, in a roaming case, this will be true. We can add some text to make > that clear. > > > > > > OK. > > > > Section 6.2, Replay Protection, last sentence: Shouldn't this > > > be the HMK? > > > > No, it is really the HK. The sequence number must be unique for every > retransmission (i.e., when the message ID is the same). Unless the MN is > involved in a lot of retransmissions, a new HKReq must typically result in a > new HK. Even when the MN is trying to verify the HKReq, it must be using a > different message ID. Does that make sense? > > > > OK, I understand now. Again, I think the draft needs to be clearer about how > the sequence number is used in retransmission. > > > > > > > Section 6.2, Denial of Service, second paragraph: I am not a > > > big fan of puzzles, because their effectiveness depends on > > > the attacker co-operating and actually trying to solve the > > > puzzle. A dedicated attacker will simply pump packets out at > > > the victim, and ignore a puzzle response. This is especially > > > an issue with DDoS, where the attacking nodes are only > > > loosely co-ordinated and the effectivenes depends on volume. > > > > > > > > > You are right. DoS attacks are really impossible to eliminate completely - > the question is whether this approach may mitigate it. > > > > > > Puzzles are fashionable, so I can understand why you might want to keep them > in. But, again, I don't see that they will really provide any help against a > dedidated attacker (and, in fact, against the most common type of DoS attack > on the Internet today). > > > > > Section 6.2, Fragmentation: This statement is highly > > > dependent on the radio layer frame size. For a small enough > > > frame size, fragementation could still be an issue. > > > > It does not seem like this protocol may need to solve this, right? > Perhaps, this section can be removed? > > > > Yes. > > > > > > > Appendix D: Some of these suggestions involve having the ARs > > > perform key distribution. Since the ARs are not authenticated > > > directly to the MN, this may compromise security. > > > > > > > Yes, this is true. This is among the reasons why we didn't consider any of > these approaches for the protocol. We may have missed stating that. We > included this appendix to essentially explain why some of the other > seemingly simple approaches were not so desirable. > > > > OK. I think this could be dropped from the draft, since it does not > contribute to explaining the protocol. > > jak > > > -- julien.bournelle at int-evry.fr _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 20 12:31:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvHTJ-0007LQ-5D; Wed, 20 Jul 2005 12:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvHTG-0007Kl-Vv for mobopts@megatron.ietf.org; Wed, 20 Jul 2005 12:30:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07053 for ; Wed, 20 Jul 2005 12:30:56 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvHx8-0007yf-Eu for mobopts@irtf.org; Wed, 20 Jul 2005 13:01:50 -0400 Message-ID: <014301c58d48$653b6440$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Julien Bournelle" References: <1B631E11D496D711BB2800065BFCB6A11B7A71D7@il02exm13> <005101c58caf$5efc36c0$016115ac@dcml.docomolabsusa.com> <20050720135802.GE21022@ipv6-3.int-evry.fr> Date: Wed, 20 Jul 2005 09:30:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, "'Tschofenig, Hannes'" , Venkitaraman Narayanan-CNV002 , mobopts@irtf.org Subject: [Mobopts] Re: Review of draft-vidya-mipshop-handover-keys-aaa-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org > We could certainly define a way to provide a key both for MN and AR > during the network authentication phase. EAP provides a way to create > key for application (AMSK) (Appendix A of our draft). > Thus we need to define a key specific for > FMIPv6 and a way for the EAP authenticator to push the keying material > to appropriate AR (not defined in the current draft). > > The problem that I can see is after IP handover, how do the MN get a > new key ? If we continue to rely on EAP, it will imply a > reauthentication from scratch. > One of two ways: 1) The MN has actually reauthenticated for network access from scratch in order to establish its session key with the new AR/AP, and in the process obtained a handover key. In 802.1x, that is, in fact, currently the only way I believe, though the 802.11r WG is looking to change this. 2) The MN has performed preauthentication with a collection of AR/APs around the current one, and so has a key already available. jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 20 15:37:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKO0-000854-4u; Wed, 20 Jul 2005 15:37:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKNv-000823-O6 for mobopts@megatron.ietf.org; Wed, 20 Jul 2005 15:37:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24487 for ; Wed, 20 Jul 2005 15:37:37 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvKrn-0003cb-M7 for mobopts@irtf.org; Wed, 20 Jul 2005 16:08:33 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j6KJklsJ014404 for ; Wed, 20 Jul 2005 12:46:47 -0700 (MST) Received: from il02exm13.corp.mot.com (il02exm13.corp.mot.com [10.0.111.24]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id j6KJhYIk010710 for ; Wed, 20 Jul 2005 14:43:35 -0500 (CDT) Received: by il02exm13 with Internet Mail Service (5.5.2657.72) id ; Wed, 20 Jul 2005 14:37:25 -0500 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A71E4@il02exm13> From: Narayanan Vidya-CVN065 To: "'James Kempf'" , Julien Bournelle Date: Wed, 20 Jul 2005 14:37:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 2.4 (++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, "'Tschofenig, Hannes'" , mobopts@irtf.org, Venkitaraman Narayanan-CNV002 Subject: [Mobopts] RE: Review of draft-vidya-mipshop-handover-keys-aaa-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org So, the real question here is - should we do a handover key request/response exchange between the MN and AR embedded in the PANA protocol (and then embedded in some EAP method between the AR and AAA server) or if we should have that as a separate protocol. If I understand correctly, you are proposing that it should be an extension to PANA and an EAP method that allows it - right? So, lets say we choose to do this using PANA. Lets consider this scenario: The MN associates with an AP, does 802.11i and gains network access. The AP itself is not doing PANA, so, this is just link layer access. Now, the MN needs to talk PANA with the AR to get a handover key. Does an entire EAP method exchange have to happen again for this key to be derived? Or, am I missing something big here? When PANA itself is used as the EAP encapsulation for network access, I can see how tying it to PANA will work fine. When network access is via EAP encapsulated in a lower layer protocol (where the entity terminating the lower layer protocol is different from the AR), will this not result in two separate EAP method exchanges? I have not read PANA in detail yet - so, maybe I am missing the picture. I will spend some time reading it in more detail. Meanwhile, please pardon my stupid questions. Regards, Vidya > -----Original Message----- > From: James Kempf [mailto:Kempf@docomolabs-usa.com] > Sent: Wednesday, July 20, 2005 11:31 AM > To: Julien Bournelle > Cc: Narayanan Vidya-CVN065; mipshop@ietf.org; > mobopts@irtf.org; Gerardo Giaretta; Julien Bournelle; > 'Tschofenig, Hannes'; Venkitaraman Narayanan-CNV002 > Subject: Re: Review of draft-vidya-mipshop-handover-keys-aaa-00.txt > > > > We could certainly define a way to provide a key both for > MN and AR > > during the network authentication phase. EAP provides a > way to create > > key for application (AMSK) (Appendix A of our draft). Thus > we need to > > define a key specific for FMIPv6 and a way for the EAP > authenticator > > to push the keying material to appropriate AR (not defined in the > > current draft). > > > > The problem that I can see is after IP handover, how do > the MN get a > > new key ? If we continue to rely on EAP, it will imply a > > reauthentication from scratch. > > > > One of two ways: > > 1) The MN has actually reauthenticated for network access > from scratch in order to establish its session key with the > new AR/AP, and in the process obtained a handover key. In > 802.1x, that is, in fact, currently the only way I believe, > though the 802.11r WG is looking to change this. > > 2) The MN has performed preauthentication with a collection > of AR/APs around the current one, and so has a key already available. > > jak > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 20 15:49:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKZl-0005lo-Fy; Wed, 20 Jul 2005 15:49:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKZj-0005le-P3 for mobopts@megatron.ietf.org; Wed, 20 Jul 2005 15:49:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25087 for ; Wed, 20 Jul 2005 15:49:49 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvL3c-0004IY-1L for mobopts@irtf.org; Wed, 20 Jul 2005 16:20:45 -0400 Message-ID: <023101c58d64$28fbe510$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Narayanan Vidya-CVN065" , "Julien Bournelle" References: <1B631E11D496D711BB2800065BFCB6A11B7A71E4@il02exm13> Date: Wed, 20 Jul 2005 12:49:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, "'Tschofenig, Hannes'" , mobopts@irtf.org, Venkitaraman Narayanan-CNV002 Subject: [Mobopts] Re: Review of draft-vidya-mipshop-handover-keys-aaa-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org > So, the real question here is - should we do a handover key request/response exchange between the MN and AR embedded in the PANA protocol (and then embedded in some EAP method between the AR and AAA server) or if we should have that as a separate protocol. > > If I understand correctly, you are proposing that it should be an extension to PANA and an EAP method that allows it - right? > > So, lets say we choose to do this using PANA. Lets consider this scenario: > > The MN associates with an AP, does 802.11i and gains network access. The AP itself is not doing PANA, so, this is just link layer access. Now, the MN needs to talk PANA with the AR to get a handover key. Does an entire EAP method exchange have to happen again for this key to be derived? Or, am I missing something big here? > Why does the MN have to use PANA when it uses 802.11i for network access? Why can't it just use the EAP method with the handover key extension during 802.1x? jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 20 15:53:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKdT-0007i2-Vc; Wed, 20 Jul 2005 15:53:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKdN-0007e2-7G for mobopts@megatron.ietf.org; Wed, 20 Jul 2005 15:53:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25964 for ; Wed, 20 Jul 2005 15:53:34 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvL7C-0004k5-KI for mobopts@irtf.org; Wed, 20 Jul 2005 16:24:30 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j6KK2rR2017039 for ; Wed, 20 Jul 2005 13:02:53 -0700 (MST) Received: from il02exm13.corp.mot.com (il02exm13.corp.mot.com [10.0.111.24]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id j6KJxejL016448 for ; Wed, 20 Jul 2005 14:59:40 -0500 (CDT) Received: by il02exm13 with Internet Mail Service (5.5.2657.72) id ; Wed, 20 Jul 2005 14:53:31 -0500 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A71E5@il02exm13> From: Narayanan Vidya-CVN065 To: "'James Kempf'" , Julien Bournelle Date: Wed, 20 Jul 2005 14:53:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 2.4 (++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, "'Tschofenig, Hannes'" , mobopts@irtf.org, Venkitaraman Narayanan-CNV002 Subject: [Mobopts] RE: Review of draft-vidya-mipshop-handover-keys-aaa-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org > > > > Why does the MN have to use PANA when it uses 802.11i for > network access? Why can't it just use the EAP method with the > handover key extension during 802.1x? > So, in this case, the AAA server will then send the MSK to the AP and the HK to the AR? This is unlike the operation today where the AAA server does not send any keys unsolicited to an entity from which it hasn't received any messages - isn't it? _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 20 20:11:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvOfG-0002Bi-49; Wed, 20 Jul 2005 20:11:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvOfA-0002BV-08; Wed, 20 Jul 2005 20:11:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17856; Wed, 20 Jul 2005 20:11:42 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvP95-00084v-Nu; Wed, 20 Jul 2005 20:42:40 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6KNdai10949; Wed, 20 Jul 2005 16:39:36 -0700 X-mProtect: <200507202339> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp166150.americas.nokia.com (10.241.166.150, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpd7YFw5P; Wed, 20 Jul 2005 16:39:33 PDT Message-ID: <42DEE822.6040809@iprg.nokia.com> Date: Wed, 20 Jul 2005 17:11:14 -0700 From: Rajeev Koodli 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 References: <1B631E11D496D711BB2800065BFCB6A11B7A71D7@il02exm13> <005101c58caf$5efc36c0$016115ac@dcml.docomolabsusa.com> <20050720135802.GE21022@ipv6-3.int-evry.fr> <014301c58d48$653b6440$016115ac@dcml.docomolabsusa.com> In-Reply-To: <014301c58d48$653b6440$016115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, mobopts@irtf.org, Venkitaraman Narayanan-CNV002 Subject: [Mobopts] Re: [Mipshop] Re: Review of draft-vidya-mipshop-handover-keys-aaa-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org James Kempf wrote: >> The problem that I can see is after IP handover, how do the MN get a >> new key ? If we continue to rely on EAP, it will imply a >> reauthentication from scratch. >> > One of two ways: > > 1) The MN has actually reauthenticated for network access from scratch in > order to establish its session key with the new AR/AP, and in the process > obtained a handover key. In 802.1x, that is, in fact, currently the only way > I believe, though the 802.11r WG is looking to change this. > > 2) The MN has performed preauthentication with a collection of AR/APs around > the current one, and so has a key already available. > There are two separate issues here. 1. Securing the FMIP signaling via key derivation. 2. Reducing the re-authentication latency. I believe we are mostly referring to 1) in this thread (so far at least). What is the scope of 2) for us? Is it an L2-specific problem that other bodies such as .11r are considering? I believe understanding the scope of 2) is important before we engineer the solution. -Rajeev > jak > > > > _______________________________________________ > Mipshop mailing list > Mipshop@ietf.org > https://www1.ietf.org/mailman/listinfo/mipshop _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mipshop-bounces@ietf.org Wed Jul 20 20:11:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvOfG-0002Bz-HW; Wed, 20 Jul 2005 20:11:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvOfA-0002BV-08; Wed, 20 Jul 2005 20:11:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17856; Wed, 20 Jul 2005 20:11:42 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvP95-00084v-Nu; Wed, 20 Jul 2005 20:42:40 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6KNdai10949; Wed, 20 Jul 2005 16:39:36 -0700 X-mProtect: <200507202339> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp166150.americas.nokia.com (10.241.166.150, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpd7YFw5P; Wed, 20 Jul 2005 16:39:33 PDT Message-ID: <42DEE822.6040809@iprg.nokia.com> Date: Wed, 20 Jul 2005 17:11:14 -0700 From: Rajeev Koodli 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: [Mipshop] Re: Review of draft-vidya-mipshop-handover-keys-aaa-00.txt References: <1B631E11D496D711BB2800065BFCB6A11B7A71D7@il02exm13> <005101c58caf$5efc36c0$016115ac@dcml.docomolabsusa.com> <20050720135802.GE21022@ipv6-3.int-evry.fr> <014301c58d48$653b6440$016115ac@dcml.docomolabsusa.com> In-Reply-To: <014301c58d48$653b6440$016115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, mobopts@irtf.org, Venkitaraman Narayanan-CNV002 X-BeenThere: mipshop@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mipshop.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mipshop-bounces@ietf.org Errors-To: mipshop-bounces@ietf.org James Kempf wrote: >> The problem that I can see is after IP handover, how do the MN get a >> new key ? If we continue to rely on EAP, it will imply a >> reauthentication from scratch. >> > One of two ways: > > 1) The MN has actually reauthenticated for network access from scratch in > order to establish its session key with the new AR/AP, and in the process > obtained a handover key. In 802.1x, that is, in fact, currently the only way > I believe, though the 802.11r WG is looking to change this. > > 2) The MN has performed preauthentication with a collection of AR/APs around > the current one, and so has a key already available. > There are two separate issues here. 1. Securing the FMIP signaling via key derivation. 2. Reducing the re-authentication latency. I believe we are mostly referring to 1) in this thread (so far at least). What is the scope of 2) for us? Is it an L2-specific problem that other bodies such as .11r are considering? I believe understanding the scope of 2) is important before we engineer the solution. -Rajeev > jak > > > > _______________________________________________ > Mipshop mailing list > Mipshop@ietf.org > https://www1.ietf.org/mailman/listinfo/mipshop _______________________________________________ Mipshop mailing list Mipshop@ietf.org https://www1.ietf.org/mailman/listinfo/mipshop From mobopts-bounces@irtf.org Wed Jul 20 20:21:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvOoN-00087y-0K; Wed, 20 Jul 2005 20:21:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvOoL-00086K-9t; Wed, 20 Jul 2005 20:21:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18234; Wed, 20 Jul 2005 20:21:11 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvPIG-0000Bu-4V; Wed, 20 Jul 2005 20:52:09 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6KNn1R18254; Wed, 20 Jul 2005 16:49:01 -0700 X-mProtect: <200507202349> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp166150.americas.nokia.com (10.241.166.150, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdyliSAZ; Wed, 20 Jul 2005 16:48:59 PDT Message-ID: <42DEEA58.4010402@iprg.nokia.com> Date: Wed, 20 Jul 2005 17:20:40 -0700 From: Rajeev Koodli 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: Narayanan Vidya-CVN065 References: <1B631E11D496D711BB2800065BFCB6A11B7A71E5@il02exm13> In-Reply-To: <1B631E11D496D711BB2800065BFCB6A11B7A71E5@il02exm13> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, 'James Kempf' , mobopts@irtf.org, Venkitaraman Narayanan-CNV002 Subject: [Mobopts] Re: [Mipshop] RE: Review of draft-vidya-mipshop-handover-keys-aaa-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Narayanan Vidya-CVN065 wrote: >>Why does the MN have to use PANA when it uses 802.11i for >>network access? Why can't it just use the EAP method with the >>handover key extension during 802.1x? >> > > > So, in this case, the AAA server will then send the MSK to the AP > and the HK to the AR? This is unlike the operation today where the Does the AR need HK in the middle of a handover? Perhaps we can do without it. Why not let .11r (or something alike) handle re-authentication problem, and assume that AR will forward the packets? At a less critical time, the MN and AR can derive their HK again. One of the key design goals in FMIP has been to disengage all other signaling (e.g., RR, BU, DHCP in fmipv4) from the critical path. We should try to preserve that as we move along. -Rajeev > AAA server does not send any keys unsolicited to an entity from which >it hasn't received any messages - isn't it? > > _______________________________________________ > Mipshop mailing list > Mipshop@ietf.org > https://www1.ietf.org/mailman/listinfo/mipshop _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 20 21:11:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvPb5-0005lM-MZ; Wed, 20 Jul 2005 21:11:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvPb2-0005jD-UC for mobopts@megatron.ietf.org; Wed, 20 Jul 2005 21:11:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21787 for ; Wed, 20 Jul 2005 21:11:31 -0400 (EDT) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvQ4y-0003H4-8b for mobopts@irtf.org; Wed, 20 Jul 2005 21:42:29 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 4008E800088; Thu, 21 Jul 2005 04:11:19 +0300 (EEST) Date: Thu, 21 Jul 2005 04:11:19 +0300 (EEST) From: Wassim Haddad To: mipshop@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Spam-Score: 2.4 (++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: mip6@ietf.org, mobopts@irtf.org Subject: [Mobopts] I-D ACTION:draft-haddad-mipshop-omm-01.txt (fwd) X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi, FYI, A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Optimizing Micromobility Management for Active and Dormant Mobile Nodes Author(s) : W. Haddad, et al. Filename : draft-haddad-mipshop-omm-01.txt Pages : 28 Date : 2005-7-20 Micromobility protocols address mobile nodes (MN) movements within a particular IP network domain. This document introduces a new protocol "Optimized Micromobility Management" (OMM), to manage Micromobility for active and dormant mobile nodes. The suggested solution is based on the Hierarchical Mobile IPv6 (HMIPv6) proposal and aims to increase the mobility performance by reducing the handover latency and the packet loss. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haddad-mipshop-omm-01.txt Comments appreciated. Regards, Wassim H. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 20 21:55:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvQHL-0008UC-Nb; Wed, 20 Jul 2005 21:55:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvQHJ-0008PK-SN for mobopts@megatron.ietf.org; Wed, 20 Jul 2005 21:55:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26867 for ; Wed, 20 Jul 2005 21:55:11 -0400 (EDT) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvQlF-0006p9-JU for mobopts@irtf.org; Wed, 20 Jul 2005 22:26:10 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate.mot.com (Motorola/Motgate) with ESMTP id j6L1t25A006723 for ; Wed, 20 Jul 2005 18:55:07 -0700 (MST) Received: from il02exm13.corp.mot.com (il02exm13.corp.mot.com [10.0.111.24]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j6L1x9a3006086 for ; Wed, 20 Jul 2005 20:59:10 -0500 (CDT) Received: by il02exm13 with Internet Mail Service (5.5.2657.72) id ; Wed, 20 Jul 2005 20:55:01 -0500 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A71EA@il02exm13> From: Narayanan Vidya-CVN065 To: "'Rajeev Koodli'" , James Kempf Subject: RE: [Mobopts] Re: [Mipshop] Re: Review of draft-vidya-mipshop-han dover-keys-aaa-00.txt Date: Wed, 20 Jul 2005 20:54:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 2.4 (++) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, Venkitaraman Narayanan-CNV002 , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi Rajeev, The protocol, as written now, has taken both into account. The signaling for derivation of handover keys is not done at the time of handover (and hence does not add to the handover latency). The signaling exchange can happen after the MN has handed off or even before it is about to handoff (through the oAR) - so, none of the messages need to be exchanged during the critical handoff time. Does that make sense or were you referring to something else? Thanks, Vidya > -----Original Message----- > From: mobopts-bounces@irtf.org > [mailto:mobopts-bounces@irtf.org] On Behalf Of Rajeev Koodli > Sent: Wednesday, July 20, 2005 7:11 PM > To: James Kempf > Cc: Gerardo Giaretta; Julien Bournelle; mipshop@ietf.org; > mobopts@irtf.org; Venkitaraman Narayanan-CNV002 > Subject: [Mobopts] Re: [Mipshop] Re: Review of > draft-vidya-mipshop-handover-keys-aaa-00.txt > > > > > James Kempf wrote: > > >> The problem that I can see is after IP handover, how do > the MN get a > >> new key ? If we continue to rely on EAP, it will imply a > >> reauthentication from scratch. > >> > > One of two ways: > > > > 1) The MN has actually reauthenticated for network access > from scratch > > in order to establish its session key with the new AR/AP, > and in the > > process obtained a handover key. In 802.1x, that is, in fact, > > currently the only way I believe, though the 802.11r WG is > looking to > > change this. > > > > 2) The MN has performed preauthentication with a collection > of AR/APs > > around the current one, and so has a key already available. > > > > > There are two separate issues here. > > 1. Securing the FMIP signaling via key derivation. > > 2. Reducing the re-authentication latency. > > I believe we are mostly referring to 1) in this thread (so > far at least). > > What is the scope of 2) for us? Is it an L2-specific > problem that other bodies such as .11r are considering? > I believe understanding the scope of 2) is important > before we engineer the solution. > > -Rajeev > > > > jak > > > > > > > > _______________________________________________ > > Mipshop mailing list > > Mipshop@ietf.org https://www1.ietf.org/mailman/listinfo/mipshop > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 20 22:10:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvQW5-0000tR-BK; Wed, 20 Jul 2005 22:10:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvQW2-0000sJ-My for mobopts@megatron.ietf.org; Wed, 20 Jul 2005 22:10:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28569 for ; Wed, 20 Jul 2005 22:10:24 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvQzy-0007ns-Je for mobopts@irtf.org; Wed, 20 Jul 2005 22:41:23 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j6L2JkSk027563 for ; Wed, 20 Jul 2005 19:19:47 -0700 (MST) Received: from il02exm13.corp.mot.com (il02exm13.corp.mot.com [10.0.111.24]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id j6L2GXU4017616 for ; Wed, 20 Jul 2005 21:16:34 -0500 (CDT) Received: by il02exm13 with Internet Mail Service (5.5.2657.72) id ; Wed, 20 Jul 2005 21:10:23 -0500 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A71EB@il02exm13> From: Narayanan Vidya-CVN065 To: "'Rajeev Koodli'" Date: Wed, 20 Jul 2005 21:10:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 2.4 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, 'James Kempf' , mobopts@irtf.org, Venkitaraman Narayanan-CNV002 Subject: [Mobopts] RE: [Mipshop] RE: Review of draft-vidya-mipshop-handover-keys-aaa -00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org > > >>Why does the MN have to use PANA when it uses 802.11i for > >>network access? Why can't it just use the EAP method with the > >>handover key extension during 802.1x? > >> > > > > > > So, in this case, the AAA server will then send the MSK to the AP > > and the HK to the AR? This is unlike the operation today where the > > Does the AR need HK in the middle of a handover? Perhaps > we can do without it. > Why not let .11r (or something alike) handle > re-authentication problem, and assume that AR will forward > the packets? At a less critical time, the MN and AR can > derive their HK again. > No, the HK is not needed in the middle of a handover. If we piggyback HK derivation on the EAP method as James proposes, it will be derived during handover (unless the MN does another EAP method exchange after handoff sometime). In the currently described protocol, the signaling between MN and AR (and subsequently the AAA server) can happen at any time - not at critical time. So, as you say, 11r or something else will handle the L2 re-auth and the HK itself can be derived before or after handoff (depending on when the MN has information available about the AR). In fact, one of the things that will be a problem for us if HK derivation is made dependent on the EAP method is 802.11r - if 11r is adopted as being proposed now with evolving keys, the MN will not perform a full EAP method upon handoff - as long as it is handing off under the same R0 entity, it will only change its PMK-R1/PMK-R2 - hence, the exchange will not reach the AAA server. So, unless the HK itself evolves the same way (which means we now rely on a hierarchy of ARs, with SAs between them, etc.) or we make an assumption that PMK-R0 will always change upon inter-subnet handoffs, it becomes a problem for us. So, I am not entirely sure how we can make L3 handover keys applicable for heterogeneous L2 handoffs (whether L2 employs 802.11i/PANA/802.11r/etc) if the L3 HKs are dependent on L2 authentication. > One of the key design goals in FMIP has been to disengage > all other signaling (e.g., RR, BU, DHCP in fmipv4) from > the critical path. We should try to preserve that as we > move along. > Yes, we had this goal as well in designing the protocol. If you look at the 5th bullet in section 1.1, it states this as one of the design goals. Regards, Vidya > -Rajeev > > > > > AAA server does not send any keys unsolicited to an entity > from which > >it hasn't received any messages - isn't it? > > > > _______________________________________________ > > Mipshop mailing list > > Mipshop@ietf.org https://www1.ietf.org/mailman/listinfo/mipshop > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 20 22:22:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvQhh-0007NU-Vb; Wed, 20 Jul 2005 22:22:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvQhg-0007NP-8X for mobopts@megatron.ietf.org; Wed, 20 Jul 2005 22:22:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29832 for ; Wed, 20 Jul 2005 22:22:25 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvRBa-0000FK-Sm for mobopts@irtf.org; Wed, 20 Jul 2005 22:53:25 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j6L2Vlrj028741 for ; Wed, 20 Jul 2005 19:31:47 -0700 (MST) Received: from il02exm13.corp.mot.com (il02exm13.corp.mot.com [10.0.111.24]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j6L2SbCM025635 for ; Wed, 20 Jul 2005 21:28:37 -0500 (CDT) Received: by il02exm13 with Internet Mail Service (5.5.2657.72) id ; Wed, 20 Jul 2005 21:22:24 -0500 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A71ED@il02exm13> From: Narayanan Vidya-CVN065 To: "'James Kempf'" , mipshop@ietf.org, mobopts@irtf.org Date: Wed, 20 Jul 2005 21:22:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 2.4 (++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Gerardo Giaretta , Julien Bournelle , Venkitaraman Narayanan-CNV002 , "'Tschofenig, Hannes'" Subject: [Mobopts] RE: Review of draft-vidya-mipshop-handover-keys-aaa-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi James, Since we seem to be having the PANA/EAP-HK dependency message exchanges in a separate email, I have not addressed those again here. Some answers to other comments and questions below. > > As I mentioned, the attraction of this protocol is that it > can leverage off the AAA infrastructure for network access > authentication. So by not doing that, I think you are > undercutting your strongest argument. I am not sure if this is the case. The fact that the HMK is derived via EAP eliminates the need for the MN to have any other security associations, except with the AAA server. It has an SA with the AAA server for EAP purposes and we are deriving a master key for handover purposes from the EAP key hierarchy. But, subsequently, since we are deriving HKs only from the HMK, it seemed like a close tie up with network access authentication is not required. > > > > The AAA server does send a recommended lifetime to the AR > (and the AR > forwards that to the MN). However, the AAA server does not > maintain any state about the lifetime itself and hence, it is > up to the MN and AR to enforce the lifetime. Perhaps, the > text can add more clarity on this. > > > > Yes. But why should the MN trust the AR on the lifetime? > There is no authenticated relationship between the AR and MN. > The MN obtains the lifetime from the AAA server itself (this attribute sent to the AR is included in the MAC sent by the AAA server and verified by the MN). So, if the AR modified the lifetime, the MN would realize that. However, ultimately, say if the AR rebooted before the lifetime expired or if the AR itself enforced a smaller lifetime than what the AAA sent it, there is not much the MN can do, except derive a new HK. > > > > Yes but I think you need to make it clearer in the draft how > retransmissions work. > OK. Will fix this. > > Again, I think the draft could be clearer on this. It needs > to emphasize that preauthentication is primarily an optimization. > OK. > > > > Yes, this is true. This is among the reasons why we didn't consider > > any of > these approaches for the protocol. We may have missed stating > that. We included this appendix to essentially explain why > some of the other seemingly simple approaches were not so desirable. > > > > OK. I think this could be dropped from the draft, since it > does not contribute to explaining the protocol. > Ok. We wanted it to be part of v00 to give an idea of what alternatives were considered by the authors and why these weren't chosen for the protocol. But, yes, this can be removed in the next revision of the draft. Thanks, Vidya _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jul 21 13:16:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvefJ-0005no-3F; Thu, 21 Jul 2005 13:16:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvefB-0005la-89 for mobopts@megatron.ietf.org; Thu, 21 Jul 2005 13:16:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18594 for ; Thu, 21 Jul 2005 13:16:46 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvezg-0005yF-U0 for mobopts@irtf.org; Thu, 21 Jul 2005 13:38:02 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IJZ0070HM2FY0@dns1.cselt.it> for mobopts@irtf.org; Thu, 21 Jul 2005 19:03:51 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 19:10:14 +0200 Date: Thu, 21 Jul 2005 19:06:45 +0200 From: Gerardo Giaretta To: Narayanan Vidya-CVN065 , James Kempf Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: Review of draft-vidya-mipshop-handover-keys-aaa-00.txt thread-index: AcWNZMTGbuJyRLLjQA+HsbzcnRICMgAsLn3g Content-Class: urn:content-classes:message X-OriginalArrivalTime: 21 Jul 2005 17:10:14.0296 (UTC) FILETIME=[0F5B4980:01C58E17] X-Spam-Score: 2.4 (++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: Julien Bournelle , mipshop@ietf.org, "Tschofenig, Hannes" , Venkitaraman Narayanan-CNV002 , mobopts@irtf.org Subject: [Mobopts] RE: Review of draft-vidya-mipshop-handover-keys-aaa-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi Vidya and James,=20 > > > > >=20 > > Why does the MN have to use PANA when it uses 802.11i for=20 > > network access? Why can't it just use the EAP method with the=20 > > handover key extension during 802.1x? > >=20 >=20 > So, in this case, the AAA server will then send the MSK to=20 > the AP and the HK to the AR? This is unlike the operation=20 > today where the AAA server does not send any keys unsolicited=20 > to an entity from which it hasn't received any messages - isn't it? =20 >=20 I think the scheme James is referring to is very simple if the NAS is the AR (e.g. PANA is used). In this case you don't need to transfer any key and the AR receives the HK directly from the AAA server.=20 If the NAS is not co-located with the AR (e.g. 802.1X), the NAS may receive the HK from the AAA server and may send it to the AR. This is somehow similar to what is done in PAA-EP exchange in PANA where SNMP is used. Some issues with Housley criteria may arise in this case, though. Anyway, I think having the AAA server that sends a key unsolicited to the AR is not a good approach.=20 --Gerardo Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jul 21 13:50:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvfC5-00067n-Jt; Thu, 21 Jul 2005 13:50:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvfC4-00067e-5a for mobopts@megatron.ietf.org; Thu, 21 Jul 2005 13:50:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21576 for ; Thu, 21 Jul 2005 13:50:47 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvfg7-0000ih-3r for mobopts@irtf.org; Thu, 21 Jul 2005 14:21:53 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j6LHxtFr019354 for ; Thu, 21 Jul 2005 10:59:55 -0700 (MST) Received: from il02exm13.corp.mot.com (il02exm13.corp.mot.com [10.0.111.24]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j6LHtSU6009168 for ; Thu, 21 Jul 2005 12:55:28 -0500 (CDT) Received: by il02exm13 with Internet Mail Service (5.5.2657.72) id ; Thu, 21 Jul 2005 12:50:31 -0500 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A71FD@il02exm13> From: Narayanan Vidya-CVN065 To: "'Gerardo Giaretta'" , James Kempf Date: Thu, 21 Jul 2005 12:50:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 2.4 (++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Julien Bournelle , mipshop@ietf.org, "Tschofenig, Hannes" , Venkitaraman Narayanan-CNV002 , mobopts@irtf.org Subject: [Mobopts] RE: Review of draft-vidya-mipshop-handover-keys-aaa-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi Gerardo, > > > > > > Why does the MN have to use PANA when it uses 802.11i for > > > network access? Why can't it just use the EAP method with the > > > handover key extension during 802.1x? > > > > > > > So, in this case, the AAA server will then send the MSK to > > the AP and the HK to the AR? This is unlike the operation > > today where the AAA server does not send any keys unsolicited > > to an entity from which it hasn't received any messages - > isn't it? > > > > I think the scheme James is referring to is very simple if the NAS is > the AR (e.g. PANA is used). In this case you don't need to > transfer any > key and the AR receives the HK directly from the AAA server. > Precisely. I don't see an issue when the AR itself is the NAS. In the scenario I was describing, the NAS is the AP, but the key needs to be sent to the AR. > If the NAS is not co-located with the AR (e.g. 802.1X), the NAS may > receive the HK from the AAA server and may send it to the AR. This is > somehow similar to what is done in PAA-EP exchange in PANA > where SNMP is > used. Some issues with Housley criteria may arise in this > case, though. > Anyway, I think having the AAA server that sends a key unsolicited to > the AR is not a good approach. > Yes, this is really the problem. Not all the AAA key management criteria will be satisfied when the NAS is different from the entity that needs the key. Also, now this means that the solution will need to be specific to each lower layer encapsulating EAP - if an 802.11 AP or an 802.16 BS needs to send the key to the AR. And, given that typically you would not expect an SA between the AP/BS and the AR, this is a problem. Vidya _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jul 21 14:01:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvfMb-0001SL-JD; Thu, 21 Jul 2005 14:01:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvfMa-0001SF-4p for mobopts@megatron.ietf.org; Thu, 21 Jul 2005 14:01:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22091 for ; Thu, 21 Jul 2005 14:01:39 -0400 (EDT) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvfqe-0001Op-DY for mobopts@irtf.org; Thu, 21 Jul 2005 14:32:45 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 71D088000A9 for ; Thu, 21 Jul 2005 21:01:24 +0300 (EEST) Date: Thu, 21 Jul 2005 21:01:24 +0300 (EEST) From: Wassim Haddad To: mobopts@irtf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Spam-Score: 2.4 (++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Mobopts] I-D ACTION:draft-haddad-mipshop-omm-01.txt (fwd) X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi, FYI, A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Optimizing Micromobility Management for Active and Dormant Mobile Nodes Author(s) : W. Haddad, et al. Filename : draft-haddad-mipshop-omm-01.txt Pages : 28 Date : 2005-7-20 Micromobility protocols address mobile nodes (MN) movements within a particular IP network domain. This document introduces a new protocol "Optimized Micromobility Management" (OMM), to manage Micromobility for active and dormant mobile nodes. The suggested solution is based on the Hierarchical Mobile IPv6 (HMIPv6) proposal and aims to increase the mobility performance by reducing the handover latency and the packet loss. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haddad-mipshop-omm-01.txt Comments appreciated. Regards, Wassim H. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jul 21 14:21:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvffq-0001jC-CM; Thu, 21 Jul 2005 14:21:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvffk-0001is-HC; Thu, 21 Jul 2005 14:21:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24006; Thu, 21 Jul 2005 14:21:27 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvg9o-0002kL-NK; Thu, 21 Jul 2005 14:52:34 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6LHnIX04557; Thu, 21 Jul 2005 10:49:18 -0700 X-mProtect: <200507211749> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141100.americas.nokia.com (172.18.141.100, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdnqip5C; Thu, 21 Jul 2005 10:49:17 PDT Message-ID: <42DFE78C.2060707@iprg.nokia.com> Date: Thu, 21 Jul 2005 11:21:00 -0700 From: Rajeev Koodli 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: Narayanan Vidya-CVN065 References: <1B631E11D496D711BB2800065BFCB6A11B7A71EB@il02exm13> In-Reply-To: <1B631E11D496D711BB2800065BFCB6A11B7A71EB@il02exm13> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, 'James Kempf' , mobopts@irtf.org, Venkitaraman Narayanan-CNV002 Subject: [Mobopts] Re: [Mipshop] RE: Review of draft-vidya-mipshop-handover-keys-aaa -00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Narayanan Vidya-CVN065 wrote: > In fact, one of the things that will be a problem for us if > HK derivation is made dependent on the EAP method is 802.11r - > if 11r is adopted as being proposed now with evolving keys, > the MN will not perform a full EAP method upon handoff - as > long as it is handing off under the same R0 entity, it will > only change its PMK-R1/PMK-R2 - hence, the exchange will > not reach the AAA server. So, unless the HK itself evolves > the same way (which means we now rely on a hierarchy of ARs, > with SAs between them, etc.) or we make an assumption that > PMK-R0 will always change upon inter-subnet handoffs, it > becomes a problem for us. So, I am not entirely sure how > we can make L3 handover keys applicable for heterogeneous > L2 handoffs (whether L2 employs 802.11i/PANA/802.11r/etc) if > the L3 HKs are dependent on L2 authentication. > Creating a shared secret between MN and PAR can be done assuming some L2 access (or L3 in the SEND-based handover key derivation draft) authentication method is used, right? This should be the focus of the draft IMO. Assuming so, which L3 handover key are you referring to that would be needed across different L2 access types? If a MN did .11i, created a shared secret (Sk-L3) for L3 to use, moved over to a different L2, and then did method auth-Y, why is the applicability of Sk-L3 on the new L2 important during a handover? -Rajeev > > >>One of the key design goals in FMIP has been to disengage >>all other signaling (e.g., RR, BU, DHCP in fmipv4) from >>the critical path. We should try to preserve that as we >>move along. >> > > > Yes, we had this goal as well in designing the protocol. If you look at the 5th bullet in section 1.1, it states this as one of the design goals. > > Regards, > Vidya > > > >>-Rajeev >> >> >> >> >>>AAA server does not send any keys unsolicited to an entity >> >>from which >> >>>it hasn't received any messages - isn't it? >>> >>>_______________________________________________ >>>Mipshop mailing list >>>Mipshop@ietf.org https://www1.ietf.org/mailman/listinfo/mipshop >> > > _______________________________________________ > Mipshop mailing list > Mipshop@ietf.org > https://www1.ietf.org/mailman/listinfo/mipshop _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jul 21 15:21:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvgbr-0004zF-4C; Thu, 21 Jul 2005 15:21:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvgbq-0004z5-78 for mobopts@megatron.ietf.org; Thu, 21 Jul 2005 15:21:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01227 for ; Thu, 21 Jul 2005 15:21:28 -0400 (EDT) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvh5n-0006z4-JR for mobopts@irtf.org; Thu, 21 Jul 2005 15:52:36 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id j6LJRUS9009936 for ; Thu, 21 Jul 2005 12:27:30 -0700 (MST) Received: from il02exm13.corp.mot.com (il02exm13.corp.mot.com [10.0.111.24]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j6LJPIQX019156 for ; Thu, 21 Jul 2005 14:25:19 -0500 (CDT) Received: by il02exm13 with Internet Mail Service (5.5.2657.72) id ; Thu, 21 Jul 2005 14:21:09 -0500 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A7200@il02exm13> From: Narayanan Vidya-CVN065 To: "'Rajeev Koodli'" Date: Thu, 21 Jul 2005 14:21:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 2.4 (++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, 'James Kempf' , mobopts@irtf.org, Venkitaraman Narayanan-CNV002 Subject: [Mobopts] RE: [Mipshop] RE: Review of draft-vidya-mipshop-handover-keys-aaa -00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org > > > In fact, one of the things that will be a problem for us if > > HK derivation is made dependent on the EAP method is 802.11r - > > if 11r is adopted as being proposed now with evolving keys, > > the MN will not perform a full EAP method upon handoff - as > > long as it is handing off under the same R0 entity, it will > > only change its PMK-R1/PMK-R2 - hence, the exchange will > > not reach the AAA server. So, unless the HK itself evolves > > the same way (which means we now rely on a hierarchy of ARs, > > with SAs between them, etc.) or we make an assumption that > > PMK-R0 will always change upon inter-subnet handoffs, it > > becomes a problem for us. So, I am not entirely sure how > > we can make L3 handover keys applicable for heterogeneous > > L2 handoffs (whether L2 employs 802.11i/PANA/802.11r/etc) if > > the L3 HKs are dependent on L2 authentication. > > > > Creating a shared secret between MN and PAR can be done > assuming some L2 access (or L3 in the SEND-based handover > key derivation draft) authentication method is used, right? > This should be the focus of the draft IMO. As long as the shared secret between MN and PAR is not piggybacked on L2 access authentication, this is true, right? If we were to tightly couple it to L2 access authentication, such independence does not seem to be available. The current protocol makes the creation of shared secret between MN and PAR be totally independent of the type of L2 access. > > Assuming so, which L3 handover key are you referring to that > would be needed across different L2 access types? > If a MN did .11i, created a shared secret (Sk-L3) for L3 to use, > moved over to a different L2, and then did method auth-Y, why > is the applicability of Sk-L3 on the new L2 important during > a handover? > I am confused by this. The L3 handover key I am referring to is the shared secret between MN and AR. If we extended an EAP method to derive this key, when the EAP authenticator is not the same as the AR, we have some issues in getting the key to the AR without breaking some of the Housley criteria. It is not that we need a new key as a result of a new L2 auth method, but it is the process of deriving a key with the next AR may now need to be different, due to the > -Rajeev > > > > > > > > >>One of the key design goals in FMIP has been to disengage > >>all other signaling (e.g., RR, BU, DHCP in fmipv4) from > >>the critical path. We should try to preserve that as we > >>move along. > >> > > > > > > Yes, we had this goal as well in designing the protocol. If > you look at the 5th bullet in section 1.1, it states this as > one of the design goals. > > > > Regards, > > Vidya > > > > > > > >>-Rajeev > >> > >> > >> > >> > >>>AAA server does not send any keys unsolicited to an entity > >> > >>from which > >> > >>>it hasn't received any messages - isn't it? > >>> > >>>_______________________________________________ > >>>Mipshop mailing list > >>>Mipshop@ietf.org https://www1.ietf.org/mailman/listinfo/mipshop > >> > > > > _______________________________________________ > > Mipshop mailing list > > Mipshop@ietf.org > > https://www1.ietf.org/mailman/listinfo/mipshop > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jul 21 15:46:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvgzg-0008Fm-Eo; Thu, 21 Jul 2005 15:46:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvgze-0008Fe-VB; Thu, 21 Jul 2005 15:46:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03276; Thu, 21 Jul 2005 15:46:05 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvhTj-0000Cu-VZ; Thu, 21 Jul 2005 16:17:13 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6LJDvk05742; Thu, 21 Jul 2005 12:13:57 -0700 X-mProtect: <200507211913> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141100.americas.nokia.com (172.18.141.100, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdvbInBc; Thu, 21 Jul 2005 12:13:55 PDT Message-ID: <42DFFB63.3050403@iprg.nokia.com> Date: Thu, 21 Jul 2005 12:45:39 -0700 From: Rajeev Koodli 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: Narayanan Vidya-CVN065 Subject: Re: [Mobopts] RE: [Mipshop] RE: Review of draft-vidya-mipshop-handover-keys-aaa -00.txt References: <1B631E11D496D711BB2800065BFCB6A11B7A7200@il02exm13> In-Reply-To: <1B631E11D496D711BB2800065BFCB6A11B7A7200@il02exm13> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, 'James Kempf' , mobopts@irtf.org, Venkitaraman Narayanan-CNV002 X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Narayanan Vidya-CVN065 wrote: > > I am confused by this. The L3 handover key I am referring to is > the shared secret between MN and AR. If we extended an EAP method > to derive this key, when the EAP authenticator is not the same as > the AR, we have some issues in getting the key to the AR without > breaking some of the Housley criteria. It is not that we need a > new key as a result of a new L2 auth method, but it is the process > of deriving a key with the next AR may now need to be different, due to the Perhaps you meant to say something more.. Okay. I guess we need to solve this so that it can also work for EAP. And, a constraint is not to derive these keys during a handover, which I guess is already being addressed. I see your point about coupling L3 key derivation tightly to L2 authentication. And, I agree that the process needs to be applicable across different L2 access types. It would be good to discuss the pros and cons. -Rajeev > > > > >>-Rajeev >> >> >> >> >>> >>>>One of the key design goals in FMIP has been to disengage >>>>all other signaling (e.g., RR, BU, DHCP in fmipv4) from >>>>the critical path. We should try to preserve that as we >>>>move along. >>>> >>> >>> >>>Yes, we had this goal as well in designing the protocol. If >> >>you look at the 5th bullet in section 1.1, it states this as >>one of the design goals. >> >>>Regards, >>>Vidya >>> >>> >>> >>> >>>>-Rajeev >>>> >>>> >>>> >>>> >>>> >>>>>AAA server does not send any keys unsolicited to an entity >>>> >>>>from which >>> >>>>>it hasn't received any messages - isn't it? >>>>> >>>>>_______________________________________________ >>>>>Mipshop mailing list >>>>>Mipshop@ietf.org https://www1.ietf.org/mailman/listinfo/mipshop >>>> >>>_______________________________________________ >>>Mipshop mailing list >>>Mipshop@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mipshop >> > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jul 21 16:03:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvhGY-0007M7-2C; Thu, 21 Jul 2005 16:03:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvhGW-0007M0-Ut for mobopts@megatron.ietf.org; Thu, 21 Jul 2005 16:03:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07563 for ; Thu, 21 Jul 2005 16:03:31 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvhka-0002MW-58 for mobopts@irtf.org; Thu, 21 Jul 2005 16:34:39 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j6LKCofs013697 for ; Thu, 21 Jul 2005 13:12:50 -0700 (MST) Received: from il02exm13.corp.mot.com (il02exm13.corp.mot.com [10.0.111.24]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j6LK9fJh002183 for ; Thu, 21 Jul 2005 15:09:41 -0500 (CDT) Received: by il02exm13 with Internet Mail Service (5.5.2657.72) id ; Thu, 21 Jul 2005 15:03:27 -0500 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A7202@il02exm13> From: Narayanan Vidya-CVN065 To: "'Rajeev Koodli'" Subject: RE: [Mobopts] RE: [Mipshop] RE: Review of draft-vidya-mipshop-han dover-keys-aaa -00.txt Date: Thu, 21 Jul 2005 15:03:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 2.4 (++) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, 'James Kempf' , mobopts@irtf.org, Venkitaraman Narayanan-CNV002 X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Oops.. Sorry, don't know how the last sentence was truncated - all I had was "...due to the fact that the L2 auth method used is different." > different, due to the > > Perhaps you meant to say something more.. > > Okay. I guess we need to solve this so that it can also work > for EAP. And, a constraint is not to derive these keys during > a handover, which I guess is already being addressed. > > I see your point about coupling L3 key derivation tightly to > L2 authentication. And, I agree that the process needs to be > applicable across different L2 access types. It would be good > to discuss the pros and cons. > > -Rajeev > > > > > > > > > > > >>-Rajeev > >> > >> > >> > >> > >>> > >>>>One of the key design goals in FMIP has been to disengage > all other > >>>>signaling (e.g., RR, BU, DHCP in fmipv4) from the > critical path. We > >>>>should try to preserve that as we move along. > >>>> > >>> > >>> > >>>Yes, we had this goal as well in designing the protocol. If > >> > >>you look at the 5th bullet in section 1.1, it states this as > >>one of the design goals. > >> > >>>Regards, > >>>Vidya > >>> > >>> > >>> > >>> > >>>>-Rajeev > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>AAA server does not send any keys unsolicited to an entity > >>>> > >>>>from which > >>> > >>>>>it hasn't received any messages - isn't it? > >>>>> > >>>>>_______________________________________________ > >>>>>Mipshop mailing list > >>>>>Mipshop@ietf.org https://www1.ietf.org/mailman/listinfo/mipshop > >>>> > >>>_______________________________________________ > >>>Mipshop mailing list > >>>Mipshop@ietf.org https://www1.ietf.org/mailman/listinfo/mipshop > >> > > > > _______________________________________________ > > Mobopts mailing list > > Mobopts@irtf.org > > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jul 21 17:28:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvib6-0008D6-JD; Thu, 21 Jul 2005 17:28:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvib4-0008Cl-I7 for mobopts@megatron.ietf.org; Thu, 21 Jul 2005 17:28:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13656 for ; Thu, 21 Jul 2005 17:28:47 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvj5A-00011j-3d for mobopts@irtf.org; Thu, 21 Jul 2005 17:59:57 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6LKuf009940; Thu, 21 Jul 2005 13:56:41 -0700 X-mProtect: <200507212056> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141100.americas.nokia.com (172.18.141.100, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdb4MI9v; Thu, 21 Jul 2005 13:56:39 PDT Message-ID: <42E01377.60205@iprg.nokia.com> Date: Thu, 21 Jul 2005 14:28:23 -0700 From: Rajeev Koodli 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: jouni.korhonen@teliasonera.com Subject: Re: [Mobopts] New topics for the RG References: <07B14A720C46C344AC96AAA64F5D6A31014911DB@FITMS201MB.tcad.telia.se> In-Reply-To: <07B14A720C46C344AC96AAA64F5D6A31014911DB@FITMS201MB.tcad.telia.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org jouni.korhonen@teliasonera.com wrote: > > Very roughly put I would assume that this kind of approach of "guiding" > handover decision requires > a mechanism to inform the mobility management point about networks & > network identities available > to MN even if the networks belong to different administrative domains. A Alternatively, the MN itself may discover those networks. Indeed, one could argue that MN is in the best position to discover. > mechanism to signal back > the home network preferences of the networks before the handover takes > place (or immediately after > the handover) in the MN is needed. Also a possibility to suggest a > handover from network side > between binding updates would be a definitive plus. I did not understand the last sentence. > > Would this group be interested in this topic from the angle I described > it? I think it is definitely worthwhile to discuss this, and even more useful to write up the problems clearly. Related to this network-controlled handovers is the handovers across different provider domains. Would a provider permit optimizations in such cases? What agreements exist today? Are they readily applicable to IP mobile networks? Regards, -Rajeev > > Cheers, > Jouni > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Jul 22 04:26:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvsry-0000yV-0D; Fri, 22 Jul 2005 04:26:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvsrv-0000w4-UL for mobopts@megatron.ietf.org; Fri, 22 Jul 2005 04:26:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22689 for ; Fri, 22 Jul 2005 04:26:53 -0400 (EDT) From: jouni.korhonen@teliasonera.com Received: from floor.dave.sonera.fi ([131.177.130.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvtM7-0001q3-6W for mobopts@irtf.org; Fri, 22 Jul 2005 04:58:08 -0400 Received: from floor.dave.sonera.fi (localhost [127.0.0.1]) by floor.dave.sonera.fi (Sendmail) with ESMTP id j6M8Ql6V026244 for ; Fri, 22 Jul 2005 11:26:47 +0300 (EEST) Received: from FITMS201MB.tcad.telia.se (fitms201ca.tcad.telia.se [131.177.121.203]) by floor.dave.sonera.fi (Sendmail) with ESMTP id j6M8QjtD026235 for ; Fri, 22 Jul 2005 11:26:47 +0300 (EEST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6617.27 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: [Mobopts] New topics for the RG Date: Fri, 22 Jul 2005 11:26:45 +0300 Message-ID: <07B14A720C46C344AC96AAA64F5D6A310149123E@FITMS201MB.tcad.telia.se> Thread-Topic: [Mobopts] New topics for the RG Thread-Index: AcWOOyoEEre243irTUiZeKndoTYEpAAVUCQA To: X-Spam-Score: 2.7 (++) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Rajeev, See comments inline. Cheers, Jouni=20 > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]=20 > Sent: 22. hein=E4kuuta 2005 0:28 > To: Korhonen, Jouni /TeliaSonera Finland Oyj > Cc: mobopts@irtf.org > Subject: Re: [Mobopts] New topics for the RG >=20 >=20 >=20 > jouni.korhonen@teliasonera.com wrote: >=20 > >=20 > > Very roughly put I would assume that this kind of approach=20 > of "guiding" > > handover decision requires > > a mechanism to inform the mobility management point about networks & > > network identities available > > to MN even if the networks belong to different=20 > administrative domains. A >=20 > Alternatively, the MN itself may discover those networks. > Indeed, one could argue that MN is in the best position to > discover. I meant.. MN does discover the surrounding networks but it might not have the best/latest knowledge which of those networks are available (or preferred/prioritized/unavailable) from the home network roaming administration point of view. Thus MN need to consult home network (or some local delegated entity) in order to learn home network preferences. =20 > > mechanism to signal back > > the home network preferences of the networks before the=20 > handover takes > > place (or immediately after > > the handover) in the MN is needed. Also a possibility to suggest a > > handover from network side > > between binding updates would be a definitive plus. >=20 > I did not understand the last sentence. For example if the exchange of network information is somehow tied to other mobility signaling (e.g. to MIP6 BUs and BAs) there should also be a way for the home network mobility management entity to send the MN new network roaming preferences without waiting for a request from the MN (after the first initial request from the MN). > > Would this group be interested in this topic from the angle=20 > I described > > it? >=20 > I think it is definitely worthwhile to discuss this, and even more > useful to write up the problems clearly. I could prepare few slides and present some of my thought during the Monday evening slot. > Related to this network-controlled handovers is the handovers > across different provider domains. Would a provider permit > optimizations in such cases? What agreements exist today? Are > they readily applicable to IP mobile networks? I'm rather skeptical that providers would allow optimizations across provider domains -- having worked on WLAN roaming. But this could change if there were good & secure methods/protocols to do such optimizations across provider domains. >=20 > Regards, >=20 > -Rajeev >=20 >=20 > >=20 > > Cheers, > > Jouni > >=20 >=20 >=20 _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Jul 22 10:58:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvyz5-0005ge-Mc; Fri, 22 Jul 2005 10:58:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvyz2-0005fR-Nq for mobopts@megatron.ietf.org; Fri, 22 Jul 2005 10:58:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22364 for ; Fri, 22 Jul 2005 10:58:38 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvzTI-0000Zp-ME for mobopts@irtf.org; Fri, 22 Jul 2005 11:29:57 -0400 Message-ID: <020601c58ecd$d4cb72b0$596015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Rajeev Koodli" , "Narayanan Vidya-CVN065" References: <1B631E11D496D711BB2800065BFCB6A11B7A71EB@il02exm13> <42DFE78C.2060707@iprg.nokia.com> Date: Fri, 22 Jul 2005 07:58:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, Venkitaraman Narayanan-CNV002 , mobopts@irtf.org Subject: [Mobopts] Re: [Mipshop] RE: Review of draft-vidya-mipshop-handover-keys-aaa -00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org > > In fact, one of the things that will be a problem for us if > > HK derivation is made dependent on the EAP method is 802.11r - > > if 11r is adopted as being proposed now with evolving keys, > > the MN will not perform a full EAP method upon handoff - as > > long as it is handing off under the same R0 entity, it will > > only change its PMK-R1/PMK-R2 - hence, the exchange will > > not reach the AAA server. So, unless the HK itself evolves > > the same way (which means we now rely on a hierarchy of ARs, > > with SAs between them, etc.) or we make an assumption that > > PMK-R0 will always change upon inter-subnet handoffs, it > > becomes a problem for us. So, I am not entirely sure how > > we can make L3 handover keys applicable for heterogeneous > > L2 handoffs (whether L2 employs 802.11i/PANA/802.11r/etc) if > > the L3 HKs are dependent on L2 authentication. > > > > Creating a shared secret between MN and PAR can be done > assuming some L2 access (or L3 in the SEND-based handover > key derivation draft) authentication method is used, right? > This should be the focus of the draft IMO. > > Assuming so, which L3 handover key are you referring to that > would be needed across different L2 access types? > If a MN did .11i, created a shared secret (Sk-L3) for L3 to use, > moved over to a different L2, and then did method auth-Y, why > is the applicability of Sk-L3 on the new L2 important during > a handover? > Yes, the MN will have a different IP address on .16 and .11 anyway, so it should have different handover keys, since the address is acting as the key name. jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Jul 22 11:03:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvz3Z-0006Oj-KK; Fri, 22 Jul 2005 11:03:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvz3Y-0006OZ-2L for mobopts@megatron.ietf.org; Fri, 22 Jul 2005 11:03:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22652 for ; Fri, 22 Jul 2005 11:03:17 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvzXm-0000kJ-A7 for mobopts@irtf.org; Fri, 22 Jul 2005 11:34:36 -0400 Message-ID: <020e01c58ece$7b855530$596015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Narayanan Vidya-CVN065" , "'Rajeev Koodli'" References: <1B631E11D496D711BB2800065BFCB6A11B7A7200@il02exm13> Date: Fri, 22 Jul 2005 08:03:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, Venkitaraman Narayanan-CNV002 , mobopts@irtf.org Subject: [Mobopts] Re: [Mipshop] RE: Review of draft-vidya-mipshop-handover-keys-aaa -00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org > I am confused by this. The L3 handover key I am referring to is the shared secret between MN and AR. If we extended an EAP method to derive this key, when the EAP authenticator is not the same as the AR, we have some issues in getting the key to the AR without breaking some of the Housley criteria. It is not that we need a new key as a result of a new L2 auth method, but it is the process of deriving a key with the next AR may now need to be different, due to the > Suppose that the AAA server pushes the key directly to the AR using some protocol. That means the AAA server and the AR need to share an end-to-end security association, that the key must be encrypted in transit, and only the AR can decrypt. Now, suppose that, instead of routing the key directly to the AR, it is routed through the NAS instead. If the key is end-to-end encrypted, how does that violate the Housley critera? The NAS is acting like a proxy AAA server and doesn't ever get to look at the key. Am I missing something? jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Jul 22 11:37:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvzaM-0006Q0-Ab; Fri, 22 Jul 2005 11:37:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvzaK-0006Mv-9s for mobopts@megatron.ietf.org; Fri, 22 Jul 2005 11:37:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26560 for ; Fri, 22 Jul 2005 11:37:09 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw04Z-0002Dd-HB for mobopts@irtf.org; Fri, 22 Jul 2005 12:08:29 -0400 Message-ID: <036f01c58ed3$365f8340$596015ac@dcml.docomolabsusa.com> From: "James Kempf" To: , References: <07B14A720C46C344AC96AAA64F5D6A310149123E@FITMS201MB.tcad.telia.se> Subject: Re: [Mobopts] New topics for the RG Date: Fri, 22 Jul 2005 08:37:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org I'm rather skeptical that providers would allow optimizations across provider domains -- having worked on WLAN roaming. But this could change if there were good & secure methods/protocols to do such optimizations across provider domains. jak>> Yes, I agree. There are also business issues involved, especially if the providers are competitors. jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Jul 22 12:16:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw0Co-00072q-UI; Fri, 22 Jul 2005 12:16:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw0Ci-00071k-BQ for mobopts@megatron.ietf.org; Fri, 22 Jul 2005 12:16:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29460 for ; Fri, 22 Jul 2005 12:16:49 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw0gy-0003mi-7s for mobopts@irtf.org; Fri, 22 Jul 2005 12:48:09 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j6MGQ2lZ007791 for ; Fri, 22 Jul 2005 09:26:02 -0700 (MST) Received: from il02exm13.corp.mot.com (il02exm13.corp.mot.com [10.0.111.24]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j6MGM7VT018673 for ; Fri, 22 Jul 2005 11:22:07 -0500 (CDT) Received: by il02exm13 with Internet Mail Service (5.5.2657.72) id ; Fri, 22 Jul 2005 11:16:38 -0500 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A720E@il02exm13> From: Narayanan Vidya-CVN065 To: "'James Kempf'" , "'Rajeev Koodli'" Date: Fri, 22 Jul 2005 11:16:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 2.4 (++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, Venkitaraman Narayanan-CNV002 , mobopts@irtf.org Subject: [Mobopts] RE: [Mipshop] RE: Review of draft-vidya-mipshop-handover-keys-aaa -00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org > > > > Suppose that the AAA server pushes the key directly to the AR > using some protocol. That means the AAA server and the AR > need to share an end-to-end security association, that the > key must be encrypted in transit, and only the AR can decrypt. > Yes, an SA with the AR is required for the protocol. > Now, suppose that, instead of routing the key directly to the > AR, it is routed through the NAS instead. If the key is > end-to-end encrypted, how does that violate the Housley > critera? The NAS is acting like a proxy AAA server and > doesn't ever get to look at the key. > I thought that the idea of coupling this with network access is (also) so that you only need an SA between the AAA server and the NAS. If you also have an SA with the AR, this is feasible. But, here are some problems I see with this approach: - the NAS is potentially different upon every handoff; depending on the scenario, the NAS is an AP, an 802.16 BS, a PAA located at the AR, a PAA separate from the AR, etc. So, this means, the NAS may be doing 802.11i, 802.11r, 802.16 or PANA. Even though it is still EAP in all these cases, I am not sure how a common design can solve this - for e.g., once the NAS gets an EAP-AMSK (that is supposed to serve as the HK), how does it get that to the AR and the corresponding keying material to the MN - that protocol, if implemented using PANA, is unique to PANA and won't be available when the NAS is not a PAA, but an 802.1x authenticator. This is why I was asking if you envision a second EAP-method exchange with a PAA after 802.1x is done, just to derive HKs. Or, I must be missing something. - Along the same lines, I especially see a problem when 802.11r is used - in this case, there may not be an EAP exchange when the MN hands off. What happens then? - This method, as Rajeev pointed out, puts HK derivation in the critical handoff path. That seems unncessary. The MN should be able to hand off with only the essential steps and nothing else. Vidya _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Jul 22 17:30:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw56b-0004Vw-Pu; Fri, 22 Jul 2005 17:30:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw56a-0004VV-Q3 for mobopts@megatron.ietf.org; Fri, 22 Jul 2005 17:30:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29159 for ; Fri, 22 Jul 2005 17:30:49 -0400 (EDT) Received: from [12.42.230.245] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dw5as-0000zB-So for mobopts@irtf.org; Fri, 22 Jul 2005 18:02:12 -0400 Received: from localhost (tarij-11.tari.toshiba.com [172.30.24.43]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id j6MLUStS069496; Fri, 22 Jul 2005 17:30:29 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Fri, 22 Jul 2005 17:05:53 -0400 To: jouni.korhonen@teliasonera.com Subject: Re: [Mobopts] New topics for the RG Message-ID: <20050722210553.GD10960@steelhead> References: <07B14A720C46C344AC96AAA64F5D6A310149123E@FITMS201MB.tcad.telia.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <07B14A720C46C344AC96AAA64F5D6A310149123E@FITMS201MB.tcad.telia.se> User-Agent: Mutt/1.5.9i From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 23 X-Spam-Score: 2.4 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: rajeev@iprg.nokia.com, mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org On Fri, Jul 22, 2005 at 11:26:45AM +0300, jouni.korhonen@teliasonera.com wrote: > > > Related to this network-controlled handovers is the handovers > > across different provider domains. Would a provider permit > > optimizations in such cases? What agreements exist today? Are > > they readily applicable to IP mobile networks? > > I'm rather skeptical that providers would allow optimizations > across provider domains -- having worked on WLAN roaming. But > this could change if there were good & secure methods/protocols > to do such optimizations across provider domains. > The following I-Ds address inter-domain handover issues including performance and security: - draft-ohba-mobopts-mpa-framework-01.txt - draft-ohba-mobopts-mpa-implementation-01.txt I'd appreciate any feedback (positive/negative) on this. Regards, Yoshihiro Ohba _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Jul 22 20:48:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw8Bb-0006KR-RL; Fri, 22 Jul 2005 20:48:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw8BZ-0006Ik-Mt; Fri, 22 Jul 2005 20:48:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15249; Fri, 22 Jul 2005 20:48:11 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw8fv-0008Nl-2E; Fri, 22 Jul 2005 21:19:35 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6N0G6c04437; Fri, 22 Jul 2005 17:16:06 -0700 X-mProtect: <200507230016> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14169.americas.nokia.com (172.18.141.69, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpduNBrsW; Fri, 22 Jul 2005 17:16:04 PDT Message-ID: <42E193B7.2030800@iprg.nokia.com> Date: Fri, 22 Jul 2005 17:47:51 -0700 From: Rajeev Koodli 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: "mobopts@irtf.org" , "'mipshop@ietf.org'" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: gabriel montenegro Subject: [Mobopts] Combined MobOpts and MIPSHOP meeting on Tuesday 0900 - 10000 X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hello folks, both the groups were scheduled during the same slot. So, we (Gabriel and myself) have decided to have a combined 1 hour meeting. The agenda for Tuesday is as follows: 1. Mobile IPv6 Route Optimization enhancements Christian Vogt, draft-irtf-mobopts-ro-enhancements-00/01.txt, 10 minutes 2. Handover Control Function Based Handover for Mobile IPv6 Yong, draft-cui-mobopts-hcf-wlan-00.txt, 10 minutes 3. Network-controlled fast handovers Telemaco Melia, draft-melia-mobopts-niho-fmip-01.txt, 10 minutes 4. Mobile IPv6 Fast Handovers for 3G CDMA Networks Hidetoshi Yokota, draft-yokota-mipshop-3gfh-00.txt 15 minutes 5. Mobile IPv6 Fast Handovers over IEEE 802.16e Networks Heejin Jang, draft-jang-mipshop-fh80216e-00.txt 15 min Regards, -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Jul 22 20:52:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw8Fq-00087f-IV; Fri, 22 Jul 2005 20:52:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw8Fo-000862-DN; Fri, 22 Jul 2005 20:52:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15578; Fri, 22 Jul 2005 20:52:34 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw8k8-0008Vi-MZ; Fri, 22 Jul 2005 21:23:58 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6N0KRh08905; Fri, 22 Jul 2005 17:20:27 -0700 X-mProtect: <200507230020> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14169.americas.nokia.com (172.18.141.69, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdr6J2pp; Fri, 22 Jul 2005 17:20:26 PDT Message-ID: <42E194BC.3010601@iprg.nokia.com> Date: Fri, 22 Jul 2005 17:52:12 -0700 From: Rajeev Koodli 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: Rajeev Koodli Subject: Re: [Mobopts] Combined MobOpts and MIPSHOP meeting on Tuesday 0900 - 10000 References: <42E193B7.2030800@iprg.nokia.com> In-Reply-To: <42E193B7.2030800@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: "'mipshop@ietf.org'" , gabriel montenegro , "mobopts@irtf.org" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Note: This is an additional slot for both the groups. -Rajeev Rajeev Koodli wrote: > > > Hello folks, > > both the groups were scheduled during the same slot. > So, we (Gabriel and myself) have decided to have a > combined 1 hour meeting. > > The agenda for Tuesday is as follows: > > 1. Mobile IPv6 Route Optimization enhancements > Christian Vogt, draft-irtf-mobopts-ro-enhancements-00/01.txt, > 10 minutes > > 2. Handover Control Function Based Handover for Mobile IPv6 > Yong, draft-cui-mobopts-hcf-wlan-00.txt, > 10 minutes > > 3. Network-controlled fast handovers > Telemaco Melia, draft-melia-mobopts-niho-fmip-01.txt, > 10 minutes > > 4. Mobile IPv6 Fast Handovers for 3G CDMA Networks > Hidetoshi Yokota, draft-yokota-mipshop-3gfh-00.txt > 15 minutes > > 5. Mobile IPv6 Fast Handovers over IEEE 802.16e Networks > Heejin Jang, draft-jang-mipshop-fh80216e-00.txt > 15 min > > > Regards, > > -Rajeev > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Sat Jul 23 03:40:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwEcK-0000A1-Tp; Sat, 23 Jul 2005 03:40:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwEcJ-00008Q-9s for mobopts@megatron.ietf.org; Sat, 23 Jul 2005 03:40:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09133 for ; Sat, 23 Jul 2005 03:40:12 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwF6h-0003je-OP for mobopts@irtf.org; Sat, 23 Jul 2005 04:11:40 -0400 Message-ID: <054f01c58f59$b8e58cc0$596015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Narayanan Vidya-CVN065" , "'Rajeev Koodli'" References: <1B631E11D496D711BB2800065BFCB6A11B7A720E@il02exm13> Date: Sat, 23 Jul 2005 00:39:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, Venkitaraman Narayanan-CNV002 , mobopts@irtf.org Subject: [Mobopts] Re: [Mipshop] RE: Review of draft-vidya-mipshop-handover-keys-aaa -00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Vidya, > > Now, suppose that, instead of routing the key directly to the > > AR, it is routed through the NAS instead. If the key is > > end-to-end encrypted, how does that violate the Housley > > critera? The NAS is acting like a proxy AAA server and > > doesn't ever get to look at the key. > > > > > I thought that the idea of coupling this with network access is (also) so that you only need an SA between the AAA server and the NAS. If you also have an SA with the AR, this is feasible. But, here are some problems I see with this approach: > No, the idea is to minimize the different protocols on the host, and to align the signaling for the handover key exchange with network access authentication. There's no way to get around having the AAA-AR SA if you want to do key exchange with it. > - the NAS is potentially different upon every handoff; depending on the scenario, the NAS is an AP, an 802.16 BS, a PAA located at the AR, a PAA separate from the AR, etc. So, this means, the NAS may be doing 802.11i, 802.11r, 802.16 or PANA. Even though it is still EAP in all these cases, I am not sure how a common design can solve this - for e.g., once the NAS gets an EAP-AMSK (that is supposed to serve as the HK), how does it get that to the AR and the corresponding keying material to the MN - that protocol, if implemented using PANA, is unique to PANA and won't be available when the NAS is not a PAA, but an 802.1x authenticator. This is why I was asking if you envision a second EAP-method exchange with a PAA after 802.1x is done, just to derive HKs. Or, I must be missing something. > I think I see your point. Your point is that the EAP is end to end, host to AAA server, and that the EAP-AMSK will end up at the NAS when it needs to be at the AR. Here is a possibility. The pAR asks the NAS for the key when the FBU arrives from the MN the first time the MN hands over. If the NAS is co-located with the pAR, then this is just an API call within the router, and fast. If the NAS is at an AP (such as 802.11) then it would require a Radius transaction, which will be slow and undesirable since it is part of the handover path. But note that this need only occur the first time the MN hands over. Since nAR also handles the FBU and the MN must authenticate through the NAS on nAP first in order to be able to send the FBU (in which case the new EAP-AMSK will be at the NAS prior to the FBU being sent), nAR can ask the NAS for the MN's handover key when the FBU goes by. This need not delay the FBU, since nAR doesn't need the handover key for processing it, because the FBU is going to pAR. Later, when the MN hands over from nAR, the key will already be there when the FBU arrives from the yet newer AR. There are also a couple other ways the NAS could get the key to the first AR prior to the first handover. Unfortunately, Radius isn't one of them, because Radius doesn't allow push. Diameter would work, however. Also, if the NAS sends some kind of COPS or SNMP message to the AR to unblock Internet routing, that would provide another vehicle. The AR could also ask for the key using Radius after performing the first NS/NA (aka ARP) to get the MN's IPv6 address to link address mapping, if it doesn't have the key, or upon reception of an outbound packet with no neighbor cache entry for the IPv6 address, or upon reception of an RS from the MN with a SLLAO. Triggering on link address to IPv6 address mapping would probably be best, because it allows the AR to establish the linking between the address as the name for the key and the key itself. Also, I think that the extension in this case would be for Radius not EAP (sorry about that) because EAP is end to end and the host isn't getting the key. The Radius extension would work for both the link authentication and PANA case. In the link authentication case, the handover key would end up on the NAS, in the PANA case, it would end up on the PAA. In either case, the AR would need to know the relevant gateway to ask, of course, but the same Radius handover key extension could be used to ask the router. > - Along the same lines, I especially see a problem when 802.11r is used - in this case, there may not be an EAP exchange when the MN hands off. What happens then? I think preauthentication is an option for 802.11r. If preauthentication is used, the key can be distributed to the NASes during the preauthenication phase. The nAR can fetch the key from its local NAS when the FBU for pAR goes by, or on NS/NA if its the first time, as above. > > - This method, as Rajeev pointed out, puts HK derivation in the critical handoff path. That seems unncessary. The MN should be able to hand off with only the essential steps and nothing else. > Only for some specific and very limited cases (i.e. if the pAR needs to ask the NAS for the key when the FBU arrives on the very first handover in the access network). And if the bootstrapping procedure using NS/NA described above is used, then it need not even happen then. How does that sound? jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jul 25 14:05:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx7KT-00061E-9Y; Mon, 25 Jul 2005 14:05:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx7KS-000619-A3 for mobopts@megatron.ietf.org; Mon, 25 Jul 2005 14:05:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11302 for ; Mon, 25 Jul 2005 14:05:27 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx7pD-0003Gy-6k for mobopts@irtf.org; Mon, 25 Jul 2005 14:37:24 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id j6PIH8jA005896 for ; Mon, 25 Jul 2005 11:17:08 -0700 (MST) Received: from il02exm13.corp.mot.com (il02exm13.corp.mot.com [10.0.111.24]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j6PI9KwC016560 for ; Mon, 25 Jul 2005 13:09:21 -0500 (CDT) Received: by il02exm13 with Internet Mail Service (5.5.2657.72) id ; Mon, 25 Jul 2005 13:05:04 -0500 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A721C@il02exm13> From: Narayanan Vidya-CVN065 To: "'James Kempf'" , "'Rajeev Koodli'" Date: Mon, 25 Jul 2005 13:05:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 2.4 (++) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, Venkitaraman Narayanan-CNV002 , mobopts@irtf.org Subject: [Mobopts] RE: [Mipshop] RE: Review of draft-vidya-mipshop-handover-keys-aaa -00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org James, > > > > No, the idea is to minimize the different protocols on the > host, and to align the signaling for the handover key > exchange with network access authentication. There's no way > to get around having the AAA-AR SA if you want to do key > exchange with it. > I am not sure what it really means to support an additional protocol on the host. We are talking about support for the same functionality regardless of whether it is an extension of an existing protocol or a new one. The fact that it is running on a different UDP port should not be a factor in my mind. Now, if there is replication of functionality between two protocols running on a host, I see your point of re-use. But, in this case, I don't see replication of functionality. I don't see an incentive to align the signaling for handover key exchange with network access - if anything it seems to be complicating the design due to its dependence on different types of L2 protocols. If there is a way to avoid having the AAA-AR SA, I can see that being an incentive - but, that seems impossible - so, I am still not seeing the point. > > > I think I see your point. Your point is that the EAP is end > to end, host to AAA server, and that the EAP-AMSK will end up > at the NAS when it needs to be at the AR. > Yes. > Here is a possibility. The pAR asks the NAS for the key when > the FBU arrives from the MN the first time the MN hands over. > If the NAS is co-located with the pAR, then this is just an > API call within the router, and fast. If the NAS is at an AP > (such as 802.11) then it would require a Radius transaction, > which will be slow and undesirable since it is part of the > handover path. But note that this need only occur the first > time the MN hands over. Since nAR also handles the FBU and > the MN must authenticate through the NAS on nAP first in > order to be able to send the FBU (in which case the new > EAP-AMSK will be at the NAS prior to the FBU being sent), > nAR can ask the NAS for the MN's handover key when the FBU > goes by. This need not delay the FBU, since nAR doesn't need > the handover key for processing it, because the FBU is going > to pAR. Later, when the MN hands over from nAR, the key will > already be there when the FBU arrives from the yet newer AR. > Certainly, we can come up with a way of pushing the key from the NAS to the AR - the thing I am struggling with is that this seems more complex to me than the AR itself getting the key in the first place. We now require different NAS-es - APs, 802.16 BSs, PAAs, etc. to support this functionality. There is not much difference in what the MN does - instead of requesting a handover key through the NAS, it requests it from the AR with which it intends to share it. Also, why should we require a L2 entity to cache the HKs for an MN? 802.11 and 802.16 seem to be having enough key caching problems on their own for pre-authentication and predictive handoffs, etc. So, I don't think it makes sense to say that the NAS needs to store the key until the AR asks for it. Also, the NAS probably doesn't know anything about the lifetime of the key (nor should it) - so, how long does it cache it if the AR doesn't ask for the key for a long time? > There are also a couple other ways the NAS could get the key > to the first AR prior to the first handover. Unfortunately, > Radius isn't one of them, because Radius doesn't allow push. > Diameter would work, however. Also, if the NAS sends some > kind of COPS or SNMP message to the AR to unblock Internet > routing, that would provide another vehicle. The AR could > also ask for the key using Radius after performing the first > NS/NA (aka ARP) to get the MN's IPv6 address to link address > mapping, if it doesn't have the key, or upon reception of an > outbound packet with no neighbor cache entry for the IPv6 > address, or upon reception of an RS from the MN with a SLLAO. > Triggering on link address to IPv6 address mapping would > probably be best, because it allows the AR to establish the > linking between the address as the name for the key and the > key itself. > > Also, I think that the extension in this case would be for > Radius not EAP (sorry about that) because EAP is end to end > and the host isn't getting the key. The Radius extension > would work for both the link authentication and PANA case. In > the link authentication case, the handover key would end up > on the NAS, in the PANA case, it would end up on the PAA. In > either case, the AR would need to know the relevant gateway > to ask, of course, but the same Radius handover key extension > could be used to ask the router. > I see the same issues on any of these approaches. > > - Along the same lines, I especially see a problem when 802.11r is > > used - > in this case, there may not be an EAP exchange when the MN > hands off. What happens then? > > I think preauthentication is an option for 802.11r. If > preauthentication is used, the key can be distributed to the > NASes during the preauthenication phase. The nAR can fetch > the key from its local NAS when the FBU for pAR goes by, or > on NS/NA if its the first time, as above. > So, now we have to define something different for an 802.11r like scenario. Pre-authentication is not a given for all systems. It comes with its own set of problems and people are still trying to see if it makes sense or not. It doesn't seem like we can have a general solution here. Also, what if later on we wanted to use this protocol over 802.11s? They do EAP in a slightly different manner and IEEE is still flushing out details. Regardless of the L2 protocol, people use IP at L3 to be able to leverage the standards and protocols. So, in general, I view L3 independence of L2 as a benefit. > > > > - This method, as Rajeev pointed out, puts HK derivation in the > > critical > handoff path. That seems unncessary. The MN should be able to > hand off with only the essential steps and nothing else. > > > > Only for some specific and very limited cases (i.e. if the > pAR needs to ask the NAS for the key when the FBU arrives on > the very first handover in the access network). And if the > bootstrapping procedure using NS/NA described above is used, > then it need not even happen then. > > How does that sound? If we were to design the protocol and architecture with a requirement that states "MUST be tied to network access authentication", I can see having approaches like this. But, the requirements we designed against were more like "MUST be simple" and "MUST be able to use the MN-AAA secret that is already present for EAP purposes" and this in my mind does not lead to an approach tied to network access. These approaches seem to be adding functionality to an entity (NAS) that does not really need to be part of this protocol. And, at least up to this point, I am not able to see what it buys. This will be a useful discussion to have in Paris. I will bring it up in the presentation so that we can discuss it further. Vidya _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jul 25 20:59:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxDn5-00015y-0c; Mon, 25 Jul 2005 20:59:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxDn3-00012D-Jm for mobopts@megatron.ietf.org; Mon, 25 Jul 2005 20:59:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11306 for ; Mon, 25 Jul 2005 20:59:24 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxEI0-0007kb-VZ for mobopts@irtf.org; Mon, 25 Jul 2005 21:31:25 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6Q0SAc07304 for ; Mon, 25 Jul 2005 17:28:10 -0700 X-mProtect: <200507260028> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14169.americas.nokia.com (172.18.141.69, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdFR8ZPR; Mon, 25 Jul 2005 17:28:09 PDT Message-ID: <42E58AD8.6080803@iprg.nokia.com> Date: Mon, 25 Jul 2005 17:59:04 -0700 From: Rajeev Koodli 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: "mobopts@irtf.org" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [Mobopts] MIPv4 Route Optimization X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hello folks, I have worked on a draft, using MIP6 RR. here is the announcement.. http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg06124.html Comments are welcome! Thanks, -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jul 26 04:39:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxKyk-0005f6-1L; Tue, 26 Jul 2005 04:39:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxKyi-0005ey-1V for mobopts@megatron.ietf.org; Tue, 26 Jul 2005 04:39:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28339 for ; Tue, 26 Jul 2005 04:39:54 -0400 (EDT) Received: from cluster-d.mailcontrol.com ([217.69.20.190] helo=rly24d.srv.mailcontrol.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxLTi-00039H-Cr for mobopts@irtf.org; Tue, 26 Jul 2005 05:11:59 -0400 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly24d.srv.mailcontrol.com (MailControl) with SMTP id j6Q8dj7S013055 for ; Tue, 26 Jul 2005 09:39:45 +0100 Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 6a90_090ae73e_fdb1_11d9_8a30_0030482aac25; Tue, 26 Jul 2005 10:41:18 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.2) with ESMTP id 2005072610394162-137280 ; Tue, 26 Jul 2005 10:39:41 +0200 Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de for mobopts@irtf.org; Tue, 26 Jul 2005 10:41:21 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 26 Jul 2005 10:37:11 +0200 Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4F31EB68@lan-ex-01.panasonic.de> Thread-Topic: I-D ACTION:draft-weniger-rota-00.txt (fwd) Thread-Index: AcWRvTdGaSwN8rgoQ0OnYIP1HV5URg== To: From: "Kilian Weniger" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-05-01-05 (www.mailcontrol.com) X-Spam-Score: 2.4 (++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Subject: [Mobopts] I-D ACTION:draft-weniger-rota-00.txt (fwd) X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi all, I'd like to request comments for the I-D "draft-weniger-rota-00.txt", which describes an optional extension to Mobile IPv6 providing both location privacy (hiding CoA from CN) and route optimization at the same time. The main scenario addressed by this I-D is MN-to-MN communication, where the use of standard bi-directional tunneling to achieve location privacy results in lengthy routes in many cases (due to routing over two HAs).=20 The solution does not require visited network support, change of MN's home link, or changes to the MIPv6 ND packet interception operations. Security issues are discussed as well. Thanks, Kilian ---- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Route Optimization and Location Privacy using Tunneling Agents (ROTA) Author(s) : K. Weniger, T. Aramaki Filename : draft-weniger-rota-00.txt Pages : 42 Date : 2005-7-12 =09 Mobile IPv6 can either provide route optimization or location privacy from CN by using Bi-directional Tunneling mode. Especially when mobile node is far away from home or when correspondent node is mobile as well, the route in Bi-directional Tunneling mode is far from optimal. This memo describes an optional extension to Mobile IPv6 providing location privacy and route optimization at the same time. To achieve this, the overlay route in Mobile IPv6 Bi- directional Tunneling mode is optimized by switching tunnel end- points to so-called Tunneling Agents in an on-demand manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-weniger-rota-00.txt ------------------------------------------------------------ Dr.-Ing. Kilian Weniger Panasonic R&D Center Germany GmbH, Monzastr. 4c, 63225 Langen, Germany phone: +49 (0)6103 766 137 fax: +49 (0)6103 766 166 e-mail: kilian.weniger@eu.panasonic.com ------------------------------------------------------------ _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jul 26 05:50:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxM4f-0004XX-5B; Tue, 26 Jul 2005 05:50:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxM4d-0004X3-Ij for mobopts@megatron.ietf.org; Tue, 26 Jul 2005 05:50:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02453 for ; Tue, 26 Jul 2005 05:50:05 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxMZe-0005I5-E8 for mobopts@irtf.org; Tue, 26 Jul 2005 06:22:11 -0400 Message-ID: <032001c591c7$63a515d0$626015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Narayanan Vidya-CVN065" , "'Rajeev Koodli'" References: <1B631E11D496D711BB2800065BFCB6A11B7A721C@il02exm13> Date: Tue, 26 Jul 2005 02:49:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, Venkitaraman Narayanan-CNV002 , mobopts@irtf.org Subject: [Mobopts] Re: [Mipshop] RE: Review of draft-vidya-mipshop-handover-keys-aaa -00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org > I am not sure what it really means to support an additional protocol on the host. We are talking about support for the same functionality regardless of whether it is an extension of an existing protocol or a new one. The fact that it is running on a different UDP port should not be a factor in my mind. Now, if there is replication of functionality between two protocols running on a host, I see your point of re-use. But, in this case, I don't see replication of functionality. I don't see an incentive to align the signaling for handover key exchange with network access - if anything it seems to be complicating the design due to its dependence on different types of L2 protocols. If there is a way to avoid having the AAA-AR SA, I can see that being an incentive - but, that seems impossible - so, I am still not seeing the point. > Well, we disagree here. The whole point of this work is to leverage existing AAA infrastructure, so the more you can leverage, the better things become. Making up a whole new protocol just to do key distribution reduces the attraction, since it must be deployed. Of course, mods to AAA protocols must be deployed too, but it seems less of a delta. > Certainly, we can come up with a way of pushing the key from the NAS to the AR - the thing I am struggling with is that this seems more complex to me than the AR itself getting the key in the first place. We now require different NAS-es - APs, 802.16 BSs, PAAs, etc. to support this functionality. There is not much difference in what the MN does - instead of requesting a handover key through the NAS, it requests it from the AR with which it intends to share it. Also, why should we require a L2 entity to cache the HKs for an MN? 802.11 and 802.16 seem to be having enough key caching problems on their own for pre-authentication and predictive handoffs, etc. So, I don't think it makes sense to say that the NAS needs to store the key until the AR asks for it. Also, the NAS probably doesn't know anything about the lifetime of the key (nor should it) - so, how long does it cache it if the AR doesn't ask for the key for a long time? > > Seems like you're convinced on having a new protocol, no sense in continuing the discussion. jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jul 26 09:27:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxPSf-0005eL-AA; Tue, 26 Jul 2005 09:27:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxPSY-0005dX-1J for mobopts@megatron.ietf.org; Tue, 26 Jul 2005 09:27:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17581 for ; Tue, 26 Jul 2005 09:27:00 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxPxa-00047e-Vf for mobopts@irtf.org; Tue, 26 Jul 2005 09:59:08 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id j6QDYEfq023314 for ; Tue, 26 Jul 2005 06:34:14 -0700 (MST) Received: from il02exm13.corp.mot.com (il02exm13.corp.mot.com [10.0.111.24]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j6QDV8BS026451 for ; Tue, 26 Jul 2005 08:31:09 -0500 (CDT) Received: by il02exm13 with Internet Mail Service (5.5.2657.72) id ; Tue, 26 Jul 2005 08:26:51 -0500 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A7226@il02exm13> From: Narayanan Vidya-CVN065 To: "'James Kempf'" , "'Rajeev Koodli'" Date: Tue, 26 Jul 2005 08:26:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 2.4 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Gerardo Giaretta , Julien Bournelle , mipshop@ietf.org, Venkitaraman Narayanan-CNV002 , mobopts@irtf.org Subject: [Mobopts] RE: [Mipshop] RE: Review of draft-vidya-mipshop-handover-keys-aaa -00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi James, > > > Certainly, we can come up with a way of pushing the key > from the NAS > > to > the AR - the thing I am struggling with is that this seems > more complex to me than the AR itself getting the key in the > first place. We now require different NAS-es - APs, 802.16 > BSs, PAAs, etc. to support this functionality. There is not > much difference in what the MN does - instead of requesting a > handover key through the NAS, it requests it from the AR with > which it intends to share it. Also, why should we require a > L2 entity to cache the HKs for an MN? 802.11 and 802.16 seem > to be having enough key caching problems on their own for > pre-authentication and predictive handoffs, etc. So, I don't > think it makes sense to say that the NAS needs to store the > key until the AR asks for it. Also, the NAS probably doesn't > know anything about the lifetime of the key (nor should it) - > so, how long does it cache it if the AR doesn't ask for the > key for a long time? > > > > > > Seems like you're convinced on having a new protocol, no > sense in continuing the discussion. > I think this is certainly a useful discussion to have. I am not convinced on having a new protocol - just that I am not yet convinced that the simplest way to do this is to tie it to network access. But, I'd like to understand the issues and pros and cons of each approach better, so that the end result we provide the WG with is the desirable one. This discussion has been very useful to us in helping us think through the approaches more. Lets capture these issues and talk through them in Paris. Thanks, Vidya _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 27 17:52:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxtp2-0006ot-U4; Wed, 27 Jul 2005 17:52:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxtp0-0006nY-Su for mobopts@megatron.ietf.org; Wed, 27 Jul 2005 17:52:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05760 for ; Wed, 27 Jul 2005 17:52:11 -0400 (EDT) Received: from rome.ucdavis.edu ([169.237.104.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxuKI-0004bE-Rr for mobopts@irtf.org; Wed, 27 Jul 2005 18:24:38 -0400 Received: from andrena.ucdavis.edu (andrena.ucdavis.edu [169.237.104.181]) by rome.ucdavis.edu (8.13.3/8.13.1/it-defang-5.4.0) with ESMTP id j6RLq6qm004014 for ; Wed, 27 Jul 2005 14:52:06 -0700 (PDT) Received: from andrena.ucdavis.edu (localhost [127.0.0.1]) by andrena.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j6RLq6fd020236 for ; Wed, 27 Jul 2005 14:52:06 -0700 (PDT) Received: (from www@localhost) by andrena.ucdavis.edu (8.12.10/8.12.9/Submit) id j6RLq5lI020235; Wed, 27 Jul 2005 14:52:05 -0700 (PDT) Date: Wed, 27 Jul 2005 14:52:05 -0700 (PDT) Message-Id: <200507272152.j6RLq5lI020235@andrena.ucdavis.edu> To: mobopts@irtf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [169.237.7.192] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.165 X-Spam-Score: 2.4 (++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Mobopts] Reviews on draft-irtf-mobopts-ro-enhancements-01 X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Dear Christian and Dear Jari, I have read draft-irtf-mobopts-ro-enhancements-01 (and the 00 version before), the new version looks very good to me. Thanks for your excellent work. I have the following comments: 1. The paragraph at the end of page 19, “It should be mentioned that …” is very similar with the next paragraph. Remove one? 2. Is it better to list section 7.6 “Future Research” as a separate section, e.g. section 8? 3. Security analysis does not distinguish between eavesdropper and man_in_middle. There are situations where malicious node can only eavesdrop rather than intercept the message, for example, in the Internet exchange point, ISP router may not select a malicious router as the next hop because of its policy but the malicious router can still eavesdrop the data traffic. MIP6 network is a little bit less secure than normal IPv6 network because an eavesdropper can turn itself into a man in the middle. This also brings out another topic: how to detect the attack reliably and without interfering other optimization approaches. 4. Hash chain could be an alternative to home address test (or in other words, authentication of identity). It should be listed in section 6, Enhancements Toolbox. 5. draft-zhao-mobopts-rr-ext-00 discusses about the security and performance improvement. It should be added to the reference section. Thanks. Sincerely, fan _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Jul 27 22:18:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxxyu-0006Ze-GK; Wed, 27 Jul 2005 22:18:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxxys-0006Xf-St for mobopts@megatron.ietf.org; Wed, 27 Jul 2005 22:18:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26065 for ; Wed, 27 Jul 2005 22:18:40 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxyUE-0003Eg-VL for mobopts@irtf.org; Wed, 27 Jul 2005 22:51:08 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6S1lKu16126 for ; Wed, 27 Jul 2005 18:47:20 -0700 X-mProtect: <200507280147> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14169.americas.nokia.com (172.18.141.69, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdjNUqaB; Wed, 27 Jul 2005 18:47:19 PDT Message-ID: <42E8406B.6020203@iprg.nokia.com> Date: Wed, 27 Jul 2005 19:18:19 -0700 From: Rajeev Koodli 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: "mobopts@irtf.org" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [Mobopts] research publications X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hello folks, I thought it might be useful to share different publications related to IP mobility that you may have produced. I am thinking about putting together a link at the RG website. If you would like me to include yours, please send me the details, preferably as a URL. Thanks, -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jul 28 11:02:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy9to-0006l1-CD; Thu, 28 Jul 2005 11:02:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy9tn-0006kw-HI for mobopts@megatron.ietf.org; Thu, 28 Jul 2005 11:02:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03784 for ; Thu, 28 Jul 2005 11:02:13 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyAPE-0008F2-Rr for mobopts@irtf.org; Thu, 28 Jul 2005 11:34:47 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E7B096E4; Thu, 28 Jul 2005 17:02:10 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Jul 2005 17:02:10 +0200 Received: from [147.214.181.79] ([147.214.181.79]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Jul 2005 17:02:10 +0200 Message-ID: <42E8F372.3040702@ericsson.com> Date: Thu, 28 Jul 2005 17:02:10 +0200 From: Conny Larsson User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mobopts] New topics for the RG References: <42D2F74B.7040908@iprg.nokia.com> In-Reply-To: <42D2F74B.7040908@iprg.nokia.com> X-OriginalArrivalTime: 28 Jul 2005 15:02:10.0681 (UTC) FILETIME=[5474EE90:01C59385] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 2.4 (++) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0971631721==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org This is a multi-part message in MIME format. --===============0971631721== Content-Type: multipart/alternative; boundary="------------090906080500000503050309" This is a multi-part message in MIME format. --------------090906080500000503050309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Rajeev, I looked through the proposed topics and would like to ask you about the status of simultaneous multi-access support for MIPv6. Some years ago Hesham wrote a draft "Flow movement in Mobile IPv6" (draft-soliman-mobileip-flow-move-03.txt). I don't know the status of the work but if no one has worked on it I would suggest it to be considered as one of the topics for the mobopts working group. /Conny Rajeev Koodli wrote: > > > Hello folks, > > we have covered some topics in the RG for a while now. In fact, > some of the documents we have produced are ready or nearly ready > for IETF working groups to take on. Specifically, > > o the RO enhancements document has got very good reviews and will > be revised > o the security association establishment for handovers is now in the > hands of MIPSHOP. One of the RG documents is a potential solution > candidate. > o we have had multiple discussions on using, enhancing FMIP. > o context transfers has been discussed, especially in the context of PANA, > and I believe there will be a document of some sort. > o there has been discussion about L2 triggers and their implementation for > handovers. I hope we will be able to wrap up a document. > > If I missed anything, please do list. > > So, I guess it's okay to say we have had some useful work done > > Now, it is time to re-consider our charter items. What sorts of topics > are folks interested in working on? I would like to broaden our scope to > consider Mobility on the Internet in general. Some possible topics for > discussion below in no preference order. Please comment, suggest your > topics and provide a brief justification. > > - multicast and mobility. A specific problem is what address should > the MN > use as its source IP address so that its packets are not discarded > due to a) RPF checks, > and b) source-specific multicast. To pass a), you need the MN to use > CoA, but to > pass b), you need HoA. How to convice multiple receivers about CoA > and HoA binding? > Is RR even an option? :-) > > - mobility (and traffic) patterns in a WLAN (e.g., a campus network). > This should provide > a better sense of traffic for admission control as well as > network-controlled handovers. > > - what is the scope of IP paging in a converged WLAN - WWAN environment? > Is it a real problem? Worthwhile documenting in any case? > > - architectural barriers to optimizing inter-domain handovers. > Although we have > some understanding of improving delay and packet loss during > handovers across > IP networks, how applicable are they across different autonomous > systems? Would > the policy barriers allow optimizations? Is this an example of > "tussle in cyberspace"? > > - privacy topics related to mobility > > - Others > > -Rajeev > > > >------------------------------------------------------------------------ > >_______________________________________________ >Mobopts mailing list >Mobopts@irtf.org >https://www1.ietf.org/mailman/listinfo/mobopts > --------------090906080500000503050309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Rajeev,

I looked through the proposed topics and would like to ask you about the status of simultaneous multi-access support for MIPv6. Some years ago Hesham wrote a draft "Flow movement in Mobile IPv6" (draft-soliman-mobileip-flow-move-03.txt). I don't know the status of the work but if no one has worked on it I would suggest it to be considered as one of the topics for the mobopts working group.

/Conny

Rajeev Koodli wrote:


Hello folks,

we have covered some topics in the RG for a while now. In fact,
some of the documents we have produced are ready or nearly ready
for IETF working groups to take on. Specifically,

o the RO enhancements document has got very good reviews and will
   be revised
o the security association establishment for handovers is now in the
   hands of MIPSHOP. One of the RG documents is a potential solution
   candidate.
o  we have had multiple discussions on using, enhancing FMIP.
o context transfers has been discussed, especially in the context of PANA,
   and I believe there will be a document of some sort.
o there has been discussion about L2 triggers and their implementation for
   handovers. I hope we will be able to wrap up a document.

If I missed anything, please do list.

So, I guess it's okay to say we have had some useful work done

Now, it is time to re-consider our charter items. What sorts of topics
are folks interested in working on?  I would like to broaden our scope to
consider Mobility on the Internet in general. Some possible topics for
discussion below in no preference order. Please comment, suggest your
topics and provide a brief justification.

- multicast and mobility. A specific problem is what address should the MN
  use as its source IP address so that its packets are not discarded due to a) RPF checks,
  and b) source-specific multicast. To pass a), you need the MN to use CoA, but to
  pass b), you need HoA. How to convice multiple receivers about CoA and HoA binding?
  Is RR even an option? :-)

- mobility (and traffic) patterns in a WLAN (e.g., a campus network). This should provide
  a better sense of traffic for admission control as well as network-controlled handovers.
 
- what is the scope of IP paging in a converged WLAN - WWAN environment?
  Is it a real problem? Worthwhile documenting in any case?

- architectural barriers to optimizing inter-domain handovers. Although we have
   some understanding of improving delay and packet loss during handovers across
   IP networks, how applicable are they across different autonomous systems? Would
   the policy barriers allow optimizations? Is this an example of "tussle in cyberspace"?
  
- privacy topics related to mobility

- Others

-Rajeev


 



_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts

--------------090906080500000503050309-- --===============0971631721== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============0971631721==-- From mobopts-bounces@irtf.org Sun Jul 31 15:57:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzJwc-0004ns-5s; Sun, 31 Jul 2005 15:57:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzJwa-0004n1-2n for mobopts@megatron.ietf.org; Sun, 31 Jul 2005 15:57:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16338 for ; Sun, 31 Jul 2005 15:57:53 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzKSh-00051Q-GU for mobopts@irtf.org; Sun, 31 Jul 2005 16:31:09 -0400 Received: from iseran.local (unknown [83.145.64.130]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id B61FD4C913 for ; Mon, 1 Aug 2005 04:57:21 +0900 (JST) Date: Sat, 30 Jul 2005 09:22:15 +0900 From: Thierry Ernst To: mobopts@irtf.org Subject: Re: [Mobopts] New topics for the RG Message-Id: <20050730092215.0fd86218.ernst@sfc.wide.ad.jp> In-Reply-To: <42E8F372.3040702@ericsson.com> References: <42D2F74B.7040908@iprg.nokia.com> <42E8F372.3040702@ericsson.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Dear Conny, I'm sorry in advance for repeating an earlier announcement for the Monami6 BOF http://www.nautilus6.org/ietf I recently made on this ML, but given the message below it must be worthwhile to point out that this is exactly what the Monami6 BOF is all about. [sorry if this is pointed before this mail reaches this ML as I'm writing this mail aboard my flight to Paris] Regards, Thierry On Thu, 28 Jul 2005 17:02:10 +0200 Conny Larsson wrote: > Hi Rajeev, > > I looked through the proposed topics and would like to ask you about > the status of simultaneous multi-access support for MIPv6. Some years > ago Hesham wrote a draft "Flow movement in Mobile IPv6" > (draft-soliman-mobileip-flow-move-03.txt). I don't know the status of > the work but if no one has worked on it I would suggest it to be > considered as one of the topics for the mobopts working group. > > /Conny > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts