From mobopts-bounces@irtf.org Mon Aug 01 06:03:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzX9C-0004nA-IZ; Mon, 01 Aug 2005 06:03:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzX99-0004mI-GM for mobopts@megatron.ietf.org; Mon, 01 Aug 2005 06:03: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 GAA16349 for ; Mon, 1 Aug 2005 06:03:45 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzXfM-00087A-9Y for mobopts@irtf.org; Mon, 01 Aug 2005 06:37:07 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j719WHS11284 for ; Mon, 1 Aug 2005 02:32:17 -0700 X-mProtect: <200508010932> Nokia Silicon Valley Messaging Protection Received: from es-nira-22-134.europe.nokia.com (10.162.22.134, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdFsTmQx; Mon, 01 Aug 2005 02:32:14 PDT Message-ID: <42EDF363.2030104@iprg.nokia.com> Date: Mon, 01 Aug 2005 03:03:15 -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: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Subject: [Mobopts] MobOpts 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 is the agenda for Tuesday and Thursday. Regards, -Rajeev Tuesday, August 2, 2005 0900 - 0930 Morning Session I Room 352 or 353 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 Thursday, August 4, 2005 1030 - 1230 Morning Session II Room 351 1. RG status update, new topics (chair, 5 - 10 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 From mobopts-bounces@irtf.org Mon Aug 01 12:06:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzco9-0005Q7-SX; Mon, 01 Aug 2005 12:06:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzco8-0005Pv-TA for mobopts@megatron.ietf.org; Mon, 01 Aug 2005 12:06: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 MAA20601 for ; Mon, 1 Aug 2005 12:06:26 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1+po8b+rB4g4613Dvf9E8a4EGBXD090ey4=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzdKR-0008Nt-5c for mobopts@irtf.org; Mon, 01 Aug 2005 12:39:52 -0400 Received: from wired-6-62.ietf63.ietf.org ([86.255.6.62]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1Dzcnu-0006Ya-Mk; Mon, 01 Aug 2005 18:06:18 +0200 Message-ID: <42EE4869.7020209@tm.uka.de> Date: Mon, 01 Aug 2005 18:06:01 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; us-US; 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: Fan Zhao Subject: Re: [Mobopts] Reviews on draft-irtf-mobopts-ro-enhancements-01 References: <200507272152.j6RLq5lI020235@andrena.ucdavis.edu> In-Reply-To: <200507272152.j6RLq5lI020235@andrena.ucdavis.edu> Content-Type: text/plain; charset=UTF-8; format=flowed X-Spam-Score: -2.6 (--) X-Spam-Status: No X-Spam-Score: 2.4 (++) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA20601 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: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi Fan, thanks for your comments on draft-irtf-mobopts-ro-enhancements-01.txt.=20 There are some more outstanding modification that we have yet to do, so=20 your comments will be considered for the 02 version. Below are some responses to your comments from my side. > 1. The paragraph at the end of page 19, =EF=BF=BDIt should be > mentioned that =EF=BF=BD=EF=BF=BD is very similar with the next paragr= aph. > Remove one? Ooops, thanks for catching this. Yes, one paragraph should be enough. ;-= ) > 2. Is it better to list section 7.6 =EF=BF=BDFuture Research=EF=BF=BD = as a > separate section, e.g. section 8? Actually, it could, yes. One of the objectives why this draft was=20 written was to provide directions for future research. So the topic=20 should be important enough to make it a dedicated section (unless people=20 in the group feel otherwise). > 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. There is certainly a difference between an eavesdropper and a=20 man-in-the-middle. Yet, I'm not quite sure that I fully understand the=20 rest of what you are saying, in particular because your attacker sits in=20 the MN's network. Are you aware of the IPsec-protected tunnel between=20 the MN and its HA through which the Home Keygen Token will be brought to=20 the MN? > 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. See below. > 5. draft-zhao-mobopts-rr-ext-00 discusses about the security > and performance improvement. It should be added to the reference > section. Your draft was somewhere in my stack anyway. It's on top of it, now. ;-) Your draft also talks about hash chains, which is good. Jari and I also=20 did something in that direction in=20 draft-arkko-mipv6-binding-lifetime-extension-00.txt. Regards, - Christian --=20 Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Fan Zhao wrote: > Dear Christian and Dear Jari, >=20 > I have read draft-irtf-mobopts-ro-enhancements-01 (and the=20 > 00 version before), the new version looks very good to me.=20 > Thanks for your excellent work. >=20 > I have the following comments: > 1. The paragraph at the end of page 19, =EF=BF=BDIt should be=20 > mentioned that =EF=BF=BD=EF=BF=BD is very similar with the next paragra= ph.=20 > Remove one? > =20 > 2. Is it better to list section 7.6 =EF=BF=BDFuture Research=EF=BF=BD a= s a=20 > separate section, e.g. section 8?=20 >=20 > 3. Security analysis does not distinguish between eavesdropper=20 > and man_in_middle. There are situations where malicious node=20 > can only eavesdrop rather than intercept the message, for=20 > example, in the Internet exchange point, ISP router may not=20 > select a malicious router as the next hop because of its policy=20 > but the malicious router can still eavesdrop the data traffic.=20 > MIP6 network is a little bit less secure than normal IPv6 network=20 > because an eavesdropper can turn itself into a man in the middle.=20 > This also brings out another topic: how to detect the attack=20 > reliably and without interfering other optimization approaches. >=20 > 4. Hash chain could be an alternative to home address test (or in=20 > other words, authentication of identity). It should be listed in=20 > section 6, Enhancements Toolbox. >=20 > 5. draft-zhao-mobopts-rr-ext-00 discusses about the security=20 > and performance improvement. It should be added to the reference=20 > section. >=20 > Thanks. >=20 > Sincerely, > fan _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Aug 02 03: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 1DzrZl-0001Hn-Mf; Tue, 02 Aug 2005 03: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 1DzrZk-0001Gn-Ap for mobopts@megatron.ietf.org; Tue, 02 Aug 2005 03: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 DAA27880 for ; Tue, 2 Aug 2005 03:52:33 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzs66-0000eF-B0 for mobopts@irtf.org; Tue, 02 Aug 2005 04:26:07 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id AAA02449; Tue, 2 Aug 2005 00:52:02 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j727qBs10206; Tue, 2 Aug 2005 00:52:11 -0700 (PDT) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 00:52:11 -0700 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: Tue, 2 Aug 2005 00:52:04 -0700 Message-ID: Thread-Index: AcWXNxD6gnVOdJAXSoWSgtsudpeaMQ== From: "Davis, Terry L" To: , , X-OriginalArrivalTime: 02 Aug 2005 07:52:11.0292 (UTC) FILETIME=[16E355C0:01C59737] X-Spam-Score: 2.4 (++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Cc: mobopts@irtf.org Subject: [Mobopts] (no subject) 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 Rui/Telemanco/Nuno I found your presentation on v6 Network Initiated handoff very interesting, especially the dual homed support, which is a requirement of the aviation industry. Take care Terry http://www.ietf.org/internet-drafts/draft-melia-mobopts-niho-fmip-01.txt _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Aug 02 04:23:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzs3A-000251-1i; Tue, 02 Aug 2005 04:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzs37-00024t-SL for mobopts@megatron.ietf.org; Tue, 02 Aug 2005 04:22: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 EAA29291 for ; Tue, 2 Aug 2005 04:22:55 -0400 (EDT) Received: from vidi.ucdavis.edu ([169.237.105.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzsZZ-0001wm-Ef for mobopts@irtf.org; Tue, 02 Aug 2005 04:56:29 -0400 Received: from localhost (localhost [127.0.0.1]) by vidi.ucdavis.edu (8.13.3/8.13.1/it-std-5.2.0) with ESMTP id j728Mrts008446; Tue, 2 Aug 2005 01:22:53 -0700 (PDT) Date: Tue, 2 Aug 2005 01:22:53 -0700 (PDT) From: Fan Zhao X-X-Sender: fanzhao@vidi.ucdavis.edu To: Christian Vogt Subject: Re: [Mobopts] Reviews on draft-irtf-mobopts-ro-enhancements-01 In-Reply-To: <42EE4869.7020209@tm.uka.de> Message-ID: References: <200507272152.j6RLq5lI020235@andrena.ucdavis.edu> <42EE4869.7020209@tm.uka.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Score: 2.4 (++) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: QUOTED-PRINTABLE 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: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Dear Christian, Thanks for your reply. On Mon, 1 Aug 2005, Christian Vogt wrote: > Hi Fan, > > thanks for your comments on draft-irtf-mobopts-ro-enhancements-01.txt. > There are some more outstanding modification that we have yet to do, so > your comments will be considered for the 02 version. > No problem. 01 version has addressed many issues I had with 00 version and has been improved significantly since then. Thanks for writing this draft, it has helped me a lot in understanding this probelm. > Below are some responses to your comments from my side. > > > 1. The paragraph at the end of page 19, =EF=BF=BDIt should be > > mentioned that =EF=BF=BD=EF=BF=BD is very similar with the next paragr= aph. > > Remove one? > > Ooops, thanks for catching this. Yes, one paragraph should be enough. ;-= ) > > > 2. Is it better to list section 7.6 =EF=BF=BDFuture Research=EF=BF=BD = as a > > separate section, e.g. section 8? > > Actually, it could, yes. One of the objectives why this draft was > written was to provide directions for future research. So the topic > should be important enough to make it a dedicated section (unless people > in the group feel otherwise). > > > 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. > > There is certainly a difference between an eavesdropper and a > man-in-the-middle. Yet, I'm not quite sure that I fully understand the > rest of what you are saying, in particular because your attacker sits in > the MN's network. Are you aware of the IPsec-protected tunnel between > the MN and its HA through which the Home Keygen Token will be brought to > the MN? NO, actually I do not assume that the attacker resides in the MN's network, instead the attacker could access either HA-CN path or MN-CN path. > > > 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. > > See below. > > > 5. draft-zhao-mobopts-rr-ext-00 discusses about the security > > and performance improvement. It should be added to the reference > > section. > > Your draft was somewhere in my stack anyway. It's on top of it, now. ;-) > > Your draft also talks about hash chains, which is good. Jari and I also > did something in that direction in > draft-arkko-mipv6-binding-lifetime-extension-00.txt. Yes, I have read this too. That is an interesting idea that is worthwhile being explored more. BTW, I could not attend this IETF due to the time conflict. I really appreciate your comments on my draft in the mailing list. Thanks. Sincerely, fan > > Regards, > - Christian > > -- > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ > > > > Fan Zhao wrote: > > 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, =EF=BF=BDIt should be > > mentioned that =EF=BF=BD=EF=BF=BD is very similar with the next paragra= ph. > > Remove one? > > > > 2. Is it better to list section 7.6 =EF=BF=BDFuture Research=EF=BF=BD a= s 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 Tue Aug 02 05:13:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzsqG-0003fl-Q6; Tue, 02 Aug 2005 05:13:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzsqE-0003fg-Tl for mobopts@megatron.ietf.org; Tue, 02 Aug 2005 05:13: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 FAA01563 for ; Tue, 2 Aug 2005 05:13:40 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DztMe-00046e-5i for mobopts@irtf.org; Tue, 02 Aug 2005 05:47:15 -0400 Received: from [86.255.28.182] (open-28-182.ietf63.ietf.org [86.255.28.182]) by kyoto.netlab.nec.de (Postfix) with ESMTP id D50351BAC4D; Tue, 2 Aug 2005 11:13:29 +0200 (CEST) Message-ID: <42EF3938.7000108@netlab.nec.de> Date: Tue, 02 Aug 2005 11:13:28 +0200 From: Telemaco Melia User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Davis, Terry L" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: mobopts@irtf.org Subject: [Mobopts] Re: aviation industry 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 Davis, Terry L wrote: >Rui/Telemanco/Nuno > >I found your presentation on v6 Network Initiated handoff very >interesting, especially the dual homed support, which is a requirement >of the aviation industry. > >Take care >Terry > >http://www.ietf.org/internet-drafts/draft-melia-mobopts-niho-fmip-01.txt > > > Hi Terry, this is good to know. Could you give more hints on what aviation industry is expecting? Maybe you have some published documents on such a matter... regards, telemaco _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Aug 02 08:04:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzvVk-0002lb-IU; Tue, 02 Aug 2005 08:04:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzvVj-0002ku-PJ for mobopts@megatron.ietf.org; Tue, 02 Aug 2005 08:04: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 IAA13894 for ; Tue, 2 Aug 2005 08:04:42 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzw2A-0004K3-CM for mobopts@irtf.org; Tue, 02 Aug 2005 08:38:17 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id FAA20246; Tue, 2 Aug 2005 05:04:11 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j72C4Ls06906; Tue, 2 Aug 2005 05:04:21 -0700 (PDT) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 05:04:21 -0700 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: Tue, 2 Aug 2005 05:04:15 -0700 Message-ID: Thread-Topic: aviation industry Thread-Index: AcWXQnR3pAzgv/aaR8iW+06JjNqScAAF5/rQ From: "Davis, Terry L" To: "Telemaco Melia" X-OriginalArrivalTime: 02 Aug 2005 12:04:21.0120 (UTC) FILETIME=[50F7E000:01C5975A] X-Spam-Score: 2.4 (++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: mobopts@irtf.org Subject: [Mobopts] RE: aviation industry 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 I have promised to provide a draft of aviation requirements to Jim Kempf; so it will show up in the next few months. Take care Terry -----Original Message----- From: Telemaco Melia [mailto:telemaco.melia@netlab.nec.de]=20 Sent: Tuesday, August 02, 2005 2:13 AM To: Davis, Terry L Cc: ruilaa@det.ua.pt; njs@av.it.pt; mobopts@irtf.org Subject: Re: aviation industry Davis, Terry L wrote: >Rui/Telemanco/Nuno > >I found your presentation on v6 Network Initiated handoff very >interesting, especially the dual homed support, which is a requirement >of the aviation industry. > >Take care >Terry > >http://www.ietf.org/internet-drafts/draft-melia-mobopts-niho-fmip-01.tx t > > =20 > Hi Terry, this is good to know. Could you give more hints on what aviation industry is expecting? Maybe you have some published documents on such a matter... regards, telemaco _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Aug 02 08:47:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwBa-0007Qq-Lb; Tue, 02 Aug 2005 08:47:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwBW-0007ND-Jd for mobopts@megatron.ietf.org; Tue, 02 Aug 2005 08:47: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 IAA16176 for ; Tue, 2 Aug 2005 08:47:48 -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 1Dzwhv-00066S-Cg for mobopts@irtf.org; Tue, 02 Aug 2005 09:21:24 -0400 Message-ID: <09a101c59760$57f0a350$596015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Davis, Terry L" , "Telemaco Melia" References: Subject: Re: [Mobopts] RE: aviation industry Date: Tue, 2 Aug 2005 05:47:27 -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: 41c17b4b16d1eedaa8395c26e9a251c4 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 Telemaco, Please take a look at: http://www.ietf.org/internet-drafts/draft-kempf-netlmm-nohost-req-00.txt This is a list of requirements for network-based localized mobility mangagement we discussed at the netlmm BOF. If there are any changes needed, let us know and we can put them in. BTW, if you want to subscribe to the netlmm mailing list, it is at: https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm jak ----- Original Message ----- From: "Davis, Terry L" To: "Telemaco Melia" Cc: Sent: Tuesday, August 02, 2005 5:04 AM Subject: [Mobopts] RE: aviation industry Telemaco I have promised to provide a draft of aviation requirements to Jim Kempf; so it will show up in the next few months. Take care Terry -----Original Message----- From: Telemaco Melia [mailto:telemaco.melia@netlab.nec.de] Sent: Tuesday, August 02, 2005 2:13 AM To: Davis, Terry L Cc: ruilaa@det.ua.pt; njs@av.it.pt; mobopts@irtf.org Subject: Re: aviation industry Davis, Terry L wrote: >Rui/Telemanco/Nuno > >I found your presentation on v6 Network Initiated handoff very >interesting, especially the dual homed support, which is a requirement >of the aviation industry. > >Take care >Terry > >http://www.ietf.org/internet-drafts/draft-melia-mobopts-niho-fmip-01.tx t > > > Hi Terry, this is good to know. Could you give more hints on what aviation industry is expecting? Maybe you have some published documents on such a matter... regards, telemaco _______________________________________________ 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 Aug 02 09:05:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwS4-0003aO-LH; Tue, 02 Aug 2005 09:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwRz-0003Qo-CN for mobopts@megatron.ietf.org; Tue, 02 Aug 2005 09:04: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 JAA17188 for ; Tue, 2 Aug 2005 09:04:53 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzwyS-0006sS-Ad for mobopts@irtf.org; Tue, 02 Aug 2005 09:38:29 -0400 Received: from [86.255.7.205] (wired-7-205.ietf63.ietf.org [86.255.7.205]) by kyoto.netlab.nec.de (Postfix) with ESMTP id ED4861BAC4D; Tue, 2 Aug 2005 15:04:43 +0200 (CEST) Message-ID: <42EF6F6A.3040803@netlab.nec.de> Date: Tue, 02 Aug 2005 15:04:42 +0200 From: Telemaco Melia User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mobopts] RE: aviation industry References: <09a101c59760$57f0a350$596015ac@dcml.docomolabsusa.com> In-Reply-To: <09a101c59760$57f0a350$596015ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: netlmm@ngnet.it, "Davis, Terry L" , 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 Thanks James for the hint. I ll read the document carefully, however from a first impression I have the feeling the issues are orthogonal. Wrong assumption? regards, telemaco James Kempf wrote: >Telemaco, > >Please take a look at: > >http://www.ietf.org/internet-drafts/draft-kempf-netlmm-nohost-req-00.txt > >This is a list of requirements for network-based localized mobility >mangagement we discussed at the netlmm BOF. If there are any changes needed, >let us know and we can put them in. > >BTW, if you want to subscribe to the netlmm mailing list, it is at: > >https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm > > jak > >----- Original Message ----- >From: "Davis, Terry L" >To: "Telemaco Melia" >Cc: >Sent: Tuesday, August 02, 2005 5:04 AM >Subject: [Mobopts] RE: aviation industry > > >Telemaco > >I have promised to provide a draft of aviation requirements to Jim >Kempf; so it will show up in the next few months. > >Take care >Terry >-----Original Message----- >From: Telemaco Melia [mailto:telemaco.melia@netlab.nec.de] >Sent: Tuesday, August 02, 2005 2:13 AM >To: Davis, Terry L >Cc: ruilaa@det.ua.pt; njs@av.it.pt; mobopts@irtf.org >Subject: Re: aviation industry > >Davis, Terry L wrote: > > > >>Rui/Telemanco/Nuno >> >>I found your presentation on v6 Network Initiated handoff very >>interesting, especially the dual homed support, which is a requirement >>of the aviation industry. >> >>Take care >>Terry >> >>http://www.ietf.org/internet-drafts/draft-melia-mobopts-niho-fmip-01.tx >> >> >t > > >> >> >> >Hi Terry, > >this is good to know. >Could you give more hints on what aviation industry is expecting? >Maybe you have some published documents on such a matter... > >regards, >telemaco > >_______________________________________________ >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 Aug 02 09:11:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwY8-0007El-8J; Tue, 02 Aug 2005 09:11:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwY0-0007ED-9B for mobopts@megatron.ietf.org; Tue, 02 Aug 2005 09:11: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 JAA17533 for ; Tue, 2 Aug 2005 09:11:06 -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 1Dzx4T-0007AL-CN for mobopts@irtf.org; Tue, 02 Aug 2005 09:44:42 -0400 Message-ID: <09fc01c59763$a12b1980$596015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Telemaco Melia" References: <09a101c59760$57f0a350$596015ac@dcml.docomolabsusa.com> <42EF6F6A.3040803@netlab.nec.de> Subject: Re: [Mobopts] RE: aviation industry Date: Tue, 2 Aug 2005 06:10:59 -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: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: netlmm@ngnet.it, "Davis, Terry L" , 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 The requirements were designed for network-based localized mobility management, which includes Layer 3 handover support. One area of orthogonality might be whether or not the IP address changes on handover. In netlmm, it doesn't. With network-based handover support, it might. Is that what you mean? jak ----- Original Message ----- From: "Telemaco Melia" To: "James Kempf" Cc: "Davis, Terry L" ; ; Sent: Tuesday, August 02, 2005 6:04 AM Subject: Re: [Mobopts] RE: aviation industry > Thanks James for the hint. > I ll read the document carefully, however from a first impression I have > the feeling the issues > are orthogonal. Wrong assumption? > > regards, > telemaco > > James Kempf wrote: > > >Telemaco, > > > >Please take a look at: > > > >http://www.ietf.org/internet-drafts/draft-kempf-netlmm-nohost-req-00.txt > > > >This is a list of requirements for network-based localized mobility > >mangagement we discussed at the netlmm BOF. If there are any changes needed, > >let us know and we can put them in. > > > >BTW, if you want to subscribe to the netlmm mailing list, it is at: > > > >https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm > > > > jak > > > >----- Original Message ----- > >From: "Davis, Terry L" > >To: "Telemaco Melia" > >Cc: > >Sent: Tuesday, August 02, 2005 5:04 AM > >Subject: [Mobopts] RE: aviation industry > > > > > >Telemaco > > > >I have promised to provide a draft of aviation requirements to Jim > >Kempf; so it will show up in the next few months. > > > >Take care > >Terry > >-----Original Message----- > >From: Telemaco Melia [mailto:telemaco.melia@netlab.nec.de] > >Sent: Tuesday, August 02, 2005 2:13 AM > >To: Davis, Terry L > >Cc: ruilaa@det.ua.pt; njs@av.it.pt; mobopts@irtf.org > >Subject: Re: aviation industry > > > >Davis, Terry L wrote: > > > > > > > >>Rui/Telemanco/Nuno > >> > >>I found your presentation on v6 Network Initiated handoff very > >>interesting, especially the dual homed support, which is a requirement > >>of the aviation industry. > >> > >>Take care > >>Terry > >> > >>http://www.ietf.org/internet-drafts/draft-melia-mobopts-niho-fmip-01.tx > >> > >> > >t > > > > > >> > >> > >> > >Hi Terry, > > > >this is good to know. > >Could you give more hints on what aviation industry is expecting? > >Maybe you have some published documents on such a matter... > > > >regards, > >telemaco > > > >_______________________________________________ > >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 Aug 02 12:21:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzWB-0007N2-31; Tue, 02 Aug 2005 12:21:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzW3-0007Jj-5I for mobopts@megatron.ietf.org; Tue, 02 Aug 2005 12:21: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 MAA03013 for ; Tue, 2 Aug 2005 12:21:15 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E002V-0008Cq-OW for mobopts@irtf.org; Tue, 02 Aug 2005 12:54:55 -0400 Received: from [86.255.28.182] (open-28-182.ietf63.ietf.org [86.255.28.182]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 291311BAC4D; Tue, 2 Aug 2005 18:21:06 +0200 (CEST) Message-ID: <42EF9D70.8060303@netlab.nec.de> Date: Tue, 02 Aug 2005 18:21:04 +0200 From: Telemaco Melia User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mobopts] RE: aviation industry References: <09a101c59760$57f0a350$596015ac@dcml.docomolabsusa.com> <42EF6F6A.3040803@netlab.nec.de> <09fc01c59763$a12b1980$596015ac@dcml.docomolabsusa.com> In-Reply-To: <09fc01c59763$a12b1980$596015ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit Cc: netlmm@ngnet.it, "Davis, Terry L" , 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 that it depends on the requirements and design decisions. If the solution is based on existing technologies (with minor modifications) then probably it is not interfering with netlmm. (i.e. IP address changes on handover). How would you approach the work? In our understanding a problem statement draft is the next logical step. Do you have major concerns? telemaco James Kempf wrote: >The requirements were designed for network-based localized mobility >management, which includes Layer 3 handover support. One area of >orthogonality might be whether or not the IP address changes on handover. In >netlmm, it doesn't. With network-based handover support, it might. Is that >what you mean? > > jak > > >----- Original Message ----- >From: "Telemaco Melia" >To: "James Kempf" >Cc: "Davis, Terry L" ; ; > >Sent: Tuesday, August 02, 2005 6:04 AM >Subject: Re: [Mobopts] RE: aviation industry > > > > >>Thanks James for the hint. >>I ll read the document carefully, however from a first impression I have >>the feeling the issues >>are orthogonal. Wrong assumption? >> >>regards, >>telemaco >> >>James Kempf wrote: >> >> >> >>>Telemaco, >>> >>>Please take a look at: >>> >>>http://www.ietf.org/internet-drafts/draft-kempf-netlmm-nohost-req-00.txt >>> >>>This is a list of requirements for network-based localized mobility >>>mangagement we discussed at the netlmm BOF. If there are any changes >>> >>> >needed, > > >>>let us know and we can put them in. >>> >>>BTW, if you want to subscribe to the netlmm mailing list, it is at: >>> >>>https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm >>> >>> jak >>> >>>----- Original Message ----- >>>From: "Davis, Terry L" >>>To: "Telemaco Melia" >>>Cc: >>>Sent: Tuesday, August 02, 2005 5:04 AM >>>Subject: [Mobopts] RE: aviation industry >>> >>> >>>Telemaco >>> >>>I have promised to provide a draft of aviation requirements to Jim >>>Kempf; so it will show up in the next few months. >>> >>>Take care >>>Terry >>>-----Original Message----- >>>From: Telemaco Melia [mailto:telemaco.melia@netlab.nec.de] >>>Sent: Tuesday, August 02, 2005 2:13 AM >>>To: Davis, Terry L >>>Cc: ruilaa@det.ua.pt; njs@av.it.pt; mobopts@irtf.org >>>Subject: Re: aviation industry >>> >>>Davis, Terry L wrote: >>> >>> >>> >>> >>> >>>>Rui/Telemanco/Nuno >>>> >>>>I found your presentation on v6 Network Initiated handoff very >>>>interesting, especially the dual homed support, which is a requirement >>>>of the aviation industry. >>>> >>>>Take care >>>>Terry >>>> >>>>http://www.ietf.org/internet-drafts/draft-melia-mobopts-niho-fmip-01.tx >>>> >>>> >>>> >>>> >>>t >>> >>> >>> >>> >>>> >>>> >>>> >>>Hi Terry, >>> >>>this is good to know. >>>Could you give more hints on what aviation industry is expecting? >>>Maybe you have some published documents on such a matter... >>> >>>regards, >>>telemaco >>> >>>_______________________________________________ >>>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 Aug 02 12:45:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzztU-0006mQ-6Y; Tue, 02 Aug 2005 12:45:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzztT-0006mI-Ht for mobopts@megatron.ietf.org; Tue, 02 Aug 2005 12:45:31 -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 MAA04214 for ; Tue, 2 Aug 2005 12:45:28 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00Px-0000nT-EJ for mobopts@irtf.org; Tue, 02 Aug 2005 13:19:07 -0400 Received: from [q??IPv6:2001:688:ffff:24:211:24ff:fe21:a941] (unknown [IPv6:2001:688:ffff:24:211:24ff:fe21:a941]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id AC1714CC11; Wed, 3 Aug 2005 01:45:14 +0900 (JST) In-Reply-To: References: <42D2F384.6050107@iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <06567170-0DCA-421C-BD93-14CD5A1DA834@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [Mobopts] Re: [Mip6] [Fwd: FW: resubmit draft-irtf-mobopts-location-privacy-ps-00.txt with revised boilerplate] Date: Wed, 3 Aug 2005 01:45:05 +0900 To: Wassim Haddad X-Mailer: Apple Mail (2.733) X-Spam-Score: 2.4 (++) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, 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 Wassim I just saw the Rajeev's presentation. If a MN can randomly generate a sequence value that is larger than the previous value and within sequence number window, it's hard to track the mobile node. no? I agree most of implementation today just increment one for sequence number. Is there any description in RFC3775 saying that MN must increment sequentially for Seq number? ryuji On 2005/07/12, at 12:50, Wassim Haddad wrote: > 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 > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Aug 02 13:07:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00El-0000XT-Vc; Tue, 02 Aug 2005 13:07:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00Ek-0000SB-Dr for mobopts@megatron.ietf.org; Tue, 02 Aug 2005 13:07: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 NAA06103 for ; Tue, 2 Aug 2005 13:07:26 -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 1E00lG-0001y0-6s for mobopts@irtf.org; Tue, 02 Aug 2005 13:41:06 -0400 Message-ID: <0b1c01c59784$a648e700$596015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Telemaco Melia" References: <09a101c59760$57f0a350$596015ac@dcml.docomolabsusa.com> <42EF6F6A.3040803@netlab.nec.de> <09fc01c59763$a12b1980$596015ac@dcml.docomolabsusa.com> <42EF9D70.8060303@netlab.nec.de> Subject: Re: [Mobopts] RE: aviation industry Date: Tue, 2 Aug 2005 10:07:21 -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: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: 7bit Cc: netlmm@ngnet.it, "Davis, Terry L" , 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 If you think you need to have the address change on every IP link change, then you should do a separate problem statement. But before you do, I'd try upleveling your thinking and examining whether you really do need to have (or want) the IP address change on every IP link change. jak ----- Original Message ----- From: "Telemaco Melia" To: "James Kempf" Cc: "Davis, Terry L" ; ; Sent: Tuesday, August 02, 2005 9:21 AM Subject: Re: [Mobopts] RE: aviation industry > I think that it depends on the requirements and design decisions. > If the solution is based on existing technologies (with minor modifications) > then probably it is not interfering with netlmm. (i.e. IP address > changes on handover). > How would you approach the work? > In our understanding a problem statement draft is the next logical step. > Do you have major concerns? > > telemaco > > James Kempf wrote: > > >The requirements were designed for network-based localized mobility > >management, which includes Layer 3 handover support. One area of > >orthogonality might be whether or not the IP address changes on handover. In > >netlmm, it doesn't. With network-based handover support, it might. Is that > >what you mean? > > > > jak > > > > > >----- Original Message ----- > >From: "Telemaco Melia" > >To: "James Kempf" > >Cc: "Davis, Terry L" ; ; > > > >Sent: Tuesday, August 02, 2005 6:04 AM > >Subject: Re: [Mobopts] RE: aviation industry > > > > > > > > > >>Thanks James for the hint. > >>I ll read the document carefully, however from a first impression I have > >>the feeling the issues > >>are orthogonal. Wrong assumption? > >> > >>regards, > >>telemaco > >> > >>James Kempf wrote: > >> > >> > >> > >>>Telemaco, > >>> > >>>Please take a look at: > >>> > >>>http://www.ietf.org/internet-drafts/draft-kempf-netlmm-nohost-req-00.txt > >>> > >>>This is a list of requirements for network-based localized mobility > >>>mangagement we discussed at the netlmm BOF. If there are any changes > >>> > >>> > >needed, > > > > > >>>let us know and we can put them in. > >>> > >>>BTW, if you want to subscribe to the netlmm mailing list, it is at: > >>> > >>>https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm > >>> > >>> jak > >>> > >>>----- Original Message ----- > >>>From: "Davis, Terry L" > >>>To: "Telemaco Melia" > >>>Cc: > >>>Sent: Tuesday, August 02, 2005 5:04 AM > >>>Subject: [Mobopts] RE: aviation industry > >>> > >>> > >>>Telemaco > >>> > >>>I have promised to provide a draft of aviation requirements to Jim > >>>Kempf; so it will show up in the next few months. > >>> > >>>Take care > >>>Terry > >>>-----Original Message----- > >>>From: Telemaco Melia [mailto:telemaco.melia@netlab.nec.de] > >>>Sent: Tuesday, August 02, 2005 2:13 AM > >>>To: Davis, Terry L > >>>Cc: ruilaa@det.ua.pt; njs@av.it.pt; mobopts@irtf.org > >>>Subject: Re: aviation industry > >>> > >>>Davis, Terry L wrote: > >>> > >>> > >>> > >>> > >>> > >>>>Rui/Telemanco/Nuno > >>>> > >>>>I found your presentation on v6 Network Initiated handoff very > >>>>interesting, especially the dual homed support, which is a requirement > >>>>of the aviation industry. > >>>> > >>>>Take care > >>>>Terry > >>>> > >>>>http://www.ietf.org/internet-drafts/draft-melia-mobopts-niho-fmip-01.tx > >>>> > >>>> > >>>> > >>>> > >>>t > >>> > >>> > >>> > >>> > >>>> > >>>> > >>>> > >>>Hi Terry, > >>> > >>>this is good to know. > >>>Could you give more hints on what aviation industry is expecting? > >>>Maybe you have some published documents on such a matter... > >>> > >>>regards, > >>>telemaco > >>> > >>>_______________________________________________ > >>>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 Aug 02 13:15:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00MM-0006aI-RO; Tue, 02 Aug 2005 13:15:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00ML-0006aD-Cp for mobopts@megatron.ietf.org; Tue, 02 Aug 2005 13:15: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 NAA06390 for ; Tue, 2 Aug 2005 13:15:17 -0400 (EDT) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00sq-0002Gg-Ge for mobopts@irtf.org; Tue, 02 Aug 2005 13:48:57 -0400 Received: from horh1.emsr.lucent.com (h135-112-138-211.lucent.com [135.112.138.211]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j72HFCX8020133; Tue, 2 Aug 2005 12:15:13 -0500 (CDT) Received: from nwmail.wh.lucent.com (nwmail.wh.lucent.com [135.5.40.100]) by horh1.emsr.lucent.com (8.12.11/8.12.11) with ESMTP id j72HFB2S004135; Tue, 2 Aug 2005 12:15:11 -0500 (CDT) Received: from lucent.com by nwmail.wh.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j72HF8t16363; Tue, 2 Aug 2005 13:15:08 -0400 (EDT) Message-ID: <42EFA9E9.8050509@lucent.com> Date: Tue, 02 Aug 2005 13:14:17 -0400 From: Ajay Rajkumar Organization: Bell Labs, Lucent Technologies Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mobopts] RE: aviation industry References: <09a101c59760$57f0a350$596015ac@dcml.docomolabsusa.com> <42EF6F6A.3040803@netlab.nec.de> <09fc01c59763$a12b1980$596015ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Cc: mobopts@irtf.org, netlmm@ngnet.it, "Davis, Terry L" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ajayrajkumar@lucent.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 James, Could you elaborate on the "localized" part of the localized mobility management? What are the assumptions on localized? -ajay On 8/2/2005 9:10 AM, James Kempf wrote: > The requirements were designed for network-based localized mobility > management, which includes Layer 3 handover support. One area of > orthogonality might be whether or not the IP address changes on handover. In > netlmm, it doesn't. With network-based handover support, it might. Is that > what you mean? > > jak > > > ----- Original Message ----- > From: "Telemaco Melia" > To: "James Kempf" > Cc: "Davis, Terry L" ; ; > > Sent: Tuesday, August 02, 2005 6:04 AM > Subject: Re: [Mobopts] RE: aviation industry > > > >>Thanks James for the hint. >>I ll read the document carefully, however from a first impression I have >>the feeling the issues >>are orthogonal. Wrong assumption? >> >>regards, >>telemaco >> >>James Kempf wrote: >> >> >>>Telemaco, >>> >>>Please take a look at: >>> >>>http://www.ietf.org/internet-drafts/draft-kempf-netlmm-nohost-req-00.txt >>> >>>This is a list of requirements for network-based localized mobility >>>mangagement we discussed at the netlmm BOF. If there are any changes >> > needed, > >>>let us know and we can put them in. >>> >>>BTW, if you want to subscribe to the netlmm mailing list, it is at: >>> >>>https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm >>> >>> jak >>> >>>----- Original Message ----- >>>From: "Davis, Terry L" >>>To: "Telemaco Melia" >>>Cc: >>>Sent: Tuesday, August 02, 2005 5:04 AM >>>Subject: [Mobopts] RE: aviation industry >>> >>> >>>Telemaco >>> >>>I have promised to provide a draft of aviation requirements to Jim >>>Kempf; so it will show up in the next few months. >>> >>>Take care >>>Terry >>>-----Original Message----- >>>From: Telemaco Melia [mailto:telemaco.melia@netlab.nec.de] >>>Sent: Tuesday, August 02, 2005 2:13 AM >>>To: Davis, Terry L >>>Cc: ruilaa@det.ua.pt; njs@av.it.pt; mobopts@irtf.org >>>Subject: Re: aviation industry >>> >>>Davis, Terry L wrote: >>> >>> >>> >>> >>>>Rui/Telemanco/Nuno >>>> >>>>I found your presentation on v6 Network Initiated handoff very >>>>interesting, especially the dual homed support, which is a requirement >>>>of the aviation industry. >>>> >>>>Take care >>>>Terry >>>> >>>>http://www.ietf.org/internet-drafts/draft-melia-mobopts-niho-fmip-01.tx >>>> >>>> >>> >>>t >>> >>> >>> >>>> >>>> >>>Hi Terry, >>> >>>this is good to know. >>>Could you give more hints on what aviation industry is expecting? >>>Maybe you have some published documents on such a matter... >>> >>>regards, >>>telemaco >>> >>>_______________________________________________ >>>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 Aug 02 13:31:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00bV-0008Kn-W5; Tue, 02 Aug 2005 13:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00bU-0008KV-FH; Tue, 02 Aug 2005 13:31:00 -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 NAA07281; Tue, 2 Aug 2005 13:30:56 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E017y-0002wS-JE; Tue, 02 Aug 2005 14:04:37 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j72GxMY04606; Tue, 2 Aug 2005 09:59:22 -0700 X-mProtect: <200508021659> Nokia Silicon Valley Messaging Protection Received: from es-nira-27-221.europe.nokia.com (10.162.27.221, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdcWJlYp; Tue, 02 Aug 2005 09:59:20 PDT Message-ID: <42EFADAF.3080906@iprg.nokia.com> Date: Tue, 02 Aug 2005 10:30: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: Ryuji Wakikawa Subject: Re: [Mobopts] Re: [Mip6] [Fwd: FW: resubmit draft-irtf-mobopts-location-privacy-ps-00.txt with revised boilerplate] References: <42D2F384.6050107@iprg.nokia.com> <06567170-0DCA-421C-BD93-14CD5A1DA834@sfc.wide.ad.jp> In-Reply-To: <06567170-0DCA-421C-BD93-14CD5A1DA834@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: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: Wassim Haddad , mobopts@irtf.org, mip6@ietf.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 Ryuji Wakikawa wrote: > Hi Wassim > > I agree most of implementation today just increment one for sequence > number. > Is there any description in RFC3775 saying that MN must increment > sequentially for Seq number? I was looking for that. I could not find text that says the Sequence Number must be incremented by one. The only requirement is that it is greater than the previous one. -Rajeev > > ryuji > > > On 2005/07/12, at 12:50, Wassim Haddad wrote: > >> 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 >> >> > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Aug 03 03:01:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DFr-00020b-Mu; Wed, 03 Aug 2005 03:01:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DFp-0001zE-W9 for mobopts@megatron.ietf.org; Wed, 03 Aug 2005 03:01: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 DAA19425 for ; Wed, 3 Aug 2005 03:01:28 -0400 (EDT) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0DmT-0007Z0-7T for mobopts@irtf.org; Wed, 03 Aug 2005 03:35:13 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id A58EF8004B0; Wed, 3 Aug 2005 10:01:16 +0300 (EEST) Date: Wed, 3 Aug 2005 10:01:16 +0300 (EEST) From: Wassim Haddad To: Ryuji Wakikawa Subject: Re: [Mobopts] Re: [Mip6] [Fwd: FW: resubmit draft-irtf-mobopts-location-privacy-ps-00.txt with revised boilerplate] In-Reply-To: <06567170-0DCA-421C-BD93-14CD5A1DA834@sfc.wide.ad.jp> Message-ID: References: <42D2F384.6050107@iprg.nokia.com> <06567170-0DCA-421C-BD93-14CD5A1DA834@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Score: 2.4 (++) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: mip6@ietf.org, 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 Ryuji, On Wed, 3 Aug 2005, Ryuji Wakikawa wrote: > Hi Wassim > > I just saw the Rajeev's presentation. > > If a MN can randomly generate a sequence value that is larger than > the previous value and within sequence number window, it's hard to track > the mobile node. no? =3D> IMHO, this may not be enough. The SQN should appear for an eavesdroppe= r as random and not larger than the previous one (i.e., this is still traceable). This issue has been addressed in: draft-haddad-privacy-omipv6-anonymity-00 > I agree most of implementation today just increment one for sequence > number. > Is there any description in RFC3775 saying that MN must increment > sequentially for Seq number? =3D> I think RFC3775 just mention that it should be larger. Regards, Wassim H. > On 2005/07/12, at 12:50, Wassim Haddad wrote: > > > 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. =C3> > > > 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 > > > > > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Aug 03 03:34:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DlM-0007Ke-C7; Wed, 03 Aug 2005 03:34:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DlJ-0007H0-L9 for mobopts@megatron.ietf.org; Wed, 03 Aug 2005 03:34: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 DAA21109 for ; Wed, 3 Aug 2005 03:34:00 -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 1E0EHw-0000eF-3X for mobopts@irtf.org; Wed, 03 Aug 2005 04:07:45 -0400 Message-ID: <0c3201c597fd$ad4cd1a0$596015ac@dcml.docomolabsusa.com> From: "James Kempf" To: References: <09a101c59760$57f0a350$596015ac@dcml.docomolabsusa.com> <42EF6F6A.3040803@netlab.nec.de> <09fc01c59763$a12b1980$596015ac@dcml.docomolabsusa.com> <42EFA9E9.8050509@lucent.com> Subject: Re: [Mobopts] RE: aviation industry Date: Wed, 3 Aug 2005 00:33:42 -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: 848ed35f2a4fc0638fa89629cb640f48 Content-Transfer-Encoding: 7bit Cc: mobopts@irtf.org, netlmm@ngnet.it, "Davis, Terry L" 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 Ajay, That is really up to the deployment. For the airline application that Terry has in mind, the geographic sense of "local" might mean the entire Northern Hemisphere of planet Earth, but the topological sense (i.e. what subnets the netlmm domain spans) might only be 20 or 30 with maybe a total of 200 hosts, corresponding to the airplanes that are in the air at the time (note that I'm projecting here based on my limited knowledge of Boeing Connexion as it currently exists, Terry is the right person to ask for a more precise answer of what they would like). For the kinds of applications that DoCoMo has in mind, the span is maybe metropolitan Tokyo with maybe on the order of 10's of millions of hosts. All of Japan would also be desirable, though that is probably pushing the upper limit in the number of hosts that netlmm could support. Another application might want to cover just a single building, like maybe Sano Tower in Tokyo, though that level might more easily be handled by TRILL. jak ----- Original Message ----- From: "Ajay Rajkumar" To: "James Kempf" Cc: "Telemaco Melia" ; ; "Davis, Terry L" ; Sent: Tuesday, August 02, 2005 10:14 AM Subject: Re: [Mobopts] RE: aviation industry > James, > > Could you elaborate on the "localized" part of the localized mobility > management? What are the assumptions on localized? > > -ajay > > On 8/2/2005 9:10 AM, James Kempf wrote: > > The requirements were designed for network-based localized mobility > > management, which includes Layer 3 handover support. One area of > > orthogonality might be whether or not the IP address changes on handover. In > > netlmm, it doesn't. With network-based handover support, it might. Is that > > what you mean? > > > > jak > > > > > > ----- Original Message ----- > > From: "Telemaco Melia" > > To: "James Kempf" > > Cc: "Davis, Terry L" ; ; > > > > Sent: Tuesday, August 02, 2005 6:04 AM > > Subject: Re: [Mobopts] RE: aviation industry > > > > > > > >>Thanks James for the hint. > >>I ll read the document carefully, however from a first impression I have > >>the feeling the issues > >>are orthogonal. Wrong assumption? > >> > >>regards, > >>telemaco > >> > >>James Kempf wrote: > >> > >> > >>>Telemaco, > >>> > >>>Please take a look at: > >>> > >>>http://www.ietf.org/internet-drafts/draft-kempf-netlmm-nohost-req-00.txt > >>> > >>>This is a list of requirements for network-based localized mobility > >>>mangagement we discussed at the netlmm BOF. If there are any changes > >> > > needed, > > > >>>let us know and we can put them in. > >>> > >>>BTW, if you want to subscribe to the netlmm mailing list, it is at: > >>> > >>>https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm > >>> > >>> jak > >>> > >>>----- Original Message ----- > >>>From: "Davis, Terry L" > >>>To: "Telemaco Melia" > >>>Cc: > >>>Sent: Tuesday, August 02, 2005 5:04 AM > >>>Subject: [Mobopts] RE: aviation industry > >>> > >>> > >>>Telemaco > >>> > >>>I have promised to provide a draft of aviation requirements to Jim > >>>Kempf; so it will show up in the next few months. > >>> > >>>Take care > >>>Terry > >>>-----Original Message----- > >>>From: Telemaco Melia [mailto:telemaco.melia@netlab.nec.de] > >>>Sent: Tuesday, August 02, 2005 2:13 AM > >>>To: Davis, Terry L > >>>Cc: ruilaa@det.ua.pt; njs@av.it.pt; mobopts@irtf.org > >>>Subject: Re: aviation industry > >>> > >>>Davis, Terry L wrote: > >>> > >>> > >>> > >>> > >>>>Rui/Telemanco/Nuno > >>>> > >>>>I found your presentation on v6 Network Initiated handoff very > >>>>interesting, especially the dual homed support, which is a requirement > >>>>of the aviation industry. > >>>> > >>>>Take care > >>>>Terry > >>>> > >>>>http://www.ietf.org/internet-drafts/draft-melia-mobopts-niho-fmip-01.tx > >>>> > >>>> > >>> > >>>t > >>> > >>> > >>> > >>>> > >>>> > >>>Hi Terry, > >>> > >>>this is good to know. > >>>Could you give more hints on what aviation industry is expecting? > >>>Maybe you have some published documents on such a matter... > >>> > >>>regards, > >>>telemaco > >>> > >>>_______________________________________________ > >>>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 Wed Aug 03 03:44:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DvF-000106-BG; Wed, 03 Aug 2005 03:44:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DvC-0000zY-Sq for mobopts@megatron.ietf.org; Wed, 03 Aug 2005 03:44: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 DAA21964 for ; Wed, 3 Aug 2005 03:44:13 -0400 (EDT) Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0ERn-0001BN-DH for mobopts@irtf.org; Wed, 03 Aug 2005 04:17:59 -0400 Received: from rodin.i2r.a-star.edu.sg (localhost [127.0.0.1]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id j737hxB3014196 for ; Wed, 3 Aug 2005 15:43:59 +0800 (SGT) Received: from newmailhost.i2r.a-star.edu.sg ([192.122.134.76])by rodin.i2r. a-star.edu.sg (8.13.1/8.13.1) with ESMTP id j737hwlK014182for ; Wed, 3 Aug 2005 15:43:59 +0800 (SGT) Received: from i2r.a-star.edu.sg (localhost [127.0.0.1])by mailhost.lit.org. sg (Sun Java System Messaging Server 6.1 HotFix 0.06(built Nov 11 2004)) wi th ESMTP id <0IKM009AAYTFHU00@mailhost.lit.org.sg> formobopts@irtf.org; Wed , 03 Aug 2005 15:44:03 +0800 (SGT) Received: from [192.122.139.152] by mailhost.lit.org.sg (mshttpd); Wed,03 Au g 2005 15:44:03 +0800 Date: Wed, 03 Aug 2005 15:44:03 +0800 From: Qiu Ying Subject: Re: [Mobopts] Re: [Mip6] [Fwd: FW:resubmit draft-irtf-mobopts-locat ion-privacy-ps-00.txtwith revised boilerplate] To: Rajeev Koodli Message-id: <866fa8ca76aa.42f0e643@i2r.a-star.edu.sg> MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.06 (built Nov 1 12004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-imss-version: 2.29 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:5 C:4 M:4 S:4 R:4 (1.5000 1.5000) X-Spam-Score: 2.4 (++) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7BIT Cc: mip6@ietf.org, Wassim Haddad , Ryuji Wakikawa , 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, Yes, RFC3775 only mentions that the SQN should be larger than the previous one. The new issue is how to let the receiver know the increment if we does not use a fixed one.. -- Qiu Ying ----- Original Message ----- From: Rajeev Koodli Date: Wednesday, August 3, 2005 1:30 am Subject: Re: [Mobopts] Re: [Mip6] [Fwd: FW:resubmit draft-irtf-mobopts-locat ion-privacy-ps-00.txtwith revised boilerplate] > > > Ryuji Wakikawa wrote: > > > Hi Wassim > > > > I agree most of implementation today just increment one for > sequence > > number. > > Is there any description in RFC3775 saying that MN must > increment > > sequentially for Seq number? > > I was looking for that. I could not find text that says the Sequence > Number must be incremented by one. The only requirement is that it is > greater than the previous one. > > -Rajeev > > > > > > > > ryuji > > > > > > On 2005/07/12, at 12:50, Wassim Haddad wrote: > > > >> 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 > >> > >> > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > 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 Aug 03 03:45:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DwZ-0001Mz-97; Wed, 03 Aug 2005 03:45:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DwV-0001MD-J0 for mobopts@megatron.ietf.org; Wed, 03 Aug 2005 03:45: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 DAA22032 for ; Wed, 3 Aug 2005 03:45:31 -0400 (EDT) Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0ET6-0001GM-KX for mobopts@irtf.org; Wed, 03 Aug 2005 04:19:17 -0400 Received: from rodin.i2r.a-star.edu.sg (localhost [127.0.0.1]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id j737jNQP014670 for ; Wed, 3 Aug 2005 15:45:23 +0800 (SGT) Received: from newmailhost.i2r.a-star.edu.sg ([192.122.134.76])by rodin.i2r. a-star.edu.sg (8.13.1/8.13.1) with ESMTP id j737jLns014648for ; Wed, 3 Aug 2005 15:45:21 +0800 (SGT) Received: from i2r.a-star.edu.sg (localhost [127.0.0.1])by mailhost.lit.org. sg (Sun Java System Messaging Server 6.1 HotFix 0.06(built Nov 11 2004)) wi th ESMTP id <0IKM009BAYVQHU00@mailhost.lit.org.sg> formobopts@irtf.org; Wed , 03 Aug 2005 15:45:26 +0800 (SGT) Received: from [192.122.139.152] by mailhost.lit.org.sg (mshttpd); Wed,03 Au g 2005 15:45:26 +0800 Date: Wed, 03 Aug 2005 15:45:26 +0800 From: Qiu Ying Subject: Re: [Mobopts] Re: [Mip6] [Fwd: FW:resubmit draft-irtf-mobopts-locat ion-privacy-ps-00.txtwith revised boilerplate] To: Rajeev Koodli Message-id: <8674a0272826.42f0e696@i2r.a-star.edu.sg> MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.06 (built Nov 1 12004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-imss-version: 2.29 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:5 C:4 M:4 S:4 R:4 (1.5000 1.5000) X-Spam-Score: 2.4 (++) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7BIT Cc: mip6@ietf.org, Wassim Haddad , Ryuji Wakikawa , 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, Yes, RFC3775 only mentions that the SQN should be larger than the previous one. The new issue is how to let the receiver know the increment if we does not use a fixed one.. -- Qiu Ying ----- Original Message ----- From: Rajeev Koodli Date: Wednesday, August 3, 2005 1:30 am Subject: Re: [Mobopts] Re: [Mip6] [Fwd: FW:resubmit draft-irtf-mobopts-locat ion-privacy-ps-00.txtwith revised boilerplate] > > > Ryuji Wakikawa wrote: > > > Hi Wassim > > > > I agree most of implementation today just increment one for > sequence > > number. > > Is there any description in RFC3775 saying that MN must > increment > > sequentially for Seq number? > > I was looking for that. I could not find text that says the Sequence > Number must be incremented by one. The only requirement is that it is > greater than the previous one. > > -Rajeev > > > > > > > > ryuji > > > > > > On 2005/07/12, at 12:50, Wassim Haddad wrote: > > > >> 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 > >> > >> > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > 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 Aug 03 04:05:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0EFK-0007Db-Tq; Wed, 03 Aug 2005 04:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0EFJ-0007CK-DW for mobopts@megatron.ietf.org; Wed, 03 Aug 2005 04:05:01 -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 EAA23204 for ; Wed, 3 Aug 2005 04:04:59 -0400 (EDT) Received: from yui.nc.u-tokyo.ac.jp ([130.69.251.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Elx-000285-AA for mobopts@irtf.org; Wed, 03 Aug 2005 04:38:45 -0400 Received: from wired-6-22.ietf63.ietf.org.sfc.wide.ad.jp (wired-6-22.ietf63.ietf.org [86.255.6.22]) (authenticated bits=0) by yui.nc.u-tokyo.ac.jp (8.12.10/8.12.3/Debian-6.4) with ESMTP id j7384J64011929; Wed, 3 Aug 2005 17:04:23 +0900 Date: Wed, 03 Aug 2005 17:04:16 +0900 Message-ID: From: Ryuji Wakikawa To: Wassim Haddad Subject: Re: [Mobopts] Re: [Mip6] [Fwd: FW: resubmit draft-irtf-mobopts-location-privacy-ps-00.txt with revised boilerplate] In-Reply-To: References: <42D2F384.6050107@iprg.nokia.com> <06567170-0DCA-421C-BD93-14CD5A1DA834@sfc.wide.ad.jp> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/22.0.50 (powerpc-apple-darwin8.1.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 2.4 (++) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, Ryuji Wakikawa , 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 Hello Wassim At Wed, 3 Aug 2005 10:01:16 +0300 (EEST), Wassim Haddad wrote: >=20 > Hi Ryuji, >=20 > On Wed, 3 Aug 2005, Ryuji Wakikawa wrote: >=20 > > Hi Wassim > > > > I just saw the Rajeev's presentation. > > > > If a MN can randomly generate a sequence value that is larger than > > the previous value and within sequence number window, it's hard to track > > the mobile node. no? >=20 > =3D> IMHO, this may not be enough. The SQN should appear for an eavesdrop= per > as random and not larger than the previous one (i.e., this is still > traceable). > This issue has been addressed in: > draft-haddad-privacy-omipv6-anonymity-00 Well, it's worth to look SQN trace, but we may solve this by operations.=20 MIP6 has the notion of window for SQN. In some case, the SQN is smaller than the previous one for eavesdropper, but still valid due to SQN turnover (within SQN window). > > I agree most of implementation today just increment one for sequence > > number. >=20 > > Is there any description in RFC3775 saying that MN must increment > > sequentially for Seq number? >=20 > =3D> I think RFC3775 just mention that it should be larger. Ok ryuji >=20 > Regards, >=20 > Wassim H. >=20 >=20 > > On 2005/07/12, at 12:50, Wassim Haddad wrote: > > > > > 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. > =C3> > > > > 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 > > > > > > > > > > > > >=20 _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Aug 03 05:04:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FAz-0002wM-Ki; Wed, 03 Aug 2005 05:04:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FAw-0002tY-3s for mobopts@megatron.ietf.org; Wed, 03 Aug 2005 05:04:34 -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 FAA26470 for ; Wed, 3 Aug 2005 05:04:31 -0400 (EDT) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0FhZ-0004sC-AS for mobopts@irtf.org; Wed, 03 Aug 2005 05:38:18 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 8671E8004B0; Wed, 3 Aug 2005 12:04:22 +0300 (EEST) Date: Wed, 3 Aug 2005 12:04:22 +0300 (EEST) From: Wassim Haddad To: Qiu Ying Subject: Re: [Mobopts] Re: [Mip6] [Fwd: FW:resubmit draft-irtf-mobopts-locat ion-privacy-ps-00.txtwith revised boilerplate] In-Reply-To: <866fa8ca76aa.42f0e643@i2r.a-star.edu.sg> Message-ID: References: <866fa8ca76aa.42f0e643@i2r.a-star.edu.sg> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 2.4 (++) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: mip6@ietf.org, Ryuji Wakikawa , 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 On Wed, 3 Aug 2005, Qiu Ying wrote: > Hi, > Yes, RFC3775 only mentions that the SQN should be larger than the previous one. The new issue is how to let > the receiver know the increment if we does not use a fixed one.. => IMHO, the CN can compute the "next", i.e., expected SQN, in the same way as the MN. In this case, if the new BU message sent by the MN does not carry the expected SQN, then it will be rejected. Regards, Wassim H. > -- Qiu Ying > > ----- Original Message ----- > From: Rajeev Koodli > Date: Wednesday, August 3, 2005 1:30 am > Subject: Re: [Mobopts] Re: [Mip6] [Fwd: FW:resubmit draft-irtf-mobopts-locat ion-privacy-ps-00.txtwith revised boilerplate] > > > > > > > Ryuji Wakikawa wrote: > > > > > Hi Wassim > > > > > > I agree most of implementation today just increment one for > > sequence > > > number. > > > Is there any description in RFC3775 saying that MN must > > increment > > > sequentially for Seq number? > > > > I was looking for that. I could not find text that says the Sequence > > Number must be incremented by one. The only requirement is that it is > > greater than the previous one. > > > > -Rajeev > > > > > > > > > > > > > > ryuji > > > > > > > > > On 2005/07/12, at 12:50, Wassim Haddad wrote: > > > > > >> 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 > > >> > > >> > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > > 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 Aug 03 05:18:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FOT-0001gG-GQ; Wed, 03 Aug 2005 05:18:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FOQ-0001bY-Py for mobopts@megatron.ietf.org; Wed, 03 Aug 2005 05:18: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 FAA27388 for ; Wed, 3 Aug 2005 05:18:28 -0400 (EDT) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Fv4-0005W8-GZ for mobopts@irtf.org; Wed, 03 Aug 2005 05:52:16 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 3EAAC8004B0; Wed, 3 Aug 2005 12:18:20 +0300 (EEST) Date: Wed, 3 Aug 2005 12:18:20 +0300 (EEST) From: Wassim Haddad To: Jianying Zhou Subject: Re: [Mobopts] Re: [Mip6] [Fwd: FW:resubmit draft-irtf-mobopts-locat ion-privacy-ps-00.txtwith revised boilerplate] In-Reply-To: <42F08B2B.5010909@i2r.a-star.edu.sg> Message-ID: References: <866fa8ca76aa.42f0e643@i2r.a-star.edu.sg> <42F08B2B.5010909@i2r.a-star.edu.sg> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 2.4 (++) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: mip6@ietf.org, 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 On Wed, 3 Aug 2005, Jianying Zhou wrote: > Is the algorithm confidential (only known to MN and CN)? > > - If yes, how to share the secret? => Yes it is confidential. Please check draft-haddad-privacy-omipv6-anonymity-00 Regards, Wassim H. > Wassim Haddad wrote: > > >On Wed, 3 Aug 2005, Qiu Ying wrote: > > > > > > > >>Hi, > >>Yes, RFC3775 only mentions that the SQN should be larger than the previous one. The new issue is how to let > >>the receiver know the increment if we does not use a fixed one.. > >> > >> > > > >=> IMHO, the CN can compute the "next", i.e., expected SQN, in the same way as the MN. In this case, if the > >new BU message sent by the MN does not carry the expected SQN, then it will be rejected. > > > > > >Regards, > > > >Wassim H. > > > > > > > > > >>-- Qiu Ying > >> > >>----- Original Message ----- > >>From: Rajeev Koodli > >>Date: Wednesday, August 3, 2005 1:30 am > >>Subject: Re: [Mobopts] Re: [Mip6] [Fwd: FW:resubmit draft-irtf-mobopts-locat ion-privacy-ps-00.txtwith revised boilerplate] > >> > >> > >> > >>>Ryuji Wakikawa wrote: > >>> > >>> > >>> > >>>>Hi Wassim > >>>> > >>>>I agree most of implementation today just increment one for sequence number. > >>>>Is there any description in RFC3775 saying that MN must increment > >>>> > >>>> > >>>>sequentially for Seq number? > >>>> > >>>> > >>>I was looking for that. I could not find text that says the Sequence > >>>Number must be incremented by one. The only requirement is that it is > >>>greater than the previous one. > >>> > >>>-Rajeev > >>> > >>> > >>> > >>> > >>> > >>> > >>>>ryuji > >>>> > >>>> > >>>>On 2005/07/12, at 12:50, Wassim Haddad wrote: > >>>> > >>>> > >>>> > >>>>>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. > >>>>> > >>>>> > >>>>> > >>>>> > > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Aug 04 05:09:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bjO-0001j2-Mr; Thu, 04 Aug 2005 05:09:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bjM-0001ig-IX for mobopts@megatron.ietf.org; Thu, 04 Aug 2005 05:09: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 FAA14748 for ; Thu, 4 Aug 2005 05:09:34 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0cGC-00077D-QG for mobopts@irtf.org; Thu, 04 Aug 2005 05:43:34 -0400 Received: from [86.255.25.220] (open-25-220.ietf63.ietf.org [86.255.25.220]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id E9D784CC73; Thu, 4 Aug 2005 18:09:24 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Koshiro MITSUYA Date: Thu, 4 Aug 2005 18:09:38 +0900 To: mobopts@irtf.org X-Mailer: Apple Mail (2.730) X-Spam-Score: 2.4 (++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: Koshiro MITSUYA Subject: [Mobopts] another approach using L2 character for adaptation 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 all, As Ryuji Wakikawa commented on draft-daniel-mip-link-characteristic-02 during IRTF session, here is our earlier output about dynamic adaptation based on L2 characteristic. If you are interesting, please look at the following short paper. http://www.sfc.wide.ad.jp/~mitsuya/PAPERS/ITST2005-mitsuya-final.pdf regards, Koshiro MITSUYA Jun MURAI lan., Keio University _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Aug 04 07:43:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0e8j-0008H3-3o; Thu, 04 Aug 2005 07:43:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0e8h-0008CT-AB for mobopts@megatron.ietf.org; Thu, 04 Aug 2005 07:43: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 HAA28836 for ; Thu, 4 Aug 2005 07:43:54 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX19ywS2ro/rJCUx3L8jHp3lnBRlXgGE6Jq8=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0efX-0006Dw-NC for mobopts@irtf.org; Thu, 04 Aug 2005 08:17:54 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1E0e8Q-0006tI-DB; Thu, 04 Aug 2005 13:43:43 +0200 Received: from [86.255.6.62] (wired-6-62.ietf63.ietf.org [86.255.6.62]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 82AA38542; Thu, 4 Aug 2005 13:43:37 +0200 (CEST) Message-ID: <42F1FF62.7010002@tm.uka.de> Date: Thu, 04 Aug 2005 13:43:30 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; us-US; 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: fanzhao@ucdavis.edu, sfwu@ucdavis.edu, jyzhou@i2r.a-star.edu.sg, souhwanj@ssu.ac.kr Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) X-Spam-Status: No X-Spam-Score: 2.4 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Jari Arkko , MOBOPTS Subject: [Mobopts] Using Hashes to Optimize RR 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, here is the draft that I mentioned after the presentation "Improvement on Security and Performance of MIP6 Return Routability Test", and which might be of relevance to the presentors: Credit-Based Authorization for Binding Lifetime Extension draft-arkko-mipv6-binding-lifetime-extension-00.txt The draft describes a hash-based mechanism that allows peers to successively prolong the time period between two home-address tests. This reduces signaling overhead and the latency associated with frequent home-address tests. A correspondent node can validate from a hash how long a MN has already been reachable at a given home address, and it can so extend the lifetime of a binding. The draft above might Regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Aug 04 08:01:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ePE-0003mF-RV; Thu, 04 Aug 2005 08:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ePD-0003m4-JA for mobopts@megatron.ietf.org; Thu, 04 Aug 2005 08:00: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 IAA29586 for ; Thu, 4 Aug 2005 08:00:58 -0400 (EDT) Received: from mail1.rz.fhtw-berlin.de ([141.45.5.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0ew4-0006s1-8T for mobopts@irtf.org; Thu, 04 Aug 2005 08:34:58 -0400 Received: from open-28-88.ietf63.ietf.org ([86.255.28.88]) by mail1.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42 (FreeBSD)) id 1E0eOs-000Nn1-9R for mobopts@irtf.org; Thu, 04 Aug 2005 14:00:38 +0200 Message-ID: <42F2047D.2060900@fhtw-berlin.de> Date: Thu, 04 Aug 2005 14:05:17 +0200 From: Thomas Schmidt 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-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [Mobopts] Paper: Reactive versus Predictive 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 Hi, there was some interest in the paper mentioned today: "Predictive versus Reactive - Analysis of Handover Performance and its Implications on IPv6 and Multicast Mobility." Here is the link: http://www.rz.fhtw-berlin.de/projekte/mipv6/telesys05.pdf It will appear in Telecommunication Systems probably in October 2005. Cheers, thomas & matthias _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Aug 04 08:09:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0eXu-0007oD-0m; Thu, 04 Aug 2005 08:09:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0eXt-0007o8-7F for mobopts@megatron.ietf.org; Thu, 04 Aug 2005 08:09: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 IAA00545 for ; Thu, 4 Aug 2005 08:09:56 -0400 (EDT) Received: from pollux.ietf63.ietf.org ([86.255.2.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0f4l-0007Lz-8b for mobopts@irtf.org; Thu, 04 Aug 2005 08:43:56 -0400 Received: from SOUHWANSENSQ (open-25-140.ietf63.ietf.org [86.255.25.140]) by pollux.ietf63.ietf.org (Postfix) with SMTP id 4A59B37; Thu, 4 Aug 2005 05:09:35 -0700 (PDT) Message-ID: <000a01c598ed$686f1a70$8c19ff56@SOUHWANSENSQ> From: "Souhwan Jung \(???\)" To: "Christian Vogt" , , , References: <42F1FF62.7010002@tm.uka.de> Date: Thu, 4 Aug 2005 21:09:47 +0900 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 2.4 (++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Jari Arkko , MOBOPTS Subject: [Mobopts] Re: Using Hashes to Optimize RR 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 Thanks, Christian. I will take a look at the draft, and get back to the issue. Souhwan ----- Original Message ----- ?? ??: "Christian Vogt" ?? ??: ; ; ; ??: "MOBOPTS" ; "Jari Arkko" ?? ??: 2005? 8? 4? ??? ?? 8:43 ??: Using Hashes to Optimize RR > Hello, > > here is the draft that I mentioned after the presentation "Improvement > on Security and Performance of MIP6 Return Routability Test", and which > might be of relevance to the presentors: > > Credit-Based Authorization for Binding Lifetime Extension > draft-arkko-mipv6-binding-lifetime-extension-00.txt > > The draft describes a hash-based mechanism that allows peers to > successively prolong the time period between two home-address tests. > This reduces signaling overhead and the latency associated with frequent > home-address tests. A correspondent node can validate from a hash how > long a MN has already been reachable at a given home address, and it can > so extend the lifetime of a binding. > > The draft above might > > Regards, > - Christian > > -- > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Aug 04 10:49:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0h1t-0002JZ-0z; Thu, 04 Aug 2005 10:49:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0h1r-0002JU-Vq for mobopts@megatron.ietf.org; Thu, 04 Aug 2005 10:49:04 -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 KAA16726 for ; Thu, 4 Aug 2005 10:49:01 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0hYk-0005wn-OT for mobopts@irtf.org; Thu, 04 Aug 2005 11:23:04 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 35B855E76C; Thu, 4 Aug 2005 16:48:52 +0200 (CEST) Received: from wired-6-5.ietf63.ietf.org (wired-6-5.ietf63.ietf.org [86.255.6.5]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id D07AB5E763; Thu, 4 Aug 2005 16:48:51 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Christian Vogt Organization: UC3M Date: Thu, 04 Aug 2005 16:49:01 +0200 Message-Id: <1123166941.21156.10.camel@acorde> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-Spam-Score: 2.4 (++) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: MOBOPTS Subject: [Mobopts] Comments and reference for section 6.19 of draft-irtf-mobopts-ro-enhancements-01.tx 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="===============0298574174==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org --===============0298574174== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-+slyQiTbTbp8pqaJAVhd" --=-+slyQiTbTbp8pqaJAVhd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Christian, I have one question about Section 6.19. It says: "It is relatively straightforward to optimize bidirectional tunneling for moving networks [39] by using a single home agent and a single tunnel between the mobile router and that home agent". RFC3963 does not specify any kind of RO (the use of the bidirectional tunnel is no optimal), so I think you mean "It is relatively straightforward to support network mobility [39] by using a single home agent and a single bidirectional tunnel between the mobile router and that home agent". Did I miss/missunderstand something? I think that draft-bernardos-nemo-miron-00.txt could be referenced in your draft when you describe the RO for NEMO consisting in the MR performing the MIPv6 signalling on behalf of the nodes of the NEMO. The approach described in the draft exactly consists on that. IMHO, some text could also be added about the NEMO-specific RO problem of nesting (mobile networks that attach to another mobile network). Do you think is appropriate? I think that could be also useful to add a reference to draft-ietf-nemo-ro-problem-statement-00.txt. What do you think? Kind Regards, Carlos J. --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-+slyQiTbTbp8pqaJAVhd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBC8ird7QxZUr+JuXQRAiH0AKCrY8c7QngyI5qwVCWiNeTfZsRQIACfTYVz zaDj8GLZiAMA3Gs650dQeKQ= =QCIw -----END PGP SIGNATURE----- --=-+slyQiTbTbp8pqaJAVhd-- --===============0298574174== 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 --===============0298574174==-- From mobopts-bounces@irtf.org Thu Aug 04 14:54:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0krU-0007O2-4A; Thu, 04 Aug 2005 14:54:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0krS-0007Np-0u for mobopts@megatron.ietf.org; Thu, 04 Aug 2005 14:54:34 -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 OAA29298 for ; Thu, 4 Aug 2005 14:54:32 -0400 (EDT) Received: from mx5.ucdavis.edu ([169.237.104.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0lON-00042r-7K for mobopts@irtf.org; Thu, 04 Aug 2005 15:28:36 -0400 Received: from tremex.ucdavis.edu (tremex.ucdavis.edu [169.237.104.172]) by mx5.ucdavis.edu (8.13.3/8.13.1/it-defang-5.4.0) with ESMTP id j74IroJX013871; Thu, 4 Aug 2005 11:53:50 -0700 (PDT) Received: from tremex.ucdavis.edu (localhost [127.0.0.1]) by tremex.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j74Irn4E006422; Thu, 4 Aug 2005 11:53:49 -0700 (PDT) Received: (from www@localhost) by tremex.ucdavis.edu (8.12.10/8.12.9/Submit) id j74IrldG006421; Thu, 4 Aug 2005 11:53:47 -0700 (PDT) Date: Thu, 4 Aug 2005 11:53:47 -0700 (PDT) Message-Id: <200508041853.j74IrldG006421@tremex.ucdavis.edu> To: Christian Vogt , sfwu@ucdavis.edu, jyzhou@i2r.a-star.edu.sg, souhwanj@ssu.ac.kr From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [169.237.7.45] X-User-Agent: Mozilla/5.0 (compatible; Konqueror/3.1; Linux) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.15 X-Spam-Score: 2.4 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Jari Arkko , MOBOPTS Subject: [Mobopts] RE: Using Hashes to Optimize RR 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, Thank you very much. I will take a look and comment on that. Sincerely, fan > Hello, > > here is the draft that I mentioned after the presentation "Improvement > on Security and Performance of MIP6 Return Routability Test", and which > might be of relevance to the presentors: > > Credit-Based Authorization for Binding Lifetime Extension > draft-arkko-mipv6-binding-lifetime-extension-00.txt > > The draft describes a hash-based mechanism that allows peers to > successively prolong the time period between two home-address tests. > This reduces signaling overhead and the latency associated with frequent > home-address tests. A correspondent node can validate from a hash how > long a MN has already been reachable at a given home address, and it can > so extend the lifetime of a binding. > > The draft above might > > Regards, > - Christian > > -- > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Aug 04 19:14:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ouw-0005Yu-Ed; Thu, 04 Aug 2005 19:14:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ouu-0005Ym-Mf for mobopts@megatron.ietf.org; Thu, 04 Aug 2005 19:14: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 TAA16600 for ; Thu, 4 Aug 2005 19:14:21 -0400 (EDT) Received: from smtp101.sbc.mail.mud.yahoo.com ([68.142.198.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E0pRq-0002dR-Sx for mobopts@irtf.org; Thu, 04 Aug 2005 19:48:29 -0400 Received: (qmail 81347 invoked from network); 4 Aug 2005 23:13:56 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@67.123.80.64 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 4 Aug 2005 23:13:56 -0000 Message-ID: <004201c5994a$307ec090$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "James Kempf" , References: <09a101c59760$57f0a350$596015ac@dcml.docomolabsusa.com> <42EF6F6A.3040803@netlab.nec.de><09fc01c59763$a12b1980$596015ac@dcml.docomolabsusa.com><42EFA9E9.8050509@lucent.com> <0c3201c597fd$ad4cd1a0$596015ac@dcml.docomolabsusa.com> Subject: Re: [Mobopts] RE: aviation industry Date: Thu, 4 Aug 2005 16:13:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 2.5 (++) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: 7bit Cc: netlmm@ngnet.it, "Davis, Terry L" , 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 > Another application might want to cover just a single building, like maybe > Sano Tower in Tokyo, though that level might more easily be handled by > TRILL. > TRILL does not cover mobility as far as i can read from the charter. Even if it does, it wouldn't be optimized for mobility i guess. So, can you clarify ? -mohan > > jak > > > ----- Original Message ----- > From: "Ajay Rajkumar" > To: "James Kempf" > Cc: "Telemaco Melia" ; ; > "Davis, Terry L" ; > Sent: Tuesday, August 02, 2005 10:14 AM > Subject: Re: [Mobopts] RE: aviation industry > > > > James, > > > > Could you elaborate on the "localized" part of the localized mobility > > management? What are the assumptions on localized? > > > > -ajay > > > > On 8/2/2005 9:10 AM, James Kempf wrote: > > > The requirements were designed for network-based localized mobility > > > management, which includes Layer 3 handover support. One area of > > > orthogonality might be whether or not the IP address changes on > handover. In > > > netlmm, it doesn't. With network-based handover support, it might. Is > that > > > what you mean? > > > > > > jak > > > > > > > > > ----- Original Message ----- > > > From: "Telemaco Melia" > > > To: "James Kempf" > > > Cc: "Davis, Terry L" ; ; > > > > > > Sent: Tuesday, August 02, 2005 6:04 AM > > > Subject: Re: [Mobopts] RE: aviation industry > > > > > > > > > > > >>Thanks James for the hint. > > >>I ll read the document carefully, however from a first impression I have > > >>the feeling the issues > > >>are orthogonal. Wrong assumption? > > >> > > >>regards, > > >>telemaco > > >> > > >>James Kempf wrote: > > >> > > >> > > >>>Telemaco, > > >>> > > >>>Please take a look at: > > >>> > > > >>>http://www.ietf.org/internet-drafts/draft-kempf-netlmm-nohost-req-00.txt > > >>> > > >>>This is a list of requirements for network-based localized mobility > > >>>mangagement we discussed at the netlmm BOF. If there are any changes > > >> > > > needed, > > > > > >>>let us know and we can put them in. > > >>> > > >>>BTW, if you want to subscribe to the netlmm mailing list, it is at: > > >>> > > >>>https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm > > >>> > > >>> jak > > >>> > > >>>----- Original Message ----- > > >>>From: "Davis, Terry L" > > >>>To: "Telemaco Melia" > > >>>Cc: > > >>>Sent: Tuesday, August 02, 2005 5:04 AM > > >>>Subject: [Mobopts] RE: aviation industry > > >>> > > >>> > > >>>Telemaco > > >>> > > >>>I have promised to provide a draft of aviation requirements to Jim > > >>>Kempf; so it will show up in the next few months. > > >>> > > >>>Take care > > >>>Terry > > >>>-----Original Message----- > > >>>From: Telemaco Melia [mailto:telemaco.melia@netlab.nec.de] > > >>>Sent: Tuesday, August 02, 2005 2:13 AM > > >>>To: Davis, Terry L > > >>>Cc: ruilaa@det.ua.pt; njs@av.it.pt; mobopts@irtf.org > > >>>Subject: Re: aviation industry > > >>> > > >>>Davis, Terry L wrote: > > >>> > > >>> > > >>> > > >>> > > >>>>Rui/Telemanco/Nuno > > >>>> > > >>>>I found your presentation on v6 Network Initiated handoff very > > >>>>interesting, especially the dual homed support, which is a requirement > > >>>>of the aviation industry. > > >>>> > > >>>>Take care > > >>>>Terry > > >>>> > > > >>>>http://www.ietf.org/internet-drafts/draft-melia-mobopts-niho-fmip-01.tx > > >>>> > > >>>> > > >>> > > >>>t > > >>> > > >>> > > >>> > > >>>> > > >>>> > > >>>Hi Terry, > > >>> > > >>>this is good to know. > > >>>Could you give more hints on what aviation industry is expecting? > > >>>Maybe you have some published documents on such a matter... > > >>> > > >>>regards, > > >>>telemaco > > >>> > > >>>_______________________________________________ > > >>>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 _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Aug 05 02:56:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0w89-0001LP-Up; Fri, 05 Aug 2005 02:56:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0w87-0001LI-47 for mobopts@megatron.ietf.org; Fri, 05 Aug 2005 02:56:31 -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 CAA19140 for ; Fri, 5 Aug 2005 02:56:29 -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 1E0wf8-0004Ig-Sl for mobopts@irtf.org; Fri, 05 Aug 2005 03:30:40 -0400 Message-ID: <007701c5998a$cba82c60$596015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Mohan Parthasarathy" , References: <09a101c59760$57f0a350$596015ac@dcml.docomolabsusa.com> <42EF6F6A.3040803@netlab.nec.de><09fc01c59763$a12b1980$596015ac@dcml.docomolabsusa.com><42EFA9E9.8050509@lucent.com> <0c3201c597fd$ad4cd1a0$596015ac@dcml.docomolabsusa.com> <004201c5994a$307ec090$6501a8c0@adithya> Subject: Re: [Mobopts] RE: aviation industry Date: Thu, 4 Aug 2005 23:56:08 -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: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: netlmm@ngnet.it, "Davis, Terry L" , 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 > > Another application might want to cover just a single building, like maybe > > Sano Tower in Tokyo, though that level might more easily be handled by > > TRILL. > > > TRILL does not cover mobility as far as i can read from the charter. Even > if it does, it wouldn't be optimized for mobility i guess. So, can you clarify ? > This is new since I last tuned into TRILL. Thanx for the update. jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Aug 09 07: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 1E2Sk2-0004li-Dt; Tue, 09 Aug 2005 07: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 1E2Sk0-0004lB-PM for mobopts@megatron.ietf.org; Tue, 09 Aug 2005 07: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 HAA00838 for ; Tue, 9 Aug 2005 07:57:55 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2THu-0004uK-HE for mobopts@irtf.org; Tue, 09 Aug 2005 08:32:59 -0400 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 5CDECDC31; Tue, 9 Aug 2005 13:57: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); Tue, 9 Aug 2005 13:57:39 +0200 Message-ID: <42F89A33.8010202@netlab.nec.de> Date: Tue, 09 Aug 2005 13:57: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: multipart/mixed; boundary="------------040302000408090906010203" X-OriginalArrivalTime: 09 Aug 2005 11:57:39.0301 (UTC) FILETIME=[8A5B6950:01C59CD9] X-Spam-Score: 2.4 (++) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: Rajeev Koodli Subject: [Mobopts] Paris minutes 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. --------------040302000408090906010203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Attached. Let me know if something is missing. regards, Telemaco --------------040302000408090906010203 Content-Type: text/plain; name="MobOpts@IETF63_2session.txt" Content-Disposition: inline; filename="MobOpts@IETF63_2session.txt" Content-Transfer-Encoding: 7bit MOBOPTS Research Group Thursday, August 4, 2005 1030 - 1230 Morning Session II Room 351 ============================== Minutes taken by Telemaco Melia, telemaco.melia@netlab.nec.de Agenda ====== 1. RG status update, new topics (chair, 5 - 10 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. RG Update ========= RG Documents status: - RO document: a lot of reviews/comments received on the mailing list - Handover keys SEND document is already in the hands of the Mipshop WG J. Korhonen on link layer characteristscs for Mobile IP ================================================= Q&A Farooq Bari: TCP can adjust itself with info (UDP as well). Why do you want to do something like this? J. Korhonen: Current HO from/to WLAN GPRS TCP take long time to adjust to new characteristics. Also other transport layers. Ajoy Singh: Do you need an explicit signalling? The MN knows hs is going to move. Please take it up on the list Gabriel Montenegro: Why do you limit the info delivery only during the HO mechanism? The bandwitdh changes dramatically also not in HO case Jouni Korhonen: From a general perspective makes sense to have it in the roaming signaling. Rajeev Koodli: We have to use what exists as much as possible Jari Arkko: You can learn information faster but what do you do with this information? What TCP does with that? Rajeev Koodli: You have to scope the problem really well. Difference between HA and CN exists. Christian Vogt: Why not just leave this problem to the transport? Probably this is enough to handle the issue only on the MN side. Aaron Falk: This work is difficult. Link indication is already existing: plese read the draft Please also refer to the link indication discusison on the technical plenary. unknown: A more General approach would be good Samita Chakrabarti on Low pan Mobility requirements =================================================== Rajeev Koodli: good start Rie Shibui on Unified L2 triggers for L3 handovers ================================================== Refer to the folowing document: http://www.ietf.org/internet-drafts/draft-koki-mobopts-l2-abstractions-02.txt Christian Vogt: FNA from userland seems to be too fast (7 ms) Farooq Bari: Please be aware 802.21 is working in this similar area. Zhang on An efficient dynamic multicast agent approach for mobile IPv6 multicast ================================================================================ Rajeev Koodli: Discuss on the mailing list Thomas Schmidt on Seamless Multicast Handover in a Hierarchical Mobile IPv6 Environment M-HMIPv6 ================================================================================================ Rajeev Koodli: tunnel MLD to the MAP? Thomas Schmidt: Yes Rajeev Koodli: Do you have implementation? Thomas Schmidt: Only simulation Christian Vogt: which simulator has been used? Thomas Schmidt: Omnet ++ Christian Vogt: Study of prediction: how did you do it? Thomas Schmidt: Signal degradation and movement: ping pong effects to be taken intco account simulated with an own model the failure depends on the model implemented Christian Vogt: Is the code open source? Thomas Schmidt: Yes can be available MPA Framework and Implementation Updates ======================================== Telemaco Melia: layer two handoff latency looks really short. How did you get such short latency times? Subir Das: we used Atheros CARDs Ajoy Singh: how do you do the neighborhhod disovery? Subir Das: Use 802.21 approach for handover capabilities discovery James kempf on Secure Proxy Neighbor Discovery using Multi-key CGAs =================================================================== Rajeev Koodli: is there any IPR? James kempf: DoCoMo will grant freely the license for interop or standard document James kempf: IETF acitvity on that? Too premature? Rajeev Koodli: Brainstorm: more work on the topic Jari: interesting work, we should go ahead not sure about experimental RFC Zhao on Improvement on Security and Performance of MIP6 Return Routability Test =============================================================================== Rajeev koodli: hash keys are generated after RR: if HoA changes the terminal regenerates the keys. Zhao: yes --------------040302000408090906010203 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 --------------040302000408090906010203-- From mobopts-bounces@irtf.org Sat Aug 13 09:23:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3vyX-0008Fc-LX; Sat, 13 Aug 2005 09:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3vyW-0008F9-65 for mobopts@megatron.ietf.org; Sat, 13 Aug 2005 09:23:00 -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 JAA20753 for ; Sat, 13 Aug 2005 09:22:58 -0400 (EDT) Received: from mail-gw1.york.ac.uk ([144.32.128.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3wXF-0006WY-G9 for mobopts@irtf.org; Sat, 13 Aug 2005 09:58:53 -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 j7DDMlad001065; Sat, 13 Aug 2005 14:22:47 +0100 (BST) Message-ID: <069101c5a00a$af96a610$68892090@grouse> From: "Ji Zhang" To: , "Mobile IP v4" Date: Sat, 13 Aug 2005 14:27:00 +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: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: waa@cs.umd.edu, Rajeev Koodli Subject: [Mobopts] [New I-D] Agent-Based Return Routability Test for Mobile IPv4 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 Dear all, Please find the following a new draft: route optimization for mip4 may be an old topic, just to see if there are still any interests. Comments are highly appreciated. Regards, Ji =================================================== A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Agent-Based Return Routability Test for Mobile IPv4 Route Optimization Author(s) : J. Zhang, D. Pearce Filename : draft-zhang-mobopts-agent-mip4rr-00.txt Pages : 18 Date : 2005-8-12 This document is to propose a more deployable route optimization scheme for Mobile IPv4, which is transparent to fixed IPv4 end nodes, and does not need any preconfigured security associations. Specifically, we propose to adapt the Mobile IPv6 Return Routability Test for Mobile IPv4 route optimization, on the basis of an agent- based architecture. In order to achieve this, six new message types and formats are defined for Mobile IPv4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zhang-mobopts-agent-mip4rr-00.txt _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Aug 24 07:18:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7tH3-0005zt-IY; Wed, 24 Aug 2005 07:18:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7tH2-0005zo-9n for mobopts@megatron.ietf.org; Wed, 24 Aug 2005 07:18: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 HAA13519 for ; Wed, 24 Aug 2005 07:18:27 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7tHI-0004A8-TA for mobopts@irtf.org; Wed, 24 Aug 2005 07:18:47 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 4D7CD89852; Wed, 24 Aug 2005 14:17:59 +0300 (EEST) Message-ID: <430C5772.7090905@kolumbus.fi> Date: Wed, 24 Aug 2005 14:18:10 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: mobopts@irtf.org Subject: [Mobopts] Comments on draft-kempf-mobopts-ringsig-ndproxy-02.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, I read the draft... I liked it a lot, a very nice scheme for a hard problem! Some comments and questions, though: > Prior to verifying the CGA or signature, the verifying node MUST > check that the router public key in the CGA Parameters Option matches > a certified public key from a router on the link. This step assures > that the keys used in signing the signature are both legitimate > members of the group, which in this case consists of the node owning > the address and a certified router on the link. If this step is not > taken, an attacker not authorized to route can sign a message with > its own key and the victim node's public key, then claim to securely > proxy the address on the victim's behalf. > > I don't see how this attack could be done, because if both keys are a part of the CGA parameters then changing either one will change the address. Of course, you may still want to check that the proxy is a legitimate proxy from your point of view. Just because the peer delegated the responsibility to someone may not imply that you want to trust that someone. But this appears to be a different issue than the one that you talk about above. > If a multi-CGA capable node receives a message with a standard RFC > 3971 RSA Signature Option but the CGA Parameters Option contains an > RST Ring Signature Key Suboption, the node SHOULD ignore the RST Ring > Signature Option and treat the message like a standard RFC 3791 SEND- > secured message. The node SHOULD use the standard RSA signature > verification algorithm and the key in the Public Key Field of the CGA > Parameters Option to verify the signature. > > Ignore? As in delete it from the contents of the CGA Parameters Option, or keep it there but not do anything special for it? > concat-val = SHA1(pk(1) | pk(2) | ... | pk(n) ) > Is this necessary, if the other keys are in the CGA parameters block? They would be included as input for the same output value from Step 2 of RFC 3971 Section 4 algorithm, as far as I can see. > The Secure Proxy Mobility Option has the following format: Is there a need to include other information that is used in the calculation of the final address, such as the modifier? Editorial: > and 6 in Section 5. In both steps, instead of calculating the has > s/has/hash/ --Jari _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Aug 24 13:19:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7yu3-0006OI-E7; Wed, 24 Aug 2005 13:19:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7yu1-0006MT-CA for mobopts@megatron.ietf.org; Wed, 24 Aug 2005 13:19: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 NAA06443 for ; Wed, 24 Aug 2005 13:19:00 -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 1E7yuK-0000De-Jr for mobopts@irtf.org; Wed, 24 Aug 2005 13:19:26 -0400 Message-ID: <027501c5a8cf$e65abc90$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jari Arkko" References: <430C5772.7090905@kolumbus.fi> Date: Wed, 24 Aug 2005 10:18:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: mobopts@irtf.org Subject: [Mobopts] Re: Comments on draft-kempf-mobopts-ringsig-ndproxy-02.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 >> Prior to verifying the CGA or signature, the verifying node MUST check >> that the router public key in the CGA Parameters Option matches a >> certified public key from a router on the link. This step assures that >> the keys used in signing the signature are both legitimate members of the >> group, which in this case consists of the node owning the address and a >> certified router on the link. If this step is not taken, an attacker not >> authorized to route can sign a message with its own key and the victim >> node's public key, then claim to securely proxy the address on the >> victim's behalf. > I don't see how this attack could be done, because if both > keys are a part of the CGA parameters then changing either > one will change the address. > > Of course, you may still want to check that the proxy is > a legitimate proxy from your point of view. Just because > the peer delegated the responsibility to someone may > not imply that you want to trust that someone. But this > appears to be a different issue than the one that you > talk about above. > Actually, that is exactly the issue I wanted to address I just didn't describe it correctly. I think I could probably make this a SHOULD. Thanx! >> If a multi-CGA capable node receives a message with a standard RFC >> 3971 RSA Signature Option but the CGA Parameters Option contains an RST >> Ring Signature Key Suboption, the node SHOULD ignore the RST Ring >> Signature Option and treat the message like a standard RFC 3791 SEND- >> secured message. The node SHOULD use the standard RSA signature >> verification algorithm and the key in the Public Key Field of the CGA >> Parameters Option to verify the signature. > Ignore? As in delete it from the contents of the CGA Parameters > Option, or keep it there but not do anything special for it? > RFC 3972 requires extensions to the CGA Parameters option to be concatenated into the calculation for verification. So what I think needs to be done is that, for the purposes of verification, it should not be included in the calculation. This part of RFC 3972 may need some attention. I don't remember what Tuomas and the WG had in mind with this, but the extensions field is underspecified. If it is treated like a standard protocol extension field, there will be TLV values for the extensions, and this is how the multi-key CGA draft treats it. But the way it is incorporated into the verification calculations implies that it is rather some bits that don't have any specific field-like structure or any identifying information as to what the extension is. Should such TLV bits be included into the calculation? They aren't for the base key, 3792 specifies specifically when the encoded public key is used (c.f. Section 4, Step 2). >> concat-val = SHA1(pk(1) | pk(2) | ... | pk(n) ) > Is this necessary, if the other keys are in the CGA parameters > block? They would be included as input for the same output > value from Step 2 of RFC 3971 Section 4 algorithm, as far as > I can see. > I think you mean 3972. Again, it depends on how the extension field is treated. >> The Secure Proxy Mobility Option has the following format: > > Is there a need to include other information that is > used in the calculation of the final address, such as > the modifier? > Right, thanx for catching this. Also the subnet prefix, since the home link may support more than one subnet, and the collision count. jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Aug 24 13:54:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zRo-0001wz-OV; Wed, 24 Aug 2005 13:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zRn-0001wu-TB for mobopts@megatron.ietf.org; Wed, 24 Aug 2005 13:53: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 NAA08409 for ; Wed, 24 Aug 2005 13:53:59 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7zS7-0001Pn-96 for mobopts@irtf.org; Wed, 24 Aug 2005 13:54:22 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5BD1889852; Wed, 24 Aug 2005 20:53:42 +0300 (EEST) Message-ID: <430CB431.3010905@kolumbus.fi> Date: Wed, 24 Aug 2005 20:53:53 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf References: <430C5772.7090905@kolumbus.fi> <027501c5a8cf$e65abc90$196115ac@dcml.docomolabsusa.com> In-Reply-To: <027501c5a8cf$e65abc90$196115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: mobopts@irtf.org Subject: [Mobopts] Re: Comments on draft-kempf-mobopts-ringsig-ndproxy-02.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: >>> If a multi-CGA capable node receives a message with a >>> standard RFC 3971 RSA Signature Option but the CGA Parameters Option >>> contains an RST Ring Signature Key Suboption, the node SHOULD ignore >>> the RST Ring Signature Option and treat the message like a standard >>> RFC 3791 SEND- >>> secured message. The node SHOULD use the standard RSA >>> signature verification algorithm and the key in the Public Key Field >>> of the CGA Parameters Option to verify the signature. >> >> Ignore? As in delete it from the contents of the CGA Parameters >> Option, or keep it there but not do anything special for it? >> > > RFC 3972 requires extensions to the CGA Parameters option to be > concatenated into the calculation for verification. So what I think > needs to be done is that, for the purposes of verification, it should > not be included in the calculation. > > This part of RFC 3972 may need some attention. I don't remember what > Tuomas and the WG had in mind with this, but the extensions field is > underspecified. If it is treated like a standard protocol extension > field, there will be TLV values for the extensions, and this is how > the multi-key CGA draft treats it. But the way it is incorporated into > the verification calculations implies that it is rather some bits that > don't have any specific field-like structure or any identifying > information as to what the extension is. Should such TLV bits be > included into the calculation? They aren't for the base key, 3792 > specifies specifically when the encoded public key is used (c.f. > Section 4, Step 2). This is what RFC 3972 says: Note that the hash values are computed over the entire CGA Parameters data structure, including any unrecognized extension fields. Now, the field itself is underspecified although its usage in the address calculation is clear (above). What we would probably need to do is to specify first a TLV structure for the extensions, and then one extension for the purposes of MCGA. But I don't think we need to touch the calculation rules. Btw, it seems that if the host's key is in the place where it should be according to RFC 3972, the other keys are in the extensions, you could easily use the RSA Signature, too, as long as you are not currently proxying -- just sign with the host's key. Of course you'd lose your privacy property. But I thought I'd mention this because it may affect whether you really want a new CGA type value or not. --Jari _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Aug 24 14:14:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zlL-0000JZ-OC; Wed, 24 Aug 2005 14:14:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zlJ-0000JK-JV for mobopts@megatron.ietf.org; Wed, 24 Aug 2005 14:14: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 OAA09579 for ; Wed, 24 Aug 2005 14:14:08 -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 1E7zlg-00028o-74 for mobopts@irtf.org; Wed, 24 Aug 2005 14:14:32 -0400 Message-ID: <02a901c5a8d7$9aad97b0$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jari Arkko" References: <430C5772.7090905@kolumbus.fi> <027501c5a8cf$e65abc90$196115ac@dcml.docomolabsusa.com> <430CB431.3010905@kolumbus.fi> Date: Wed, 24 Aug 2005 11:14:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: mobopts@irtf.org Subject: [Mobopts] Re: Comments on draft-kempf-mobopts-ringsig-ndproxy-02.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 > This is what RFC 3972 says: > > Note that the hash values are computed > over the entire CGA Parameters data structure, including any > unrecognized extension fields. > > Now, the field itself is underspecified although its usage in the > address calculation is clear (above). What we would probably need > to do is to specify first a TLV structure for the extensions, and > then one extension for the purposes of MCGA. But I don't > think we need to touch the calculation rules. > The draft has a specification for a generic TLV structure. I suppose it does no harm in including the TLV values into the calculation, but it is not the way most protocols I'm familiar with handle this. Typically, the semantically relevant fields are extracted and used, the identifying fields are discarded. But it does simplify the implementation, less parsing. > Btw, it seems that if the host's key is in the place where it > should be according to RFC 3972, the other keys are in > the extensions, you could easily use the RSA Signature, too, > as long as you are not currently proxying -- just sign with > the host's key. Of course you'd lose your privacy property. > But I thought I'd mention this because it may affect whether > you really want a new CGA type value or not. > You mean use an RSA signature that could have been generated by one of several key pairs rather than a ring signature? The location privacy aspect is lost as you say, but it is much more backward compatible with SEND. In effect, the ND options and basic address calculation would be covered by the existing RFCs, a new draft would only need to specify the CGA Parameters Extension and multi-key CGA generation. Since the address is constructed from multiple keys, I suppose no single key is designated as the owner, so an attribute cert delegating signing rights wouldn't be needed. Needs some thought, though, might be some subtle attack here. jak PS: BTW, we implemented the RST algorithm and the performance with two keys is about the same as RSA for signing and about twice as slow for verification. Signature size and performance scales with the number of keys, as expected. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Aug 24 15:02:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80WF-0006ii-63; Wed, 24 Aug 2005 15:02:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80WC-0006ho-CE for mobopts@megatron.ietf.org; Wed, 24 Aug 2005 15:02: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 PAA11709 for ; Wed, 24 Aug 2005 15:02:34 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E80WY-0003Y7-3V for mobopts@irtf.org; Wed, 24 Aug 2005 15:02:59 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1080289852; Wed, 24 Aug 2005 22:02:20 +0300 (EEST) Message-ID: <430CC447.2070305@kolumbus.fi> Date: Wed, 24 Aug 2005 22:02:31 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mobopts] Re: Comments on draft-kempf-mobopts-ringsig-ndproxy-02.txt References: <430C5772.7090905@kolumbus.fi> <027501c5a8cf$e65abc90$196115ac@dcml.docomolabsusa.com> <430CB431.3010905@kolumbus.fi> <02a901c5a8d7$9aad97b0$196115ac@dcml.docomolabsusa.com> In-Reply-To: <02a901c5a8d7$9aad97b0$196115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; 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 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: >> This is what RFC 3972 says: >> >> Note that the hash values are computed >> over the entire CGA Parameters data structure, including any >> unrecognized extension fields. >> >> Now, the field itself is underspecified although its usage in the >> address calculation is clear (above). What we would probably need >> to do is to specify first a TLV structure for the extensions, and >> then one extension for the purposes of MCGA. But I don't >> think we need to touch the calculation rules. >> > > The draft has a specification for a generic TLV structure. I suppose > it does no harm in including the TLV values into the calculation, but > it is not the way most protocols I'm familiar with handle this. > Typically, the semantically relevant fields are extracted and used, > the identifying fields are discarded. But it does simplify the > implementation, less parsing. Your draft has the generic TLV thing, but RFC 3972 did not have that. The generic TLV structure is necessary, but I see that as an add-on to RFC 3972 rather than something that needs to change other pieces when its specified. Your draft does this very well, as long as we don't change the address calculation rules. I do prefer including everything as an opaque bit string in the calculation. First of all, this is what RFC 3972 says. Secondly, It ensures that there are no replacement attacks where you keep the actual value but replace its type. Thirdly, its simpler. --Jari _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Aug 26 18:57:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8n8v-0000Ax-3j; Fri, 26 Aug 2005 18:57:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8n8t-0000Aa-Jt for mobopts@megatron.ietf.org; Fri, 26 Aug 2005 18:57: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 SAA29661 for ; Fri, 26 Aug 2005 18:57:44 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8n9h-0002kU-3y for mobopts@irtf.org; Fri, 26 Aug 2005 18:58:38 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j7QMPIg25595 for ; Fri, 26 Aug 2005 15:25:18 -0700 X-mProtect: <200508262225> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14157.americas.nokia.com (172.18.141.57, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpddVN3U0; Fri, 26 Aug 2005 15:25:16 PDT Message-ID: <430F9E53.6030802@iprg.nokia.com> Date: Fri, 26 Aug 2005 15:57:23 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) 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: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: [Mobopts] presentations and minutes 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 uploaded them at people.nokia.net/~rajeev/mobopts If I am missing anything, please let me know. Also, I have created a link to Publications but the index file is empty. Please (re)send a URL to your publications and not URLs to individual publications. Thanks, -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts