From fanzhao@ucdavis.edu Sun May 22 13:13:03 2005 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA12703; Sun, 22 May 2005 13:17:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4MJjoo30273; Sun, 22 May 2005 12:45:50 -0700 X-mProtect: <200505221945> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpdw1CFNy; Sun, 22 May 2005 12:45:49 PDT X-Scanned: Sun, 22 May 2005 13:16:51 -0700 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j4MKGpco014885; Sun, 22 May 2005 13:16:51 -0700 X-pstn-settings: 5 (1.50000:1.50000) p:5 r:4 m:4 c:5 X-pstn-version: pase:2.23 X-pstn-levels: s:99.90000/99.90000 p:95.91080 r:95.91080 m:94.89227 c:98.76780 X-pstn-address: from X-pstn-spam: N Received: from megatron.ietf.org (132.151.6.71) by mailrelay.iprg.nokia.com 00ek2qXi; Sun, 22 May 2005 13:16:49 PDT Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZwpe-0003n0-5A; Sun, 22 May 2005 16:13:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZwpc-0003mW-Kh for mobopts@megatron.ietf.org; Sun, 22 May 2005 16:13:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21892 for ; Sun, 22 May 2005 16:13:50 -0400 (EDT) Received: from nairobi.ucdavis.edu ([169.237.104.168]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZx7R-0001uy-Hj for mobopts@irtf.org; Sun, 22 May 2005 16:32:19 -0400 Received: from cucujus.ucdavis.edu (cucujus.ucdavis.edu [169.237.104.179]) by nairobi.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id j4MKD3O7008872 for ; Sun, 22 May 2005 13:13:47 -0700 (PDT) Received: from cucujus.ucdavis.edu (localhost [127.0.0.1]) by cucujus.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j4MKD3GK011091 for ; Sun, 22 May 2005 13:13:03 -0700 (PDT) Received: (from www@localhost) by cucujus.ucdavis.edu (8.12.10/8.12.9/Submit) id j4MKD328011090; Sun, 22 May 2005 13:13:03 -0700 (PDT) Date: Sun, 22 May 2005 13:13:03 -0700 (PDT) Message-Id: <200505222013.j4MKD328011090@cucujus.ucdavis.edu> To: mobopts@irtf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.195 X-Spam-Score: 2.4 (++) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [Mobopts] Call for Paper: JSAC-MRNM (The deadline is approaching.) 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 Status: O PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPERS IEEE Journal on Selected Areas in Communications MOBILE ROUTERS AND NETWORK MOBILITY http://www.argreenhouse.com/society/J-SAC/Calls/mobile_routers.html Network mobility support is concerned with managing the mobility of an entire network that is changing its point of attachment to the Internet and thus its reachability in the Internet topology. If network mobility is not explicitly supported by some mechanisms, existing sessions break and connectivity to the global Internet is lost. A mobile network is composed of Mobile Router(s) (MR) and Mobile Network Nodes (MNN) that can be fixed or mobile. There has been rapid development in network mobility support, i.e., providing Internet connectivity to the networks that move using mobile routers since the inception of Mobile IPv4 in 1996. Seamless Internet access in public transportation such as in trains and busses can be possible if mobile routers are used. Cars with low-power sensors seamlessly connected to the Internet constitute yet another example of networks which move. To date, some airline companies announced Internet connectivity support during commercial flights and this trend is expected to accelerate and cover most if not all flights. This issue is focused on modeling, analysis, and simulation of network mobility support protocols. We solicit papers presenting original and unpublished work including, but not limited to the following topics: * Modeling and Analysis of Network Mobility o Modeling, analysis and simulation of mobile router o Protocols for route optimization o Mobility issues inside a mobile network o Mobile IPv6 extensions for route optimization o Nested mobile networks o Multihomed mobile networks o Operational issues to deploy mobile networks o Auto-configuration for mobile networks o Mobile router support on cellular phone platforms * Services in the Networks that Move o Service advertisement and discovery protocols in networks that move o Specifications nad models of services for network mobility o Encryption and authentication in service access for network mobility * Security Issues in Network Mobility o Security analysis of present network mobility support protocols o Applications of AAA and EAP to network mobility o Interaction with security-enhanced modules in other layers (vertically) or other middle boxes (horizontally) Prospective authors should follow the IEEE J-SAC manuscript format described in the Information for Authors. Authors MUST submit their draft manuscripts through the EDAS peer review website, together with a short abstract (approximately 150 words) in the EDAS website form. Please note potential authors should create their own accounts through the EDAS peer review website before submitting manuscript(s). EDAS will accept manuscripts in PDF format only. There will be one round of reviewers and acceptance will be limited to those papers requiring only moderate revisions. The following timetable applies: Manuscript Submission: JUNE 1, 2005 Acceptance Notification: December 1, 2005 Final Manuscript Due: March 1, 2006 Publication: 3rd Quarter 2006 Guest Editorial Board: Behcet Sarikaya Computer Science Dept Univ of Northern British Columbia Prince George, BC Canada V2N 4Z9 sarikaya@unbc.ca S. Felix Wu Dept of Computer Science Univ of California at Davis Davis, CA 95616 USA wu@cs.ucdavis.edu Gopal Dommety Cisco Systems, Inc 170 West Tasman Dr San Jose, CA 95134-1706 USA gdommety@cisco.com Claude Castelluccia INRIA Rhtne-Alpes ZIRST 655 Ave de l'Europe Montbonnot 38334 Saint Ismier cedex France claude.castelluccia@inria.fr Thierry Ernst Jun Murai Lab Keio Univ K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki, Kanagawa 212-0054 Japan ernst@sfc.wide.ad.jp Charles E. Perkins Communication Systems Lab Nokia Research Center 313 Fairchild Dr Mountain View, CA 94943 USA charliep@iprg.nokia.com _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From fanzhao@ucdavis.edu Tue May 03 10:54:33 2005 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA13930; Tue, 3 May 2005 11:01:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j43HUqg23260; Tue, 3 May 2005 10:30:52 -0700 X-mProtect: <200505031730> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpdH451lI; Tue, 03 May 2005 10:30:50 PDT X-Scanned: Tue, 3 May 2005 11:01:05 -0700 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j43I15s6029988; Tue, 3 May 2005 11:01:05 -0700 X-pstn-settings: 5 (1.50000:1.50000) p:5 r:4 m:4 c:5 X-pstn-version: pase:2.23 X-pstn-levels: s:99.90000/99.90000 p:95.91080 r:95.91080 m:94.89227 c:98.76780 X-pstn-address: from X-pstn-spam: N Received: from megatron.ietf.org (132.151.6.71) by mailrelay.iprg.nokia.com 00dAqLhB; Tue, 03 May 2005 11:01:03 PDT Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT1bV-0002Ut-O2; Tue, 03 May 2005 13:54:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT1bU-0002Uo-8f for mobopts@megatron.ietf.org; Tue, 03 May 2005 13:54:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15124 for ; Tue, 3 May 2005 13:54:39 -0400 (EDT) Received: from warsaw.ucdavis.edu ([169.237.104.157]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT1pO-0008GF-IX for mobopts@irtf.org; Tue, 03 May 2005 14:09:04 -0400 Received: from tremex.ucdavis.edu (tremex.ucdavis.edu [169.237.104.172]) by warsaw.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id j43HsYfa007912 for ; Tue, 3 May 2005 10:54:35 -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 j43HsYdS007265 for ; Tue, 3 May 2005 10:54:34 -0700 (PDT) Received: (from www@localhost) by tremex.ucdavis.edu (8.12.10/8.12.9/Submit) id j43HsXEj007264; Tue, 3 May 2005 10:54:33 -0700 (PDT) Date: Tue, 3 May 2005 10:54:33 -0700 (PDT) Message-Id: <200505031754.j43HsXEj007264@tremex.ucdavis.edu> To: mobopts@irtf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.195 X-Spam-Score: 2.4 (++) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [Mobopts] Call for Paper: JSAC-MRNM 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 Status: O PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPERS IEEE Journal on Selected Areas in Communications MOBILE ROUTERS AND NETWORK MOBILITY http://www.argreenhouse.com/society/J-SAC/Calls/mobile_routers.html Network mobility support is concerned with managing the mobility of an entire network that is changing its point of attachment to the Internet and thus its reachability in the Internet topology. If network mobility is not explicitly supported by some mechanisms, existing sessions break and connectivity to the global Internet is lost. A mobile network is composed of Mobile Router(s) (MR) and Mobile Network Nodes (MNN) that can be fixed or mobile. There has been rapid development in network mobility support, i.e., providing Internet connectivity to the networks that move using mobile routers since the inception of Mobile IPv4 in 1996. Seamless Internet access in public transportation such as in trains and busses can be possible if mobile routers are used. Cars with low-power sensors seamlessly connected to the Internet constitute yet another example of networks which move. To date, some airline companies announced Internet connectivity support during commercial flights and this trend is expected to accelerate and cover most if not all flights. This issue is focused on modeling, analysis, and simulation of network mobility support protocols. We solicit papers presenting original and unpublished work including, but not limited to the following topics: * Modeling and Analysis of Network Mobility o Modeling, analysis and simulation of mobile router o Protocols for route optimization o Mobility issues inside a mobile network o Mobile IPv6 extensions for route optimization o Nested mobile networks o Multihomed mobile networks o Operational issues to deploy mobile networks o Auto-configuration for mobile networks o Mobile router support on cellular phone platforms * Services in the Networks that Move o Service advertisement and discovery protocols in networks that move o Specifications nad models of services for network mobility o Encryption and authentication in service access for network mobility * Security Issues in Network Mobility o Security analysis of present network mobility support protocols o Applications of AAA and EAP to network mobility o Interaction with security-enhanced modules in other layers (vertically) or other middle boxes (horizontally) Prospective authors should follow the IEEE J-SAC manuscript format described in the Information for Authors. Authors MUST submit their draft manuscripts through the EDAS peer review website, together with a short abstract (approximately 150 words) in the EDAS website form. Please note potential authors should create their own accounts through the EDAS peer review website before submitting manuscript(s). EDAS will accept manuscripts in PDF format only. There will be one round of reviewers and acceptance will be limited to those papers requiring only moderate revisions. The following timetable applies: Manuscript Submission: JUNE 1, 2005 Acceptance Notification: December 1, 2005 Final Manuscript Due: March 1, 2006 Publication: 3rd Quarter 2006 Guest Editorial Board: Behcet Sarikaya Computer Science Dept Univ of Northern British Columbia Prince George, BC Canada V2N 4Z9 sarikaya@unbc.ca S. Felix Wu Dept of Computer Science Univ of California at Davis Davis, CA 95616 USA wu@cs.ucdavis.edu Gopal Dommety Cisco Systems, Inc 170 West Tasman Dr San Jose, CA 95134-1706 USA gdommety@cisco.com Claude Castelluccia INRIA Rhtne-Alpes ZIRST 655 Ave de l'Europe Montbonnot 38334 Saint Ismier cedex France claude.castelluccia@inria.fr Thierry Ernst Jun Murai Lab Keio Univ K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki, Kanagawa 212-0054 Japan ernst@sfc.wide.ad.jp Charles E. Perkins Communication Systems Lab Nokia Research Center 313 Fairchild Dr Mountain View, CA 94943 USA charliep@iprg.nokia.com _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From pars.mutaf@inrialpes.fr Tue May 17 10:37:44 2005 +0200 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id BAA16033; Tue, 17 May 2005 01:38:37 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4H87U605834; Tue, 17 May 2005 01:07:30 -0700 X-mProtect: <200505170807> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpdVnJbke; Tue, 17 May 2005 01:07:28 PDT X-Scanned: Tue, 17 May 2005 01:38:20 -0700 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j4H8cKob004326; Tue, 17 May 2005 01:38:20 -0700 X-pstn-settings: 5 (1.50000:1.50000) p:5 r:4 m:4 c:5 X-pstn-version: pase:2.23 X-pstn-levels: s:99.90000/99.90000 p:95.91080 r:95.91080 m:97.02319 c:98.76780 X-pstn-address: from X-pstn-spam: N Received: from megatron.ietf.org (132.151.6.71) by mailrelay.iprg.nokia.com 00I4u5jj; Tue, 17 May 2005 01:38:19 PDT Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXxae-0000Ly-2v; Tue, 17 May 2005 04:38:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXxac-0000KW-Qi for mobopts@megatron.ietf.org; Tue, 17 May 2005 04:38:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23510 for ; Tue, 17 May 2005 04:38:08 -0400 (EDT) Received: from ebene.inrialpes.fr ([194.199.18.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXxrJ-0007FM-RH for mobopts@irtf.org; Tue, 17 May 2005 04:55:27 -0400 Received: from inrialpes.fr (felix.inria.fr [138.96.88.53]) by ebene.inrialpes.fr (8.13.0/8.13.0) with SMTP id j4H8bhT1000256; Tue, 17 May 2005 10:37:44 +0200 (MEST) Message-ID: <4289AD58.5050009@inrialpes.fr> Date: Tue, 17 May 2005 10:37:44 +0200 From: Pars Mutaf User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mobopts@irtf.org References: <014401c55a3f$7fec4fc0$016115ac@dcml.docomolabsusa.com> In-Reply-To: <014401c55a3f$7fec4fc0$016115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-1.4 (ebene.inrialpes.fr [194.199.18.70]); Tue, 17 May 2005 10:37:44 +0200 (MEST) X-GOTHMOG-MailScanner: Found to be clean Envelope-From: pars.mutaf@inrialpes.fr X-Spam-Score: 2.4 (++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: Pars.Mutaf@inrialpes.fr Subject: [Mobopts] Compact Neighbor Discovery 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 Status: O Hello, This is FYI. We have a paper on "Compact Neighbor Discovery" (appeared in Infocom'05). This is a "stateless" bandwidth optimization for reducing more than 40 times the bandwidth consumed by ND-DoS in IPv6 subnets with wireless access points. If you are interested, the paper is available online: http://www.inrialpes.fr/planete/people/mutaf/infocom05.pdf BTW, I'm looking for a simpler hash function. MD5 was probably an overkill. Regards, pars James Kempf wrote: >I've just posted a new draft on how to do secure address proxying. Until the >draft appears in the Interent Drafts directory, you can find the draft here: > >http://www.geocities.com/kempf42/draft-kempf-mobopts-ringsig-ndproxy-00.txt > >The draft defines how to use Rivest-Shamir-Tauman ring signatures (Asiacrypt >2001) and CGAs generated with multiple keys to allow a router, such as a >Mobile IPv6 home agent, to securely proxy a CGA. Multi-key CGAs allow secure >proxying without revealing from the cryptographic material whether the >mobile node is on or off the link, unlike other secure proxying techniques. > >Note that DoCoMo has filed for IPR on this draft, we're working on the >release currently. DoCoMo's policy is to release IPR royality-free if the >draft is approved as an Internet Standard if the IPR involves >interoperability, and I'm recommending that for this case. > > jak > > > >_______________________________________________ >Mobopts mailing list >Mobopts@irtf.org >https://www1.ietf.org/mailman/listinfo/mobopts > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From soohong.park@samsung.com Tue May 24 09:02:08 2005 +0900 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA15740; Mon, 23 May 2005 17:03:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4NNW3707372; Mon, 23 May 2005 16:32:03 -0700 X-mProtect: <200505232332> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpdHXoWLw; Mon, 23 May 2005 16:32:02 PDT X-Scanned: Mon, 23 May 2005 17:03:14 -0700 Nokia Message Protector V1.3.35 2005042208 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j4O03EuY030718; Mon, 23 May 2005 17:03:14 -0700 X-pstn-settings: 5 (1.50000:1.50000) p:5 r:4 m:4 c:5 X-pstn-version: pase:2.23 X-pstn-levels: s:99.90000/99.90000 p:95.91080 r:95.91080 m:97.02319 c:98.76780 X-pstn-address: from X-pstn-spam: N Received: from megatron.ietf.org (132.151.6.71) by mailrelay.iprg.nokia.com 00CzErXi; Mon, 23 May 2005 17:03:12 PDT Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaMsQ-00041L-Gz; Mon, 23 May 2005 20:02:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaMsP-00040P-5K for mobopts@megatron.ietf.org; Mon, 23 May 2005 20:02:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16009 for ; Mon, 23 May 2005 20:02:27 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaNAS-0002ej-Ur for mobopts@irtf.org; Mon, 23 May 2005 20:21:10 -0400 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IGY00FQUW3PZC@mailout2.samsung.com> for mobopts@irtf.org; Tue, 24 May 2005 09:02:13 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IGY00LVEW3PH9@mmp1.samsung.com> for mobopts@irtf.org; Tue, 24 May 2005 09:02:13 +0900 (KST) Date: Tue, 24 May 2005 09:02:08 +0900 From: "Soohong Daniel Park@SAMSUNG.COM" To: mipshop@ietf.org, mobopts@irtf.org Message-id: <018e01c55ff3$d3d35020$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 2.4 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7BIT Cc: Subject: [Mobopts] Link Characteristics Information for Mobile IP (revision) 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 Status: O Folks, I am posting this draft to both mipshop and mobopts. Title : Link Characteristics Information for Mobile IP Author(s) : S. Park, et al. Filename : draft-daniel-mip-link-characteristic-01.txt Pages : 12 Date : 2005-5-23 This document introduces a mechanism for link characteristic information and network information exchange from the mobile node to the home agent and the correspondent node. This model allows the home agent and the correspondent node to know the characteristics of the links the mobile node is attached to or could attach to. Based on this information the home agent and the correspondent node may shape ongoing traffic flows for the available bandwidth on the new link after the handover. This functionality also allows the home agent and the correspondent node to indicate preferred links or networks to where the mobile node should move to. This model can be applicable for Mobile IPv4 as well as Mobile IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-daniel-mip-link-characteristic-01. txt All comments are highly welcome. --------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From jz105@york.ac.uk Tue May 24 11:09:10 2005 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id DAA10305; Tue, 24 May 2005 03:10:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4O9cwJ30914; Tue, 24 May 2005 02:38:58 -0700 X-mProtect: <200505240938> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpdEIW6Gk; Tue, 24 May 2005 02:38:56 PDT X-Scanned: Tue, 24 May 2005 03:10:08 -0700 Nokia Message Protector V1.3.35 2005042208 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j4OAA8Hv018614; Tue, 24 May 2005 03:10:08 -0700 X-pstn-settings: 5 (1.50000:1.50000) p:5 r:4 m:4 c:5 X-pstn-version: pase:2.23 X-pstn-levels: s:99.90000/99.90000 p:95.91080 r:95.91080 m:97.02319 c:98.76780 X-pstn-address: from X-pstn-spam: N Received: from megatron.ietf.org (132.151.6.71) by mailrelay.iprg.nokia.com 00U4Emha; Tue, 24 May 2005 03:10:07 PDT Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaWIp-0001M2-LQ; Tue, 24 May 2005 06:06:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaWIo-0001Lu-Gi; Tue, 24 May 2005 06:06:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13025; Tue, 24 May 2005 06:06:19 -0400 (EDT) Received: from mail-gw0.york.ac.uk ([144.32.128.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaWay-0004B5-0Z; Tue, 24 May 2005 06:25:08 -0400 Received: from grouse (grouse.ohm.york.ac.uk [144.32.137.104]) by mail-gw0.york.ac.uk (8.12.10/8.12.10) with SMTP id j4OA69Ai009770; Tue, 24 May 2005 11:06:09 +0100 (BST) Message-ID: <022101c56048$a11cfaf0$68892090@grouse> From: "Ji Zhang" To: "Soohong Daniel Park@SAMSUNG.COM" References: <018e01c55ff3$d3d35020$6cc6dba8@daniel> Subject: Re: [Mobopts] Link Characteristics Information for Mobile IP (revision) Date: Tue, 24 May 2005 11:09:10 +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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-York-MailScanner: Found to be clean X-York-MailScanner-From: jz105@york.ac.uk X-Spam-Score: 3.3 (+++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: mipshop@ietf.org, mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Status: O Hi Daniel, I had a browse through the draft. My first impression is that it still lacks some words mentioning about supporting multiple correspondent nodes with this option, though bandwidth assignment is surely out of the scope of this draft. I think this is a very important aspect to make the draft practical. Second, you mentioned in the draft that HA and CN may indicate to the MN that it should perform a handover, which I feel a bit odd, since IMHO whether to perform a handover depends on the MN itself or the local access network policies. What do you think? Ji > Folks, > > I am posting this draft to both mipshop and mobopts. > > Title : Link Characteristics Information for Mobile IP > Author(s) : S. Park, et al. > Filename : draft-daniel-mip-link-characteristic-01.txt > Pages : 12 > Date : 2005-5-23 > > This document introduces a mechanism for link characteristic > information and network information exchange from the mobile node to > the home agent and the correspondent node. This model allows the > home agent and the correspondent node to know the characteristics of > the links the mobile node is attached to or could attach to. Based > on this information the home agent and the correspondent node may > shape ongoing traffic flows for the available bandwidth on the new > link after the handover. This functionality also allows the home > agent and the correspondent node to indicate preferred links or > networks to where the mobile node should move to. This model can be > applicable for Mobile IPv4 as well as Mobile IPv6. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-daniel-mip-link-characteristic-01. > txt > > > > All comments are highly welcome. > > --------------------------------------------- > Daniel (Soohong Daniel Park) > Mobile Platform Laboratory, SAMSUNG Electronics. > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From kempf@docomolabs-usa.com Mon May 16 10:48:36 2005 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA11033; Mon, 16 May 2005 10:49:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4GHIoc02387; Mon, 16 May 2005 10:18:50 -0700 X-mProtect: <200505161718> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpdnawKpi; Mon, 16 May 2005 10:18:49 PDT X-Scanned: Mon, 16 May 2005 10:49:39 -0700 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j4GHnd8B011569; Mon, 16 May 2005 10:49:39 -0700 X-pstn-settings: 5 (1.50000:1.50000) p:5 r:4 m:4 c:5 X-pstn-version: pase:2.23 X-pstn-levels: s:73.90305/99.90000 p:95.91080 r:95.91080 m:97.02319 c:98.76780 X-pstn-address: from X-pstn-spam: N Received: from megatron.ietf.org (132.151.6.71) by mailrelay.iprg.nokia.com 00P9aZm7; Mon, 16 May 2005 10:49:39 PDT Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXjgk-0007yT-Cg; Mon, 16 May 2005 13:47:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXjgj-0007yO-5n for mobopts@megatron.ietf.org; Mon, 16 May 2005 13:47:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16129 for ; Mon, 16 May 2005 13:47:31 -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.33) id 1DXjxI-0005fr-C9 for mobopts@irtf.org; Mon, 16 May 2005 14:04:42 -0400 Message-ID: <014401c55a3f$7fec4fc0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Date: Mon, 16 May 2005 10:48:36 -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: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Mobopts] New Draft on Proxy SEND 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 Status: O I've just posted a new draft on how to do secure address proxying. Until the draft appears in the Interent Drafts directory, you can find the draft here: http://www.geocities.com/kempf42/draft-kempf-mobopts-ringsig-ndproxy-00.txt The draft defines how to use Rivest-Shamir-Tauman ring signatures (Asiacrypt 2001) and CGAs generated with multiple keys to allow a router, such as a Mobile IPv6 home agent, to securely proxy a CGA. Multi-key CGAs allow secure proxying without revealing from the cryptographic material whether the mobile node is on or off the link, unlike other secure proxying techniques. Note that DoCoMo has filed for IPR on this draft, we're working on the release currently. DoCoMo's policy is to release IPR royality-free if the draft is approved as an Internet Standard if the IPR involves interoperability, and I'm recommending that for this case. jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From brett.pentland@eng.monash.edu.au Wed May 25 17:32:58 2005 +1000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id AAA04064; Wed, 25 May 2005 00:35:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4P746N14637; Wed, 25 May 2005 00:04:06 -0700 X-mProtect: <200505250704> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpdvXmctC; Wed, 25 May 2005 00:04:04 PDT X-Scanned: Wed, 25 May 2005 00:35:15 -0700 Nokia Message Protector V1.3.35 2005042208 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j4P7ZFPS030159; Wed, 25 May 2005 00:35:15 -0700 X-pstn-settings: 5 (1.50000:1.50000) p:5 r:4 m:4 c:5 X-pstn-version: pase:2.23 X-pstn-levels: s:99.90000/99.90000 p:95.91080 r:95.91080 m:97.02319 c:98.76780 X-pstn-address: from X-pstn-spam: N Received: from megatron.ietf.org (132.151.6.71) by mailrelay.iprg.nokia.com 00hFq4u2; Wed, 25 May 2005 00:35:14 PDT Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaqO9-00069N-W4; Wed, 25 May 2005 03:33:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaqO3-00066J-Fz for mobopts@megatron.ietf.org; Wed, 25 May 2005 03:33:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14984 for ; Wed, 25 May 2005 03:33:05 -0400 (EDT) Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaqgN-0004RW-8G for mobopts@irtf.org; Wed, 25 May 2005 03:52:04 -0400 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOOM2AZ46S9ANU7V@vaxh.its.monash.edu.au> for mobopts@irtf.org; Wed, 25 May 2005 17:33:00 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7A57BAB543; Wed, 25 May 2005 17:32:59 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 531A04FB0C; Wed, 25 May 2005 17:32:59 +1000 (EST) Date: Wed, 25 May 2005 17:32:58 +1000 From: Brett Pentland Subject: Re: [Mobopts] New Draft on Proxy SEND In-reply-to: <014401c55a3f$7fec4fc0$016115ac@dcml.docomolabsusa.com> To: James Kempf Message-id: <42942A2A.5010600@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513) References: <014401c55a3f$7fec4fc0$016115ac@dcml.docomolabsusa.com> X-Spam-Score: 2.4 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Status: O Hi Jim, I don't think I understand the signature stuff well enough for much meaningful commentary, but the general concept sounds good. I have one question about the backward compatibility section (3.5). If a multi-CGA capable node needs to be able to issue ND messages with standard SEND RSA signatures, what procedure is used to decide when to do this? Does the node try a Ring Signature Option, and if it gets no response, try again with a standard SEND signature? If so, would it keep an notation in its neighbour cache of the Ring Signature capability of each node, for future reference? Cheers, Brett. James Kempf wrote: > I've just posted a new draft on how to do secure address proxying. Until the > draft appears in the Interent Drafts directory, you can find the draft here: > > http://www.geocities.com/kempf42/draft-kempf-mobopts-ringsig-ndproxy-00.txt > > The draft defines how to use Rivest-Shamir-Tauman ring signatures (Asiacrypt > 2001) and CGAs generated with multiple keys to allow a router, such as a > Mobile IPv6 home agent, to securely proxy a CGA. Multi-key CGAs allow secure > proxying without revealing from the cryptographic material whether the > mobile node is on or off the link, unlike other secure proxying techniques. > > Note that DoCoMo has filed for IPR on this draft, we're working on the > release currently. DoCoMo's policy is to release IPR royality-free if the > draft is approved as an Internet Standard if the IPR involves > interoperability, and I'm recommending that for this case. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From kempf@docomolabs-usa.com Wed May 25 09:18:13 2005 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA23037; Wed, 25 May 2005 09:19:48 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4PFmLl06343; Wed, 25 May 2005 08:48:21 -0700 X-mProtect: <200505251548> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpdAn32na; Wed, 25 May 2005 08:48:19 PDT X-Scanned: Wed, 25 May 2005 09:19:35 -0700 Nokia Message Protector V1.3.35 2005042208 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j4PGJZjP014202; Wed, 25 May 2005 09:19:35 -0700 X-pstn-settings: 5 (1.50000:1.50000) p:5 r:4 m:4 c:5 X-pstn-version: pase:2.23 X-pstn-levels: s:99.90000/99.90000 p:95.91080 r:95.91080 m:97.02319 c:98.76780 X-pstn-address: from X-pstn-spam: N Received: from megatron.ietf.org (132.151.6.71) by mailrelay.iprg.nokia.com 003CrdfO; Wed, 25 May 2005 09:19:33 PDT Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DayZH-0006qI-9p; Wed, 25 May 2005 12:17:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DayZG-0006qD-23 for mobopts@megatron.ietf.org; Wed, 25 May 2005 12:17:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25058 for ; Wed, 25 May 2005 12:17:11 -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.33) id 1Dayre-0001mY-VJ for mobopts@irtf.org; Wed, 25 May 2005 12:36:16 -0400 Message-ID: <069e01c56145$5eb27ac0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Brett Pentland" References: <014401c55a3f$7fec4fc0$016115ac@dcml.docomolabsusa.com> <42942A2A.5010600@eng.monash.edu.au> Subject: Re: [Mobopts] New Draft on Proxy SEND Date: Wed, 25 May 2005 09:18:13 -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: 7655788c23eb79e336f5f8ba8bce7906 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 Status: O Hi Brett, > I have one question about the backward compatibility section (3.5). > If a multi-CGA capable node needs to be able to issue ND messages > with standard SEND RSA signatures, what procedure is used to decide > when to do this? Does the node try a Ring Signature Option, and if > it gets no response, try again with a standard SEND signature? If > so, would it keep an notation in its neighbour cache of the Ring > Signature capability of each node, for future reference? > It could to that, or the other possibility is it could include both standard SEND and multi-key SEND signatures in the packet, at a considerable expense in terms of packet size. A multi-key node will ignore the standard signatue while a regular SEND node will ignore the ring signature. At this point, I haven't completely thought through the backward compatibility issues, but they will need to be thought through clearly if this work ever goes to IETF. jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From itijibox-mobopts@yahoo.com Wed May 25 11:22:27 2005 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA28357; Wed, 25 May 2005 11:24:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4PHqeP31671; Wed, 25 May 2005 10:52:40 -0700 X-mProtect: <200505251752> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpduahdLb; Wed, 25 May 2005 10:52:39 PDT X-Scanned: Wed, 25 May 2005 11:23:52 -0700 Nokia Message Protector V1.3.35 2005042208 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j4PINqRk018424; Wed, 25 May 2005 11:23:52 -0700 X-pstn-settings: 5 (1.50000:1.50000) p:5 r:4 m:4 c:5 X-pstn-version: pase:2.23 X-pstn-levels: s:99.90000/99.90000 p:95.91080 r:95.91080 m:97.02319 c:98.76780 X-pstn-address: from X-pstn-spam: N Received: from megatron.ietf.org (132.151.6.71) by mailrelay.iprg.nokia.com 00x3tKHG; Wed, 25 May 2005 11:23:51 PDT Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db0Wd-0004Eh-76; Wed, 25 May 2005 14:22:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db0Wb-0004EY-Uj for mobopts@megatron.ietf.org; Wed, 25 May 2005 14:22:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06271 for ; Wed, 25 May 2005 14:22:36 -0400 (EDT) Received: from web81903.mail.mud.yahoo.com ([68.142.207.182]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Db0p1-0004sw-RF for mobopts@irtf.org; Wed, 25 May 2005 14:41:41 -0400 Received: (qmail 77478 invoked by uid 60001); 25 May 2005 18:22:27 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=2SVTz9d5891lfMhWAuRQ6vVVv1muGCKSMz7RQdMBphi0QkY7/MxTXNXN7kc5LCPkguH+tnnkVPqFnQjFmt5q3T7TckvOGtgL+Ogm/SpTpDzAQ16G7yLPprLHAVmHP1MT6kXTsWbgFhE+AZA+auLP+1emIwMgvxo2JqW8MSGY3aM= ; Message-ID: <20050525182227.77476.qmail@web81903.mail.mud.yahoo.com> Received: from [131.107.0.102] by web81903.mail.mud.yahoo.com via HTTP; Wed, 25 May 2005 11:22:27 PDT Date: Wed, 25 May 2005 11:22:27 -0700 (PDT) From: gabriel montenegro Subject: Re: [Mobopts] New Draft on Proxy SEND To: James Kempf , Brett Pentland In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 2.9 (++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-mobopts@yahoo.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 Status: O Yes, inefficiency over the air (implying fragmentation) is an issue. Also, how does performance of signing and verification operations compare with, say, vanilla RSA? -gabriel --- James Kempf wrote: > Hi Brett, > > > I have one question about the backward compatibility section (3.5). > > If a multi-CGA capable node needs to be able to issue ND messages > > with standard SEND RSA signatures, what procedure is used to decide > > when to do this? Does the node try a Ring Signature Option, and if > > it gets no response, try again with a standard SEND signature? If > > so, would it keep an notation in its neighbour cache of the Ring > > Signature capability of each node, for future reference? > > > > It could to that, or the other possibility is it could include both standard > SEND and multi-key SEND signatures in the packet, at a considerable expense > in terms of packet size. A multi-key node will ignore the standard signatue > while a regular SEND node will ignore the ring signature. > > At this point, I haven't completely thought through the backward > compatibility issues, but they will need to be thought through clearly if > this work ever goes to IETF. > > jak > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From kempf@docomolabs-usa.com Wed May 25 11:53:36 2005 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA29552; Wed, 25 May 2005 11:53:59 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4PIMV822328; Wed, 25 May 2005 11:22:31 -0700 X-mProtect: <200505251822> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpdYCsiE4; Wed, 25 May 2005 11:22:30 PDT X-Scanned: Wed, 25 May 2005 11:53:45 -0700 Nokia Message Protector V1.3.35 2005042208 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j4PIrjVG019357; Wed, 25 May 2005 11:53:45 -0700 X-pstn-settings: 5 (1.50000:1.50000) p:5 r:4 m:4 c:5 X-pstn-version: pase:2.23 X-pstn-levels: s:99.90000/99.90000 p:95.91080 r:95.91080 m:97.02319 c:98.76780 X-pstn-address: from X-pstn-spam: N Received: from megatron.ietf.org (132.151.6.71) by mailrelay.iprg.nokia.com 00T0LrM9; Wed, 25 May 2005 11:53:42 PDT Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db0zg-00006l-G4; Wed, 25 May 2005 14:52:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db0ze-00006g-V8 for mobopts@megatron.ietf.org; Wed, 25 May 2005 14:52:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08455 for ; Wed, 25 May 2005 14:52:35 -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.33) id 1Db1I2-0005Y5-Vh for mobopts@irtf.org; Wed, 25 May 2005 15:11:40 -0400 Message-ID: <07f501c5615b$13a13f60$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , "Brett Pentland" References: <20050525182227.77476.qmail@web81903.mail.mud.yahoo.com> Subject: Re: [Mobopts] New Draft on Proxy SEND Date: Wed, 25 May 2005 11:53:36 -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: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Status: O > Yes, inefficiency over the air (implying fragmentation) is an issue. > Also, how does performance of signing and verification operations compare > with, say, vanilla RSA? > I'm working on getting it implemented, so I can measure it. BTW, there are a couple other ring signature algorithms, including one based on pairings, but some of those are covered by patents. The Rivest-Shamir-Tauman algorithm is public domain, so far as I can tell. jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From kempf@docomolabs-usa.com Fri May 27 08:54:33 2005 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA15617; Fri, 27 May 2005 08:54:54 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4RFNMG19119; Fri, 27 May 2005 08:23:22 -0700 X-mProtect: <200505271523> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpdnjLYTE; Fri, 27 May 2005 08:23:21 PDT X-Scanned: Fri, 27 May 2005 08:54:39 -0700 Nokia Message Protector V1.3.35 2005042208 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j4RFsdU6015101; Fri, 27 May 2005 08:54:39 -0700 X-pstn-settings: 5 (1.50000:1.50000) p:5 r:4 m:4 c:5 X-pstn-version: pase:2.23 X-pstn-levels: s:99.90000/99.90000 p:95.91080 r:95.91080 m:88.14956 c:98.76780 X-pstn-address: from X-pstn-spam: N Received: from megatron.ietf.org (132.151.6.71) by mailrelay.iprg.nokia.com 00CVRGwV; Fri, 27 May 2005 08:54:38 PDT Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbh9R-0005jZ-JA; Fri, 27 May 2005 11:53:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbh9Q-0005jU-PS for mobopts@megatron.ietf.org; Fri, 27 May 2005 11:53:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22104 for ; Fri, 27 May 2005 11:53: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.33) id 1DbhSA-0006JS-Hw for mobopts@irtf.org; Fri, 27 May 2005 12:12:56 -0400 Message-ID: <007c01c562d4$632fe840$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jean-Michel COMBES" , , "'Brett Pentland'" References: <041801c562b7$d91a16b0$75a1c10a@rd.francetelecom.fr> Subject: Re: [Mobopts] New Draft on Proxy SEND Date: Fri, 27 May 2005 08:54:33 -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: 25620135586de10c627e3628c432b04a 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 Status: O We did some work on generating standard single key CGAs and the amount of time required to validate a signature compared to standard ND w.o SEND. It was presented at the SF IETF (I think), in the SEND WG. I'll see if I can dig it up. jak ----- Original Message ----- >From: "Jean-Michel COMBES" To: "'James Kempf'" ; ; "'Brett Pentland'" Cc: Sent: Friday, May 27, 2005 5:30 AM Subject: RE : [Mobopts] New Draft on Proxy SEND > Hi, > > At first, sorry if my question is a little out of scope of the subject. > > Does someone has some figures regarding the time to generate CGA addresses > and linked security material on devices (eg. on PDA, laptops, ...)? Or a > link to a paper on this subject? > > BTW, I will be interested by your results James :) > > Best regards. > > JMC. > > France Telecom - R&D Division - MAPS/NSS > Jean-Michel COMBES, Internet/Intranet Security > E-Mail: jeanmichel.combes@francetelecom.com > Phone: +33 (0)1 45 29 45 94 > Fax: +33 (0)1 45 29 65 19 > Mobile: +33 (0)6 07 29 30 16 > > > > -----Original Message----- > > From: mobopts-bounces@irtf.org > > [mailto:mobopts-bounces@irtf.org] On Behalf Of James Kempf > > Sent: Wednesday, May 25, 2005 8:54 PM > > To: itijibox-mobopts@yahoo.com; Brett Pentland > > Cc: mobopts@irtf.org > > Subject: Re: [Mobopts] New Draft on Proxy SEND > > > > > > > Yes, inefficiency over the air (implying fragmentation) is an issue. > > > Also, how does performance of signing and verification > > operations compare > > > with, say, vanilla RSA? > > > > > > > I'm working on getting it implemented, so I can measure it. > > > > BTW, there are a couple other ring signature algorithms, > > including one based > > on pairings, but some of those are covered by patents. The > > Rivest-Shamir-Tauman algorithm is public domain, so far as I can tell. > > > > jak > > > > > > > > _______________________________________________ > > Mobopts mailing list > > Mobopts@irtf.org > > https://www1.ietf.org/mailman/listinfo/mobopts > > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From kempf@docomolabs-usa.com Thu May 26 16:02:22 2005 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA09262; Thu, 26 May 2005 16:58:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4QNQXc11003; Thu, 26 May 2005 16:26:33 -0700 X-mProtect: <200505262326> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpd6YZIZy; Thu, 26 May 2005 15:35:20 PDT X-Scanned: Thu, 26 May 2005 16:06:36 -0700 Nokia Message Protector V1.3.35 2005042208 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j4QN6aEq012425; Thu, 26 May 2005 16:06:36 -0700 X-pstn-settings: 5 (1.50000:1.50000) p:5 r:4 m:4 c:5 X-pstn-version: pase:2.23 X-pstn-levels: s:99.90000/99.90000 p:95.91080 r:95.91080 m:94.89227 c:98.76780 X-pstn-address: from X-pstn-spam: N Received: from megatron.ietf.org (132.151.6.71) by mailrelay.iprg.nokia.com 001FeSxB; Thu, 26 May 2005 16:06:29 PDT Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbRLv-0001Ne-4G; Thu, 26 May 2005 19:01:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbRLs-0001N5-TP for mobopts@megatron.ietf.org; Thu, 26 May 2005 19:01:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22082 for ; Thu, 26 May 2005 19:01:17 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbReY-0001G1-6m for mobopts@irtf.org; Thu, 26 May 2005 19:20:39 -0400 Message-ID: <0abd01c56246$fe2927f0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , Date: Thu, 26 May 2005 16:02:22 -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: 3f3e54d3c03ed638c06aa9fa6861237e Content-Transfer-Encoding: 7bit Cc: Subject: [Mobopts] Review of draft-irtf-mobopts-ro-enhancements-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Status: O Raj requested I review this draft. Here is my review. jak ----------------------- Editorial meta-comment: While I found the draft to be very good, it is quite long, and I think it could be improved by dropping some parts that are superficial and not relevent to the basic theme. For example, Sections 5.13 through 5.17, Section 6.2.1, and some material in Section 6.3 on the same topics. These sections all talk about handover optimizations schemes that do not involve improvements in the basic Mobile IPv6 route optimization algorithm and its security, return routability, which is the basic theme of the document. There is a very extensive academic literature on HMIP, FMIP, and other local optimizations for Mobile IP handover, and none of this has been cited or reviewed in this draft. Removing the material on this would help to focus and shorten the draft. Specific comments: page 6: lightway and does not -> lightweight and does not page 6: "On the other hand, the return routability procedure usually consumes one round-trip time" - The number I've seen cited is 1.5 RTT on the average. Section 2.0: I believe Pekka Nikander has a MIP6 WG draft (draft-ietf-mip6-ro-sec-02.txt) that discusses many of the issues that are discussed in this and subsequent sections. This draft should be referenced somewhere here. Section 2.3, 2nd last para: I was looking here for the standard "ingress filtering will handle redirection-based DoS attacks" here, and the refutation of why that isn't practical. It might be useful to put in a forward reference, since it is dealt with later in the paper. Section 3.2, end of 1st para: The impact on the core Internet of bidirectional tunneling is actually quite minimal given the amount of dark fiber left over from the Boom. It has been estimated that less that 10% of the cross-continent fiber in North America is lit, and the number is probably similar for intercontinental and other long distance links in other countries. There is of course still an issue with access networks, but the real impact of always tunneling through the home agent is on RTT latency. This is sometimes known as "the two Japanese in America" problem, where two people from Japan come to America, and call each other through their Mobile IP home agents back in Japan. Section 3.2, begining of the 2nd para: I'm not clear what the relationship between the CN and authorization for a home address has to do with deployment of route optimization. There is an even more basic issue, that is that modifications for route optimization which utilize end-to-end signaling require that every CN in the IPv6 Internet support them. While we are yet far away from widespread deployment of IPv6, the longer such end-to-end optimizations are delayed, the less likely that every CN will support them. Section 3.2, 3rd para: and so does without -> and does so without Section 3.2, 5th para: The preconfigured keys draft should be cited here. Section 3.2, 6th para: This paragraph misses the issue of CRL checks. These could be a significant issue when using certificates for route optimization security. Section 3.2, 9th para: In my mind, the primary argument against depending on ingress filtering is that there is no incentive - financial, regulatory, or legal - for ISPs to deploy it. A diligent ISP will of course do so, but a corrupt ISP might even have a financial incentive to not deploy it, if redirection-based DoS attacks using route optimization ever become possible and are exploited for financial gain. This has been an issue with spam, for example. I think something to that effect needs to be said. While some people might be offended by this, the need for security in the Internet results from the fact that, lacking any incentives to the contrary, some people will do bad things if they can get away with it and it can result in financial gain. Most discussions of security ignore this basic fact of human nature, and treat the problem like solar physics or something. Section 3.2, 10th para: This section loses sight of the fact that malware installed surreptitiously on a host may compromise it even if the host has a trust relationship with the home agent service provider. The issue is not the trust relationship but rather that the home agent service provider has a record of who the user is and can cut them off if they start behaving badly. Now how the home agent service provider is supposed to detect whether or not a particular host is behaving badly is another story. Section 3.3, 1st para: against the tree -> against the three Section 3.3, 3rd para: This said -> That said Section 3.3, 4th para: But here again could the attacker launch -> But here again, the attacker can launch Section 3.3, 5th para: that is called "space-and-time shift attacks" -> that is called a "space-and-time-shift attack" for a better point of time -> for a better point in time Section 4.1, 2nd para: This isn't clear. If the MN sends a BU to the CN, then it isn't a round trip, it's one way. I'm assuming here that the text isn't including the HoTI/HoT, CoTI/CoT in that calculation. If so, then I think the average would be 2 RTs, 1.5 for the RR signaling and 0.5 for the BU. Section 4.2, 3rd & 4th para: I've never been convinced that a mobile node would want to keep optimized routes hot while it was in dormant mode, and this example doesn't convince me either. Route optimization helps with RTT latency, and such latency is an issue primarily in real time traffic. The example given here, a messaging server (presumably IM), is a store and forward system that will derive little benefit from keeping routes hot during optimization. Even for real time traffic, like VoIP, the CN still has to do SIP signaling to initiate the connection, and while there is some amount of urgency to the signaling above a store and forward application, it still is not going to suffer if the traffic is routed through the home agent. The latency involved in initiating the IP connection with the dormant mode mobile node through paging is likely to exceed any benefit from keeping optimized routes hot. Section 4.3, 1st para: lightway -> lightweight In some cases, however, may better security be useful -> ???? Section 4.3, 2nd para: mobility management can the Internet as whole not -> mobility management, the Internet as a whole can not Section 5, meta comment: One issue the entire document has ignored is route optimization for mobile networks. As noted above, since end to end route optimization technquies require support in every IPv6 node, a host-based route optimization technique that is adopted for next-gen MIPv6 but doesn't support mobile networks may preclude widespread use of route optimization for mobile networks because it might be difficult to get the support in a broad enough collection of IPv6 nodes. Section 6.3.2, paragraph 1 makes the argument that the current set of new RO techniques is likely to be directed at specific usage scenerios, but I'm not so sure that's likely to be the case. Section 5, para 1: many enhancements techniques -> many enhancement techniques Section 5, para 1: Are the tradeoffs between universal applicablity v.s. efficiency discussed in this paper anywhere? This would be the ideal paper to have the discussion. Section 5.1, para 2: IP-ddress -> IP-address can anyway do without route optimization -> can do without route optimization anyway Section 5.1, para 3: Again, I've heard 1.5 RTT for this. Section 5.2, para 1: same problem as in 5.1 para 2 Section 5.4, para 1: I've never heard the term "critical phase" used. Section 5.4, para 2: One issue raised earlier in the paper was the frequency of signaling. Here, it seems to be advocating doing a home address test every 3.5 mintues regardless of whether movement is immanent or not. This seems a contradiction. anyway re-initiate the correspondent registration -> re-initiate the correspondent registration anyway Section 5.5, para 2: Later in the paper, you discuss this, but the statistical uniqueness properties of CGAs suggest that the care-of test might not be needed since the probability of another node having exactly the same interface identifier is fairly low. I think you should state that here. It is the same tradeoff that optimistic DAD makes. The argument you advance later in the paper that the attacker can still mount an attack on the subnet is irrelevent. An attacker can do that without using route optimization, by creating a zombie and programming it to iterate through non-existant addresses in the victim subnet. Section 5.6, para 1: until it has been told about this -> until it has been told. are usually lost and must be transmitted -> are usually lost and must be retransmitted Section 5.7: I think it might be worthwhile to include a paragragh describing how the mobile node's credit is measured. I recently attempted to construct a bandwidth measuring algorithm and found it not so simple. There are probably very simple ways to do it, but I think they may not be obvious to the casual reader. Section 5.7, para 5: Thus, its is the -> Thus, it is the Section 5.7, para 5.7: I wonder if the Spot Check tokens aren't a potential state depletion threat. Since they are essentially per flow state, an attacker could iterate creating a bunch of flows until the victim's Spot Check token storage was exhausted. Section 5.8, para 2: it in general hard -> it is in general hard Actually, I think it is impossible for the correspondent to know that two home addresses are from the same node unless the interface identifier is the same. The interface identifier is what is used for routing on the last hop link, and so only it will determine if two packets with destination addresses known to be home addresses and the same subnet prefix go to the same node. Section 5.9, para 4: RFC 3972 describes how to compute CGAs such that an attacker can't claim ownership. It used the said subnet prefix trick, and should probably be cited. Section 5.10: This section seems to imply that the CoA test can be eliminated with preconfiguration, but I think that is too optimistic. Even if two nodes that trust each other initially are preconfigured, subsequently one or the other can be infected with malware without the owner knowing and become untrustworthy. Section 6.2.2, para 2: The assumption that mobile nodes are fair-minded turns out to be quite far stretching. -> ?????? from figure Figure 1, -> from Figure 1, and a trust relationship for misuse prevention -> and an address authorization for misuse prevention Section 6.2.2, para 4: These things said, -> That said, protocol bendable to different -> protocol customizable to different Section 6.2.3: Here is the discussion of statistical uniqueness and its effect on the need for the CoA test. The point about network attacks in the 2nd para is really irrelevant, as noted above. Section 6.2.4, 4th para: that mobility-managment protocols -> that these mobility-management protocols Section 6.2.4: Can CBA somehow get rid of the need to re-authorize every 7 minutes? If the MN is building credit, then perhaps it doesn't need to re-authorize because its ability to attack is limited by the credit. Of course, the issue of the home address test would have to be addressed too, but I think it worthwhile to explore this, since the signaling overhead of RR is onerous. Section 6.3.1: This section could be removed too. Section 6.3.2: final, all-encompassing method -> widespread method Actually, I disagree with this conclusion. I think the current crop of limited applicability RO security protocols are likely to die from lack of implementation and interest and a next gen protocol, possibly including CGA and CBA, that is widely applicable and a big improvement on RR is likely to have more success. Section 6.3.2: One issue that I've never really seen dealt with is whether or not RO is really needed. Nobody has measured this. Skype seems to get by with lots of indirect routes For example, our experiments show that when we make a Skype call from one node in our San Jose lab to another, it goes through a supernode in Europe, yet the quality of the call is fine. Everybody seems to be assuming this is a problem, but nobody seems to have set up a network and actually measured whether it is *really* a problem, with MOS scores, etc. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From bingyizhang@hotmail.com Fri May 27 08:40:10 2005 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id BAA28745 for ; Fri, 27 May 2005 01:40:33 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4R892k15038 for ; Fri, 27 May 2005 01:09:02 -0700 X-mProtect: <200505270809> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpd5SBYPD; Fri, 27 May 2005 01:08:56 PDT X-Scanned: Fri, 27 May 2005 01:40:12 -0700 Nokia Message Protector V1.3.35 2005042208 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j4R8eCmg031448 for ; Fri, 27 May 2005 01:40:12 -0700 X-pstn-settings: 5 (1.50000:1.50000) p:5 r:4 m:4 c:5 X-pstn-version: pase:2.23 X-pstn-levels: s:10.93793/99.78745 p:95.91080 r:95.91080 m:94.50220 c:99.59020 X-pstn-address: from X-pstn-spam: N Received: from bay22-f31.bay22.hotmail.com (64.4.16.81, claiming to be "hotmail.com") by mailrelay.iprg.nokia.com 00sZoSnc; Fri, 27 May 2005 01:40:12 PDT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 27 May 2005 01:40:11 -0700 Message-ID: Received: from 218.76.51.3 by by22fd.bay22.hotmail.msn.com with HTTP; Fri, 27 May 2005 08:40:10 GMT X-Originating-IP: [218.76.51.3] X-Originating-Email: [bingyizhang@hotmail.com] X-Sender: bingyizhang@hotmail.com From: =?gb2312?B?1cUgsfni+Q==?= To: mobopts@irtf.org Cc: rajeev@iprg.nokia.com, waa@cs.umd.edu Subject: Re:draft-zhang-mobopts-multicast-dma-00.txt Date: Fri, 27 May 2005 08:40:10 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed X-OriginalArrivalTime: 27 May 2005 08:40:11.0764 (UTC) FILETIME=[B21B3B40:01C56297] X-MIME-Autoconverted: from 8bit to quoted-printable by mailrelay.iprg.nokia.com id j4R8eCmg031448 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.iprg.nokia.com id BAA28745 Status: O Hi, everyone I am the leader of the IP lab of College of Electronics and Information Engineering, Beijing Jiaotong University, Beijing 100044, P.R.China. I also is a professor and the president of this college. I am glad to contribute our draft to this work group and get your help and comment about it. First, I give an introduction as follows: IPv6 will replace IPv4 gradually in next generation network. Along with the development of the wireless IP technologies, more and more people have the chance to use wireless equipment accessing network. They will likeing this method gradually and being in the habit of accessing wireless network. Now there are more than 200 millions of mobile terminal users such as mobile phone users in China. Multicast is also a hot point and many research have been studyed in it. There have been many multicast route protocols, such as DVMRP, MOSPF, MSDP, BGMP and PIM-SSM and so on. Unfortunately they are not suit to mobility wireleless network. Supporting the mobility and multicast will becomes the inevitable function in next generation network. So how to support multicast in mobile IPv6 network is a inevitable question. The research in mobile multicast is important and necessary. However we face the challenge to combine mobile IP with multicast now. There are many difficulties during the researches. First the existing IP multicast protocols can¡¯t satisfy the needs of node for mobility. Second the handoff time of mobile node and the delay used in rejoining in multicast group is too long , so it can¡¯t meet the requirement of QoS yet. Third the reconstruction of multicast tree caused by the MN handoff in the subnet frequently burden the network load. Fourth the existing mobile IP multicast protocols have the problems of triangle route and tunnel congregation. Above all the optimization design for mobile multicast route is very important. For conquerving the above problems, we propose a DMA (Dynamic Multicast Agent) approach in our draft. The DMA approach is based on the porposed MIP-BT (Mobile IP ¨C Bidirectional tunnel) and MIP-RS (Mobile IP ¨C Remote Subscription). The MIP-BT use a bi-directional tunnel between a MN with its HA to support mulcast in mobile network. The MIP-RS using a multicast router in a foreign subnet being visited to support multicast in mobile network. These two methods can remain the multicast communications when MNs move, but there are some disadvantages about them. To MIP-BT, the triangle route problem will add the network cost and the tunnel congreation problem can not be solved yet. To MIP-RS, when the handoff occures frequently, the rejoin of a MN and the reconstruction of multicast tree will cause too long delay and too much cost. The DMA conquers the problems in MIP-BT and MIP-RS. The DMA approach includes three concepts of MSA (Multicast subnet Agent), DMA and Tunnel State. The approach is a combination of MIP-BT and MIP-RS, and it is also a hybrid solution of movement based method and distance based method. Such a configuration allows MNs to optimize multicast routes, and meanwhile reduce the number of handoffs by selecting new multicast agents dynamically. In addition to weakening the triangle route problem and diminishing the influence of handoff to multicast A throughness flow chart of DMA approach, the operation of MSA and dynamic multicast agent selection all have been given. The mathmatics analysis and simulation in NS are also completed. The results in simulation denote that DMA approach can effectively reduces the reconstructing of multicast tree and the multicast packages can be forwarded through optimal path. The DMA approach can improving the network performance effectively and adapt to the mobile IPv6 multicast. At last, I hope you can give your generous help and comments to make it wonderful. Best regards with many thanks Hong-Ke Zhang _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn From chvogt@tm.uka.de Fri May 27 09:22:23 2005 +0200 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id AAA26097; Fri, 27 May 2005 00:24:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4R6rAs16237; Thu, 26 May 2005 23:53:10 -0700 X-mProtect: <200505270653> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpdqSpsdf; Thu, 26 May 2005 23:53:06 PDT X-Scanned: Fri, 27 May 2005 00:24:26 -0700 Nokia Message Protector V1.3.35 2005042208 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j4R7OQEk028629; Fri, 27 May 2005 00:24:26 -0700 X-pstn-settings: 5 (1.50000:1.50000) p:5 r:4 m:4 c:5 X-pstn-version: pase:2.23 X-pstn-levels: s:99.90000/99.90000 p:95.91080 r:95.91080 m:92.89886 c:99.59020 X-pstn-address: from X-pstn-spam: N Received: from megatron.ietf.org (132.151.6.71) by mailrelay.iprg.nokia.com 00MqZ9Qx; Fri, 27 May 2005 00:24:22 PDT Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbZB3-0004yp-Tr; Fri, 27 May 2005 03:22:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbZB2-0004yk-Nk for mobopts@megatron.ietf.org; Fri, 27 May 2005 03:22:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17013 for ; Fri, 27 May 2005 03:22:39 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1/hdLnkRdZf02jgpkWFwDnrRjm3ZRqw9w8=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbZTm-0003Vp-N5 for mobopts@irtf.org; Fri, 27 May 2005 03:42:03 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1DbZAn-0001Su-Fj; Fri, 27 May 2005 09:22:30 +0200 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uni-karlsruhe.de with esmtps id 1DbZAm-000134-HT; Fri, 27 May 2005 09:22:24 +0200 Message-ID: <4296CAAF.5010104@tm.uka.de> Date: Fri, 27 May 2005 09:22:23 +0200 From: Christian Vogt User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Francis Dupont References: <200505190554.j4J5smg3035512@givry.rennes.enst-bretagne.fr> In-Reply-To: <200505190554.j4J5smg3035512@givry.rennes.enst-bretagne.fr> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -18.1 (------------------) X-Spam-Status: No X-Spam-Score: 2.4 (++) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Content-Transfer-Encoding: 7bit Cc: MOBOPTS , Jari Arkko , Basavaraj.Patil@nokia.com Subject: [Mobopts] Francis' Review of draft-irtf-mobopts-ro-enhancements (was Re: FW: Please review draft-irtf-mobopts-ro-enhancements-00.txt) X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Status: O Hi Francis, first of all, thanks for reviewing the document and commenting on it. We revised the document and put the new, preliminary version here: http://doc.tm.uka.de/2005/draft-irtf-mobopts-ro-enhancements-01-pre.txt BTW, Vidya and James both did a review as well, so there is going to be another round of revision. Below are my responses to your, Francis', comments. > - abstract: IMHO the goals of improvements/alternatives are in the > wrong order: signaling messages/latency/etc can be improved only > because the security is better. (same about 4.x section order) Hmm, there wasn't actually an intention to prioritize the proposals, Francis. But it might be wise to do so. Do you think that the order (1) low latency (2) increased security (3) reduced signaling overhead is capable of reaching agreement? It seems that there is a common ground to at least not increase the latency of standard Mobile IPv6. In other words, many of the described proposals have merits in terms of reduced latency, even if their primary goal is to increase security. (OMIPv6 is a good example. If you combine it with Credit-Based Authorization, which is what we will do in Mipshop, you get both, higher security and lower latency.) > - 1.introduction: to put HIP at the same level than Mobile IPv6 and > Mobile IP is a clear bias. Ok, this document is about Mobile IPv6, so it should be made clear in the introduction. Re-wrote that part. > - 1.introduction: IKE is only a standard way to dynamically establish > security associations. (same comment about section 3) Right. > - 2.3flooding attacks: arguments about amplification are specious: > the current real world threat is DDoS and the main defense against > it, the ingress filtering (BCPs 38 and 84), i.e., we are either > vulnerable or not vulnerable to both DDoS and RO reflection attacks > (modulo the use of "real" alternate care-of addresses). So I consider > the 2.3 section as delibarately incomplete. Francis, I added a sub-section 1.1, "A Note on Source Address Filtering", to the introduction that attends to the ongoing discussion about whether or not ingress filtering is a suitable replacement for care-of-address tests. The estimate of many folks, that it is not, has shaped the design of Mobile IPv6, and it was a basis for this document, too. But you are right that one should render the assumption clearer, and justify it, within this document. I think that the new sub-section accomplishes this. Its signification is the same as section 1.1.1 in draft-ietf-mip6-ro-sec-02, which Gabriel added for similar reasons. I also added draft-dupont-mipv6-3bombing-01 to the references. > - 3.1registration procedure: ESP (with non-null encryption and > authentication) support is mandatory for HAs and use is recommended > for mobile nodes. At least the word "optionally" before encrypted is > wrong. Are you positive, Francis? As far as I know, use of ESP encryption is not mandatory for both MN or HA. This is what RFC 3775 says about this: ++++ 5.1. Binding Updates to Home Agents The mobile node and the home agent MUST use an IPsec security association to protect the integrity and authenticity of the Binding Updates and Acknowledgements. Both the mobile nodes and the home agents MUST support and SHOULD use the Encapsulating Security Payload (ESP) [6] header in transport mode and MUST use a non-NULL payload authentication algorithm to provide data origin authentication, connectionless integrity and optional anti-replay protection. Note that Authentication Header (AH) [5] is also possible but for brevity not discussed in this specification. [...] ++++ And RFC 3776 says in the introduction: ++++ The control traffic between the mobile node and the home agent requires message authentication, integrity, correct ordering and anti-replay protection. The mobile node and the home agent must have an IPsec security association to protect this traffic. [...] ++++ I am not quite sure how this relates to what it says in section 4.3, however: ++++ The following requirements apply to both home agents and mobile nodes: [...] Mandatory support for encryption and integrity protection algorithms is as defined in RFC 2401 [2], RFC 2402 [8], and RFC 2406 [3]. [...] ++++ Can you comment on this? > - 3.2goals and assumptions: the discussion about the size of the PKI > is misleading: first the number of certificates is the number of > mobile nodes, not the number of possible home addresses [...] Right, it's done. > nodes, not the number of possible home addresses, second X.509 PKIs > are hierarchical and can handle very large numbers of end entities (I > know examples of PKIs with millions of certificates). The only real > issue is it seems a global PKI is not wanted by people (and not for > security reasons :-) so should not be considered as available in any > time scale. The scalability issue is not so much meant to be a technical one, but is more about acceptance, administrative feasibility, and performance. But, yes, the text might have been a bit imprecise here. So I re-wrote it with your concerns in mind. Here are the new paragraphs from section 3.2: ++++ Public-key cryptography requires some external binding between a public key and the identity this public key is supposed to protect. Certificates issued by a trusted authority can usually do this job, although there is little experience with using home addresses as identifiers in the certificates. (E.g., the home address could be placed into a certificate's Subject AltName field.) Given a certificate that binds a public key to a home address, the owner of this home address can authenticate itself as such by signing some arbitrary piece of data with its private key. Since everybody can verify the signature with the mobile node's public key, this proves, in the end, that the mobile node actually knows the private key complementing the certified public key, and the certificate authority vouches that the public key, in turn, is associated with the home address. The eventual decision to not depend the security of Mobile IPv6 on public-key cryptography was sparked by problems related to scalability, performance, administrative feasibility, and acceptance as explained next. There are differing opinions on whether public-key infrastructures (PKIs) could scale up to hundreds of millions of mobile nodes. Some people argue they do, as there are already examples of PKIs with millions of certificates. But apart from an increase just in the number of certificates, a shift in application patterns can be anticipated as well: Public-key infrastructures (PKI) are nowadays used only for the types of applications that really can't go without the strong protection certificates provide. But as soon as mobility joins the set of applications, not only does the number of nodes using certificates increase, but the new users, the mobile nodes, would also most likely have their certificates checked at a much higher frequency than other nodes use to do for other applications. It is unclear whether PKIs could handle this new workload. Another issue is performance from the user's perspective: Certificate verification takes some time, especially when multiple levels of PKI hierarchies are involved. If this delay happens only at the beginning of a session, most users would probably come to terms with it. If it happens in the middle of a session, or the session is very short-term anyway, it could have a disturbing effect. Moreover, while it is conceivable that mobile users be well-disposed to configuring certificates into their mobile nodes, busy servers functioning as correspondent nodes might not be willing to check the mobile nodes' certificates depending on the service they provide. Besides, it might not be easy to coordinate address assignment with certificate issuing. Typically, the entities responsible for these tasks are not the same. And finally, the bigger a PKI grows, the more attractive it becomes as an attack target, endangering the Internet as a whole. ++++ > - 3.2goals and assumptions: the argument that authentication can not > help against flooding attacks is wrong: authentication can help but > at the condition the care-of address is covered. This is usually not > the case but this is a different argument. Do you think about care-of addresses that mobile nodes own, or reserve, at different networks to where they might roam at some point in the future? Or do you have in mind an extension to SeND through which a remote correspondent node could verify a mobile node's presence at the care-of address? Note that CGAs alone do not solve the issue because the addresses can be configured at any place. I'm not sure if I see your point. Could you please clarify this? > - 3.2goals and assumptions: I reviewed a research paper proposing > certificate-based authorization of care-of addresses so the > discussion about this concluding it is not possible is wrong. Ah, ok. So you mean special care-of addresses, owned by a mobile node, which are verifiable through certificates. Or you allow the mobile node to configure any care-of address---with certain prefixes or without contraints at all---and have some entity vouch for the mobile node's sincerity. Draft-qiu-mip6-certificated-binding-update-03.txt proposes something like this, too. > - 3.2...: the decision about ingress filtering refers to > routing-routability design *only*. The idea that ingress filtering > can't help and care-of address test is necessary is the own opinion > of authors. Ok, see new sub-section 1.1 for this matter. > - 4.2signaling optimizations: bps is not an ISO unit. Should be understandable now. ;) > - 5.1ip-address tests: I suggest to add correspondent-driven tests to > this section, cf draft-dupont-mipv6-rrcookie-00.txt) Agreed. I added this paragraph to section 5.1: ++++ A home-address test can most efficiently be initiated by the mobile node itself, as the correspondent node can thus delay state creation until the mobile node has authenticated. Yet, conceptually, either the mobile node or the correspondent node could start a care-of-address test. RFC 3775 uses mobile-node-initiated IP-address tests, whereas [draft-dupont-mipv6-rrcookie] proposes a way to have the correspondent node send the first message. [draft-ietf-hip-mm] follows this latter approach as well. The correspondent-node-driven approach has advantages when authentication is done through other means than a home-address test. Since RFC 3775 does use the home-address test for authentication, letting the mobile node initiate both IP-address test allows for more efficient parallelization. ++++ > - 5.10: acess -> access Thanks. > I have a real concern about this document: its title is for a WG > document, reflecting a consensus of the WG, when what I can find in > it is mainly the own opinion of authors. Well, this is why we do reviews. ;) I think there are now some substantial changes to the document (see the link at the top of this email). Underlying assumption are more clearly expressed now, additional techniques have been included, and some imprecisenesses have been corrected. With the new "Note on Source Address Filtering" within the Introduction, readers will become aware that there is an ongoing debate about this topic, and that assumptions about it may change as technology evolves. Once again, thanks for the review! Kind regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Francis Dupont wrote: > Here are some notes taken when I received the call for review. I'll > summarize in the list. > > Some comments about draft-irtf-mobopts-ro-enhancements-00.txt: - > abstract: IMHO the goals of improvements/alternatives are in the > wrong order: signaling messages/latency/etc can be improved only > because the security is better. (same about 4.x section order) - > 1.introduction: to put HIP at the same level than Mobile IPv6 and > Mobile IP is a clear bias. - 1.introduction: IKE is only a standard > way to dynamically establish security associations. (same comment > about section 3) - 2.3flooding attacks: arguments about amplification > are specious: the current real world threat is DDoS and the main > defense against it, the ingress filtering (BCPs 38 and 84), i.e., we > are either vulnerable or not vulnerable to both DDoS and RO > reflection attacks (modulo the use of "real" alternate care-of > addresses). So I consider the 2.3 section as delibarately incomplete. > - 3.1registration procedure: ESP (with non-null encryption and > authentication) support is mandatory for HAs and use is recommended > for mobile nodes. At least the word "optionally" before encrypted is > wrong. - 3.2goals and assumptions: the discussion about the size of > the PKI is misleading: first the number of certificates is the number > of mobile nodes, not the number of possible home addresses, second > X.509 PKIs are hierarchical and can handle very large numbers of end > entities (I know examples of PKIs with millions of certificates). The > only real issue is it seems a global PKI is not wanted by people (and > not for security reasons :-) so should not be considered as > available in any time scale. - 3.2goals and assumptions: the argument > that authentication can not help against flooding attacks is wrong: > authentication can help but at the condition the care-of address is > covered. This is usually not the case but this is a different > argument. - 3.2goals and assumptions: I reviewed a research paper > proposing certificate-based authorization of care-of addresses so the > discussion about this concluding it is not possible is wrong. - > 3.2...: the decision about ingress filtering refers to routing-routability > design *only*. The idea that ingress filtering can't help and care-of > address test is necessary is the own opinion of authors. - > 4.2signaling optimizations: bps is not an ISO unit. - 5.1ip-address > tests: I suggest to add correspondent-driven tests to this section, > cf draft-dupont-mipv6-rrcookie-00.txt) - 5.10: acess -> access ... > > I have a real concern about this document: its title is for a WG > document, reflecting a consensus of the WG, when what I can find in > it is mainly the own opinion of authors. > > Regards > > Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From marco.conti@iit.cnr.it Fri May 06 18:48:26 2005 +0200 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA09197; Tue, 10 May 2005 15:27:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4ALu7i24028; Tue, 10 May 2005 14:56:07 -0700 X-mProtect: <200505102156> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpdCqLrai; Tue, 10 May 2005 14:56:00 PDT X-Scanned: Tue, 10 May 2005 15:26:38 -0700 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j4AMQchC012023; Tue, 10 May 2005 15:26:38 -0700 X-pstn-settings: 5 (1.50000:1.50000) p:5 r:4 m:4 c:5 X-pstn-version: pase:2.23 X-pstn-levels: s:78.89138/99.90000 p:95.91080 r:95.91080 m:97.02319 c:98.76780 X-pstn-address: from X-pstn-spam: N Received: from megatron.ietf.org (132.151.6.71) by mailrelay.iprg.nokia.com 006AEyUi; Tue, 10 May 2005 15:26:27 PDT Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVd9m-0004ld-OG; Tue, 10 May 2005 18:24:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU5yj-0000FM-3M for mobopts@megatron.ietf.org; Fri, 06 May 2005 12:47:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08817 for ; Fri, 6 May 2005 12:47:01 -0400 (EDT) Received: from mx1.iit.cnr.it ([146.48.98.40] helo=mx.iit.cnr.it) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU6DD-0001Sk-TV for mobopts@irtf.org; Fri, 06 May 2005 13:02:05 -0400 Received: from localhost (mx.iit.cnr.it [127.0.0.1]) by mx.iit.cnr.it (Postfix) with ESMTP id B7C0B2EE18; Fri, 6 May 2005 18:46:52 +0200 (CEST) Received: from mx.iit.cnr.it ([127.0.0.1]) by localhost (mx.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14157-17; Fri, 6 May 2005 18:46:47 +0200 (CEST) Received: from [146.48.99.123] (dhcp60.iit.cnr.it [146.48.99.123]) by mx.iit.cnr.it (Postfix) with ESMTP id 40AA12EE17; Fri, 6 May 2005 18:46:46 +0200 (CEST) Mime-Version: 1.0 X-Sender: marco.conti@iit.cnr.it@mx.iit.cnr.it Message-Id: Date: Fri, 6 May 2005 18:48:26 +0200 To: mip4@ietf.org, mobopts@irtf.org From: Marco Conti X-Virus-Scanned: by Content Checker at iit.cnr.it X-Spam-Score: 3.2 (+++) X-Scan-Signature: 8eea8f4473ae4de7baa9fae348a439c7 X-Mailman-Approved-At: Tue, 10 May 2005 18:24:48 -0400 Cc: Subject: [Mobopts] IEEE WoWMoM 2005 Advance Program and Call for Participation 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="===============1493161866==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Status: O --===============1493161866== Content-Type: multipart/alternative; boundary="============_-1096724385==_ma============" --============_-1096724385==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable We apologize in advance if you receive multiple copies of this CFP. ---------------------------------------------------------------------- CALL FOR PARTICIPATION WoWMoM 2005 Sixth IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks http://cnd.iit.cnr.it/wowmom2005 Taormina, Italy, June 13-16, 2005 Sponsored by The IEEE Computer Society The University of Texas at Arlington Technical sponsored by IEEE TCCC ************************************************************************** ADVANCE REGISTRATION DEADLINE Early Registration Deadline to avail of special discounted rates: May 15, 20= 05. Please see: http://wukong.uta.edu/cgi-bin/register.cgi ************************************************************************* WoWMoM 2005 MAIN FEATURES *** 15 Technical Sessions *** 2 Keynote Speeches Sensor networks: A hype or real challenge? Adam Wolisz, TU Berlin, Germany Designing Self-Organized Wireless Networks - Is It Possible? Sudhir Dixit, Nokia-NRC, Boston, USA *** 1 Panel "The Future Wireless Network: Revolution vs.=20 Evolution? Will managed cellular networks evolve=20 and survive, or will they be replaced by a fully=20 decentralized ad-hoc/mesh architecture?" *** 1 Poster Session *** 2 Workshops ************************************************************************* WoWMoM 2005 PRELIMINARY PROGRAM Monday - June 13, 2005 8h30 - 18h00: WoWMoM 2005 Workshops Workshop #1: Autonomic Communications and Computing (ACC 2005) http://www.autonomic-communication.org/acc/index.html Workshop #2: Trust, Security and Privacy for Ubiquitous Computing (TSPUC2005= ) http://www.iit.cnr.it/TSPUC2005 ************************************************************************* Tuesday - June 14, 2005 8h30 -8h40: Opening Remarks 8h40-10h20: Session 1: Ad Hoc Networks I Interference-Limited MAC Protocol for MANETs with Directional Antennas Aman Arora and Marwan Krunz (The University of Arizona, USA) An Integrated Neighbor Discovery and MAC Protocol=20 for Ad Hoc Networks Using Directional Antennas Gentian Jakllari, Wenjie Luo, and Srikanth V.=20 Krishnamurthy (University of California at Santa=20 Barbara, USA) Exploiting Path Diversity in the Link Layer in Wireless Ad Hoc Networks Shweta Jain and Samir R Das (State University of New York at Stony Brook, US= A) A Scenario-Based Performance Evaluation of=20 Multicast Routing Protocols for Ad Hoc Networks Manoj Pandey and Daniel Zappala (Brigham Young University, Provo USA) 10h20-10h45: Coffee break 10h45-11h45: Keynote speech Sensor networks: A hype or real challenge? Adam Wolisz, TU Berlin, Germany 12h00-13h00: Sessions 2A - 2B Session 2A: Ad Hoc Networks II An Adaptive Routing Protocol for Ad-Hoc Peer-to-Peer Networks Luca Gatani, Giuseppe Lo Re and Salvatore Gaglio (University of Palermo, Ita= ly) Evaluation of Peer-to-Peer Network Content=20 Discovery Techniques over Mobile Ad Hoc Networks Leonardo B Oliveira, Isabela Siqueira, Daniel F.=20 Macedo, Antonio A. Loureiro, and Hao Chi Wong=20 (Federal University of Minas Gerais, Belo=20 Horizonte, Brazil) Stable, Congestion-Controlled Application-Layer=20 Multicasting in PedestrianAd-Hoc Networks Peter Baumung (University of Karlsruhe, Germany) Session 2B: From 3G to 4G Application Rate Adaptation for Mobile Streaming Igor D. D. Curcio (Nokia Technology Platforms,=20 =46inland) and David Leon (Nokia Research Center,=20 USA) An Agent-Based Architecture for Handover Initiation and Decision in 4G Netwo= rks V. E. Zafeiris and E. A. Giakoumakis (Athens=20 University of Economics and Business, Greece) DIMSUMNet: New Directions in Wireless Networking=20 Using Coordinated Dynamic Spectrum Access Milind M. Buddhikot (Lucent Bell Labs, USA), Paul=20 Kolodzy (Stevens Institute of Technology, USA),=20 Scott Miller (Lucent Bell Labs, USA), Kevin Ryan,=20 and Jason Evans (Stevens Institute of Technology,=20 USA) 13h00 -14h30 Lunch break 14h30-15h30: Poster Session 15h30-16h00: Coffee break 16h00-17h15: Session 3: Systems Evaluation Performance Analysis of the IEEE 802.11 MAC and Physical Layer Protocol Mohammad Hossein Manshaei (INRIA, France), Gion=20 Reto Cantieni (EPFL, Switzerland), Chadi Barakat,=20 and Thierry Turletti (INRIA, France) Saturation Throughput Analysis of a System of Interfering IEEE 802.11 WLANs Manoj K. Panda (Satyam Computer Services Ltd.,=20 India), Anurag Kumar (Indian Institute of=20 Science, Bangalore, India), and S. H. Srinivasan=20 (Satyam Computer Services Ltd., India) What Is Wrong in Multimedia Messaging? Olli-Pekka Pohjola and Kalevi Kilkki (Nokia Research, Helsinki, Finland) *********************************************************************** Wednesday June 15, 2005 8h30-10h10: Session 4: Ad Hoc Networks III Service Discovery in Mobile Ad Hoc Networks: A Field Theoretic Approach Vincent Lenders, Martin May, and Bernhard Plattner (ETH, Switzerland) An Agile Approach to Distributed Information=20 Dissemination in Mobile Ad Hoc Networks Nicholas Bauer, Michael Colagrosso, and Tracy=20 Camp (Colorado School of Mines, USA) Lightweight Replication Middleware for Data and=20 Service Components in Dense MANETs Paolo Bellavista, Antonio Corradi, and Eugenio=20 Magistretti (University of Bologna, Italy) Energy-Efficient Replica Voting Mechanisms for=20 Secure Real-Time Embedded Systems Kevin A. Kwiat (Air Force Research Laboratory,=20 Rome, NY, USA), Kaliappa Ravindran (City=20 University of New York, USA), and Patrick Hurley=20 (Air Force Research Laboratory, Rome, NY, USA) 10h15-11h15: Keynote speech Designing Self-Organized Wireless Networks - Is It Possible? Sudhir Dixit, Nokia-NRC, Boston, USA 11h15-11h45: Coffee break 11h45-13h05: Sessions 5A - 5B Session 5A: Multi-hop Networks Design and Evaluation of iMesh: An Infrastructure-Mode Wireless Mesh Network Vishnu Navda, Anand Kashyap, and Samir R. Das=20 (University of New York at Stony Brook, USA) High Throughput Routing in Hybrid Cellular and Ad-Hoc Networks Ioannis Ioannidis, Bogdan Carbunar, and Cristina=20 Nita-Rotaru (Purdue University, USA) On the Clustering Properties of Exponential Random Networks Nikhil Karamchandani, D. Manjunath (IIT-Bombay,=20 India), and Srikanth K. Iyer (IIT-Kanpur, India) Adaptive Routing for Intermittently Connected Mobile Ad Hoc Networks Mirco Musolesi, Stephen Hailes, and Cecilia=20 Mascolo (University College London, UK) Session 5B: Wireless Channel Protocols Modeling and Analysis of Robust Header Compression Performance Chia Yuan Cho, Yong Huat Chew, Winston Khoon Guan=20 Seah (Institute for Infocomm Research, Singapore) A Joint Coding at Neighbor Network Layers Evgenii Krouk (St. Petersburg State University of=20 Aerospace Instrumentation, Russia) and Sergei=20 Semenov (Nokia Technology Platforms, Finland) Cross-Layer Design of Dynamic Resource Allocation=20 with Diverse QoS Guarantees for MIMO-OFDM=20 Wireless Networks Jia Tang and Xi Zhang (Texas A&M University, USA) A Generalized Algorithm for the Generation of=20 Correlated Rayleigh Fading Envelopes Le Chung Tran, Tadeusz A. Wysocki (University of=20 Wollongong, Australia), Alfred Mertins=20 (University of Oldenburg, Germany) and Jennifer=20 Seberry (University of Wollongong, Australia) 13h05-14h30: Lunch break 14h30-15h45: Session 6: 802.11 Temporal Fairness Provisioning in Multi-Rate Contention-Based 802.11e WLANs Ilenia Tinnirello (University of Palermo, Italy)=20 and Sunghyun Choi (Seoul National University,=20 Korea) The Wireless Hierarchical Token Bucket: A Channel Aware Scheduler for 802.11 Networks Rosario G. Garroppo, Stefano Giordano, Stefano=20 Lucetti, and Edoardo Valori (University of Pisa,=20 Italy) Revisit of RTS/CTS Exchange in High-Speed IEEE 802.11 Networks Ilenia Tinnirello (University of Palermo, Italy),=20 Sunghyun Choi, and Youngsoo Kim (Seoul National=20 University, Korea) 15h45-16h15: Coffee break 16h15-17h35: Sessions 7A - 7B Session 7A: Applications & Services Adaptive Resource Management for Multimedia Applications in Wireless Network= s Nilanjan Banerjee, Kalyan Basu, and Sajal K. Das=20 (The University of Texas at Arlington, USA) Personalized Service Composition for Ubiquitous Multimedia Delivery Swaroop Kalasapur, Mohan Kumar, and Behrooz=20 Shirazi (The University of Texas at Arlington,=20 USA) Supporting Semantic-Based Multimedia Data Access in Ad Hoc Networks Bo Yang and Ali R. Hurson (The Pennsylvania State University, USA) A System Structure for Adaptive Mobile Applications Vincenzo De Florio and Chris Blondia (University of Antwerp, Belgium) Session 7B: MAC Protocols A High-Throughput MAC Strategy for Next-Generation WLANs Seongkwan Kim, Youngsoo Kim, Sunghyun Choi (Seoul=20 National University, Korea), Kyunghun Jang, and=20 Jin-Bong Chang (Samsung Advanced Institute of=20 Technology, Korea) PARMA: A PHY/MAC Aware Routing Metric for Ad-Hoc=20 Wireless Networks with Multi-Rate Radios Suli Zhao, Zhibin Wu (WINLAB, Rutgers University,=20 USA), Arup Acharya (IBM Research, USA) and=20 Dipankar Raychaudhuri (WINLAB, Rutgers=20 University, USA), Ad-Hoc Extensions to the 802.15.3 MAC Protocol Samir Datta, Ivan Seskar (WINLAB, Rutgers=20 University, USA), Mustafa Demirhan (Intel Corp.,=20 USA), Siun-Chuon Mau, and Dipankar Raychaudhuri=20 (WINLAB, Rutgers University, USA) Packet Delay Distribution of the IEEE 802.11 Distributed Coordination Functi= on P. Raptis, V. Vitsas (Technological Educational=20 Institution, Thessaloniki, Greece), K, K.=20 Paparrizos (University of Macedonia,=20 Thessaloniki, Greece), P. Chatzimisios, and A. C.=20 Boucouvalas (Bournemouth University, UK) 20h00: Social Dinner ********************************************************** Thursday June 16, 2005 9h00-10h20: Sessions 8A - 8B Session 8A: Energy Management Energy-Aware Routing in Wireless Ad-Hoc Networks Panagiotis C. Kokkinos, Christos A. Papageorgiou=20 and Emmanouel A. Varvarigos (University of=20 Patras, Greece) On Maximizing Lifetime of a Sensor Cluster Samar Agnihotri and Pavan Nuggehalli, and H.=20 Jamadagni (Indian Institute of Science, India) On Topology Control of Wireless Peer-to-Peer File=20 Sharing Networks: Energy Efficiency, Fairness and=20 Incentive Andrew Ka-Ho Leung, and Yu-Kwong Kwok (The University of Hong Kong) Game Theoretic Power Aware Wireless Data Access Mark Kai-Ho Yeung and Yu-Kwong Kwok (The University of Hong Kong) Session 8B: Quality of Service =46ast IP Handoff Support for VoIP and Multimedia Applications in 802.11 WLA= Ns Ioanna Samprakou (Atmel Hellas S.A., Greece),=20 Christos Bouras (University of Patras, Greece),=20 and Theodore Karoubalis (Atmel Hellas S.A.,=20 Greece) Exploiting MAC Flexibility in WiMAX for Media Streaming Shamik Sengupta, Mainak Chatterjee (University of=20 Central Florida, USA), Samrat Ganguly, and Rauf=20 Izmailov (NEC Labs, USA) Dynamic QoS Negotiation and Adaptation for Networked Virtual Reality Service= s Lea Skorin-Kapov (Ericsson, Croatia) and Maja=20 Matijasevic (University of Zagreb, Croatia) 10h20-10h50: Coffee break 10h50-12h10: Sessions 9A - 9B Session 9A: Ad Hoc Networks IV Hello Protocols for Wireless Ad-Hoc Networks: Overhead and Accuracy Tradeoff= s Venkata C. Giruka and Mukesh Singhal (University of Kentucky, USA) A Generic Algorithm to Improve the Performance of Proactive Ad Hoc Mechanism= s Mona Ghassemian, Vasilis Friderikos, and A. Hamid=20 Aghvami (King's College London, UK) Comparisons of Inter-Domain Routing Schemes for Heterogeneous Ad Hoc Network= s Wenbin Ma and Mooi Choo Chuah (University Bethlehem, USA) Real-Time Intrusion Detection for Ad Hoc Networks Ioanna Stamouli, Patroklos G. Argyroudis, and=20 Hitesh Tewari (University of Dublin, Ireland) Session 9B: Location Mechanisms & Services A Friis-Based Calibrated Model for WiFi Terminals Positioning =46r=E9d=E9ric Lassabe, Philippe Canalda, Pascal=20 Chatonnay, Fran=E7ois Spies (Universit=E9 de=20 =46ranche-Comt=E9, France), and Oumaya. Baala=20 (Universit=E9 de Technologie de=20 Belfort-Montb=E9liard, France) Precise Distributed Localization Algorithms for Wireless Networks Saad Biaz and Yiming Ji (Auburn University, USA) A Hidden Environment Model for Constructing Indoor Radio Maps Zhe Xiang, Hangjin Zhang, Jian Huang, Song Song=20 (IBM China Research Lab., China), and Kevin C.=20 Almeroth (University of California, USA) Mobile Terminal Location Discovery Schemes for a=20 'Beyond 3G' Inter-Worked Network Daniel Morris, Paul Pangalos, and Hamid Aghvami (Kings College London, UK) 12h15-13h45: Lunch break 13h45-14h45 Panel "The Future Wireless Network: Revolution vs.=20 Evolution? Will managed cellular networks evolve=20 and survive, or will they be replaced by a fully=20 decentralized ad-hoc/mesh architecture?" Panel Organizer: Dipankar Raychaudhuri (WINLAB, Rutgers Univ, , USA) 15h00-16h40: Session 10: Power Control and Power Management =46lexible Power Modeling for Wireless Systems:=20 Power Modeling and Optimization of two Bluetooth=20 Implementations Luca Negri, Mariagiovanna Sami (Politecnico di=20 Milano, Italy), Que Dung Tran, and Davide Zanetti=20 (USI, Switzerland) Power Control is not Required for Wireless Networks in the Linear Regime Bozidar Radunovic and Jean-Yves Le Boudec (EPFL, Switzerland) Integrated Power Control and Rate Allocation for=20 Radio Resource Management in Uplink Wideband CDMA=20 Systems Lian Zhao (Ryerson University, Canada) and Jon W.=20 Mark (University of Waterloo, Canada) A Power Allocation Algorithm for Throughput Maximization in Mobile Networks Enzo Baccarelli, Mauro Biagi, Cristian Pelizzoni,=20 Nicola Cordeschi, and Fabio Garzia (University of=20 Rome "La Sapienza", Italy) 16h45: Closing session & Refreshments -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Marco Conti Technical Program Co-chair IEEE Symposium on a World of Wireless, Mobile and=20 Multimedia Networks (WoWMoM 2005) -=20 http://cnd.iit.cnr.it/wowmom2005 Institute for Informatics and Telematics (IIT) National Research Council (CNR) Via G. Moruzzi, 1 56124 Pisa,Italy tel.: + 39 050 315 3062 (direct) mobile: +39 348 3966807 fax.: +39 050 3152593 --============_-1096724385==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IEEE WoWMoM 2005 Advance Program and Call for Participatio

We apologize in advance if you receive multiple copies of this CFP.
----------------------------------------------------------------------


CALL FOR PARTICIPATION

WoWMoM 2005
Sixth IEEE International Symposium on a World of Wireless,
Mobile and Multimedia Networks

http://cnd.iit.cnr.it/wowmom2005
Taormina, Italy, June 13-16, 2005

Sponsored by
The IEEE Computer Society
The University of Texas at Arlington
Technical sponsored by IEEE TCCC

    
**************************************************************************
ADVANCE REGISTRATION DEADLINE

Early Registration Deadline to avail of special discounted rates: May 15, 2005.
Please see: http://wukong.uta.edu/cgi-bin/register.cgi 
*************************************************************************

WoWMoM 2005 MAIN FEATURES

*** 15 Technical Sessions

*** 2 Keynote Speeches

Sensor networks: A hype or real challenge?
Adam Wolisz, TU Berlin, Germany

Designing Self-Organized Wireless Networks - Is It Possible?
Sudhir Dixit, Nokia-NRC, Boston, USA


*** 1 Panel

"The Future Wireless Network: Revolution vs. Evolution? Will managed cellular networks  evolve and survive, or will they be replaced by a fully decentralized ad-hoc/mesh architecture?"

*** 1 Poster Session

*** 2 Workshops

*************************************************************************

WoWMoM 2005 PRELIMINARY PROGRAM


Monday - June 13, 2005


8h30 - 18h00: WoWMoM 2005 Workshops

Workshop #1: Autonomic Communications and Computing (ACC 2005)
http://www.autonomic-communication.org/acc/index.html

Workshop #2: Trust, Security and Privacy for Ubiquitous Computing (TSPUC2005)
http://www.iit.cnr.it/TSPUC2005

*************************************************************************



Tuesday - June 14, 2005

8h30 -8h40: Opening Remarks

8h40-10h20: Session 1: Ad Hoc Networks I
Interference-Limited MAC Protocol for MANETs with Directional Antennas
Aman Arora and Marwan Krunz (The University of Arizona, USA)

An Integrated Neighbor Discovery and MAC Protocol for Ad Hoc Networks Using Directional Antennas
Gentian Jakllari, Wenjie Luo, and Srikanth V. Krishnamurthy (University of California at Santa Barbara, USA)

Exploiting Path Diversity in the Link Layer in Wireless Ad Hoc Networks
Shweta Jain and Samir R Das (State University of New York at Stony Brook, USA)

A Scenario-Based Performance Evaluation of Multicast Routing Protocols for Ad Hoc Networks
Manoj Pandey and Daniel Zappala (Brigham Young University, Provo USA)


10h20-10h45: Coffee break


10h45-11h45: Keynote speech

Sensor networks: A hype or real challenge?
Adam Wolisz, TU Berlin, Germany


12h00-13h00: Sessions 2A - 2B

Session 2A: Ad Hoc Networks II
An Adaptive Routing Protocol for Ad-Hoc Peer-to-Peer Networks
Luca Gatani, Giuseppe Lo Re and Salvatore Gaglio (University of Palermo, Italy)

Evaluation of Peer-to-Peer Network Content Discovery Techniques over Mobile Ad Hoc Networks
Leonardo B Oliveira, Isabela Siqueira, Daniel F. Macedo, Antonio A. Loureiro, and Hao Chi Wong (Federal University of Minas Gerais, Belo Horizonte, Brazil)

Stable, Congestion-Controlled Application-Layer Multicasting in PedestrianAd-Hoc Networks
Peter Baumung (University of Karlsruhe, Germany)


Session 2B: From 3G to 4G
Application Rate Adaptation for Mobile Streaming
Igor D. D. Curcio (Nokia Technology Platforms, Finland) and David Leon (Nokia Research Center, USA)

An Agent-Based Architecture for Handover Initiation and Decision in 4G Networks
V. E. Zafeiris and E. A. Giakoumakis (Athens University of Economics and Business, Greece)

DIMSUMNet: New Directions in Wireless Networking Using Coordinated Dynamic Spectrum Access
Milind M. Buddhikot (Lucent Bell Labs, USA), Paul Kolodzy (Stevens Institute of Technology, USA), Scott Miller (Lucent Bell Labs, USA), Kevin Ryan, and Jason Evans (Stevens Institute of Technology, USA)


13h00 -14h30 Lunch break

14h30-15h30: Poster Session


15h30-16h00: Coffee break


16h00-17h15: Session 3: Systems Evaluation
Performance Analysis of the IEEE 802.11 MAC and Physical Layer Protocol
Mohammad Hossein Manshaei (INRIA, France), Gion Reto Cantieni (EPFL, Switzerland), Chadi Barakat, and Thierry Turletti (INRIA, =46rance)

Saturation Throughput Analysis of a System of Interfering IEEE 802.11 WLANs
Manoj K. Panda (Satyam Computer Services Ltd., India), Anurag Kumar (Indian Institute of Science, Bangalore, India), and S. H. Srinivasan (Satyam Computer Services Ltd., India)

What Is Wrong in Multimedia Messaging?
Olli-Pekka Pohjola and Kalevi Kilkki (Nokia Research, Helsinki, =46inland)


***********************************************************************




Wednesday June 15, 2005


8h30-10h10: Session 4: Ad Hoc Networks III
Service Discovery in Mobile Ad Hoc Networks: A Field Theoretic Approach
Vincent Lenders, Martin May, and Bernhard Plattner (ETH, Switzerland)

An Agile Approach to Distributed Information Dissemination in Mobile Ad Hoc Networks
Nicholas Bauer, Michael Colagrosso, and Tracy Camp (Colorado School of Mines, USA)

Lightweight Replication Middleware for Data and Service Components in Dense MANETs
Paolo Bellavista, Antonio Corradi, and Eugenio Magistretti (University of Bologna, Italy)

Energy-Efficient Replica Voting Mechanisms for Secure Real-Time Embedded Systems
Kevin A. Kwiat (Air Force Research Laboratory, Rome, NY, USA), Kaliappa Ravindran (City University of New York, USA), and Patrick Hurley (Air Force Research Laboratory, Rome, NY, USA)


10h15-11h15: Keynote speech

Designing Self-Organized Wireless Networks - Is It Possible?
Sudhir Dixit, Nokia-NRC, Boston, USA


11h15-11h45: Coffee break


11h45-13h05: Sessions 5A - 5B


Session 5A: Multi-hop Networks
Design and Evaluation of iMesh: An Infrastructure-Mode Wireless Mesh Network
Vishnu Navda, Anand Kashyap, and Samir R. Das (University of New York at Stony Brook, USA)

High Throughput Routing in Hybrid Cellular and Ad-Hoc Networks
Ioannis Ioannidis, Bogdan Carbunar, and Cristina Nita-Rotaru (Purdue University, USA)

On the Clustering Properties of Exponential Random Networks
Nikhil Karamchandani, D. Manjunath (IIT-Bombay, India), and Srikanth K. Iyer (IIT-Kanpur, India)

Adaptive Routing for Intermittently Connected Mobile Ad Hoc Networks
Mirco Musolesi, Stephen Hailes, and Cecilia Mascolo (University College London, UK)


Session 5B: Wireless Channel Protocols
Modeling and Analysis of Robust Header Compression Performance
Chia Yuan Cho, Yong Huat Chew, Winston Khoon Guan Seah (Institute for Infocomm Research, Singapore)

A Joint Coding at Neighbor Network Layers
Evgenii Krouk (St. Petersburg State University of Aerospace Instrumentation, Russia) and Sergei Semenov (Nokia Technology Platforms, Finland)

Cross-Layer Design of Dynamic Resource Allocation with Diverse QoS Guarantees for MIMO-OFDM Wireless Networks
Jia Tang and Xi Zhang (Texas A&M University, USA)

A Generalized Algorithm for the Generation of Correlated Rayleigh Fading Envelopes
Le Chung Tran, Tadeusz A. Wysocki (University of Wollongong, Australia), Alfred Mertins (University of Oldenburg, Germany) and Jennifer Seberry (University of Wollongong, Australia)


13h05-14h30: Lunch break


14h30-15h45: Session 6: 802.11

Temporal Fairness Provisioning in Multi-Rate Contention-Based 802.11e WLANs
Ilenia Tinnirello (University of Palermo, Italy) and Sunghyun Choi (Seoul National University,  Korea)

The Wireless Hierarchical Token Bucket: A Channel Aware Scheduler
 for 802.11 Networks
Rosario G. Garroppo, Stefano Giordano, Stefano Lucetti, and Edoardo Valori (University of Pisa, Italy)

Revisit of RTS/CTS Exchange in High-Speed IEEE 802.11 Networks
Ilenia Tinnirello (University of Palermo, Italy), Sunghyun Choi, and Youngsoo Kim (Seoul National University, Korea)


15h45-16h15: Coffee break


16h15-17h35: Sessions 7A - 7B


Session 7A: Applications & Services
Adaptive Resource Management for Multimedia Applications in Wireless Networks
Nilanjan Banerjee, Kalyan Basu, and Sajal K. Das (The University of Texas at Arlington, USA)

Personalized Service Composition for Ubiquitous Multimedia Delivery
Swaroop Kalasapur, Mohan Kumar, and Behrooz Shirazi (The University of Texas at Arlington, USA)

Supporting Semantic-Based Multimedia Data Access in Ad Hoc Networks
Bo Yang and Ali R. Hurson (The Pennsylvania State University, USA)

A System Structure for Adaptive Mobile Applications
Vincenzo De Florio and Chris Blondia (University of Antwerp, Belgium)


Session 7B: MAC Protocols
A High-Throughput MAC Strategy for Next-Generation WLANs
Seongkwan Kim, Youngsoo Kim, Sunghyun Choi (Seoul National University, Korea), Kyunghun Jang, and Jin-Bong Chang (Samsung Advanced Institute of Technology, Korea)

PARMA: A PHY/MAC Aware Routing Metric for Ad-Hoc Wireless Networks with Multi-Rate Radios
Suli Zhao, Zhibin Wu (WINLAB, Rutgers University, USA), Arup Acharya (IBM Research, USA) and Dipankar Raychaudhuri (WINLAB, Rutgers University, USA),

Ad-Hoc Extensions to the 802.15.3 MAC Protocol
Samir Datta, Ivan Seskar (WINLAB, Rutgers University, USA), Mustafa Demirhan (Intel Corp., USA), Siun-Chuon Mau, and Dipankar Raychaudhuri (WINLAB, Rutgers University, USA)

Packet Delay Distribution of the IEEE 802.11 Distributed Coordination =46unction
P. Raptis, V. Vitsas (Technological Educational Institution, Thessaloniki, Greece), K, K. Paparrizos (University of Macedonia, Thessaloniki, Greece), P. Chatzimisios, and A. C. Boucouvalas (Bournemouth University, UK)



20h00: Social Dinner
**********************************************************





Thursday June 16, 2005


9h00-10h20: Sessions 8A - 8B


Session 8A: Energy Management
Energy-Aware Routing in Wireless Ad-Hoc Networks
Panagiotis C. Kokkinos, Christos A. Papageorgiou and Emmanouel A. Varvarigos (University of Patras, Greece)

On Maximizing Lifetime of a Sensor Cluster
Samar Agnihotri and Pavan Nuggehalli, and H. Jamadagni (Indian Institute of Science, India)

On Topology Control of Wireless Peer-to-Peer File Sharing Networks: Energy Efficiency, =46airness and Incentive
Andrew Ka-Ho Leung, and Yu-Kwong Kwok (The University of Hong Kong)

Game Theoretic Power Aware Wireless Data Access
Mark Kai-Ho Yeung and Yu-Kwong Kwok (The University of Hong Kong)


Session 8B: Quality of Service

Fast IP Handoff Support for VoIP and Multimedia Applications in 802.11 WLANs
Ioanna Samprakou (Atmel Hellas S.A., Greece), Christos Bouras (University of Patras, Greece), and Theodore Karoubalis (Atmel Hellas S.A., Greece)

Exploiting MAC =46lexibility in WiMAX for Media Streaming
Shamik Sengupta, Mainak Chatterjee (University of Central Florida, USA), Samrat Ganguly, and Rauf Izmailov (NEC Labs, USA)

Dynamic QoS Negotiation and Adaptation for Networked Virtual Reality Services
Lea Skorin-Kapov (Ericsson, Croatia) and Maja Matijasevic (University of Zagreb, Croatia)



10h20-10h50: Coffee break


10h50-12h10: Sessions 9A - 9B

Session 9A: Ad Hoc Networks IV
Hello Protocols for Wireless Ad-Hoc Networks: Overhead and Accuracy Tradeoffs
Venkata C. Giruka and Mukesh Singhal (University of Kentucky, USA)

A Generic Algorithm to Improve the Performance of Proactive Ad Hoc Mechanisms
Mona Ghassemian, Vasilis Friderikos, and A. Hamid Aghvami (King's College London, UK)

Comparisons of Inter-Domain Routing Schemes for Heterogeneous Ad Hoc Networks
Wenbin Ma and Mooi Choo Chuah (University Bethlehem, USA)

Real-Time Intrusion Detection for Ad Hoc Networks
Ioanna Stamouli, Patroklos G. Argyroudis, and Hitesh Tewari (University of Dublin, Ireland)


Session 9B: Location Mechanisms & Services
A Friis-Based Calibrated Model for WiFi Terminals Positioning
Fr=E9d=E9ric Lassabe, Philippe Canalda, Pascal Chatonnay, Fran=E7ois Spies (Universit=E9 de =46ranche-Comt=E9, France), and Oumaya. Baala (Universit=E9 de Technologie de Belfort-Montb=E9liard, France)

Precise Distributed Localization Algorithms for Wireless Networks
Saad Biaz and Yiming Ji (Auburn University, USA)

A Hidden Environment Model for Constructing Indoor Radio Maps
Zhe Xiang, Hangjin Zhang, Jian Huang, Song Song (IBM China Research Lab., China), and Kevin C. Almeroth (University of California, USA)

Mobile Terminal Location Discovery Schemes for a 'Beyond 3G' Inter-Worked Network
Daniel Morris, Paul Pangalos, and Hamid Aghvami (Kings College London, UK)


12h15-13h45: Lunch break


13h45-14h45 Panel 

"The =46uture Wireless Network: Revolution vs. Evolution? Will managed cellular networks  evolve and survive, or will they be replaced by a fully decentralized ad-hoc/mesh architecture?"

Panel Organizer: Dipankar Raychaudhuri (WINLAB, Rutgers Univ, , USA)


15h00-16h40: Session 10: Power Control and Power Management

Flexible Power Modeling for Wireless Systems: Power Modeling and Optimization of two Bluetooth Implementations
Luca Negri, Mariagiovanna Sami (Politecnico di Milano, Italy), Que Dung Tran, and Davide Zanetti (USI, Switzerland)

Power Control is not Required for Wireless Networks in the Linear Regime
Bozidar Radunovic and Jean-Yves Le Boudec (EPFL, Switzerland)

Integrated Power Control and Rate Allocation for Radio Resource Management in Uplink Wideband CDMA Systems
Lian Zhao (Ryerson University, Canada) and Jon W. Mark (University of Waterloo, Canada)

A Power Allocation Algorithm for Throughput Maximization in Mobile Networks
Enzo Baccarelli, Mauro Biagi, Cristian Pelizzoni, Nicola Cordeschi, and =46abio Garzia (University of Rome "La Sapienza", Italy)


16h45: Closing session & Refreshments



--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Marco Conti
Technical Program Co-chair
IEEE Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM 2005) - http://cnd.iit.cnr.it/wowmom2005

Institute for Informatics and Telematics (IIT)
National Research Council (CNR)
Via G. Moruzzi, 1
56124 Pisa,Italy
tel.: + 39 050 315 3062 (direct)
mobile: +39 348 3966807
fax.: +39 050 3152593



--============_-1096724385==_ma============-- --===============1493161866== 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 --===============1493161866==-- From Wassim.Haddad@ericsson.com Fri May 27 09:56:48 2005 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id GAA10728; Fri, 27 May 2005 06:57:20 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4RDPm920566; Fri, 27 May 2005 06:25:48 -0700 X-mProtect: <200505271325> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpdouRnTs; Fri, 27 May 2005 06:25:47 PDT X-Scanned: Fri, 27 May 2005 06:57:03 -0700 Nokia Message Protector V1.3.35 2005042208 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j4RDv3ZU010630; Fri, 27 May 2005 06:57:03 -0700 X-pstn-settings: 5 (1.50000:1.50000) p:5 r:4 m:4 c:5 X-pstn-version: pase:2.23 X-pstn-levels: s:99.90000/99.90000 p:95.91080 r:95.91080 m:97.02319 c:98.76780 X-pstn-address: from X-pstn-spam: N Received: from megatron.ietf.org (132.151.6.71) by mailrelay.iprg.nokia.com 00Y7uab2; Fri, 27 May 2005 06:57:01 PDT Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbfHg-0004E7-2b; Fri, 27 May 2005 09:53:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbfHe-0004Dp-Gc; Fri, 27 May 2005 09:53:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12230; Fri, 27 May 2005 09:53:52 -0400 (EDT) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbfaR-0003cF-37; Fri, 27 May 2005 10:13:21 -0400 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id j4RDsHIW007104; Fri, 27 May 2005 08:54:17 -0500 Received: by eamrcnt751.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 27 May 2005 08:53:40 -0500 Received: from [142.133.116.21] (Nautilus.dyn.lmc.ericsson.se [142.133.116.21]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id K0LKHXJ4; Fri, 27 May 2005 09:53:37 -0400 In-Reply-To: <1B631E11D496D711BB2800065BFCB6A11B7A7084@il02exm13> References: <1B631E11D496D711BB2800065BFCB6A11B7A7084@il02exm13> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7B8E46D8-8C86-4353-B416-D55D8772BB85@ericsson.com> Content-Transfer-Encoding: 7bit From: Wassim Haddad Date: Fri, 27 May 2005 09:56:48 -0400 To: Narayanan Vidya-CVN065 X-Mailer: Apple Mail (2.730) X-Spam-Score: 2.4 (++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, mobopts@irtf.org Subject: [Mobopts] Re: [Mip6] Review Comments and Questions on draft-irtf-mobopts-ro-enhancemen ts-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Status: O Hello Vidya, On 26-May-05, at 11:25 PM, Narayanan Vidya-CVN065 wrote: > 3. One of the situations in which RO can be useful is when the RO > solution allows the MN and CN to continue communication during a > period of HA unavailability (failure, for e.g.). The current RR > solution does not achieve this, due to the necessity for short > lifetimes and hence the need for home address tests via the HA > every so often. It may be worthwhile adding this to the design > goals for the solution. => In OMIPv6, you need to do only *one* HoA test at the beginning. The shared secret, i.e., SKbm, lifetime is set to 24 hours so that you don't need to exchange HoTI/HoT messages during this period. Regards, Wassim H. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From chvogt@tm.uka.de Fri May 27 16:13:42 2005 +0200 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA12147; Fri, 27 May 2005 07:18:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4RDkxq06942; Fri, 27 May 2005 06:46:59 -0700 X-mProtect: <200505271346> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpd6tJmWJ; Fri, 27 May 2005 06:46:57 PDT X-Scanned: Fri, 27 May 2005 07:18:13 -0700 Nokia Message Protector V1.3.35 2005042208 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j4REIDmJ011477; Fri, 27 May 2005 07:18:13 -0700 X-pstn-settings: 5 (1.50000:1.50000) p:5 r:4 m:4 c:5 X-pstn-version: pase:2.23 X-pstn-levels: s:99.90000/99.90000 p:95.91080 r:95.91080 m:97.02319 c:98.76780 X-pstn-address: from X-pstn-spam: N Received: from megatron.ietf.org (132.151.6.71) by mailrelay.iprg.nokia.com 00hwpsJY; Fri, 27 May 2005 07:17:46 PDT Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbfb1-0001Y4-Nf; Fri, 27 May 2005 10:13:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbfb0-0001X7-2K; Fri, 27 May 2005 10:13:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14644; Fri, 27 May 2005 10:13:52 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1+yFIdyZHnznu9Y3Q6u36UBAJc7JOuepK8=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbftn-0004B5-4c; Fri, 27 May 2005 10:33:20 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1Dbfar-0006lE-Rq; Fri, 27 May 2005 16:13:49 +0200 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uni-karlsruhe.de with esmtps id 1Dbfao-00042g-N5; Fri, 27 May 2005 16:13:42 +0200 Message-ID: <42972B16.9000801@tm.uka.de> Date: Fri, 27 May 2005 16:13:42 +0200 From: Christian Vogt User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Wassim Haddad References: <4296CF83.1080000@tm.uka.de> <3B4E49F6-5C00-4F3E-84DF-B8154EDCD697@ericsson.com> In-Reply-To: <3B4E49F6-5C00-4F3E-84DF-B8154EDCD697@ericsson.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -19.6 (-------------------) X-Spam-Status: No X-Spam-Score: 2.4 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: MIP6 , tm-ro2@tm.uka.de, Francis Dupont , Jari Arkko , Basavaraj Patil , MOBOPTS Subject: [Mobopts] Re: [Mip6] Francis' Review of draft-irtf-mobopts-ro-enhancements (was Re: FW: Please review draft-irtf-mobopts-ro-enhancements-00.txt) X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Status: O > => IMHO, you also get lower latency with OMIPv6 alone, in addition to > getting higher security, since you > don't need to do the HoTI/HoT exchange. Hi Wassim, you are right. The path through the HA is longer than the direct one in many, probably most, scenarios. OMIPv6 without CBA reduces the overall latency by the difference between the HoA-test latency and the CoA-test latency. OMIPv6 with CBA reduces it by the maximum of the HoA-test latency and the CoA-test latency. Thanks for correcting this. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Wassim Haddad wrote: > Hello Christian, > > On 27-May-05, at 3:42 AM, Christian Vogt wrote: > >> It seems that there is a common ground to at least not increase the >> latency of standard Mobile IPv6. In >> other words, many of the described proposals have merits in terms of >> reduced latency, even if their >> primary goal is to increase security. (OMIPv6 is a good example. If >> you combine it with Credit-Based >> Authorization, which is what we will do in Mipshop, you get both, >> higher security and lower latency.) > > > => IMHO, you also get lower latency with OMIPv6 alone, in addition to > getting higher security, since you > don't need to do the HoTI/HoT exchange. > > > Regards, > > Wassim H. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From vidya@motorola.com Fri May 27 10:17:30 2005 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA14533; Fri, 27 May 2005 08:19:39 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4REm7i25008; Fri, 27 May 2005 07:48:07 -0700 X-mProtect: <200505271448> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpdKnzWSV; Fri, 27 May 2005 07:48:06 PDT X-Scanned: Fri, 27 May 2005 08:19:27 -0700 Nokia Message Protector V1.3.35 2005042208 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j4RFJRkE013731; Fri, 27 May 2005 08:19:27 -0700 X-pstn-settings: 5 (1.50000:1.50000) p:5 r:4 m:4 c:5 X-pstn-version: pase:2.23 X-pstn-levels: s:99.90000/99.90000 p:95.91080 r:95.91080 m:97.02319 c:98.76780 X-pstn-address: from X-pstn-spam: N Received: from megatron.ietf.org (132.151.6.71) by mailrelay.iprg.nokia.com 001wXszi; Fri, 27 May 2005 08:19:26 PDT Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbgas-0006sU-3x; Fri, 27 May 2005 11:17:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbgap-0006rn-QD for mobopts@megatron.ietf.org; Fri, 27 May 2005 11:17:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20220 for ; Fri, 27 May 2005 11:17:45 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbgtd-0005aB-GQ for mobopts@irtf.org; Fri, 27 May 2005 11:37:14 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (Motorola/Motgate7) with ESMTP id j4RFPZP7025351 for ; Fri, 27 May 2005 08:25:36 -0700 (MST) Received: from il02exm13.corp.mot.com (il02exm13.corp.mot.com [10.0.111.24]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j4RFLjna001861 for ; Fri, 27 May 2005 10:21:45 -0500 (CDT) Received: by il02exm13 with Internet Mail Service (5.5.2657.72) id ; Fri, 27 May 2005 10:17:39 -0500 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A7086@il02exm13> From: Narayanan Vidya-CVN065 To: "'Wassim Haddad'" Date: Fri, 27 May 2005 10:17:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 2.4 (++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: mip6@ietf.org, mobopts@irtf.org Subject: [Mobopts] RE: [Mip6] Review Comments and Questions on draft-irtf-mobopts-ro -enhancemen ts-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Status: O Hi Wassim, Yes, this seems to be the case. I did not see this point brought out in draft-irtf-mobopts-ro-enhancements. It might be good to add some text about this in the draft. Regards, Vidya > -----Original Message----- > From: Wassim Haddad [mailto:Wassim.Haddad@ericsson.com] > Sent: Friday, May 27, 2005 8:57 AM > To: Narayanan Vidya-CVN065 > Cc: mip6@ietf.org; mobopts@irtf.org > Subject: Re: [Mip6] Review Comments and Questions on > draft-irtf-mobopts-ro-enhancemen ts-00.txt > > > Hello Vidya, > > On 26-May-05, at 11:25 PM, Narayanan Vidya-CVN065 wrote: > > > 3. One of the situations in which RO can be useful is when the RO > > solution allows the MN and CN to continue communication during a > > period of HA unavailability (failure, for e.g.). The current RR > > solution does not achieve this, due to the necessity for short > > lifetimes and hence the need for home address tests via the HA > > every so often. It may be worthwhile adding this to the design > > goals for the solution. > > => In OMIPv6, you need to do only *one* HoA test at the beginning. > The shared secret, i.e., SKbm, lifetime is set to 24 hours so that > you don't need to > exchange HoTI/HoT messages during this period. > > > Regards, > > Wassim H. > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From jeanmichel.combes@francetelecom.com Fri May 27 14:30:21 2005 +0200 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id FAA06993; Fri, 27 May 2005 05:31:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4RBxnU02806; Fri, 27 May 2005 04:59:49 -0700 X-mProtect: <200505271159> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpdW6pN5u; Fri, 27 May 2005 04:59:47 PDT X-Scanned: Fri, 27 May 2005 05:31:06 -0700 Nokia Message Protector V1.3.35 2005042208 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j4RCV6TQ007162; Fri, 27 May 2005 05:31:06 -0700 X-pstn-settings: 5 (1.50000:1.50000) p:5 r:4 m:4 c:5 X-pstn-version: pase:2.23 X-pstn-levels: s:99.90000/99.90000 p:95.91080 r:95.91080 m:88.14956 c:98.76780 X-pstn-address: from X-pstn-spam: N Received: from megatron.ietf.org (132.151.6.71) by mailrelay.iprg.nokia.com 00SacIWi; Fri, 27 May 2005 05:31:04 PDT Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbdyy-0002qe-6W; Fri, 27 May 2005 08:30:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbdyu-0002qZ-39 for mobopts@megatron.ietf.org; Fri, 27 May 2005 08:30:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06229 for ; Fri, 27 May 2005 08:30:26 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbeHf-0001b6-W0 for mobopts@irtf.org; Fri, 27 May 2005 08:49:53 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 14:30:21 +0200 Received: from PXPELLAFOL ([10.193.161.117]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 14:30:21 +0200 From: "Jean-Michel COMBES" To: "'James Kempf'" , , "'Brett Pentland'" Subject: RE : [Mobopts] New Draft on Proxy SEND Date: Fri, 27 May 2005 14:30:21 +0200 Organization: France Telecom R&D Message-ID: <041801c562b7$d91a16b0$75a1c10a@rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <07f501c5615b$13a13f60$016115ac@dcml.docomolabsusa.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-OriginalArrivalTime: 27 May 2005 12:30:21.0057 (UTC) FILETIME=[D9161F10:01C562B7] X-Spam-Score: 2.4 (++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Status: O Hi, At first, sorry if my question is a little out of scope of the subject. Does someone has some figures regarding the time to generate CGA addresses and linked security material on devices (eg. on PDA, laptops, ...)? Or a link to a paper on this subject? BTW, I will be interested by your results James :) Best regards. JMC. France Telecom - R&D Division - MAPS/NSS Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16 > -----Original Message----- > From: mobopts-bounces@irtf.org > [mailto:mobopts-bounces@irtf.org] On Behalf Of James Kempf > Sent: Wednesday, May 25, 2005 8:54 PM > To: itijibox-mobopts@yahoo.com; Brett Pentland > Cc: mobopts@irtf.org > Subject: Re: [Mobopts] New Draft on Proxy SEND > > > > Yes, inefficiency over the air (implying fragmentation) is an issue. > > Also, how does performance of signing and verification > operations compare > > with, say, vanilla RSA? > > > > I'm working on getting it implemented, so I can measure it. > > BTW, there are a couple other ring signature algorithms, > including one based > on pairings, but some of those are covered by patents. The > Rivest-Shamir-Tauman algorithm is public domain, so far as I can tell. > > jak > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From vidya@motorola.com Thu May 26 22:25:47 2005 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id UAA18053; Thu, 26 May 2005 20:29:20 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4R2vnG13900; Thu, 26 May 2005 19:57:49 -0700 X-mProtect: <200505270257> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpdXcQ7ML; Thu, 26 May 2005 19:57:46 PDT X-Scanned: Thu, 26 May 2005 20:29:05 -0700 Nokia Message Protector V1.3.35 2005042208 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j4R3T55l020967; Thu, 26 May 2005 20:29:05 -0700 X-pstn-settings: 5 (1.50000:1.50000) p:5 r:4 m:4 c:5 X-pstn-version: pase:2.23 X-pstn-levels: s:99.90000/99.90000 p:95.91080 r:95.91080 m:97.02319 c:98.76780 X-pstn-address: from X-pstn-spam: N Received: from megatron.ietf.org (132.151.6.71) by mailrelay.iprg.nokia.com 002nBuq6; Thu, 26 May 2005 20:29:03 PDT Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbVTw-00014Z-PR; Thu, 26 May 2005 23:25:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbVTv-00014P-J4 for mobopts@megatron.ietf.org; Thu, 26 May 2005 23:25:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09778 for ; Thu, 26 May 2005 23:25:52 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbVmd-0006yf-KQ for mobopts@irtf.org; Thu, 26 May 2005 23:45:16 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j4R3aLCD002248 for ; Thu, 26 May 2005 20:36:21 -0700 (MST) Received: from il02exm13.corp.mot.com (il02exm13.corp.mot.com [10.0.111.24]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j4R3SUtJ015701 for ; Thu, 26 May 2005 22:28:30 -0500 (CDT) Received: by il02exm13 with Internet Mail Service (5.5.2657.72) id ; Thu, 26 May 2005 22:25:50 -0500 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A7084@il02exm13> From: Narayanan Vidya-CVN065 To: mip6@ietf.org, mobopts@irtf.org Date: Thu, 26 May 2005 22:25:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 4.2 (++++) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Subject: [Mobopts] Review Comments and Questions on draft-irtf-mobopts-ro-enhancemen ts-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1941769898==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1941769898== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5626B.C5E6D54C" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5626B.C5E6D54C Content-Type: text/plain Here are some comments and questions I have from reviewing the draft. Thanks, Vidya 1. The draft provides a good, comprehensive overview of the security aspects of RO and the solution space in general. However, given that there is already a draft on RO security, perhaps the security aspects should be integrated with that draft and this draft should attempt to cover the solution space alone? 2. Need for "fast" RO - The draft mentions in a few places (including section 4) that one of the objectives for RO is latency optimization. I belong to the group that is yet to be convinced that there is a real need for "fast" RO. In my mind, there is a need for fast handoffs, but not necessarily fast RO. I don't think that RO is going to satisfy the latency requirements of real-time applications. Link layer mechanisms are defining methods to reduce the handoff latency to less than 100ms or so. Such enhancements are useful during inter-subnet handoffs only if the network layer latency can be reduced to adding very marginal latency on top of that. Do we really think RO is going to buy us that? Given that any design for RO cannot control the relative positions of the CN and the MN, it doesn't seem like any RO solution can claim that. The need for such applications really drives us towards FMIP-like approaches. I still think RO can be useful - when long periods of traffic exchange happens between an MN and CN, it may be better to get away from triangular routing. I noticed that James brought up the point of almost ubiquitous wireline bandwidth perhaps eliminating the need for RO. While that is a very valid argument against the real need for RO, I think it will still be good to design the support for RO, before widespread deployment of CNs that don't support it. I am only questioning the need for latency reduction as a design objective for an RO solution. 3. One of the situations in which RO can be useful is when the RO solution allows the MN and CN to continue communication during a period of HA unavailability (failure, for e.g.). The current RR solution does not achieve this, due to the necessity for short lifetimes and hence the need for home address tests via the HA every so often. It may be worthwhile adding this to the design goals for the solution. 4. Section 3.3 (last paragraph) mentions the fact that the current RR solution trades off protection against attacks on CN's processing capacity for protection against CN's memory. Perhaps an RO solution can be flexible enough to allow the CN to determine what trade off makes sense in a particular case? 5. Section 6.2.1 talks about HMIP and FMIP-like proposals. I am not sure I understand how such proposals can replace RO. For e.g., the use of FMIP will remove stringent latency requirements on RO, but not provide a solution for RO itself, right? ------_=_NextPart_001_01C5626B.C5E6D54C Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0OTgiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48IS0tIENvbnZlcnRlZCBmcm9tIHRleHQvcGxhaW4gZm9y bWF0IC0tPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkhlcmUgYXJlIA0Kc29tZSBjb21tZW50cyBh bmQgcXVlc3Rpb25zIEkgaGF2ZSBmcm9tIHJldmlld2luZyB0aGUgZHJhZnQuIDwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5UaGFua3MsPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPUFyaWFsIHNpemU9Mj5WaWR5YTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNp emU9Mj4xLiBUaGUgZHJhZnQgcHJvdmlkZXMgYSBnb29kLCBjb21wcmVoZW5zaXZlIA0Kb3ZlcnZp ZXcgb2YgdGhlIHNlY3VyaXR5IGFzcGVjdHMgb2YgUk8gYW5kIHRoZSBzb2x1dGlvbiBzcGFjZSBp biBnZW5lcmFsLiANCkhvd2V2ZXIsIGdpdmVuIHRoYXQgdGhlcmUgaXMgYWxyZWFkeSBhIGRyYWZ0 IG9uIFJPIHNlY3VyaXR5LCBwZXJoYXBzIHRoZSANCnNlY3VyaXR5IGFzcGVjdHMgc2hvdWxkIGJl IGludGVncmF0ZWQgd2l0aCB0aGF0IGRyYWZ0IGFuZCB0aGlzIGRyYWZ0IHNob3VsZCANCmF0dGVt cHQgdG8gY292ZXIgdGhlIHNvbHV0aW9uIHNwYWNlIGFsb25lPyA8L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+Mi4gTmVlZCBmb3IgImZhc3QiIFJPIC0gVGhlIGRyYWZ0IG1lbnRp b25zIGluIGEgZmV3IA0KcGxhY2VzIChpbmNsdWRpbmcgc2VjdGlvbiA0KSB0aGF0IG9uZSBvZiB0 aGUgb2JqZWN0aXZlcyBmb3IgUk8gaXMgbGF0ZW5jeSANCm9wdGltaXphdGlvbi4gPC9GT05UPjxG T05UIGZhY2U9QXJpYWwgc2l6ZT0yPkkgYmVsb25nIHRvIHRoZSBncm91cCB0aGF0IGlzIHlldCAN CnRvIGJlIGNvbnZpbmNlZCB0aGF0IHRoZXJlIGlzIGEgcmVhbCBuZWVkIGZvciAiZmFzdCIgUk8u IEluIG15IG1pbmQsIHRoZXJlIGlzIGEgDQpuZWVkIGZvciBmYXN0IGhhbmRvZmZzLCBidXQgbm90 IG5lY2Vzc2FyaWx5IGZhc3QgUk8uIEkgZG9uJ3QgdGhpbmsgdGhhdCBSTyBpcyANCmdvaW5nIHRv IHNhdGlzZnkgdGhlIGxhdGVuY3kgcmVxdWlyZW1lbnRzIG9mIHJlYWwtdGltZSBhcHBsaWNhdGlv bnMuIExpbmsgbGF5ZXIgDQptZWNoYW5pc21zIGFyZSBkZWZpbmluZyBtZXRob2RzIHRvIHJlZHVj ZSB0aGUgaGFuZG9mZiBsYXRlbmN5IHRvIGxlc3MgdGhhbiAxMDBtcyANCm9yIHNvLiBTdWNoIGVu aGFuY2VtZW50cyBhcmUgdXNlZnVsIGR1cmluZyBpbnRlci1zdWJuZXQgaGFuZG9mZnMgb25seSBp ZiB0aGUgDQpuZXR3b3JrIGxheWVyIGxhdGVuY3kgY2FuIGJlIHJlZHVjZWQgdG8gYWRkaW5nIHZl cnkgbWFyZ2luYWwgbGF0ZW5jeSBvbiB0b3Agb2YgDQp0aGF0LiBEbyB3ZSByZWFsbHkgdGhpbmsg Uk8gaXMgZ29pbmcgdG8gYnV5IHVzIHRoYXQ/IEdpdmVuIHRoYXQgYW55IGRlc2lnbiBmb3IgDQpS TyBjYW5ub3QgY29udHJvbCB0aGUgcmVsYXRpdmUgcG9zaXRpb25zIG9mIHRoZSBDTiBhbmQgdGhl IE1OLCBpdCBkb2Vzbid0IHNlZW0gDQpsaWtlIGFueSBSTyBzb2x1dGlvbiBjYW4gY2xhaW0gdGhh dC4gVGhlIG5lZWQgZm9yIHN1Y2ggYXBwbGljYXRpb25zIHJlYWxseSANCmRyaXZlcyB1cyB0b3dh cmRzIEZNSVAtbGlrZSBhcHByb2FjaGVzLiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBz aXplPTI+SSBzdGlsbCB0aGluayBSTyBjYW4gYmUgdXNlZnVsIC0gd2hlbiBsb25nIHBlcmlvZHMg DQpvZiB0cmFmZmljIGV4Y2hhbmdlIGhhcHBlbnMgYmV0d2VlbiBhbiBNTiBhbmQgQ04sIGl0IG1h eSBiZSBiZXR0ZXIgdG8gZ2V0IGF3YXkgDQpmcm9tIHRyaWFuZ3VsYXIgcm91dGluZy4gSSBub3Rp Y2VkIHRoYXQgSmFtZXMgYnJvdWdodCB1cCB0aGUgcG9pbnQgb2YgYWxtb3N0IA0KdWJpcXVpdG91 cyB3aXJlbGluZSBiYW5kd2lkdGggcGVyaGFwcyBlbGltaW5hdGluZyB0aGUgbmVlZCBmb3IgUk8u Jm5ic3A7V2hpbGUgDQp0aGF0Jm5ic3A7aXMgYSB2ZXJ5IHZhbGlkIGFyZ3VtZW50IGFnYWluc3Qg dGhlIHJlYWwgbmVlZCBmb3IgUk8sIEkgdGhpbmsgaXQgd2lsbCANCnN0aWxsIGJlIGdvb2QgdG8g ZGVzaWduIHRoZSBzdXBwb3J0IGZvciBSTywgYmVmb3JlIHdpZGVzcHJlYWQgZGVwbG95bWVudCBv ZiBDTnMgDQp0aGF0IGRvbid0IHN1cHBvcnQgaXQuIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj5JIGFtIG9ubHkgcXVlc3Rpb25pbmcgdGhlIG5lZWQgZm9yIGxhdGVuY3kgDQpy ZWR1Y3Rpb24gYXMgYSBkZXNpZ24gb2JqZWN0aXZlIGZvciBhbiBSTyBzb2x1dGlvbi4gPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjMuIE9uZSBvZiB0aGUgc2l0dWF0aW9ucyBp biB3aGljaCBSTyBjYW4gYmUgdXNlZnVsIA0KaXMgd2hlbiB0aGUgUk8gc29sdXRpb24gYWxsb3dz IHRoZSBNTiBhbmQgQ04gdG8gY29udGludWUgY29tbXVuaWNhdGlvbiBkdXJpbmcgYSANCnBlcmlv ZCBvZiBIQSB1bmF2YWlsYWJpbGl0eSAoZmFpbHVyZSwgZm9yIGUuZy4pLiBUaGUgY3VycmVudCBS UiBzb2x1dGlvbiBkb2VzIA0Kbm90IGFjaGlldmUgdGhpcywgZHVlIHRvIHRoZSBuZWNlc3NpdHkg Zm9yIHNob3J0IGxpZmV0aW1lcyBhbmQgaGVuY2UgdGhlIG5lZWQgDQpmb3IgaG9tZSBhZGRyZXNz IHRlc3RzIHZpYSB0aGUgSEEgZXZlcnkgc28gb2Z0ZW4uIEl0IG1heSBiZSB3b3J0aHdoaWxlIGFk ZGluZyANCnRoaXMgdG8gdGhlIGRlc2lnbiBnb2FscyBmb3IgdGhlIHNvbHV0aW9uLiA8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+NC4gU2VjdGlvbiAzLjMgKGxhc3QgcGFyYWdy YXBoKSBtZW50aW9ucyB0aGUgZmFjdCANCnRoYXQgdGhlIGN1cnJlbnQgUlIgc29sdXRpb24gdHJh ZGVzIG9mZiBwcm90ZWN0aW9uIGFnYWluc3QgYXR0YWNrcyBvbiBDTidzIA0KcHJvY2Vzc2luZyBj YXBhY2l0eSBmb3IgcHJvdGVjdGlvbiBhZ2FpbnN0IENOJ3MgbWVtb3J5LiBQZXJoYXBzIGFuIFJP IHNvbHV0aW9uIA0KY2FuIGJlIGZsZXhpYmxlIGVub3VnaCB0byBhbGxvdyB0aGUgQ04gdG8gZGV0 ZXJtaW5lIHdoYXQgdHJhZGUgb2ZmIG1ha2VzIHNlbnNlIA0KaW4gYSBwYXJ0aWN1bGFyIGNhc2U/ IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj41LiBTZWN0aW9uIDYuMi4xIHRh bGtzIGFib3V0IEhNSVAgYW5kIEZNSVAtbGlrZSANCnByb3Bvc2Fscy4gSSBhbSBub3Qgc3VyZSBJ IHVuZGVyc3RhbmQgaG93IHN1Y2ggcHJvcG9zYWxzIGNhbiByZXBsYWNlIFJPLiBGb3IgDQplLmcu LCB0aGUgdXNlIG9mIEZNSVAgd2lsbCByZW1vdmUgc3RyaW5nZW50IGxhdGVuY3kgcmVxdWlyZW1l bnRzIG9uIFJPLCBidXQgbm90IA0KcHJvdmlkZSBhIHNvbHV0aW9uIGZvciBSTyBpdHNlbGYsIHJp Z2h0PyA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4m bmJzcDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01C5626B.C5E6D54C-- --===============1941769898== 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 --===============1941769898==--